[M3devel] LONGINT, my original proposal

[Jay K]

On a 32bit system, what is the difference?
Obviously LAST(INTEGER) is different and probably more correct on 64bit.

 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 17:45:09 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT, my original proposal



Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)]  instead of [0..16_FFFFFFFF]?


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


On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:

Tony Hosking wrote: (excerpted)
........................................
2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).
Currently, direct comparison between LONGINT and INTEGER is not permitted.  If it were then this would be true.


I remember there was some vexing problem about what the result type
should be for FIRST and LAST, but not the details.  It seems to
me now that the only thing that makes any sense is to preserve the
existing rule that it is the base type of the argument type.
This is really necessary to preserve existing semantics of the
language and of existing code.

This original proposal seems to be silent on the matter, which I suppose
means I intended it as a NO CHANGE.  I guess, if
mixed relations are allowed, then I can't think of a problem
with this.  Even if mixed relations are disallowed, this range
constraint could be expressed with explicit conversions, I suppose.

.......................................................................

15. There is a new builtin type named LONGCARD.  It "behaves just
   like" (but is not equal to) [0..LAST(LONGINT)].

     The current CARDINAL has an interesting history.  Originally, it
     was just a predefined name for the type [0..LAST(INTEGER)].  It
     was later changed to be "just like" the subrange, i.e., the two
     are not the same type, but have the same properties in every
     other respect.  The only reason for the change had to do with
     reading pickles, which are completely defined and implemented as
     library code.  The change did affect the type analysis of the
     language, nevertheless.

     We should preserve this property for LONGCARD too.
Currently there is no implementation of LONGCARD.  I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles...  Rodney?

LONGCARD is needed for pickles (and for no other reason, that I can
think of).  The problem is that if a record or object has a field of
type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes
the type to be different on different target machines, making a pickle
written on, say a 32-bit machine unreadable on a 64-bit machine.
LONGCARD can be treated as the same type regardless of word size,
allowing the automatic size changes pickles already does for INTEGER,
CARDINAL, and LONGINT to extend to this subrange too.

(Note: If you try to extend this size-changing by pickles to arbitrary
subranges that use FIRST/LAST/NUMBER in their bounds expressions, you
are jumping head first into a tar pit.  I've thought about it just enough
to conclude I wanted to step back.)

.......................................................................

20. The statement that the upperbound of a FOR loop should not be
   LAST(INTEGER) also applies to LAST(LONGINT).
Agreed.
     Note that the existing definition of FOR otherwise generalizes
     to LONGINT without change.
The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match.  Will we permit any mixing of values?  If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).


I think allowing mixtures here is going too far.  Moreover, the existing
rule for FOR already requires the same base type for the two bounds, unlike
the assignability rule for operators, so unless we change an existing
language rule here, this form of mixing is not allowed.

Note that the step value is "integer-valued" unconditionally, i.e.,
even if the bounds have, say, an enumeration type.  Taken literally, I
would say this would allow its type to be INTEGER, LONGINT, or any subrange
thereof.  Perhaps on a tiny 8-bit embedded processor, this could have
a use.

......................................................................


22. There is a new required interface LongWord.  It almost exactly
   parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains
   new functions ToWord and FromWord, that conversion between the two
   types, using unsigned interpretations of the values.  ToInt may
   produce a checked runtime error, if the result value is not in the
   range of an unsigned interpretation of INTEGER.
This is the current implementation, but we do not support ToWord and FromWord.  Why do we need these?

All the operations in Word apply an unsigned interpretation to the bits
of the word, whereas the operators and functions in the language apply
signed.  Unsigned expansion is different(zero extend) from signed (sign
extend).  FromWord would do the unsigned, while VAL would do the signed.

Similarly, for contracting, the value range check is different.  Signed
means leftmost 33 bits all equal to each other.  Unsigned means leftmost
32 are all zero.

     Word.T = INTEGER, so LongWord.T should = LONGINT, for
     consistency.  This means simple assignability tests and
     assignments between the types will use signed interpretations.
     So different functions are needed to do size changes with
     unsigned interpretation.
This is the current implementation.


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