Sun Jun 10 08:48:25 EDT 2012

RPC context save

RPC calls should preserve the following state:
- 3 stacks: xs, ds, rs
- 2 registers: a, f

However, the interpreter acts as if it owns these registers, so before
doing anything destructive a/f need to be saved.  It's easy to do this
on the target but why not do it on the host?

The trouble is that indirect addressing uses the a register, so it
doesn't look like this is possible without a register fetch support.

Maybe it's simplest to reuse the stackptr word to also dump out other
state.  Then, what about restoring?  Store also needs the a reg, so
restoring a reg is not possible without target support.

Looks like this needs 2 words: save and restore.  There's one slot
left as I see 2x reply0.  I guess slot 6 is not used.

Also, I'm not sure if jsr is still useful, so might reuse slot 7 also.

It seems better to turn the basic >t t> support words into multi-byte
words.  OK, done.

However, I'm not sure that was really necessary but it's good to have

I'm thinking a bit more.  It's probably good to keep the interpreter
minimal, and only implement support for other features where they are
actually needed.  I.e. when not running a recursive interpreter,
save/restore is not necessary.  So let's put it in debug.f

EDIT: reply/1 isn't necessary.  Only used for stackptr and checkblk.
stackptr is necessary for ts, so might go in debug.f also.

EDIT: interpreter now only does memory transfer + execute (with and
without ack).  Decoupled other functionality from the host i/o.