From: | George Neuner <gneuner2@comcast.net> |
Newsgroups: | comp.compilers |
Date: | Sat, 04 May 2019 17:44:02 -0400 |
Organization: | A noiseless patient Spider |
References: | 19-04-021 19-04-023 19-04-037 19-04-039 19-04-042 19-04-044 19-04-047 19-05-004 19-05-006 19-05-016 19-05-017 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="77178"; mail-complaints-to="abuse@iecc.com" |
Keywords: | debug, errors, comment |
Posted-Date: | 04 May 2019 18:32:15 EDT |
On Fri, 3 May 2019 10:52:27 +0100, Martin Ward <martin@gkc.org.uk>
wrote:
>On 2019-05-01, David Brown <david.brown@hesbynett.no> wrote:
>> Detecting signed overflow at run-time can be a significant cost.
>
>Firstly: the cost is not as high as the cost of security breaches due
>to buffer overflows.
Exactly. In well written code, often it is possible to amortize
up-front limit tests over a substantial block of code. Similar to
hoisting common subexpressions.
>Secondly: if many popular languages specified
>suitable handling for signed overflow, buffer overruns and so on, then
>CPUs hardware would be developed which makes these tests efficient:
>because compiled code in these popular languages would run faster on
>such CPUs.
Intel and AMD CPUs have bounds check instructions: but they are
cumbersome (similar to using segments), cause exceptions rather than
setting flags, and the instructions are relatively slow because few
compilers ever used them.
George
[Are you referring to the old BOUND instruction or the newer MPX feature. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.