[M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Tue Jan 12 20:39:06 CET 2010


The MIPS for example has overflow traps on signed arithmetic.
SPARC has tagged arithmetic that causes an overflow trap.
x86 probably needs explicit test of the condition codes -- sigh!  That's why C is silent about integer arithmetic overflow...  because Intel can't support it via traps...

On 12 Jan 2010, at 13:47, Jay K wrote:

> 
> What hardware traps?
> 
> Sure, maybe integer divide by zero.
> 
> 
> Unlikely I think for integer overflow.
> I agree out of line inefficient.
> Probably want "check the carry flag" generated inline,
> in whatever machine-specific way that is done, may
> or may not require extra work in m3cg.
> 
> 
> I might try this soon though, where a command line option (for now)
> uses function calls and raises exceptions.
> My slightly refined thinking is that the generate code will look like:
> 
> 
> a := b + c * d;
> Foo()
> d := a + b * c;
> Bar()
> 
> 
> overflow = 0;
> a = add(b, mult(c, d), &overflow);
> if (overflow) Raise...
> Foo();
> overflow = 0;
> a = add(a, mult(b, c), &overflow);
> if (overflow) Raise...
> 
> 
> That is -- the overflow flag need only be checked "occasionally", such as before any function call, maybe at the start of any loop.
> Or at the very least, if a statement contains no function calls, only at the end of the statement, not after evaluating each term in an expression.
> 
> 
> Once overflow occurs, there's little requirement on how the statement proceeds. Though divide by zero shouldn't result. Probably if an expression contains any division, check overflow at each step.
> ?
> 
> 
> But maybe "check the overflow flag" is easy enough and right surely far more efficient.
> 
> 
> 
> - Jay
> 
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Tue, 12 Jan 2010 13:18:27 -0500
>> To: jkrell at elego.de
>> CC: m3commit at elegosoft.com
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> 
>> 
>> Do we really want to do this via compilation and out-of-line functions? Surely we would prefer to implement the FloatMode interface to catch hardware traps... I haven't looked at the details but that seems to be the intent...
>> 
>> 
>> 
>> On 12 Jan 2010, at 12:16, Jay Krell wrote:
>> 
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 10/01/12 12:16:59
>> 
>> Modified files:
>> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c
>> 
>> Log message:
>> add portable possible functions for implementing overflow checking of add/sub/mult of int, int64, uint, uint64
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100112/fbe9b0b0/attachment-0002.html>


More information about the M3commit mailing list