[M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent?

[Rodney M. Bates]

Once more, with feeling.

On 05/27/2015 11:14 AM, Hendrik Boom wrote:
> On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote:
>>
>> Hmm?
>>
>> Modula-3's INTEGERs are the "integers" of mathematics.  The intent is
>> that if your implementation is limited and doesn't support a particular
>> operation because it goes out of range, your computation aborts.  Same
>> as any other implementation limitation.
>>
>> There is no reason I can think of you couldn't come up with an implementation
>> that has unlimited-range integers.  FIRST(INTEGER) and LAST(INTEGER) would have
>> to be a little special.
>
> That was, in essence, my proposal for LONGINT, not for INTEGER.
> We still need an integer length that's efficient.  I wasn't proposing to
> change the definition of INTEGER, FIRST(INTEGER), and so forth.
>
> But if one had a base tyoe of LONGINT and forbade declaring anything of
> type LONGINT, you could still have BITS 45 FOR LONGINT and the like.

TYPE U = BITS n FOR T *does not change the range of values.*  The range
of U is the same as that of T.

If you try to stuff it into too few bits, e.g., BITS 4 FOR [ 0 .. 255 ],
it is a static error.

If you try to assign a value outside the value range, it is an error,
generally at runtime, even if that value would fit in the bit count.
E.g., VAR V : BITS 16 FOR [ 0 .. 255 ] := 256 is illegal.

The *only* thing BITS n FOR does is, if legal, affect the amount of
storage the compiler allocates, and *only for array elements and
fields of RECORDs and OBJECTs*.

Look at 2.2.5.

> It just happens that the usual arithmetic operations are bounded in
> nature -- the number of bits in the result are bounded by functions of
> the numbers of bits in the operands, and an assignment so assigning
> to variable of could end up truncating, possibly with an overflow
> check.
>
> In fact, one could possibly define INTEGER to be BITS 32 FOR
> LONGINT, but that might involve further consequences in corrner
> case in the language.
>
> -- hendrik
>
>>
>>       Mika
>

-- 
Rodney Bates
rodney.m.bates at acm.org