On Sun, 2003-06-01 at 10:08, Gopal V wrote: > If memory serves me right, Bryan C. Warnock wrote: > > > 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.) > > Let me get this straight .... if we endup using a 64-bit INTVAL in > a 32-bit machine , it will suffer a speed loss even when you write > a Rot13 converter ?
Of course. 64-bit math on a 32-bit machine will be a tad slower than 32-bit math. 64-bit math on a 64-bit machine can be a tad slower than 32-bit math. (But that's another story.) Emulating (in software) 64-bit math on a 32-bit machine will be much slower. But we're not going to do that except where we have to. (Which shouldn't be too many places, any more.) 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. But that doesn't mean Parrot, which spends most of it time mediating amongst a language's PMCs and hardware services (like IO and signals), needs to be built upon it. > > /me mutters about Dan, Python , Zope labs and banana creme pie > > > 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.) > > In parallel speaking IL has an "INTVAL" according to hardware and fixed > size integers usable in the VM . (read more comments on that below) > > > Of course, I completely forgot that splitting Parrot registers (which is > > basically casting a register as being wider, and obliterating the > > DotGNU Parrot IRC meeting -- 2002-10-19 > > *****************************Parrot, IL and JVM************************** > [10:26] <Dan> acme: Do you remember if the JVM requires 64 bit ints? > [10:27] <q[acme]> Dan: yup, for longs. see > http://java.sun.com/docs/books/vmspec/2nd-edition/html/ > Overview.doc.html#22239 > [10:28] <Dan> Okay, then. That clinches it. Time to do weird things for > parrot's ints. > [10:29] <q[acme]> shame that jvm and msil are more hardware-level really ;-) > [10:30] <Dan> I just begrudge the cache fluff that emulated 64 bit ints > will bring > [10:31] <Dan> But split registers are a major pain, and I don't want to > emulate 64 bit math anywhere if I can avoid it > > :-) > > > Perl 6, Lisp, DotGNU - they should be free within their own framework > > to define their own types. > > Though those types are available for any language that's strict about > sizes ... like say Java :-) . The mul.ovf and similar operations do > throw exceptions on overflow from native... But even the JVM doesn't cripple itself by mandating that, in order to support 64-bit longs, all integers and operations on integers must be 64-bit wide. Which is *exactly* what Parrot is doing. > > 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? It's these types of problems that have caused me - and I've caught Dan, on occasion - to constantly waffle on what we should be doing. 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.) As Leo and I both documented, the integer registers are iffy. We don't know. (The problem stems from trying to dual-purpose the registers for interpreter-space and user-space calculations. Early on, Dan wasn't expecting too much to use them.) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
