Thu, 25 Apr 2019 23:01:01 +0000 (UTC)

Related articles |
---|

[12 earlier articles] |

Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-23) |

Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-23) |

Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-23) |

Re: Optimization techniques rick.c.hodgin@gmail.com (Rick C. Hodgin) (2019-04-24) |

Re: Optimization techniques martin@gkc.org.uk (Martin Ward) (2019-04-25) |

Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-25) |

Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-04-25) |

Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-04-26) |

Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-04-26) |

Re: Optimization techniques alexfrunews@gmail.com (2019-04-26) |

Re: Optimization techniques derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2019-04-26) |

Re: Optimization techniques martin@gkc.org.uk (Martin Ward) (2019-04-26) |

Re: Optimization techniques martin@gkc.org.uk (Martin Ward) (2019-04-26) |

[15 later articles] |

From: | Kaz Kylheku <847-115-0292@kylheku.com> |

Newsgroups: | comp.compilers |

Date: | Thu, 25 Apr 2019 23:01:01 +0000 (UTC) |

Organization: | Aioe.org NNTP Server |

References: | <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> 19-04-020 |

Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="18127"; mail-complaints-to="abuse@iecc.com" |

Keywords: | design, optimize |

Posted-Date: | 25 Apr 2019 21:33:19 EDT |

On 2019-04-25, Martin Ward <martin@gkc.org.uk> wrote:

*> David Brown <david.brown@hesbynett.no> wrote:*

*>> And there are undefined behaviours which could be given definitions, but*

*>> doing so is not actually a positive thing. The prime example is signed*

*>> integer overflow. Since overflowing your integers is almost always an*

*>> error in the code anyway, there are no benefits in giving it defined*

*>> behaviour.*

*>*

*> This is completely backwards. If signed overflow was given a defined*

*> behaviour (such as the two's complement result), then compilers for*

*> CPUs which do not implement two's complement operations would have to*

*> generate less efficient code (but does anyone still make such a CPU?).*

*> Any program which guarantees not to overflow would be unaffected. Any*

*> program which expects a two's complement result could now be relied*

*> upon to work correctly, and not suddenly produce random results when*

*> the next version of the compuler comes out! Any program which*

*> expected a different result (one's complement anyone?) would need*

*> additional code.*

*>*

*> With the current situation, anyone wanting to avoid*

*> undefined behaviour (and don't we all?) has to write code like*

*> this for any signed operation:*

*>*

*> signed int sum;*

*> if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||*

*> ((si_b < 0) && (si_a < (INT_MIN - si_b)))) {*

*> /* Handle error */*

*> } else {*

*> sum = si_a + si_b;*

*> }*

Problem is that even though we have made the overflowing addition

defined behavior, it's often not the right behavior for the program,

which really wanted the arithmetic sum that doesn't fit into the type.

We still need to defend against this situation, and so need a glob of

code.

However, that code becomes a little bit simpler and more elegant: gone

are the INT_MAX and INT_MIN constants, and calculations:

int sum = si_a + si_b;

if ((si_a > 0 && si_b > 0 && sum < 0) ||

(si_a < 0 && si_b < 0 && sum > 0))

/* Handle error */

Overflow happens when the operands have the same sign, which is opposite

to the result's sign. We can test for that with bit ops:

if (((si_a ^ s_b) & SIGN_BIT_MASK) == 0) &&

((si_a ^ sum) & SIGN_BIT_MASK) != 0))

/* Handle error */

--

TXR Programming Lanuage: http://nongnu.org/txr

Music DIY Mailing List: http://www.kylheku.com/diy

ADA MP-1 Mailing List: http://www.kylheku.com/mp1

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.