On Fri, 2003-06-06 at 16:34, Leopold Toetsch wrote: > > *) Integer constants are limited to 32 bit signed integers because > > they're inline. > > Yep. But this will cause problems with JIT/Prederef and multi threading, > and its already causing problems inside JIT on architectures with only > small immediate constants. We have to consider these upcoming problems > too. I dont see any reason, not to have optionally/additionally - or > always - integers in the const_table.
There must be *some* limit, even if it's the physical limit of the machine. Either that limit is hard - Parrot cannot support integers larger than that type - or it's soft - Parrot will work around the limit by promoting to arbitrary-width numbers. If it's a soft limit (which it is), then the limit itself is arbitrary. > > > *) INTVAL is meant to be the fastest native integer type for integer > > math that's at least 32 bits. That integer registers are INTVALs is > > an unfortunate side-effect, and one I'm tempted to do something about. > > In one of the FUPs, I had a different definition: > An INTVAL is the size of the integer register. The fastest integer > type on $arch ought to be just a plain C<int>. I think, when we look at > the problem from this side, it should be simpler. IIRC, Jarkko pointed out that that's not always true. (The *last* time I was waffling on sizes.) > I'm - as stated in the thread - for a new register type (L, long). > > They have the same relation as 32bit ints and 64 bit longs, with the > difference that we guarantee at least these sizes. I'm not an actor, nor do I play one on TV. That being said, if you can handle making Parrot keep all the registers straight, I'm not adverse to this. (What am I saying? Of course *you* can handle that. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
