Nicholas Clark wrote: [ PerlUndef vs int vs num ]
> If I understand things correctly, all the parrot ops dealing in integer > registers keep the result in integer registers, floating point in floating > point registers. By default the perl6 language will carry on treating > numbers as "numbers" attempting to hide the underlying representation. Yep, currently P6C's basic scalar type is PerlUndef, which takes just every scalar value and should do the right thing. > This is potentially slow, so I'd expect the perl6 interpreter/compiler to > try to find ways to generate integer or floating point bytecode whenever > it can get away with it. But it does have to be mindful of overflow. Actually, yesterday sitting over my first attempts of imcc:optimizer and looking at mops.p6, the main loop could be converted to native int, imcc (via life analysis) has all the info to accomplish such an optimization. new P .PerlUndef , clone P,P would go, and with iteger arithmetik this would reach exactly mops.pasm's Mops (1 instruction kills the branch reordering already accounting for 1 % ;-) > (and tied variables, or whatever supercedes them, and %caller::MY) Are there already an ideas on tied variables? But anyway, imcc would know this variable is tied, so don't otimize it to a plain int. And on the second thing, of which I don't know, what it will be able to do, but, as I can imagine a lot of code retrospection ... > Nicholas Clark leo
