[M3devel] Oops, forgot to ask

[Tony Hosking]

This does not make sense:

Here is the compiler's definition of the builtin CARDINAL type:

MODULE Card;

IMPORT SubrangeType, Target, TInt, Tipe, Int;

PROCEDURE Initialize () =
  BEGIN
    T := SubrangeType.New (TInt.Zero, Target.Integer.max, Int.T, TRUE);
    Tipe.Define ("CARDINAL", T, TRUE);
  END Initialize;

BEGIN
END Card.


Notice that it is a subrange type [0..LAST(INTEGER)].

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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                                      |
>>> +--------------------------------------------------------+
>>> 
>>> 
>>> 
>>>    
>> 
>> 
>>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091216/2445a4da/attachment-0002.html>