On Sat, 2003-05-31 at 11:15, Gopal V wrote: > If memory serves me right, Bryan C. Warnock wrote: > > Not to mention all the *other* problems we'll have if we've got more > > than 2^31 different opcodes. (Although that's why there's UUIDs now, > > isn't there?) > > I think parrot has already crossed the limit of 1024 ... > (I can't even keep 256 opcodes in my head , let alone 1024 :-) > > > And for what? To be able to add large numbers? > > No .. to add large numbers very quickly ... ie split registers and > enemies ;-)
Understood. My point was that - to parallel virtual machines with physical ones - the big drive for 64-bit has never been about squeezing out another point-n percent when doing ultra-high precision math, but more about the ability to represent a range of numbers, such as those needed to address memory or storage. (Which Parrot is completely dependent on the hardware to do.) > > No sense in keeping an Int64 in 2 32 bit regs if you have a 64 bit > CPU & shift-mask-add .. But how can you be sure where the .pbc will > run. I'm not saying keep Parrot 32-bit. I'm saying there's no reason to run the Parrot core at a width wider than the hardware. (So core Parrot on a 64 bit machine will do 64 bit math. That doesn't prevent languages running atop from using wider types, as long as Parrot is aware.) > > > to borrow a page from the physical hardware and simply join two smaller > > registers together? (The advantage of contiguous memory regions.) > > Well that's only if those two regs are in memory ... the Parrot JIT > does use a register allocation scheme , IIRC . That's why the big punt on whether it'd be doable in the JIT. I'll let those more clever than me address how to do that. Of course, I completely forgot that splitting Parrot registers (which is basically casting a register as being wider, and obliterating the register behind it) might introduce alignment problems, so you might only be able to do that for registers mod 2. > > > Can we simplify interpreter types this much, while still providing > > extended numerics to hosted languages? > > I *had* to hack out a couple of types of parrot to have fixed size > types irrespective of implementation size ... (@see dotgnu.ops) Which, I think, is okay. Perl 6, Lisp, DotGNU - they should be free within their own framework to define their own types. > > But of course it's a sad situation that Parrot is missing > Objects still . Until then those opcodes are there to occupy numbers. > > Gopal -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
