Issue title: Doubts regarding the library
 Issue body: Hi,

We are trying to use this library and would like to know if it will be easy to modify the library to do the following:

1) We run a FORTH script, but only partially.
2) We store the VM in memory.
3) We restore the VM from memory
3) We resume the script at the point we previously finished, using the return stacks, the latest instruction we were running, the latest word, etc, ...

After our tests, it seems that the library resets the stacks each time we execute an script we can not execute partial scripts or limit the amount of instructions we execute each time.

Thanks,

 Comments: 
 Comment 0: Hi Richard, thanks for you quick answer. I detail below what we are trying to achieve.

1) We are using libforth inside another program.
2) We use the features it has to save/load from memory.
3) We work on Linux/Ubuntu.
4) We already noticed that there are issues with the return stack :-(, seems not saved and the VM, when resumed does not take into account it and reads directly the next input script instead of executing first the pending instructions and then move to parsing new text (this is the main feature we are interested in).
5) Our logic does the following:
- Reads an input script
- Loads VM from memory (or creates a new one if none) and executes it.
- We want to limit the number of instructions that are executed each cycle, so after N instructions, we save everything and resume later. Here is where it is important to save correctly the return stack and then when resumed, execute first the pending instructions (taken from return stack) before moving to next text token.
5) There is no problem controlling the number of instructions we execute in each cycle, we can control it adding small tweaks to the code, I think that even we are able to save the return stack just not initializing the RSTK register, the problem we are facing now is at the resume step, the VM should go first to the RSTK and execute any pending call stored in the return stack before moving into the READ instruction.

Hope this helps to understand our issue:
1) We need to save the return stack when VM is saved into memory.
2) We need to continue at the return stack when resumed, and execute any pending instruction before moving ahead to READ (parse more text).

Thanks a lot
Carlos
 Comment 1: I still do not quite understand what you are trying to do. The functions 'forth_save_core_memory' and 'forth_load_core_memory' are just analogues to 'forth_save_core_file' and 'forth_load_core_file', they are for the serialization to disk (for the file functions, or to other mediums for the memory functions),  you shouldn't be calling them inbetween halting and resuming execution for 'N' cycles.  'forth_run' does not reset the return stack between calls, so the logic should be:

      /* Error checking omitted */
      forth_t *f = forth_load_core_file("your.core");
      FILE *my_script = fopen("script.fth", "rb");
      forth_set_file_input(f, script);
      while(true) {
           forth_run(f); /* Modified version of forth_run() to only run for, say 1000 cycles */
           do_some_other_stuff();
      }

The position in the script (a FILE*) and the return stack (held in m[RSTK]) should not change between calls. So do not need modifying.

Or do you mean you need to resume execution at the same point after saving to disk?

The code to exit after a 1000 cycles in the main loop will have to look like this:

      for(;(pc = m[ck(I++)]);) {
           if(cycle_count++ > N) {
                    I--;
                    o->m[INSTRUCTION] = I;
                    goto end;
           }
           /* ... The rest of the interpreter ... */
      }

Does this help? Or have I misunderstood what you are trying to do? It would help if I could see the code? (it would not need to be public).


 Comment 2: Hi Richard.   Just to give you a little more background, Carlos and I are developing a multiplayer space game that teaches players to code using FORTH.   You're welcome to take at our GitHub project here: https://github.com/Darwin-River/Ex-Machinis 

Our goal is to have players develop increasingly complex dictionaries to control fleets of remotely piloted drones on the edges of the solar system.  As such, we need a compact FORTH interpreter that can rapidly cycle between each of the in-game spacecraft as they execute the contents of their own VMs.

We started using your libforth and ran into problems when we tried to pause and return to a VM that was in the middle of executing a user-supplied script.  The problem occurs when we try to switch between paused VMs that are stored in an SQL DB when not being processed by the interpreter.

You suggest above that we consider using a16-bit FORTH interpreter that you’re also developing.  This sounds like it might actually be a better solution since it’s compact and already contains a functioning stack.  

I’m just wondering, before we decide to switch over to embed, what are the primary differences between libforth and embed? Would embed work better with our system of shuffling paused VMs in and out of DB?

Thanks for helping us work through this problem!

Dave

 Comment 3: Hello!

Ok, this makes more sense, it would make a lot more sense to use the embed project, at https://github.com/howerj/embed, for multiple reasons.

1) It's smaller and easier for you to understand, it's also much more like a traditional Forth.
2) If you look at 'libforth', the virtual machine has instructions like 'SYSTEM', which would allow the user
to run arbitrary commands on your server, but that's not the only security issue. The embed project wasn't designed for security either - but given how simple it is, it would be much easier to modify to suite your requirements. If I understand the games architecture many people would submit
commands/scripts via email to an instance of the server which hosts the game, if that's right security is going to be one of your concerns.
3) Users could provide their own images and target the Virtual Machine if they are not happy
with the Forth interpreter it provides. As you can see, the entire program is only 200 LOC, and
could be your games version of https://en.wikipedia.org/wiki/0x10c.

