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 ;-) 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. > 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 . > 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) But of course it's a sad situation that Parrot is missing Objects still . Until then those opcodes are there to occupy numbers. Gopal -- The difference between insanity and genius is measured by success
