[M3devel] 64bit file sizes now?

[Tony Hosking]

Overflow checking is a whole other ball of wax... ;-)
The language reference provides for controlling the behavior of integer operations regarding overflow and divide by zero through the interface FloatMode.i3.  Unfortunately, the implementation of this interface on many targets is incomplete and the default behaviour is to allow integer operations to silently overflow.
Range checks are still injected by the compiler to ensure that no variable has a bit representation that is not a legal value for that variable.  Thus, for example:

VAR x: INTEGER := LAST(INTEGER)+1

will leave x with the value -1.

But,

VAR x: CARDINAL := LAST(INTEGER)+1

will cause a range fault because the overflowed result is not a legal CARDINAL.

It would be great if someone could devote some time to implementing this interface for x86 or x86_64 as they are the most widely used these days.  Of course, each OS target will probably need a different implementation.

On 11 Jan 2010, at 22:27, Daniel Alejandro Benavides D. wrote:

> Hi all:
> forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: 
> (LAST(INTEGER) + 1) = FIRST (INTEGER)
> This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).
> Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code.   
> Please let me know if I'm wrong about this issue on current discussions. 
> 
> --- El lun, 11/1/10, Jay K <jay.krell at cornell.edu> escribió:
> 
>> De: Jay K <jay.krell at cornell.edu>
>> Asunto: [M3devel] 64bit file sizes now?
>> Para: "m3devel" <m3devel at elegosoft.com>
>> Fecha: lunes, 11 de enero, 2010 22:02
>> 
>> 
>> 
>> 
>> 
>> So.. LONGINT as I understand will remain roughly as it was,
>> except VAL(expr, INTEGER) is how you convert expr to
>> INTEGER, instead of ORD(expr).
>> 
>> 
>> 
>> 
>> 
>> And this is already in place.
>> 
>> 
>> 
>> 
>> 
>> ?
>> 
>> 
>> 
>> 
>> 
>> So I should go ahead and update File.i3/Status/size and
>> Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever
>> the consequences"? The consequences are roughly the
>> first diff I sent out, with the caveats that I used ORD()
>> instead of VAL(,INTEGER), and a few packages were left to
>> fix. It is mechanical and simple and predictable, just
>> tedious and ugly.
>> Most Rd/Wr users are limited to INTEGER "sizes"
>> anyway, but a few might gain capacity.
>> 
>> Classic simple example is the mklib and libdump code, they
>> read the entire file into memory and then deal with that.
>> 
>> 
>> 
>> 
>> 
>> I can send the diffs ahead of time, but there's really
>> no choices left as to what they'll look like, it is
>> forced by the limited capability of LONGINT.
>> 
>> Had they used LONGINT in the first place, of course,
>> there'd be no diff at this time, the ugliness would have
>> been builtin from the start.
>> 
>> 
>> 
>> 
>> 
>> - Jay
>> 
>> 		 	   		  
>> 
> 
> 
>