On Sun, 12 Feb 2012, Jonathan Worthington wrote: > Well, in this case I'd say M0 needs to mostly decouple various things that > Parrot couples (like register size and opcode size), and actually have some > notion of native type system, so it is aware of different integer sizes and > signednesses. That probably means leaving the notion of "4 register types to > rule them all" behind, if that didn't already happen.
My feeling is we want *two* "register" types: pointer and value, because GC needs to be able to pick them apart reliably. Signed vs unsigned ops aren't sharable unless you assume no overflow (or wrap-on-overflow), which kinda goes against the grain. Even if we're not auto-promoting at the opcode level, it does need signal that promotion is needed, and that's signed-ness dependent. -Martin PS: The last CPU I saw without a properly working carry flag was the PDP-11, whose instruction set was composed in 1975. The flag was there, but it lacked an add-with-carry instruction. On the other hand, some early embeddable CPUs lacked an add-without-carry instruction, but made up for it by having a clear-carry instruction. PPS: Crazy out-there idea: would it be useful to expose the the stack-frame as a pair of objects: an array of pointers (starting with dynamic & scope chains) and a struct of variously-sized non-pointer bit-strings? _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
