[M3devel] The role INTEGER and subranges in Modula-3

[Rodney M. Bates]

On 05/30/2015 11:33 AM, Elmar Stellnberger wrote:
> Am 30.05.15 um 17:13 schrieb Rodney M. Bates:
>> There are no implicit type conversions.  Instead, this need is met by
>> the concept of assignability.  If the abstract value is in a
>> variable's range, it can be assigned to the variable.  Size changes,
>> if needed, are the code generator's problem.
> So what does the code generator do if there is an overflow not checked
> by the predefined value range (i.e. BITS 8 FOR INTEGER instead of
> BITS 8 for [0..255])

BITS 8 FOR INTEGER  will not compile.  It is statically illegal, because
the asked-for bit size is not enough to hold the value range of the type INTEGER.
(Unless the compiler is configured with FIRST(INTEGER) = -128 and
LAST(INTEGER) = 127, as might be done for an 8-bit microprocessor.)

>> All this drastically simplifies the language, while also allowing the ...
> Yes, I understand your decision.
>> likely to be commonly needed, LONGINT would have no place.  But native
>> sized arithmetic is always the most efficient.  In today's world,
>> there are two very common classes of use cases: 1) 32-bit arithmetic is wide enough, 2) 32-bit is not wide enough, but 64-bit is.  In both
>> cases, on machines of either native arithmetic size, we want the best
>> efficiency.  LONGINT is for case 2, and when you further need to be
>> able to run on either size of machine.  INTEGER is for otherwise.
>   Well, that was exactly my argument for a language specified type
> size of INTEGER, because things do not get faster if you use 64bit
> integers instead of 32bit integers. CPU arithmetics perhaps but the
> real bottleneck of today is the memory hierarchy - and using 64bit
> integers doubles our memory need at least for scalars.
>>
>> Whether you believe in LONGINT or not, there is certainly no
>> justification for more base integer types than two: one the native
>> size of the machine and one bigger.
> Yes, we really don`t need them as anything becomes 64bit or the native
> word size respectively on the stack (that is why Ctypes.int works).
> Memory latency should be a minor issue as long as our parameters and
> parts of the activation records fit into the cache.
>
>
>
>

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