<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I think there is a language hole here.<div>The language should perhaps allow for</div><div>unsigned literals and unsigned constant</div><div>expressions.</div><div><br></div><div><br></div><div>Something I don't quite have my head around as well,</div><div>maybe a language/library hole, is how to do</div><div>e.g. the below, without assuming two's complement</div><div>representation of signed integers.</div><div><br></div><div><br></div><div>Can we maybe add Word.AbsoluteValueOfInteger?</div><div>The implementation would, roughly:</div><div> IF i < 0 THEN </div><div> i := -i;</div><div> END;</div><div> RETURN i;</div><div> END;</div><div><br></div><div>with the extra qualification that overflow is silent</div><div><br></div><div><br></div><div> > But surely, we could agree that compile time<br style="text-indent: 0in !important; "> > arithmetic should do the same thing as runtime would, for a given<br style="text-indent: 0in !important; "> > implementation.</div><div><br></div><div>Uh huh. This is why you need *different types* (or interfaces)</div><div>for the variety of integer overflow behavior and not a runtime</div><div>setting. Otherwise the compiler can't know what the</div><div>runtime behavior is.</div><div><br></div><div><br></div><div>As well, using static typing instead of a runtime setting,</div><div>allows for efficiency. Imagine, say, if x86 does require</div><div>extra code to check for overflow.</div><div>Well, if using "integer-with-silent-overflow", that</div><div>would be omitted. If using "integer-with-overflow"</div><div>the code would be included.</div><div><br></div><div><br></div><div>I introduce the error. It used to be silent.</div><div>I changed it to a warning, for the</div><div>very specific case of negating FIRST(INTEGER).</div><div>Any other overflow here, which is probably not</div><div>possible, will still error.</div><div><br></div><div> - Jay<br><br><br>> Date: Fri, 22 Jan 2010 19:56:37 +0000<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] the meaning of -FIRST(INTEGER)?<br>> <br>> ><br>> > So..I have m3back using Target.Int a bunch.<br>> ><br>> > And converting back and forth some between Target.Int and<br>> ><br>> > INTEGER and doing match with Target.Int.<br>> ><br>> > And various operations can fail.<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > And my current diff results in:<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > new source -> compiling Lex.m3<br>> > "..\src\fmtlex\Lex.m3", line 227: doneg: Negate overflowed<br>> > "..\src\fmtlex\Lex.m3", line 343: doneg: Negate overflowed<br>> > 2 errors encountered<br>> > new source -> compiling Scan.i3<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > which is nice to see, it means my code is actually running.<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > So I look at the code in question:<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > PROCEDURE ReadNumber(rd: Rd.T; defaultBase: [2..16]; signed: BOOLEAN):<br>> > Word.T<br>> > VAR c: CHAR; sign: [0..1]; res: Word.T; BEGIN<br>> > ...<br>> ><br>> > IF signed AND<br>> > ((sign = 0 AND Word.GT(res, LAST(INTEGER))) OR<br>> > (sign = 1 AND Word.GT(res, -FIRST(INTEGER)))) THEN<br>> > RAISE FloatMode.Trap(FloatMode.Flag.IntOverflow)<br>> > ....<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > -FIRST(INTEGER).<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > What is that supposed to do?<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > I mean, I kind of know, I'm slightly playing stupid, partly not.<br>> ><br>> > Does the compiler know what is an INTEGER vs. what is a "Word"?<br>> ---------------------------------------------------------Word.T?<br>> <br>> No, they are the same type.<br>> <br>> > Or it is just obligated to assume everything is a Word?<br>> <br>> It is obligated to do the builtin operators (unary - being one<br>> of these) using signed interpretation of the value and functions<br>> in Word using unsigned interpretation.<br>> <br>> The signed operators don't assume anything about the machine<br>> representation. The functions in Word do assume two-s complement<br>> binary, in order to be defined. This is a low-level facility.<br>> <br>> > To do the negation at compile time and ignore the overflow?<br>> <br>> This may be poorly specified. The code sample you cite clearly assumes<br>> this is what it does. The compile errors indicate the assumption<br>> has become wrong.<br>> <br>> > Does the language need work here?<br>> <br>> Overflow detection wars! But surely, we could agree that compile time<br>> arithmetic should do the same thing as runtime would, for a given<br>> implementation.<br>> <br>> > I mean, like, -FIRST(INTEGER), that is a problematic expression, isn't it?<br>> <br>> Yes, it's a statically unconditional overflow, and the language doesn't<br>> specify what happens.<br>> <br>> As long as we are assuming two-s complement binary, I would just remove<br>> the - in front of FIRST(INTEGER). If the compiler does not consider it<br>> and overflow error and wraps around, in this particular case, the - is<br>> an identity operation on the bits. Maybe the writer intended the -<br>> to hint to a human reader that unsigned interpretation is about to be<br>> applied to this value.<br>> <br>> ><br>> ><br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br>> <br>> <br></div> </body>
</html>