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

[Tony Hosking]

There's no language hole!  Unsigned literals and unsigned constant expressions can easily be handled.

Literals:

If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a sixteen-bit two's complement machine, 16_FFFF and -1represent the same value.

Constant expressions:

CONST x = Word.Plus(16_FFFF, 1)


On 22 Jan 2010, at 17:51, Jay K wrote:

> I think there is a language hole here.
> The language should perhaps allow for
> unsigned literals and unsigned constant
> expressions.
> 
> 
> Something I don't quite have my head around as well,
> maybe a language/library hole, is how to do
> e.g. the below, without assuming two's complement
> representation 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 runtime
> setting. Otherwise the compiler can't know what the
> runtime behavior is.
> 
> 
> As well, using static typing instead of a runtime setting,
> allows for efficiency. Imagine, say, if x86 does require
> extra code to check for overflow.
> Well, if using "integer-with-silent-overflow", that
> would 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 the
> very specific case of negating FIRST(INTEGER).
> Any other overflow here, which is probably not
> possible, 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/2b9bcb0a/attachment-0002.html>