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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-07 00:07 +0100 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <o27g8v$arv$1@dont-email.me> |
| In reply to | #98216 |
Le 06/12/2016 à 23:24, supercat@casperkitty.com a écrit : > 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. > 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: 1: the extra instruction and 2: the code needed to report line and file 3: The line and file literals. Of course that could be simplified with a signal, integer input, encoding the line number in 20 bits (1 million + lines possible per file) and the file number as a 12 bit index in the global file table. You could have 8192 different files for an executable. For instance. There are many other schemas possible. I think that people that try to avoid ANY development of C are far worse than the ones bashing it.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-07 22:04 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o29tdp$nbl$1@dont-email.me> |
| In reply to | #98218 |
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. Not all architectures have an "overflow flag". Not all architectures have a "one cycle penalty for non-taken jumps". You are aware that, only a few years ago, Apple PCs ran on PowerPC, not x86 right? And you know that gcc supports dozens, nay scores, of different architectures? And that's the spirit of C... to run on all kinds of different systems.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-07 23:44 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2a39e$c8b$1@dont-email.me> |
| In reply to | #98297 |
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! But understanding THAT is beyond your abilities I suppose? > You are aware that, only a few years ago, Apple PCs > ran on PowerPC, not x86 right? > A few years ago many things were different. So what? > And you know that gcc supports dozens, nay scores, of > different architectures? > Bla bla bla > And that's the spirit of C... to run on all kinds of > different systems. > Yes. And not care about whether the results are correct. Just that they are calculated very fast. Great NOOB; You are GREAT!
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-07 23:02 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2a4c4$ino$1@dont-email.me> |
| In reply to | #98315 |
On 07/12/2016 22:44, jacobnavia wrote: [Overflow detection] > Yes. And not care about whether the results are correct. Just that they > are calculated very fast. Suppose there is a language feature to detect whether an expression has overflowed that shouldn't have done. What can the code then do about it? I can see this being of use when debugging programs, like putting in array bounds checking, but then it be taken care of with special checking code put in by the compiler. It doesn't need new language features. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-07 15:28 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <ln7f7b1fqs.fsf@kst-u.example.com> |
| In reply to | #98320 |
BartC <bc@freeuk.com> writes:
> On 07/12/2016 22:44, jacobnavia wrote:
>
> [Overflow detection]
>
>> Yes. And not care about whether the results are correct. Just that they
>> are calculated very fast.
>
> Suppose there is a language feature to detect whether an expression has
> overflowed that shouldn't have done.
>
> What can the code then do about it?
It can handle the error, just as it would handle any other error. It
can give up on some operation and go on to do something else, perhaps
after informing the user if appropriate.
Here's an example in Ada, a language that supports exceptions and
requires an exception to be raised on numeric overflow. It prints
"Overflow". Ada does the same thing for array bound errors.
with Ada.Text_IO; use Ada.Text_IO;
procedure Overflow is
N: Integer := Integer'Last;
begin
N := N + 1;
Put_Line("OK");
exception
when Constraint_Error =>
Put_Line("Overflow");
end Overflow;
> I can see this being of use when debugging programs, like putting in
> array bounds checking, but then it be taken care of with special
> checking code put in by the compiler. It doesn't need new language features.
It's very difficult to do reliable overflow checking in C without either
adding new language features or using extensions.
--
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 | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-08 21:36 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2cg6d$mo0$1@dont-email.me> |
| In reply to | #98315 |
On 07/12/2016 23:44, jacobnavia 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. I do know what you do! You annoy me :-p >> 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! > > But understanding THAT is beyond your abilities I suppose? OK, mister smarty pants. How do you implement your proposed overflow detection scheme on the Itanium? http://www.intel.com/content/dam/doc/manual/itanium-architecture-vol-1-2-3-4-reference-set-manual.pdf IMO, writing a compiler targeting a few arches does not make one qualified to dismiss 30 years of engineering compromises by WG14 et al. Especially if one doesn't offer an honest assessment of the pros and cons of one's proposal. > Great NOOB; You are GREAT! There's something about the way you express irony that cracks me up (most of the time). I guess that's why I can't keep you in my KF. Regards.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 12:56 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <88255352-818d-4066-8faa-5af8870836e8@googlegroups.com> |
| In reply to | #98404 |
On Thursday, December 8, 2016 at 2:36:54 PM UTC-6, Noob wrote: > OK, mister smarty pants. How do you implement your proposed > overflow detection scheme on the Itanium? I'm not sure how one could reasonably implement useful semantics for a non-latching overflow flag, but if "int" is 32 bits [often useful even on 64-bit processors because each cache line holds twice as many 32-bit values as 64-bit values] a compiler could keep track of registers that hold values that might have exceeded the range of a 32-bit "int" and check whether they hold values that are within "int" range whenever they would be in danger of overflowing 64-bit range, whenever the compiler would get tired of keeping track of the fact that they hold possibly- overflowed values, or whenever code wants to check whether any overflows have occurred yet. Supporting overflow trapping on 64-bit values would likely require the compiler to check for overflows after a lot more operations, but I'm not sure what problem you see with the Itanium in particular. A MIPS would seem harder to deal with.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-08 23:03 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2cl8c$98f$1@dont-email.me> |
| In reply to | #98407 |
On 08/12/2016 21:56, supercat@casperkitty.com wrote: > On Thursday, December 8, 2016 at 2:36:54 PM UTC-6, Noob wrote: > >> OK, mister smarty pants. How do you implement your proposed >> overflow detection scheme on the Itanium? > > I'm not sure how one could reasonably implement useful semantics for a > non-latching overflow flag, but if "int" is 32 bits [often useful even > on 64-bit processors because each cache line holds twice as many 32-bit > values as 64-bit values] a compiler could keep track of registers that > hold values that might have exceeded the range of a 32-bit "int" and > check whether they hold values that are within "int" range whenever they > would be in danger of overflowing 64-bit range, whenever the compiler > would get tired of keeping track of the fact that they hold possibly- > overflowed values, or whenever code wants to check whether any overflows > have occurred yet. Are you saying that even if a CPU does not provide any HW support for overflow detection, a compiler may insert appropriate arithmetic checks at strategic places in the code? > Supporting overflow trapping on 64-bit values would likely require the > compiler to check for overflows after a lot more operations, but I'm > not sure what problem you see with the Itanium in particular. A MIPS > would seem harder to deal with. MIPS's ADD traps on overflow. Itanium has no HW support for integer arithmetic overflow detection (no trap, no flag, zilch). Regards.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 14:21 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <1fe4fa83-86ae-47a7-88ee-21fffb28049a@googlegroups.com> |
| In reply to | #98420 |
On Thursday, December 8, 2016 at 4:03:17 PM UTC-6, Noob wrote: > Are you saying that even if a CPU does not provide any HW support > for overflow detection, a compiler may insert appropriate arithmetic > checks at strategic places in the code? Not only can it perform arithmetic checks, but it can defer and consolidate them so as to minimize their cost. > > Supporting overflow trapping on 64-bit values would likely require the > > compiler to check for overflows after a lot more operations, but I'm > > not sure what problem you see with the Itanium in particular. A MIPS > > would seem harder to deal with. > > MIPS's ADD traps on overflow. > Itanium has no HW support for integer arithmetic overflow detection > (no trap, no flag, zilch). The Itanium manual talked about the Overflow Flag and listed the ADD instruction as modifying it; perhaps that only happens in 32-bit mode? In any case, a compiler supported overflow-trapped integer types should have an easier time producing efficient code using those than producing efficient code from the kludge workarounds that would be necessary to check whether operations on the largest integer size would produce overflow purely within C code.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-08 23:36 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2cn7a$fn7$1@dont-email.me> |
| In reply to | #98421 |
On 08/12/2016 23:21, supercat@casperkitty.com wrote: > On Thursday, December 8, 2016 at 4:03:17 PM UTC-6, Noob wrote: >> Are you saying that even if a CPU does not provide any HW support >> for overflow detection, a compiler may insert appropriate arithmetic >> checks at strategic places in the code? > > Not only can it perform arithmetic checks, but it can defer and consolidate > them so as to minimize their cost. OK, you lost me. Integer overflow has UB. So nothing in the standard prevents a compiler from implementing your proposed scheme. What's the problem? You would want such overflow detection to become mandatory/standard? In fact, gcc and clang with their UB "sanitizer" are probably able to catch most cases of overflow, I would think. >>> Supporting overflow trapping on 64-bit values would likely require the >>> compiler to check for overflows after a lot more operations, but I'm >>> not sure what problem you see with the Itanium in particular. A MIPS >>> would seem harder to deal with. >> >> MIPS's ADD traps on overflow. >> Itanium has no HW support for integer arithmetic overflow detection >> (no trap, no flag, zilch). > > The Itanium manual talked about the Overflow Flag and listed the ADD > instruction as modifying it; perhaps that only happens in 32-bit mode? You're not familiar with Itanium, are you? Intel built an entire x86 core into the first generation to ease the unavoidable (ha!) transition from x86 to IA-64. You should ignore everything in Volume 4, it's just an x86 reference. IA-64's integer add is documented on page 913. Regards.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-08 21:59 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2cl1i$8c8$1@dont-email.me> |
| In reply to | #98404 |
On 08/12/2016 20:36, Noob wrote: > On 07/12/2016 23:44, jacobnavia wrote: > OK, mister smarty pants. How do you implement your proposed > overflow detection scheme on the Itanium? > > http://www.intel.com/content/dam/doc/manual/itanium-architecture-vol-1-2-3-4-reference-set-manual.pdf Start by writing an emulator for x86? > IMO, writing a compiler targeting a few arches does not make > one qualified to dismiss 30 years of engineering compromises > by WG14 et al. Especially if one doesn't offer an honest > assessment of the pros and cons of one's proposal. How many years did it take to agree on binary literals? (That's if they have agreed yet.) There are many things that are no-brainers yet which haven't made it into the language, despite their 30 years' experience. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-08 23:25 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2cmht$dkt$1@dont-email.me> |
| In reply to | #98419 |
On 08/12/2016 22:59, BartC wrote: > On 08/12/2016 20:36, Noob wrote: >> On 07/12/2016 23:44, jacobnavia wrote: > >> OK, mister smarty pants. How do you implement your proposed >> overflow detection scheme on the Itanium? >> >> http://www.intel.com/content/dam/doc/manual/itanium-architecture-vol-1-2-3-4-reference-set-manual.pdf > > Start by writing an emulator for x86? In fact, Intel built an x86 "emulator" for IA-64. https://en.wikipedia.org/wiki/IA-32_Execution_Layer >> IMO, writing a compiler targeting a few arches does not make >> one qualified to dismiss 30 years of engineering compromises >> by WG14 et al. Especially if one doesn't offer an honest >> assessment of the pros and cons of one's proposal. > > How many years did it take to agree on binary literals? (That's if they > have agreed yet.) You're not allowed to discuss C if you can't even bother to check the standard at least once in a blue moon. > There are many things that are no-brainers yet which > haven't made it into the language, despite their 30 years' experience. Many things such as... Binary constants? What else? I wasn't aware that they are allowed as a gcc extension. https://gcc.gnu.org/onlinedocs/gcc/Binary-constants.html There are also clever macro hacks to support binary constants. http://embeddedgurus.com/barr-code/2009/09/binary-literals-in-c/ I haven't made a careful costs/benefits assessment for such a feature. Apparently, WG14 rejected them for C99. http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf "A proposal to add binary constants was rejected due to lack of precedent and insufficient utility." Perhaps after a few decades of gcc, clang, and icc having that particular extension, WG14 will accept it? Regards.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 14:34 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <fe3c6276-4f04-465d-98da-9c127ddb9937@googlegroups.com> |
| In reply to | #98426 |
On Thursday, December 8, 2016 at 4:25:24 PM UTC-6, Noob wrote: > "A proposal to add binary constants was rejected due to lack of > precedent and insufficient utility." > > Perhaps after a few decades of gcc, clang, and icc having that > particular extension, WG14 will accept it? Not to mention a huge variety of embedded compilers. Statements like the above make me wonder if anyone on the Committee does anything with embedded or systems programming.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-08 23:59 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2coie$jpb$1@dont-email.me> |
| In reply to | #98427 |
On 08/12/2016 23:34, supercat@casperkitty.com wrote: > On Thursday, December 8, 2016 at 4:25:24 PM UTC-6, Noob wrote: >> "A proposal to add binary constants was rejected due to lack of >> precedent and insufficient utility." >> >> Perhaps after a few decades of gcc, clang, and icc having that >> particular extension, WG14 will accept it? > > Not to mention a huge variety of embedded compilers. Statements like the > above make me wonder if anyone on the Committee does anything with embedded > or systems programming. In Linux, it seems arch/arm64/kvm uses a few binary constants, but I don't see other uses. Either programmers don't find them useful enough, or they've grown used to not having them. Regards.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-12-09 00:18 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <20161209001802.678ee452@maxa-pc> |
| In reply to | #98430 |
On Thu, 8 Dec 2016 23:59:43 +0100 Noob <root@127.0.0.1> wrote: > On 08/12/2016 23:34, supercat@casperkitty.com wrote: > > > On Thursday, December 8, 2016 at 4:25:24 PM UTC-6, Noob wrote: > >> "A proposal to add binary constants was rejected due to lack of > >> precedent and insufficient utility." > >> > >> Perhaps after a few decades of gcc, clang, and icc having that > >> particular extension, WG14 will accept it? > > > > Not to mention a huge variety of embedded compilers. Statements > > like the above make me wonder if anyone on the Committee does > > anything with embedded or systems programming. > > In Linux, it seems arch/arm64/kvm uses a few binary constants, > but I don't see other uses. Either programmers don't find them > useful enough, or they've grown used to not having them. > > Regards. > I find I use binary constants much more in assembler. Actually i don't use them at all in C++ (as I haven't programmed straight C since 90s). -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-12-09 00:06 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <53a8e977-1d8a-4f7d-b054-4e46e51fcba7@googlegroups.com> |
| In reply to | #98431 |
W dniu piątek, 9 grudnia 2016 00:18:09 UTC+1 użytkownik Melzzzzz napisał: > On Thu, 8 Dec 2016 23:59:43 +0100 > Noob <root@127.0.0.1> wrote: > > > On 08/12/2016 23:34, supercat@casperkitty.com wrote: > > > > > On Thursday, December 8, 2016 at 4:25:24 PM UTC-6, Noob wrote: > > >> "A proposal to add binary constants was rejected due to lack of > > >> precedent and insufficient utility." > > >> > > >> Perhaps after a few decades of gcc, clang, and icc having that > > >> particular extension, WG14 will accept it? > > > > > > Not to mention a huge variety of embedded compilers. Statements > > > like the above make me wonder if anyone on the Committee does > > > anything with embedded or systems programming. > > > > In Linux, it seems arch/arm64/kvm uses a few binary constants, > > but I don't see other uses. Either programmers don't find them > > useful enough, or they've grown used to not having them. > > > > Regards. > > > > I find I use binary constants much more in assembler. Actually i don't > use them at all in C++ (as I haven't programmed straight C since 90s). > > -- > press any key to continue or any other to quit i recently read some book and found good anectode in it (not releted but fine and this group somewhat lacks of better mood ) The existence of such extraordinary coincidences is difficult to reconcile with the understanding of the universe developed by materialistic science. It is easier to imagine that these occurrences have some deeper meaning and that they are playful creations of cosmic intelligence. This explanation is particularly plausible when they contain an element of humor, which is often the case. I will use here as an illustration a true story from the life of the American astronaut Neil Armstrong, the first man to land on the moon. The astronomical improbability of something like this happening by chance combined with the exquisite humor of the story makes this certainly one of the most unique “coincidences” of all time. Descending from the lunar module, just before his foot touched the sur- face of the moon, Neil Armstrong said his famous words: “One small step for man; one giant step for mankind.” It is much less known that, as he was climbing back from the moon surface into the lunar module, he mut- tered another sentence, “Good luck Mr. Gorski.” After his return to earth, curious reporters inquired what this sentence meant, but Armstrong re- fused to reveal it. Some thought it might have been addressed to a Soviet cosmonaut, but there was no one of that name. After frustrating efforts of the journalists, the entire affair was forgotten. Last year, at a party in Florida, someone brought it up again. This time, Neil Armstrong felt free to disclose the meaning of the sentence since, in the meantime, Mr. Gorski and his wife had died. When Neil was a boy, the Gorskis were their next-door neighbors. One day, Neil was playing ball in his backyard with his friends. At one point, the ball landed in the Gorskis’ garden under the open window of their bedroom and Neil was appointed to retrieve it. The Gorskis were in the middle of a heated argument. As Neil was picking up the ball, he heard Mrs. Gorski screaming: “Oral sex? You want oral sex? You’ll get oral sex the day the kid next door walks on the moon!”
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2016-12-09 11:35 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <eavj87F7ao8U1@mid.uni-berlin.de> |
| In reply to | #98430 |
Noob <root@127.0.0.1> wrote:
> On 08/12/2016 23:34, supercat@casperkitty.com wrote:
> > On Thursday, December 8, 2016 at 4:25:24 PM UTC-6, Noob wrote:
> >> "A proposal to add binary constants was rejected due to lack of
> >> precedent and insufficient utility."
> >>
> >> Perhaps after a few decades of gcc, clang, and icc having that
> >> particular extension, WG14 will accept it?
> >
> > Not to mention a huge variety of embedded compilers. Statements like the
> > above make me wonder if anyone on the Committee does anything with embedded
> > or systems programming.
> In Linux, it seems arch/arm64/kvm uses a few binary constants,
> but I don't see other uses. Either programmers don't find them
> useful enough, or they've grown used to not having them.
I've seen them supported by some embedded compilers but just
find them annoying. It's much harder to find bit 23 in a string
of 32 '0' and '1' than by looking at a hex constant and doing
the tiniest bit of mental arithmetic. Or try comparing two of
them visually when they aren't nicely lined up, one over the
other. So to me the "insufficient utility" argument seems not
too far off the mark;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-09 12:12 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2e71s$bg3$1@dont-email.me> |
| In reply to | #98479 |
On 09/12/2016 11:35, Jens Thoms Toerring wrote: > Noob <root@127.0.0.1> wrote: >> On 08/12/2016 23:34, supercat@casperkitty.com wrote: > >>> On Thursday, December 8, 2016 at 4:25:24 PM UTC-6, Noob wrote: >>>> "A proposal to add binary constants was rejected due to lack of >>>> precedent and insufficient utility." >>>> >>>> Perhaps after a few decades of gcc, clang, and icc having that >>>> particular extension, WG14 will accept it? >>> >>> Not to mention a huge variety of embedded compilers. Statements like the >>> above make me wonder if anyone on the Committee does anything with embedded >>> or systems programming. > >> In Linux, it seems arch/arm64/kvm uses a few binary constants, >> but I don't see other uses. Either programmers don't find them >> useful enough, or they've grown used to not having them. > > I've seen them supported by some embedded compilers but just > find them annoying. It's much harder to find bit 23 in a string > of 32 '0' and '1' than by looking at a hex constant and doing > the tiniest bit of mental arithmetic. Or try comparing two of > them visually when they aren't nicely lined up, one over the > other. So to me the "insufficient utility" argument seems not > too far off the mark;-) It's a rubbish implementation then. Try: 2x0000_0100__1001_0110__0000_1111__1101_1000 They are grouped in blocks of 8 as bits 31..24, 23..16, 15..8 and 7..0. I've also split each block into two so that each four bits corresponds to the hex. Try this however in hex, where groups of 5 bits are significant: 2x00110_01001_10000_11001 Or this where you want alternating groups of 0s and 1s, the width of each group increasing by one bit each time (I used stuff like this for defining dotted line patterns in graphics drivers): 2x11111111_0000000_111111_00000_1111_000_11_0 Intel datasheets for devices such as 8086 used to represent instruction codings in binary where specific groups were significant: 2x_01_011_101 This now matches exactly what might be in the datasheet instead of using hex or (more usefully) octal. Or suppose you're comparing these two values trying to see some similarity or some link: 2x11010010 // D2 2x01101001 // 69 You'd have to be pretty good at hex to see that they are the same pattern but with a 1-bit shift (0xD2 is 0x69*2). [I think gcc uses 0b rather than 2x as the prefix; but it doesn't have separators.] -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 13:33 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2e880$fj8$1@dont-email.me> |
| In reply to | #98479 |
On 09/12/16 12:35, Jens Thoms Toerring wrote: > Noob <root@127.0.0.1> wrote: >> On 08/12/2016 23:34, supercat@casperkitty.com wrote: > >>> On Thursday, December 8, 2016 at 4:25:24 PM UTC-6, Noob wrote: >>>> "A proposal to add binary constants was rejected due to lack of >>>> precedent and insufficient utility." >>>> >>>> Perhaps after a few decades of gcc, clang, and icc having that >>>> particular extension, WG14 will accept it? >>> >>> Not to mention a huge variety of embedded compilers. Statements like the >>> above make me wonder if anyone on the Committee does anything with embedded >>> or systems programming. > >> In Linux, it seems arch/arm64/kvm uses a few binary constants, >> but I don't see other uses. Either programmers don't find them >> useful enough, or they've grown used to not having them. > > I've seen them supported by some embedded compilers but just > find them annoying. It's much harder to find bit 23 in a string > of 32 '0' and '1' than by looking at a hex constant and doing > the tiniest bit of mental arithmetic. Or try comparing two of > them visually when they aren't nicely lined up, one over the > other. So to me the "insufficient utility" argument seems not > too far off the mark;-) > Regards, Jens > Agreed. I think binary literals are fine for small numbers - but above perhaps 8 digits they are very hard to read. Digit separators are available in some languages, but not C - 0b'0101'1010 in C++14 is easier to interpret than 0b01011010 (underscore would have been nicer, but it would conflict with other things in C++). There is no single "best" way to write literals or constants. Sometimes a binary literal is best, sometimes hex, sometimes decimal, and sometimes expressions like (1 << 23) | (1 << 12) is clearest.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-09 15:41 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <40d49b7f-ecc9-4af7-9bbd-2daac805d4c8@googlegroups.com> |
| In reply to | #98491 |
On Friday, December 9, 2016 at 12:33:28 PM UTC, David Brown wrote: > > Agreed. I think binary literals are fine for small numbers - but above > perhaps 8 digits they are very hard to read. Digit separators are > available in some languages, but not C - 0b'0101'1010 in C++14 is easier > to interpret than 0b01011010 (underscore would have been nicer, but it > would conflict with other things in C++). > > There is no single "best" way to write literals or constants. Sometimes > a binary literal is best, sometimes hex, sometimes decimal, and > sometimes expressions like (1 << 23) | (1 << 12) is clearest. > Often a string literal is best. It's then converted to binary in some early pass which doesn't have any severe execution time constraints. If a table of string literals is published, which is often the case, you can then cut and paste and check for correctness (often no string may be a prefix of another and every combination of bits must yield a string. You can write code to test that holds).
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web