[M3devel] Oops, forgot to ask

[Tony Hosking]

I just dug this correspondence out of my pile and realised that we still don't have LONGCARD.  This means it is difficult to pickle values in the range [0L..LAST(LONGINT) portably across machines.  I will shortly add support for LONGCARD to the compiler, but this will incur additional bootstrapping pain, because it entails changes to both m3core and cm3.  Might as well do it now instead of later, so the pain is not dragged out over time.

On 16 Dec 2009, at 17:56, Rodney M. Bates wrote:

> Tony Hosking wrote:
>> On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
>> 
>>  
>>> Hi Gang,
>>> 
>>> 0 - CARDINALs are an integral type defined by the language
>>> spec to be from 0 (zero) to MAXINT (not MAXCARD).  Recently,
>>> a change was made to CM3 to extend the language it recognizes
>>> beyond the original language spec (SPWM3), now CM3 understands
>>> a LONGINT.  
>>> Was there a corresponding LONGCARD defined?
>>>    
>> 
>> No.  But you can write:
>> 
>> [0L..LAST(LONGINT)]
>> 
>> just as
>> 
>> CARDINAL=[0..LAST(INTEGER)]
>>  
> Actually, the line above was once true, long long ago, when dinosaurs
> roamed unfettered.  CARDINAL was changed to be "just like"
> (but not equal to) [0..LAST(INTEGER)].  This would have been
> maybe early 1990s. 
> It took me years to figure out what this actually meant, and more
> years to figure out why, but I believe I now know.  CARDINAL is not an
> equal type to [0..LAST(INTEGER)], but otherwise has all the same
> properties.  This makes the two mutually assignable, which is close
> enough to equal to not matter in most contexts.  The exact consequences
> follow from other language rules. 
> The motivation is this:  [0..LAST(INTEGER)] on a 32-bit machine is not
> equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> machines with different values of LAST(INTEGER)), because the numeric
> value of LAST(INTEGER) is part of the expanded type.  The one place this
> matters is if you use pickles to transfer data between machines of different
> word sizes.  If the type is [0..LAST(INTEGER)], the type signature (a hash
> of the complete, expanded type definition) is different on the two machines,
> and values of or containing this type cannot be transferred.  Exact type
> signature matches are used in pickles to find corresponding types when
> reading. 
> But pickles handle different sized INTEGER values fine, expanding/shortening
> as needed.  Being a leaf in a type definition, INTEGER is always the same
> type on any machine.  So CARDINAL was changed to be its own unique
> type too, so it would be possible also to transfer CARDINAL values in pickles
> between different word sizes. 
> So, we really should have a LONGCARD, parallel to CARDINAL.
> 
> Note that this also affects network objects, which use pickles to transfer
> values of the objects.
> 
> 
>> 
>>  
>>> Can is use all 64-bits, or is it restricted to 63, like
>>> the CARDINAL is only 31-bits.
>>>    
>> 
>> 63 bits, since its underlying base type is LONGINT.
>> 
>> 
>>  
>>> 
>>> 
>>> 
>>> +--------------------------------------------------------+
>>> | Peter P. Eiserloh                                      |
>>> +--------------------------------------------------------+
>>> 
>>> 
>>> 
>>>    
>> 
>> 
>>