On 17 January 2007 19:09, Joe Buck wrote:
> On Wed, Jan 17, 2007 at 05:48:34PM +0000, Andrew Haley wrote:
>> From a performance/convenience angle, the best place to handle this is
>> either libc or the kernel. Either of these can quite easily fix up
>> the operands when a trap happens, with zero performance degradation of
>> existing code. I don't think there's any need for gcc to be altered
>> to handle this.
>
> How will the kernel know whether the overflow in the divide instruction
> is because the user's source code has a '%' and not a '/'? We generate
> the exact same instruction for i / minus_one(), after all, and in that
> case the trap really should be there.
>
> I suppose that the trap handler could try to analyze the code following
> the divide instruction; if the quotient result is never used and the
> divisor is -1, it could replace the remainder result with zero and return.
> But that would be rather hairy, if it is even feasible. Alternatively,
> the divide instruction could be marked somehow, but I have no idea how.
Didn't someone suggest a no-op prefix somewhere back up-thread?
cheers,
DaveK
--
Can't think of a witty .sigline today....
