Handling non-standard integer types

[Martin D Kealey]

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?