On Tue, 2003-06-03 at 03:54, Henrik Tougaard wrote:
> On Sat, May 31, 2003 at 09:54:45AM -0400, Bryan C. Warnock wrote:
> [snip]
Part of what was snipped was this line:
(For the sake of using real numbers, I'll assume 32/64.)
> > Currently, the flow is, in variable sizes:
> >
> > Opcodes: 32 (constants are limited by the spec)
> > PMCs : 64
> > Regs : 64
> > Guts : 64/32 mix
> > System : 32
> >
> [snip]
> > The flow *really* is, in value sizes:
> >
> > Opcodes: 32 (constants are limited by the spec)
> > PMCs : 64
> > Regs : 32
> > Guts : 32
> > System : 32
> [snip]
> You seem to forget that there *are* systems out there that have a native 64-bit
> integer size (and a heavy penalty
> for handling 32-bit ints). Even the pointer size *has* to be 64 bits - the system I
> write this on has 6 GB of
> memory installed, so a 32 bit pointer is just useless.
I have forgotten nothing.[1] I simply got tired of talking in the
abstract. The above also holds true for 64/128. (Well, except that
opcode values are still limited to 32-bits, but padded in a 64-bit
construct.
I believe this was reiterated in the thread that followed with Gopal V,
but I'll try to clarify here. (I don't always convey my messages
clearly.)
This is *not* a proposal that Parrot should be 32 bit.
This *is* a suggestion that the Parrot core should *not* be built around
types wider than the underlying physical hardware is.
> So even the 'System' size must be 64-bits, as
> size_t is an unsigned long (and therefor 8 bits.
And that's right in line with what I was saying. Don't get wrapped up
in the numbers. They were just an example.
[1] Actually, I'm sure I've forgotten a lot, which it why I'm posted
this for comments and criticism. But I haven't forgotten about 64 bit
platforms, which is my platform of predominant use. That would be
rather short-sighted, even for me.
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
