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.