'embed' would work better, but it still needs modifications (although they would be minor). 
1). Remove the 'assert(!(sp & 0x8000) && !(rp & 0x8000))' in the 'embed_forth()' main loop. This won't stop the variable stack (sp) and return stack pointer (rp) from going where they shouldn't but it will stop it from taking down the interpreter.
2). Move and modify the definition of 'forth_t' to the 'embed.h' header:

      typedef struct forth_t { uw_t pc, t, rp, sp, core[CORE/sizeof(uw_t)]; } forth_t;

becomes:

      typedef struct forth_t { uw_t pc, t, rp, sp, core[CORE]; } forth_t;

This (should) prevent the virtual machine from accessing out of bounds memory.

3) You'll want to comment out the 22 VM instruction, which saves to disk (but do not reuse this
instruction!).

4) After the for loop you will need to add a 'goto finished' after your cycle timer has run out.

5) You'll need to make similar modifications to the input/output functions that you made to 'libforth', although there should be only two VM instructions which you need to modify, 'fputc' and 'fgetc', which should be easier.

To run this you will need both the virtual machine, and the provided image, 'eforth.blk', if you want
to add VM instructions the process is more complicated than it would be with 'libforth', and would require a lit bit of an understanding of how to generate new images with the metacompiler in 'meta.fth', which would be the biggest complication. I can help you out with that, but as you know my time is limited at the moment due to a new job/move (I'll have more free time in a couple of weeks!).

If you do want to continue using 'libforth', I can make some more recommendations, it does not look like you have added the code that I suggested though? Did it work or not?

Thanks,
Richard Howe
 Comment 4: Hi Carlos,

Yes it would be possible, if you make the changes I've suggested, which
I can check. You'll need to write your own serialization routines to
save the state as well, everything in the 'forth_t' object to be
serialized needs to be saved, not just the core. That should be
trivial to write. It would be worth writing a unit test framework to
tests the behaviour.

I just noticed I did not really answer Dave's question about the
differences between 'libforth' and the 'embed' project. The 'libforth'
project was one of my first attempts at a Forth interpreter written in
C, and it uses a hybrid technique of doing a lot of the Forth interpreter 
loop processing in C, with the READ instruction.  This makes things
easier for a C programmer to understand how Forth works, but it is more
awkward and less flexible.  The main goal of the 'libforth' project was 
to document how to put a Forth interpreter together (hence the 
copious documentation), and as a secondary goal to provide a Forth 
interpreter as a library. 

The 'embed' project actually derives from a my processor project,
which is a Forth core written in VHDL (which takes its design from
the J1 Forth core, written in Verilog). I took the simulator I had
written for it and turned it into a small interpreter. The goal of
that project was to make a Forth metacompiler that could create new
images, which allows a Forth interpreter to be written entirely in
Forth (the virtual machine is in C, but the Forth interpreter logic
is entirely present in the image provided). Given it's heritage, the
'embed' VM greatly resembles the 16-bit processor that it derives
from.

The current 'embed' image is fairly minimal, just enough to compile a
new version of itself, there is a lot more code hiding in the history
of the repository that you might find useful. 

Thanks.

On Fri, Apr 20, 2018 at 08:20:04AM +0000, crodnun wrote:
> Hi Richard, thanks for your amazing help. We are now considering to move to embed, but the most important question is the following:
> 
> Could this version be stopped and resumed without trouble?
> I try to detail it a bit more below:
> 
> 1) Imagine a simple FORTH script:
> : word1 2 4 + . ;
> : word2 3 5 + . ;
> word1 word2
> 
> 2) We pass this input to the VM
> 
> 3) Imagine that we stop the VM in the middle of word1 execution (both words have been defined), we serialize it and store in DB.
> 
> 4) Later we resume it (load in memory again) passing the rest of the script "word2" (word1 was on the fly).
> 
> 5)  In this scenario, will EMBED execute the pending instructions at word1 before going ahead with word2?
> 
> Thanks
> Carlos
> 
> -- 
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub:
> https://github.com/howerj/libforth/issues/4#issuecomment-383021712

 Comment 5: Thanks Richard! We really appreciate all your help with this.  It sounds like Embed is the way to go for all the reasons you have mentioned above. 

I really like you're idea of advanced users supplying their own image if they're not keen on the supplied interpreter.  My hope is to create a FORTH environment that is easy for beginners to engage with but infinitely adaptable for players who would like to go down that rabbit hole. 

Dave
 Comment 6: Richard, Thanks so much for your help! We've begun migrating our Game Engine over to Embed and will keep you posted via email.  We'll post any future issues on the Embed project.
 Comment 7: Ok, thanks!
{'source': 'GithubIssues', 'repo_name_with_owner': 'howerj/libforth', 'issue_id': 312966003, 'repo_stars': 132.0}