I've been out of touch this weekend (and currently sorta swamped now) so
I've not been commenting, but here's a quick sum-up of what I've been
thinking about:
1) The paired register thing's silly. Forget I mentioned it.
2) The interpreter will have some int, float, and string registers. Some
stuff will be faster because of it, and it'll make the generated TIL or C
code (when we do a TILperl or perl2c version) faster since we won't need to
call opcode functions to add 3 and 4 together...
3) Whether the registers are really stack-based or not's an implementation
detail. They'll be based off of some per-interpreter thing, of course,
so'll be thread-local
4) We will have some sort of register push/pop system independent of the
register implementation. (Probably, like the 68K family, with the ability
to move multiple registers in one go)
5) The bytecode should be really, really close to the final executable
form. I'd really like to be able to read in the bytecode in one big chunk
and start executing it without change. (We'll end up with some sections
that'll need to be changed--that's inevitable. If we can mmap in the
non-fixup section pieces, though, that'd be great)
6) We may formally split the registers used to pass parameters from the
working registers. I'm not sure if that'll ultimately be a win or not. (I
can forsee lots of pointless register->register moving, and I'm not keen on
pointless anything)
If someone can make a compelling argument for details on how the registers
should be done that should be visible to the bytecode (Like, say, a variant
on SPARC's windowing system, or forcing them on the stack such that pushes
and pops renumber the registers) that'd be keen. I can see the merits, but
I'm not compelled one way or the other quite yet.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
