If memory serves me right, Bryan C. Warnock wrote: Reply inline ... and I've said more than I've quoted ... It could be called as a critical appreciation ... though not much has been appreciated below ... and what I know about parrot can be written on a shirt sleeve ;-) Please do tell me if I've gone off the track below.
> If the hardware can do 64-bit math, and the compiler can produce the > code to do 64-bit math on the hardware, then languages running atop > Parrot should be able to do 64-bit math on the hardware. 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. Though I must say this is totally against the INTVAL philosophy ... 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 . So compiling perl6 code with --with-64bit-integers (or something like that) will use the Int64 instead of Int32 for all "int" variables without affecting the array indexing , addressing features. Thus the engine can adopt the policy of "The compiler asked for Int64" and let it go at that. So we standardize data/integer sizes after the packfile phase of Perl6 code. So after compiling something that needs 64 bit ints , you could pick it up and run it in a Parrot configured to 32 bit operations and it will use Int64 (2 registers, register pairs or software emulation -- JIT picks) since that is mentioned explicitly in code . And we'll all be happy. Similarly for 32 bit code compiled and ran on a 64 bit platform will have the correct semantics & overflow modes as it is explicitly mentioned as Int32 in the packfile. Having said all that ... Isn't it a bit too late to bring this up ? > > The reason these were made into new ops instead of PMCs was to allow > > JIT'ing these in the future if needed ... They are simple enough to be > > easily JIT'd, but better wait until they are used :-) > > Good point. But for most supported languages other than those > statically typed - ie, Parrot's tier 1 audience - those operations are > going to be vectored through PMCs anyway. Perhaps even for statically > typed languages. After all, Parrot really only has one size register. > Have we provided full semantics - like overflow - for all supported > integer sizes? Another point ... how are PMC methods called ?. Do they cause a register flush ?. Ie do you push registers before moving into a PMC ?. Because in x86, an Int32 addition is 1 instruction and a (reg,reg) => (reg) operation as well. Being able to do it inline rather than pass through a stack push, call and pop is also another speed factor. Such a register flush back to memory would have the a side-effect on the perfomance .. Especially when *all* numerics are via PMCs. > I think that with most languages handling their numerics via PMCs, there > are few places within Parrot that need to built around "long long"s on a > 32-bit platform. (Technically, we can't even *guarantee* "long long"s > on a 32-bit platform.) You're making me wonder if Parrot_Int4 should be the user/lang space type and INTVAL the interpreter space type , instead of otherwise. > As Leo and I both documented, the integer registers are iffy. We don't > know. 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 ;-) Gopal -- The difference between insanity and genius is measured by success
