Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Date | 2016-12-08 22:05 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <o2chri$stf$1@dont-email.me> (permalink) |
| References | (13 earlier) <o28u0n$4v8$2@dont-email.me> <o2a3bg$cf6$1@dont-email.me> <o2a5ha$mb5$1@dont-email.me> <o2b8ql$bhk$1@dont-email.me> <490a9713-ac98-47f5-a8ec-a0c7825ee97c@googlegroups.com> |
On 08/12/16 16:44, supercat@casperkitty.com wrote:
> On Thursday, December 8, 2016 at 3:25:08 AM UTC-6, David Brown wrote:
>> Don't you also want to ask if it /should/ be done? I think in many
>> cases there is no need to have overflow checking in floating point
>> either - especially as the ability to check for overflow can be
>> extremely costly. In particular, if you have overflow checking (for
>> integer or floating point) you hinder a lot of compiler optimisation
>> such as re-arrangement of expressions, as your operations are no longer
>> commutable, associative, and otherwise mathematically "nice". And when
>> dealing with "big" processors, overflow checking means you can't do
>> things in parallel using SIMD or vector instructions.
>
> Many optimizations can be maintained if overflow may, but need not be,
> reported in cases where a program would manage to yield arithmetically-
> correct output anyway, and if a program need not be notified of the
> precise place where overflow occurred but merely informed that an overflow
> may have resulted in inaccurate results having been produced.
>
>> I agree that overflow checking can sometimes be useful for testing and
>> debugging. If you want to implement it, there are various methods:
>
> It's often more important in production code. While there may be a few
> places where efficiency is more important than safety, most programs spend
> the vast majority of their time in a tiny portion of the code, and except
> in places where code size is critical (small embedded systems) the cost
> of using overflow checking outside the most time-critical loops would be
> relatively slight. Further, on many platforms a compiler that is designed
> to optimize such checks may be able to perform them quite cheaply even in
> an optimized loop. For example, on some ARM platforms, a loop which needs
> to add many 32-bit values to yield a 32-bit sum and report whether an
> overflow occurred could perform such a check with almost zero extra overhead
> by using conditional instructions. Start by loading r6 with a counter that
> will hit 0x80000000 on the last iteration, and then generate code equivalent
> to:
>
> do {
> fetch *r5++ into r0,r1,r2,r3
> if (!last_add_overflowed) r4+=r0;
> if (!last_add_overflowed) r4+=r1;
> if (!last_add_overflowed) r4+=r2;
> if (!last_add_overflowed) r4+=r3;
> if (!last_add_overflowed) r6++;
> } while(!last_add_overflowed);
>
> The conditional checks add zero time overhead on the ARM7-TDMI or
> Cortex-M3 (and probably some other versions as well), so there would
> be zero per-loop overhead. The only extra time cost in the non-overflow
> case would be adjusting the index in r6 (so it will set the overflow flag
> on the last repetition) and checking whether the index reached 0x80000000
> before the loop terminated. Note that if an overflow does occur the value
> in r5 would be meaningless (code wouldn't know which registers had been
> added to r5) but if code were to only use the total in the non-overflow
> case a compiler wouldn't have to worry about that. If the mod-0xFFFFFFFF
> value is needed in the overflow case, that could be handled at a cost of
> one extra instruction per loop [save the value of r4 before on each
> repetition so the last four adds can be repeated once overflow is detected]
> or else by restarting the loop from scratch on the first overflow [doubling
> the cost of the loop in the first-overflow case].
As usual, you examples are very creative and very unrealistic. Adding
up 2^31 numbers but stopping when there is an overflow? Never happens.
Conditional checks are /not/ zero time overhead on any ARM devices,
though they can be close to zero overhead on pipelined superscaler
devices where skipped instructions can be eliminated early. On devices
such as the M3, the skipped instruction still takes a cycle to do
nothing, and it still costs in the bandwidth to read in the skipped
instruction.
At best, your code would be looking for something like:
ITE VC // if-then-else overflow clear
ADD.VC r4, r0, r4 // r4 = r0 + r4 if overflow clear
B.VS exitloop // else branch if overflow set
for each of the add lines.
On the other hand, with a nice simple 64-bit sum stored in r4, r7 then
the critical lines become:
ADDS r4, r0, r4 // r4 = r0 + r4, set carry flag
ADC r7, r7, #0 // r7 = r7 + 0 + carry flag
That is shorter and faster. At the edge of the loop, check r7 to
indicate an overflow.
Alternatively, on an M4 with saturating arithmetic, just do it all as
saturated addition and check for the saturated flag at the end. That
would be rather target-specific, but that's okay - and you can use the
ARM CMSIS headers to make it compiler independent.
>
>> 1. Make it machine-dependent and have a way to check for an "overflow
>> flag" after an operation. This only makes sense on processors that
>> actually have an overflow flag. It is also, IMHO, a poor solution. It
>> gets really messy for expressions of more than one part - how is the
>> flag set in "(a + b) * (c + d)" ? The user pays a high price in weak
>> code generation even when he knows there is no overflow.
>> ...
>> 5. I expect there are more ideas ...
>
> 5. Have a per-thread flag (perhaps errno, or perhaps something else) which
> is set when an overflow occurs. My inclination would be to have macros
> which would check if an overflow occurs, reset the flag, or save/restore
> the flag, and specify that implementations may use errno or something
> else, at their convenience.
>
It is certainly possible to do that, yes.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
"Let’s Stop Bashing C" Lynn McGuire <lynnmcguire5@gmail.com> - 2016-12-05 19:57 -0600
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 02:34 +0000
Re: "Let’s Stop Bashing C" BGB <cr88192@hotmail.com> - 2016-12-06 00:13 -0600
Re: "Let’s Stop Bashing C" BartC <bc@freeuk.com> - 2016-12-06 23:15 +0000
Re: "Let’s Stop Bashing C" BGB <cr88192@hotmail.com> - 2016-12-06 21:16 -0600
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 11:54 +0000
Re: "Let’s Stop Bashing C" BartC <bc@freeuk.com> - 2016-12-06 12:07 +0000
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 12:25 +0000
Re: "Let’s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-06 14:07 +0100
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 13:40 +0000
Re: "Let’s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 19:40 +0100
Re: "Lete2��s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-06 13:55 -0500
Re: "Lete2��s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 19:13 +0000
Re: "Lete2��s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-06 11:51 -0800
Re: "Lete2��s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 12:22 -0800
Re: "Lete2��s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 20:16 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 11:20 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 22:15 +0100
Re: "Lete2�™s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-06 16:49 -0500
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 14:24 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:07 +0100
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-07 22:04 +0100
Re: micro-architectural details jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 23:44 +0100
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-07 23:02 +0000
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-07 15:28 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 21:36 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 12:56 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:03 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 14:21 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:36 +0100
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-08 21:59 +0000
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:25 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 14:34 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:59 +0100
Re: micro-architectural details Melzzzzz <mel@zzzzz.com> - 2016-12-09 00:18 +0100
Re: micro-architectural details fir <profesor.fir@gmail.com> - 2016-12-09 00:06 -0800
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-09 11:35 +0000
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-09 12:12 +0000
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-09 13:33 +0100
Re: micro-architectural details Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-09 15:41 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 09:28 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-10 09:58 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:53 -0800
Re: micro-architectural details Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 03:10 -0600
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-11 13:48 +0000
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-11 14:43 +0000
Re: micro-architectural details Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 16:23 +0000
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-11 12:53 -0800
Re: micro-architectural details Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:27 +0000
Re: micro-architectural details supercat@casperkitty.com - 2016-12-11 08:46 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:14 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-15 08:25 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:11 -0800
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-15 14:28 +0000
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-11 18:38 +0100
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 00:25 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-09 07:42 -0800
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-09 11:54 -0800
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-09 10:27 +0100
Re: other missing features (no-brainers) Noob <root@127.0.0.1> - 2016-12-09 17:05 +0100
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-09 09:51 +0000
Re: "Lete2�™s Stop Bashing C" Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 20:42 -0500
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 14:16 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:31 +0100
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-06 15:55 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 01:01 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 16:42 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 01:55 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-07 07:11 -0800
Re: "Lete2??s Stop Bashing C" Ike Naar <ike@iceland.freeshell.org> - 2016-12-06 23:05 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:43 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 03:06 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:47 +0100
Re: "Lete2??s Stop Bashing C" Thiago Adams <thiago.adams@gmail.com> - 2016-12-07 03:10 -0800
Re: "Lete2??s Stop Bashing C" Thiago Adams <thiago.adams@gmail.com> - 2016-12-07 03:13 -0800
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 11:47 +0000
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 12:08 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-07 23:45 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 00:22 +0100
Re: "Lete2??s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 15:32 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 01:25 +0100
Re: "Let's Stop Bashing C" supercat@casperkitty.com - 2016-12-07 16:36 -0800
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 17:09 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 10:28 +0100
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-08 08:34 -0800
Re: "Let's Stop Bashing C" Gareth Owen <gwowen@gmail.com> - 2016-12-08 20:08 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 10:24 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 15:49 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 15:23 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 16:58 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 18:57 +0000
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 15:29 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 17:09 +0100
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 16:41 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 17:04 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 17:15 +0100
Re: "Lete2??s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:34 -0500
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 18:40 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 10:00 -0800
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 19:05 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 19:58 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 08:22 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 20:12 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 11:40 -0800
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 02:44 -0600
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 16:22 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 20:14 +0100
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 02:19 -0600
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 07:44 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 22:05 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 22:14 +0100
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-09 10:39 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 13:33 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-09 11:13 +0100
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 06:27 -0600
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-07 07:17 -0800
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 23:43 -0600
Re: "Lete2??s Stop Bashing C" Ike Naar <ike@iceland.freeshell.org> - 2016-12-07 07:41 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:45 +0100
Re: "Lete2??s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 09:22 -0800
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:49 +0100
Re: "Lete2??s Stop Bashing C" Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:28 -0500
Re: "Lete2��s Stop Bashing C" "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-06 14:22 -0500
Re: Subject field encoding Noob <root@127.0.0.1> - 2016-12-07 21:40 +0100
Re: Subject field encoding Keith Thompson <kst-u@mib.org> - 2016-12-07 13:01 -0800
Re: Subject field encoding Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 16:02 -0500
Re: "Lete2�™s Stop Bashing C" asetofsymbols@gmail.com - 2016-12-08 15:50 -0800
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 19:07 +0000
Re: "Let€™s Stop Bashing C" Xcott Craver <nospam@nospam.invalid> - 2016-12-07 16:48 -0500
Re: "Let's Stop Bashing C" Noob <root@127.0.0.1> - 2016-12-07 23:29 +0100
Re: "Let’s Stop Bashing C" "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-06 12:06 +0800
csiph-web