[M3commit] CVS Update: cm3

[Jay K]

further clarification: We should be able to inject these functions as inlines at the start of any module, in terms of the gcc backend.
That is something we might want to explore a bit in general.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; jkrell at elego.de
> Date: Tue, 12 Jan 2010 18:47:44 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
>
> 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
>>