[M3devel] the meaning of -FIRST(INTEGER)?

[Jay K]

I think there is a language hole here.The language should perhaps allow forunsigned literals and unsigned constantexpressions.

Something I don't quite have my head around as well,maybe a language/library hole, is how to doe.g. the below, without assuming two's complementrepresentation of signed integers.

Can we maybe add Word.AbsoluteValueOfInteger?The implementation would, roughly:  IF i < 0 THEN     i := -i;  END;  RETURN i;  END;
with the extra qualification that overflow is silent

 > But surely, we could agree that compile time > arithmetic should do the same thing as runtime would, for a given > implementation.
Uh huh. This is why you need *different types* (or interfaces)for the variety of integer overflow behavior and not a runtimesetting. Otherwise the compiler can't know what theruntime behavior is.

As well, using static typing instead of a runtime setting,allows for efficiency. Imagine, say, if x86 does requireextra code to check for overflow.Well, if using "integer-with-silent-overflow", thatwould be omitted. If using "integer-with-overflow"the code would be included.

I introduce the error. It used to be silent.I changed it to a warning, for thevery specific case of negating FIRST(INTEGER).Any other overflow here, which is probably notpossible, will still error.
 - Jay


> Date: Fri, 22 Jan 2010 19:56:37 +0000
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?
> 
> >
> > So..I have m3back using Target.Int a bunch.
> >
> > And converting back and forth some between Target.Int and
> >
> > INTEGER and doing match with Target.Int.
> >
> > And various operations can fail.
> >
> >
> >
> >
> >
> > And my current diff results in:
> >
> >
> >
> >
> >
> >   new source -> compiling Lex.m3
> >   "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed
> >   "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed
> >   2 errors encountered
> >   new source -> compiling Scan.i3
> >
> >
> >
> >
> >
> >   which is nice to see, it means my code is actually running.
> >
> >
> >
> >
> >
> >   So I look at the code in question:
> >
> >
> >
> >
> >
> >   PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):
> > Word.T
> >   VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN
> > ...
> >
> >     IF signed AND
> >        ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR
> >         (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN
> >       RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)
> > ....
> >
> >
> >
> >
> >
> > -FIRST(INTEGER).
> >
> >
> >
> >
> >
> > What is that supposed to do?
> >
> >
> >
> >
> >
> > I mean, I kind of know, I'm slightly playing stupid, partly not.
> >
> > Does the compiler know what is an INTEGER vs. what is a "Word"?
>   ---------------------------------------------------------Word.T?
> 
> No, they are the same type.
> 
> > Or it is just obligated to assume everything is a Word?
> 
> It is obligated to do the builtin operators (unary - being one
> of these) using signed interpretation of the value and functions
> in Word using unsigned interpretation.
> 
> The signed operators don't assume anything about the machine
> representation.  The functions in Word do assume two-s complement
> binary, in order to be defined.  This is a low-level facility.
> 
> >  To do the negation at compile time and ignore the overflow?
> 
> This may be poorly specified.  The code sample you cite clearly assumes
> this is what it does.  The compile errors indicate the assumption
> has become wrong.
> 
> > Does the language need work here?
> 
> Overflow detection wars!  But surely, we could agree that compile time
> arithmetic should do the same thing as runtime would, for a given
> implementation.
> 
> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?
> 
> Yes, it's a statically unconditional overflow, and the language doesn't
> specify what happens.
> 
> As long as we are assuming two-s complement binary, I would just remove
> the - in front of FIRST(INTEGER). If the compiler does not consider it
> and overflow error and wraps around, in this particular case, the - is
> an identity operation on the bits.  Maybe the writer intended the -
> to hint to a human reader that unsigned interpretation is about to be
> applied to this value.
> 
> >
> >
> >
> >
> >  - Jay
> >
> >
> >
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100122/e3ab2126/attachment-0002.html>