Gopal V <[EMAIL PROTECTED]> wrote: > What I wanted to say was to have fixed size variables and an interpreter > specific internal notation would be ideal. And only if you wanted to > operate stuff with direct int registers.. The fixed size variables allow > the JIT to decide if we use half-a-register , one or two for each operation > according to hardware.
I think, we should see parrot like what it is - a CPU. A CPU has its natural integer size - called INTVAL in the parrot CPU. INTVAL size differs because parrots CPU depends on the underlying hardware CPU. So we need an additional concept of fixed sized integers (as e.g. a C compiler with int and int64_t ...) The fixed sized int operations could either be done with separate opcodes or with current opcodes (where appropriate) + dotgnu-like ops for size adjustment. Bigger then INTVAL types would need special storage + special treetment, so they dont fit very well into this scheme. But I really have strange feelings against putting an 64bit int into two adjacent 32-bit INTVAL registers. We might end up with another register set e.g. L (LONGINTVAL) plus basic math opcodes. > But I think the INTVAL philosophy is a creep of a Perl idea into > Parrot ie having variable size integers to execute ... Why this > interpreter concept (ie perl5) ended up in the engine instead of > the code production phase shows how blurry the distinction is for > Parrot & Perl6 . It seems that these scheme is good for Perl - or Perl users are just used to it - but impractical for typed languages. > So compiling perl6 code with --with-64bit-integers (or something like that) > will use the Int64 instead of Int32 Perl6 will be (optionally for the user) a typed language too. Why not adopt existing schemes to Perl6: A C<int> is whatever the CPU i.e. parrot i.e. the hardware provides. And if the user wants a C<int64> she will get one. The same conecpts hold in C (gcc) with "int" vs "long long". >> ... - those operations are >> going to be vectored through PMCs anyway. Not for ultimate performance. If parrot will compete with Java and C#, we probably will need fixed sized natural types. > Another point ... how are PMC methods called ?. Do they cause a register > flush ?. Partially yes. But JIT/i386 and JIT/sun4 already call vtable functions directly and at least JIT/i386 also do push the register of mapped Parrot registers directly onto the processor stack. But a register flush will be necessary anyway due to exceptions - at least very likely. > Neither do I ... I'm just saying what I can see ..And of course I'm > waiting for Dan and Leo to pounce on this thread (and hopefully they'll > be quick & merciful ;-) I thinks, we should combine Brian and Gopal's concepts: - parrot guts use natural integers (the C compiler's "int") - INTVAL is the natural parrot integer (dependig on what hardware parrot was configured) - additionally parrot provides fixed sized integer types and math operations for these. > Gopal leo
