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 ?
/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...
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 :-)
Gopal
--
The difference between insanity and genius is measured by success
