On Sat, 2003-05-31 at 11:43, Leopold Toetsch wrote: > Bryan C. Warnock <[EMAIL PROTECTED]> wrote: > > > The flow *really* is, in value sizes: > > > Opcodes: 32 (constants are limited by the spec) > > In which spec? How would we handle 64 bit INTVAL constants on 32 bit > systems?
Parrotbyte.pod. Googling for 'parrot constant "32 bit"' also returns some discussions. (Although I don't remember - and can't find - any reference to what Dan had suggested for handling what, essentially, are PMC constants.) > > > PMCs : 64 > > Regs : 32 > > Guts : 32 > > System : 32 > > Yep, guts should really be plain C<int> or C<size_t>. There are far too > many U?INTVALs in data structures or whatever. > > I'm not sure, if we need 64 bit INTVAL in regs. But the implementation > in JIT wouldn't be too hard. I don't think we need them. An awful lot of the numbers making it to the registers are passing through to the guts. And implemented languages have to take into consideration that a 64-bit type isn't available in the first place, so we shouldn't be breaking anything. (Actually, this will make sure we don't break anything.) > > > Can we simplify interpreter types this much, while still providing > > extended numerics to hosted languages? > > For sure. Okay, let me rephase. Can *those of us who aren't Leo* simplify interpreter types this much, while still providing extended numerics to hosted languages? :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
