Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98113 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2016-12-05 19:57 -0600 |
| Last post | 2016-12-06 12:06 +0800 |
| Articles | 20 on this page of 131 — 25 participants |
Back to article view | Back to comp.lang.c
"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
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2016-12-09 09:51 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <eavd59F5kggU1@mid.uni-berlin.de> |
| In reply to | #98315 |
jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 07/12/2016 à 22:04, Noob a écrit :
> > On 07/12/2016 00:07, jacobnavia wrote:
> >
> >> Look, a non taken jump on overflow is one cycle. No memory access, since
> >> a CPU flag doesn't take any. The only overhead is code size:
> >
> > When you mention CPU-specific details, it's obvious you
> > have Intel CPUs in mind.
> Obvious of course. I am programming lcc-win for ARM-64, and have done
> versions for the power pc and even a 16 bit CPU.
> You do not know what you are talking about when you speak about me. You
> do not even know what I do.
> > Not all architectures have an
> > "overflow flag". Not all architectures have a "one cycle
> > penalty for non-taken jumps".
> >
> Yes, other architectures have more cycles. But programming is not about
> getting something in less cycles, it is about getting correct results!
Well, you're talking about a certain kind of programming. But
there are others too you don't seem to consider. Here's just
a data point.
I very recently had to modify the bootloader for an embedded
(ARM) system. This is the code that is loaded by the firmware
in the CPU from NAND (where it has to reside at a specific
address). Since at that time not even the controller for ex-
ternal SDRAM is initialized, the bootloader gets loaded into
CPU-internal RAM, of which there's only 4 kB. Thus the boot-
loader must be smaller than that, still leaving room for a
bit of stack. The bootloader does some hardware initiali-
zation (e.g. setting up the SDRAM controller and some other
crucial sub-systems) and then loads the kernel (and the device
tree blob) into (external) memory before passing control to
the now loaded kernel.
Obviously, correctness of that program is crucial. But it's
necessary that the program fits into those 4 kB of internal
CPU RAM. It was a very tight fit indeed, I ended up with
104 bytes left for the stack (that's space for just 26
addresses or integer data items).
The program doesn't do much integer arithmetic, but even a few
additional required instructions would have made it impossible
to squeeze it into the available space (or would have required
what amounts to a rewrite of the whole existing program, making
it incompatible to what's maintained up-stream and taking a real
lot of extra time).
Since nowadays C probably is mostly used in embedded pro-
gramming, where tight requirements are common, anything
like overflow checking or array bounds checking (something
else you seem to think should go into the language, if I
remember correctly) should definitely not be mandated by the
language. I find nothing to say against having that as optional
features (which some compilers, your's included, already sup-
port), it would be indeed nice in a number of circumstances -
I'd be the first to use them. But don't try to make that manda-
tory since it might render C unusable for an important field
of programming where it's now used everywhere.
Also speed can be an issue in this context. It's not uncommon
that you are dealing with a microcontroller that does not run
with a GHz clock but something in the single digit MHz range
and where there are severe time constraints on what can be
done e.g. in an interrupt handler and thus each cycle really
counts (yes, on those tiny things CPU time is still more or
less directly proportional to the number of instructions as
in the good old days of the Z-80 and friends;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-06 20:42 -0500 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <o27pbc$7vp$4@jstuckle.eternal-september.org> |
| In reply to | #98216 |
On 12/6/2016 5:24 PM, supercat@casperkitty.com wrote: > On Tuesday, December 6, 2016 at 3:49:12 PM UTC-6, Lew Pitcher wrote: >> Why not have your code generate a signal (like the floatingpoint error signal >> SIGFPE, but for integer operations) when an arithmetic overflow occurs? That >> way, arithmetic overflow could be handled in the same manner as floatingpoint >> exceptions and leave the programmer in charge of whether (and how) to handle >> the occurrence. Yes, it would be a non-standard extension of C's asynchronous >> signal handling facilities, but would fit with both the current programming >> practice that ignore overflows, /and/ the current programming practice that >> handles asynchronous math failures through signals. > > Much of the cost of overflow trapping comes not from the expense of > checking for overflow, but rather the limitations it imposes upon a > compiler's ability to optimize the sequence in which operations are > performed. If the expression "x+y+z" occurs in a loop, even if x and > z do not change within the loop, a compiler with precisely-defined > overflow semantics would need to evaluate that using two additions > and two overflow checks. If the compiler could specify looser overflow > semantics, however, it could evaluate (x+z) outside the loop and, if > that subexpression didn't overflow, it could replace x+y+z with (x+z)+y, > saving an overflow check within the loop. That would cause a compiler > not to report overflow in cases where (x+y) would overflow but (x+z)+y > wouldn't, but in cases where the latter expression can be evaluated > without overflow the fact that (x+y)+z can't be evaluated without overflow > shouldn't matter. > Yes and no. Some processors have an overflow flag which checks for such operations. But even if the processor does, it would be an unnecessary check according to the C philosophy. It's like going out of bounds on an array. C doesn't check to ensure a request is within the array bounds; that is the programmer's responsibility. The same with overflow. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 14:16 -0800 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <52ccfda1-19b5-4996-ae9c-18b98ea6dd4f@googlegroups.com> |
| In reply to | #98209 |
On Tuesday, December 6, 2016 at 3:15:52 PM UTC-6, jacobnavia wrote:
> That costs around 4% when I wrote the first version of the software, but
> can go down to 1-2% when you try to optimize a little bit.
>
> We, discussed this here extensively in a thread that I started in
> comp.std.c and here in Sep 1, 2009.
The problem is that if user code explicitly checks for overflow, then a
compiler must generate code which detects overflow in all cases where the
user code checks for it, even in scenarios where the user wouldn't care
about overflow because it wouldn't interfere with correct computations.
Consider as a simple example, x=(y+z)>>1; on an implementation which
promises to trap any signed overflows which could result in numerical
inaccuracy, and documents signed >> as floored power-of-two dovision. While
it could be implemented on x86 as
add esi,edi
jo overflow_occurred
asr esi,1
it could be even more efficiently implemented as:
add esi,edi
ror esi,1
In the event that the addition of ESI+EDI would overflow, a compiler would
be entitled to trap, but letting a compiler yield the arithmetically-correct
result even when not required to do so could yield more efficient code.
An even more extreme example of that principle would occur in cases where
a function computes a number of values, some of which will be ignored by
many callers. If a caller is going to ignore a value, but its computation
could result in overflow, a compiler won't be able to optimize out any
user-written checks for overflow. If, however, a compiler instead has its
own support for overflow trapping/reporting, it would only need to check
for overflows in calculations which are actually used for some purpose. If
the result of a calculation isn't used, it should be possible to omit the
calculation altogether, rendering the question of overflow moot.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-07 00:31 +0100 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <o27hmq$frb$1@dont-email.me> |
| In reply to | #98215 |
Le 06/12/2016 à 23:16, supercat@casperkitty.com a écrit : > On Tuesday, December 6, 2016 at 3:15:52 PM UTC-6, jacobnavia wrote: >> That costs around 4% when I wrote the first version of the software, but >> can go down to 1-2% when you try to optimize a little bit. >> >> We, discussed this here extensively in a thread that I started in >> comp.std.c and here in Sep 1, 2009. > > The problem is that if user code explicitly checks for overflow, then a > compiler must generate code which detects overflow in all cases where the > user code checks for it, even in scenarios where the user wouldn't care > about overflow because it wouldn't interfere with correct computations. > > Consider as a simple example, x=(y+z)>>1; on an implementation which > promises to trap any signed overflows which could result in numerical > inaccuracy, and documents signed >> as floored power-of-two dovision. While > it could be implemented on x86 as > > add esi,edi > jo overflow_occurred > asr esi,1 > > it could be even more efficiently implemented as: > > add esi,edi > ror esi,1 > You think then, that asr is more expensive than ror? If I eliminate the test for overflow, the first code becomes > add esi,edi > asr esi,1 What is the same thing as your proposed better > add esi,edi > ror esi,1 Arithmetic shift right, and rotate right are the same, I do not think there is even a measurable difference after billions of operations... We are running at 2GHZ at least... Testing the overflow flag is nothing, and the difference between asr/ror is not even measurable. Same with most processors: testing a CPU flag incurs NO I/O, not even a register data movement and are extremely fast operations in all processors. > In the event that the addition of ESI+EDI would overflow, a compiler would > be entitled to trap, but letting a compiler yield the arithmetically-correct > result even when not required to do so could yield more efficient code. > At the risk of corrupting the results? Wait... it depends. If the numbers you are calculating are of no great importance, why do you calculate them anyway? I just do not follow very much your logic. There is practically no difference between checking or not checking! > An even more extreme example of that principle would occur in cases where > a function computes a number of values, some of which will be ignored by > many callers. If a caller is going to ignore a value, but its computation > could result in overflow, a compiler won't be able to optimize out any > user-written checks for overflow. If, however, a compiler instead has its > own support for overflow trapping/reporting, it would only need to check > for overflows in calculations which are actually used for some purpose. If > the result of a calculation isn't used, it should be possible to omit the > calculation altogether, rendering the question of overflow moot. > Contrary to your examples I have a lot of counter examples where an overflow should be checked but it wasn't. In an implementation: void *calloc(size_t items, size_t itemsize); There was an implementation of that function that did not test, and with specially built arguments would return a small buffer instead of a huge one. And that is one of the thousands of similar errors. Why this obstination with "efficiency" when there is almost none? What is the efficiency of wrong results? Because you introduce noise in the data, and I have the vague feeling sometimes, that MOST OF THE CALCULATION RESULTS ARE USED! I would say even all of them in any serious software. The common case is far more important than those fringe cases. And I think that we can safely forget about the problems of software that calculates things for nothing, since the results are no used... Modern compilers optimize that away. Lcc-win doesn't in many cases but gcc/clang/whatever do that kind of stuff.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-06 15:55 -0800 |
| Subject | Re: "Let's Stop Bashing C" |
| Message-ID | <lnlgvs3955.fsf_-_@kst-u.example.com> |
| In reply to | #98221 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> In an implementation:
>
> void *calloc(size_t items, size_t itemsize);
>
> There was an implementation of that function that did not test, and with
> specially built arguments would return a small buffer instead of a huge one.
Then that implementation is non-conforming. The specification of calloc
doesn't say it multiplies its argument, it says it "allocates space for
an array of nmemb objects, each of whose size is size".
Do you happen to remember which implementation had this bug?
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-07 01:01 +0100 |
| Subject | Re: "Let's Stop Bashing C" |
| Message-ID | <o27jeo$lr5$1@dont-email.me> |
| In reply to | #98224 |
Le 07/12/2016 à 00:55, Keith Thompson a écrit : > Do you happen to remember which implementation had this bug? You would have to look for the calloc discussion. There were specially crafted arguments that provoked an overflow with a very small result, but not zero, so the returned buffer was wrong but not null. We discussed that here some years ago. It was a Mac implementation if I remember correctly. I remember proposing to everyone to check their implementations and most compilers did check OK.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 16:42 -0800 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <34568063-b96c-4984-981d-f386b2636068@googlegroups.com> |
| In reply to | #98221 |
On Tuesday, December 6, 2016 at 5:32:01 PM UTC-6, jacobnavia wrote:
> Le 06/12/2016 à 23:16, supercat a écrit :
> > Consider as a simple example, x=(y+z)>>1; on an implementation which
> > promises to trap any signed overflows which could result in numerical
> > inaccuracy, and documents signed >> as floored power-of-two dovision. While
> > it could be implemented on x86 as
> >
> > add esi,edi
> > jo overflow_occurred
> > asr esi,1
> >
> > it could be even more efficiently implemented as:
> >
> > add esi,edi
> > ror esi,1
> >
>
> You think then, that asr is more expensive than ror?
The first version needs a test to ensure that any arithmetically-incorrect
results get flagged. The latter doesn't, since it won't produce any
arithmetically-incorrect results.
> If I eliminate the test for overflow, the first code becomes
> > add esi,edi
> > asr esi,1
And if the two values were 1000000000 and 2000000000, it will report their
average as -647483648 without indicating that an overflow occurred. The
optimized version will return 1500000000 with no overflow.
> What is the same thing as your proposed better
> > add esi,edi
> > ror esi,1
My version will work correctly, without overflow, when values exceed the
range of int. Even if trapped overflows would be acceptable, having
overflows not occur in the first place isn't any worse.
> Same with most processors: testing a CPU flag incurs NO I/O, not even a
> register data movement and are extremely fast operations in all processors.
If the averaging code occurs within a loop, it could be a significant
performance difference on many kinds of embedded processors. Not
monstrous, but bigger than some other performance improvements that
compiler writers chase after.
> > In the event that the addition of ESI+EDI would overflow, a compiler would
> > be entitled to trap, but letting a compiler yield the arithmetically-correct
> > result even when not required to do so could yield more efficient code.
>
> At the risk of corrupting the results?
What do you mean? If code tries to average 1000000000 and 2000000000, it
would be acceptable to report an overflow, but yielding 1500000000 without
signalling an overflow should be no less helpful. Yielding -647483648 or
doing anything else weird may not be acceptable, but the ror version does
not do either of those things.
> Wait... it depends. If the numbers you are calculating are of no great
> importance, why do you calculate them anyway?
>
> I just do not follow very much your logic. There is practically no
> difference between checking or not checking!
The "ror" version yields arithmetically-correct results even in cases
where the value before the shift would be too large to fit in an "int".
An even simpler example would be "long long x = int1*int2;". If a
compiler can yield a 64-bit result as cheaply as a 32-bit one, would it
make more sense to check whether a 32-bit multiply overflows, or just
use the result from a 64-bit multiply directly?
> > An even more extreme example of that principle would occur in cases where
> > a function computes a number of values, some of which will be ignored by
> > many callers. If a caller is going to ignore a value, but its computation
> > could result in overflow, a compiler won't be able to optimize out any
> > user-written checks for overflow. If, however, a compiler instead has its
> > own support for overflow trapping/reporting, it would only need to check
> > for overflows in calculations which are actually used for some purpose. If
> > the result of a calculation isn't used, it should be possible to omit the
> > calculation altogether, rendering the question of overflow moot.
>
> Contrary to your examples I have a lot of counter examples where an
> overflow should be checked but it wasn't.
Of course, which is why it would be desirable to have a language include
an option to check for overflows in cases where they might cause incorrect
results.
> In an implementation:
>
> void *calloc(size_t items, size_t itemsize);
>
> There was an implementation of that function that did not test, and with
> specially built arguments would return a small buffer instead of a huge one.
Of course, unsigned overflow is an entirely different animal from signed
overflow.
> And that is one of the thousands of similar errors. Why this obstination
> with "efficiency" when there is almost none?
Compiler writers seem to chase after far smaller efficiency improvements
which break a lot of existing code. I want ways of specifying what things
are actually important, so that compilers can implement real efficiency
improvements.
> What is the efficiency of wrong results? Because you introduce noise in
> the data, and I have the vague feeling sometimes, that MOST OF THE
> CALCULATION RESULTS ARE USED!
In many cases that's true, but in some cases it should be patently clear
that results aren't used. Is any useful purpose served by having a compiler
for a two's-complement system with 32-bit int and 16-bit short treat
unsigned mul(unsigned short x, unsigned short y) { return x*y; }
as something other than an unsigned 16x16->32 multiply?
> I would say even all of them in any serious software. The common case is
> far more important than those fringe cases.
> And I think that we can safely forget about the problems of software
> that calculates things for nothing, since the results are no used...
>
> Modern compilers optimize that away. Lcc-win doesn't in many cases but
> gcc/clang/whatever do that kind of stuff.
If code checks whether calculations would cause overflow and sets a per-
thread overflow flag if so, and something later checks that flag to see if
an overflow occurred, then the check of the overflow flag will create a
dependency upon all code which could have set it, even if the result of
those calculations would otherwise have been unused.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-07 01:55 +0100 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <o27mil$1uj$1@dont-email.me> |
| In reply to | #98226 |
Le 07/12/2016 à 01:42, supercat@casperkitty.com a écrit : > If code checks whether calculations would cause overflow and sets a per- > thread overflow flag if so, and something later checks that flag to see if > an overflow occurred, then the check of the overflow flag will create a > dependency upon all code which could have set it, even if the result of > those calculations would otherwise have been unused. It is THAT difficult for an advanced compiler to ignore the flag check when establishing dependencies? I do not think so. In a similar vein, code reorganization can still be done if the operation and the test for overflow are moved together always.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-07 07:11 -0800 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <a4264cee-2047-4986-b2ff-741c267edc69@googlegroups.com> |
| In reply to | #98227 |
On Tuesday, December 6, 2016 at 6:55:12 PM UTC-6, jacobnavia wrote:
> Le 07/12/2016 à 01:42, supercat a écrit :
> > If code checks whether calculations would cause overflow and sets a per-
> > thread overflow flag if so, and something later checks that flag to see if
> > an overflow occurred, then the check of the overflow flag will create a
> > dependency upon all code which could have set it, even if the result of
> > those calculations would otherwise have been unused.
>
> It is THAT difficult for an advanced compiler to ignore the flag check
> when establishing dependencies?
>
> I do not think so.
If I write a function which is supposed to take two int32_t[] arrays and
either report the sum of products or report that an overflow occurred,
with the proviso that an overflow may *but need not* be reported if an
intermediate result would overflow but the function produces a correct
result anyway, and I write something like:
int compute_sum(int32_t *result, int32_t *x[], int32_t *y, size_t count)
{
int64_t sum = 0;
for (int i=0; i<count; i++)
{
sum += (int64_t)x[i]*y[i];
if (sum < INT_MIN || sum > INT_MAX)
return 1;
}
*result = sum;
return 0;
}
a compiler would not be allowed to parallelize the addition since it would
be required to generate code that stops as soon as an overflow occurs on
any intermediate computation. Even if it would be cheaper for the compiler
to determine that the arithmetically-correct sum of products would fit in
an int32_t and report that value, the compiler wouldn't have such an option.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-12-06 23:05 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <slrn3vfso4eh4n.o6p.ike@iceland.freeshell.org> |
| In reply to | #98209 |
On 2016-12-06, jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 06/12/2016 ? 20:20, supercat@casperkitty.com a ?crit : >> In Standard C, determining whether an arithmetic operation would produce an >> overflow is generally much more difficult than performing the operation in >> the non-overflow case. In many cases, it will be difficult or impossible >> for a compiler to generate code which is anywhere near as efficient as would >> be possible if the language supported better overflow semantics. > > A compiler can (as I did with lcc-win) test always the overflow flag > after each operation that can generate an overflow condition. What if the hardware does not support an overflow flag? (Example: the DEC Alpha).
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-07 00:43 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o27id0$ht9$1@dont-email.me> |
| In reply to | #98217 |
Le 07/12/2016 à 00:05, Ike Naar a écrit : > On 2016-12-06, jacobnavia <jacob@jacob.remcomp.fr> wrote: >> Le 06/12/2016 ? 20:20, supercat@casperkitty.com a ?crit : >>> In Standard C, determining whether an arithmetic operation would produce an >>> overflow is generally much more difficult than performing the operation in >>> the non-overflow case. In many cases, it will be difficult or impossible >>> for a compiler to generate code which is anywhere near as efficient as would >>> be possible if the language supported better overflow semantics. >> >> A compiler can (as I did with lcc-win) test always the overflow flag >> after each operation that can generate an overflow condition. > > What if the hardware does not support an overflow flag? > (Example: the DEC Alpha). > The DEC Alpha supports testing for overflow. I wrote in this newsgroup on Sep 1 2009: <quote> > DEC Alpha assembler manual page 23 (in the pdf file) > > "Overflow exceptions occur when arithmetic operations compute signed > values and the destination lacks the precision to store the result" > > Page 48 lists the assembler operations and we have: > > ... > Add longword (with overflow): addlv > Multiply longword (with overflow) mullv <end quote> At that time, a certain Mr Carmody started that thing just like you. Six and half years have passed and still the same people oppose any progress, any change with the same falsehoods. I repeat: The dec alpja has an overflow flag that will be triggered by suitable opcodes that do NOT discard the value of that flag but write it, so you can test it in the next instructions. The dec alpha had already disappeared when Carmody brought that bright idea... Six and half years later and it has not been rebuilt... Other processors (risc machines) do the same. But you can still repeat the same nonsense and I still can tell you GO FUCK! This ensures that hodgin will not answer this message since he said that he will never answer to a post with obscenities.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-07 03:06 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <87y3zsfnep.fsf@bsb.me.uk> |
| In reply to | #98223 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 07/12/2016 à 00:05, Ike Naar a écrit : >> On 2016-12-06, jacobnavia <jacob@jacob.remcomp.fr> wrote: >>> Le 06/12/2016 ? 20:20, supercat@casperkitty.com a ?crit : >>>> In Standard C, determining whether an arithmetic operation would produce an >>>> overflow is generally much more difficult than performing the operation in >>>> the non-overflow case. In many cases, it will be difficult or impossible >>>> for a compiler to generate code which is anywhere near as efficient as would >>>> be possible if the language supported better overflow semantics. >>> >>> A compiler can (as I did with lcc-win) test always the overflow flag >>> after each operation that can generate an overflow condition. >> >> What if the hardware does not support an overflow flag? >> (Example: the DEC Alpha). >> > > The DEC Alpha supports testing for overflow. Yes, but I don't think it has an overflow flag. Originally you were proposing a function that gives you access to this flag. Are you arguing for a specific mechanism like that, or just that C should offer some machine-specific form of detection be it a flag, and exception or whatever? > I wrote in this newsgroup on Sep 1 2009: > > <quote> >> DEC Alpha assembler manual page 23 (in the pdf file) >> >> "Overflow exceptions occur when arithmetic operations compute signed >> values and the destination lacks the precision to store the result" >> >> Page 48 lists the assembler operations and we have: >> >> ... >> Add longword (with overflow): addlv >> Multiply longword (with overflow) mullv > <end quote> These instructions raise an exception when overflow occurs. No doubt one could harness that to provide what looks like an overflow flag but it would not be as simple as returning a bit from some status register. <snip> > I repeat: > > The dec alpja has an overflow flag that will be triggered by suitable > opcodes that do NOT discard the value of that flag but write it, so > you can test it in the next instructions. I don't think that's how it works at all. What is your source for this? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-07 11:47 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o28p9e$lhj$2@dont-email.me> |
| In reply to | #98232 |
Le 07/12/2016 à 04:06, Ben Bacarisse a écrit : > These instructions raise an exception when overflow occurs. No doubt > one could harness that to provide what looks like an overflow flag but > it would not be as simple as returning a bit from some status register. So what? Any overflow trap sets that flag! And it would be simpler than what I have to generate for the x86. In the x86 I have to generate the test and the jump. Using the dec alpha I wouldn't have to generate anything, just set the overflow signal to a function that does the appropiate thing. All the code I need to generate for doing the same thing would be superfluous. I repeat: There is NO MACHINE that hasn't a way for testing overflow, even if all regulars here say the contrary.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-12-07 03:10 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <fd3cc5ce-8c3f-4e8c-ba35-bd668d10d082@googlegroups.com> |
| In reply to | #98240 |
On Wednesday, December 7, 2016 at 8:47:33 AM UTC-2, jacobnavia wrote:
> Le 07/12/2016 à 04:06, Ben Bacarisse a écrit :
> > These instructions raise an exception when overflow occurs. No doubt
> > one could harness that to provide what looks like an overflow flag but
> > it would not be as simple as returning a bit from some status register.
>
> So what?
> Any overflow trap sets that flag!
>
> And it would be simpler than what I have to generate for the x86. In the
> x86 I have to generate the test and the jump. Using the dec alpha I
> wouldn't have to generate anything, just set the overflow signal to a
> function that does the appropiate thing.
>
> All the code I need to generate for doing the same thing would be
> superfluous.
>
> I repeat: There is NO MACHINE that hasn't a way for testing overflow,
> even if all regulars here say the contrary.
I think it is useful to add support in the language for these hardware flags. It's the C job ins't it, to give access to the hardware?
But, on the other hand, I think the correct approach for overflow/underflow/division by zero etc.. is the analysis of the function and not each operation.
for instance.
double F(double x)
{
return 2 * x*x + 10.0;
}
The overflow problem here is something you can determine statically. there is range of x that can be used without overflow. And then the check for the overhead is a if x > SOMEMIN && x < SOMEMAX.
In other cases, if you can generate division by zero, the check also includes values that cannot be used.
Maybe for very complicated expressions this is not the best approach.
Sometimes you also don't want just to see if an expression is with overflow. In case of big values you can have a perfect reasonable value to replace. (Let's say you are calculating some line intersection with floats to print the screen, and then you replace some values and get a perfect imagine you want)
So, In my view, we always need to do analysis for each context and type of expression. I don't know if someone did, but it's not too difficult to create a software that gives the ranges for valid values in a expression.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-12-07 03:13 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <959d48b8-9ceb-462d-901e-ad0b7d47e6b7@googlegroups.com> |
| In reply to | #98243 |
On Wednesday, December 7, 2016 at 9:11:01 AM UTC-2, Thiago Adams wrote:
> On Wednesday, December 7, 2016 at 8:47:33 AM UTC-2, jacobnavia wrote:
> > Le 07/12/2016 à 04:06, Ben Bacarisse a écrit :
> > > These instructions raise an exception when overflow occurs. No doubt
> > > one could harness that to provide what looks like an overflow flag but
> > > it would not be as simple as returning a bit from some status register.
> >
> > So what?
> > Any overflow trap sets that flag!
> >
> > And it would be simpler than what I have to generate for the x86. In the
> > x86 I have to generate the test and the jump. Using the dec alpha I
> > wouldn't have to generate anything, just set the overflow signal to a
> > function that does the appropiate thing.
> >
> > All the code I need to generate for doing the same thing would be
> > superfluous.
> >
> > I repeat: There is NO MACHINE that hasn't a way for testing overflow,
> > even if all regulars here say the contrary.
>
>
> I think it is useful to add support in the language for these hardware flags. It's the C job ins't it, to give access to the hardware?
>
> But, on the other hand, I think the correct approach for overflow/underflow/division by zero etc.. is the analysis of the function and not each operation.
>
> for instance.
>
> double F(double x)
> {
> return 2 * x*x + 10.0;
> }
>
> The overflow problem here is something you can determine statically. there is range of x that can be used without overflow. And then the check for the overhead is a if x > SOMEMIN && x < SOMEMAX.
> In other cases, if you can generate division by zero, the check also includes values that cannot be used.
> Maybe for very complicated expressions this is not the best approach.
> Sometimes you also don't want just to see if an expression is with overflow. In case of big values you can have a perfect reasonable value to replace. (Let's say you are calculating some line intersection with floats to print the screen, and then you replace some values and get a perfect imagine you want)
> So, In my view, we always need to do analysis for each context and type of expression. I don't know if someone did, but it's not too difficult to create a software that gives the ranges for valid values in a expression.
"And then the check for the overhead is a if x > SOMEMIN && x < SOMEMAX. "
Sorry, I mean overflow not overhead.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-07 11:47 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <87fum0ezb6.fsf@bsb.me.uk> |
| In reply to | #98240 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 07/12/2016 à 04:06, Ben Bacarisse a écrit : >> These instructions raise an exception when overflow occurs. No doubt >> one could harness that to provide what looks like an overflow flag but >> it would not be as simple as returning a bit from some status register. > > So what? > Any overflow trap sets that flag! What flag? > And it would be simpler than what I have to generate for the x86. In > the x86 I have to generate the test and the jump. Using the dec alpha > I wouldn't have to generate anything, just set the overflow signal to > a function that does the appropiate thing. Yes, my remark was about the machine having an overflow flag. But I'm still confused about what you are proposing. For a compiler writer to detect overflow is one thing, but making that facility useful to programmers is another. I would like to know what you are proposing. I've seen a lot of different approaches and I'm not much of a fan of any of them. I get the feeling there is probably a useful way to do this but I'm not sure I know what it is. I lean towards a construct that lets the programmer delineate the code for which overflow checking matters: if (_Overflow(c += a*b)) ... handle overflow ... Being a high-level sort of person I'd want this to propagate into function calls which might mean that the compiler needs to generate both a checked and an unchecked version of each function if there is some cost to the checking: if (_Overflow(f(g()))) ... f and g called outside of an _Overflow(...) expression should not pay any price. This, though, goes wrong with functions called through a pointer object. What mechanisms have people used before, and what was good/bad about it? > All the code I need to generate for doing the same thing would be > superfluous. > > I repeat: There is NO MACHINE that hasn't a way for testing overflow, > even if all regulars here say the contrary. Has anyone said that? Someone may have done but I don't recall any (let alone all) regular poster dong so. In fact you are a regular who says the opposite. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-07 12:08 +0000 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o28u0n$4v8$2@dont-email.me> |
| In reply to | #98247 |
On 07/12/16 11:47, Ben Bacarisse wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: > >> Le 07/12/2016 à 04:06, Ben Bacarisse a écrit : >>> These instructions raise an exception when overflow occurs. No doubt >>> one could harness that to provide what looks like an overflow flag but >>> it would not be as simple as returning a bit from some status register. >> >> So what? >> Any overflow trap sets that flag! > > What flag? > >> And it would be simpler than what I have to generate for the x86. In >> the x86 I have to generate the test and the jump. Using the dec alpha >> I wouldn't have to generate anything, just set the overflow signal to >> a function that does the appropiate thing. > > Yes, my remark was about the machine having an overflow flag. But I'm > still confused about what you are proposing. For a compiler writer to > detect overflow is one thing, but making that facility useful to > programmers is another. I would like to know what you are proposing. > > I've seen a lot of different approaches and I'm not much of a fan of any > of them. I get the feeling there is probably a useful way to do this > but I'm not sure I know what it is. > > I lean towards a construct that lets the programmer delineate the code > for which overflow checking matters: > > if (_Overflow(c += a*b)) ... handle overflow ... > > Being a high-level sort of person I'd want this to propagate into > function calls which might mean that the compiler needs to generate both > a checked and an unchecked version of each function if there is some > cost to the checking: > > if (_Overflow(f(g()))) ... > > f and g called outside of an _Overflow(...) expression should not pay > any price. This, though, goes wrong with functions called through a > pointer object. > > What mechanisms have people used before, and what was good/bad about it? > >> All the code I need to generate for doing the same thing would be >> superfluous. >> >> I repeat: There is NO MACHINE that hasn't a way for testing overflow, >> even if all regulars here say the contrary. > > Has anyone said that? I said that C doesn't require the CPU to have an overflow flag. That is not the same as claiming that there is a machine that doesn't have one. > Someone may have done but I don't recall any (let > alone all) regular poster dong so. Nor do I. > In fact you are a regular who says the opposite. I think Jacob may not understand what "regular" means. Jacob, a "regular" is someone who posts many articles over a lengthy period of time. That includes you, Jacob. You /are/ a regular. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-07 23:45 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2a3bg$cf6$1@dont-email.me> |
| In reply to | #98250 |
On 07/12/16 13:08, Richard Heathfield wrote: > On 07/12/16 11:47, Ben Bacarisse wrote: >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> >>> Le 07/12/2016 à 04:06, Ben Bacarisse a écrit : >>>> These instructions raise an exception when overflow occurs. No doubt >>>> one could harness that to provide what looks like an overflow flag but >>>> it would not be as simple as returning a bit from some status register. >>> >>> So what? >>> Any overflow trap sets that flag! >> >> What flag? >> >>> And it would be simpler than what I have to generate for the x86. In >>> the x86 I have to generate the test and the jump. Using the dec alpha >>> I wouldn't have to generate anything, just set the overflow signal to >>> a function that does the appropiate thing. >> >> Yes, my remark was about the machine having an overflow flag. But I'm >> still confused about what you are proposing. For a compiler writer to >> detect overflow is one thing, but making that facility useful to >> programmers is another. I would like to know what you are proposing. >> >> I've seen a lot of different approaches and I'm not much of a fan of any >> of them. I get the feeling there is probably a useful way to do this >> but I'm not sure I know what it is. >> >> I lean towards a construct that lets the programmer delineate the code >> for which overflow checking matters: >> >> if (_Overflow(c += a*b)) ... handle overflow ... >> >> Being a high-level sort of person I'd want this to propagate into >> function calls which might mean that the compiler needs to generate both >> a checked and an unchecked version of each function if there is some >> cost to the checking: >> >> if (_Overflow(f(g()))) ... >> >> f and g called outside of an _Overflow(...) expression should not pay >> any price. This, though, goes wrong with functions called through a >> pointer object. >> >> What mechanisms have people used before, and what was good/bad about it? >> >>> All the code I need to generate for doing the same thing would be >>> superfluous. >>> >>> I repeat: There is NO MACHINE that hasn't a way for testing overflow, >>> even if all regulars here say the contrary. >> >> Has anyone said that? > > I said that C doesn't require the CPU to have an overflow flag. That is > not the same as claiming that there is a machine that doesn't have one. > MIPS and RISC-V do not have overflow flags. They /do/ have methods for checking for overflow, but they don't use flags. In particular, MIPS has an "add" instruction that causes a trap or processor exception on overflow, which is a pretty drastic action. In order to detect overflow at runtime without using exceptions, you need quite complex code: (This example is taken off a webpage, and I haven't tested it. But it looks okay, based on my very limited knowledge of MIPS assembly) #addition... addu $t0, $t1, $t2 # caution, don't trap! xor $t3, $t1, $t2 # if signs differ $t3 < 0 slt $t3, $t3, $zero bne $t3, $zero, No_overflow #signs differ xor $t3,$t0,$t1 # signs match, check result slt $t3,$t3,$zero #sum sign different bne $t3,$zero, Overflow.. Basically, MIPS (and RISC-V, and Alpha) designers realised that people are very rarely actually interested in checking for overflow. It is usually far easier to use types that are big enough to work without overflow. So rather than having a flags register, which is complicated and a bottleneck in a superscaler pipelined architecture, they simply didn't bother with overflow in most cases - and added a few "kill the program on error" trap on overflow instructions. >> Someone may have done but I don't recall any (let >> alone all) regular poster dong so. > > Nor do I. > >> In fact you are a regular who says the opposite. > > I think Jacob may not understand what "regular" means. Jacob, a > "regular" is someone who posts many articles over a lengthy period of > time. That includes you, Jacob. You /are/ a regular. >
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-08 00:22 +0100 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <o2a5ha$mb5$1@dont-email.me> |
| In reply to | #98316 |
>> I think Jacob may not understand what "regular" means. Jacob, a >> "regular" is someone who posts many articles over a lengthy period of >> time. That includes you, Jacob. You /are/ a regular. >> > Look guys, I am repeating what I said six and half years ago and it is distressing that all the refuted arguments come again as nothing ever would move in this group. 1) You all know very well what I mean when I say that C has weakness that should be adressed. In my discussion I present technical arguments that are not refuted. 2) All machines can check for overflow. For instance, Mr Brown proposed for MIPS: #addition... addu $t0, $t1, $t2 # caution, don't trap! xor $t3, $t1, $t2 # if signs differ $t3 < 0 slt $t3, $t3, $zero bne $t3, $zero, No_overflow #signs differ xor $t3,$t0,$t1 # signs match, check result slt $t3,$t3,$zero #sum sign different bne $t3,$zero, Overflow.. That's when you buy a machine like that... Others are better, as everybody knows. Some machines do not have flags to test but any overflow is rerouted to an interrupt routine that probably the software can adapt. It is maybe expensive but the language should provide means of doing that fairly easily, by default if you want. Any overflow is a signal that is rerouted to code to treat an overflow condition. You can assign priorities to pieces of the software, meaning that if an overflow occurs because of data noise, or electrical problems, or just variables that weren't sized correctly there is a "restart" point for that module. C allows for a standard way of treating floating point overflow but not integer overflow. This is no longer justified. Now, how could that be done? Let's discuss that for once? OK?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-07 15:32 -0800 |
| Subject | Re: "Lete2??s Stop Bashing C" |
| Message-ID | <ln37hz1fjm.fsf@kst-u.example.com> |
| In reply to | #98322 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> C allows for a standard way of treating floating point overflow but not
> integer overflow. This is no longer justified.
>
> Now, how could that be done?
>
> Let's discuss that for once?
>
> OK?
OK.
Perhaps you could start by answering my question about setting an
overflow flag on Alpha. To repeat the context:
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 07/12/2016 á 08:41, Ike Naar a écrit :
>> The 'overflow' variants the of arithmetic instructions (addlv,
>> mullv, sublv etc.) signal an overflow exception, but they do not
>> set an overflow flag, so I don't see how one could efficiently
>> "test the overflow flag".
>
> So what?
> Any overflow trap sets that flag!
Sets what flag? My understanding (based mostly on reading this
discussion) is that the Alpha doesn't have a hardware "overflow flag".
Are you talking about dedicating some memory location for use as an
overflow flag, controlled by software?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web