On Mon, 2002-10-21 at 15:11, Dan Sugalski wrote: > Okay, I'm about ready to just bite the bullet and declare that > INTVALs have to be 64 bit integers.
Which INTVALs? INTVAL, IMHAOSBRPO[1], is overused internally. I see little relative performance and size damage if INTVAL is made 64 bits and relegated only to user-space math as long as the internals (pointer-tracking, sizes, offsets, etc) are left as native. You can check and cast when numbers cross over. OTOH, converting all of the internals to 64-bit is probably not such a good idea. Of course, I registers are probably being used for both uses completely independent of each other. Or did I miss the point on wherefore 64-bit? > > Does anyone know of a platform that has neither native nor emulated > 64 bit integers? (One we're likely to run on, rather) If it has neither, the internals shouldn't be affected, although user-space values will be. But you can convert to BigInt at 32 bits vice 64. (Assuming that's still the plan.) [1] In My Humble And Oft-Stated But Rarely Patching Opinion ;) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
