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 dan@sidhe.org have teddy bears and even teddy bears get drunkThread Next