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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-10 09:28 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <kfna8c3k81d.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #98479 |
jt@toerring.de (Jens Thoms Toerring) writes: > 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;-) I agree. An unnecessary frill, and one likely to make things worse rather than better. The language should make it harder to write mysterious magic numbers everywhere, not make it easier to supply them in a form that is hard to assimilate.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-10 09:58 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <ca883c2a-5a54-45c5-9d60-ad3d70f6c0a3@googlegroups.com> |
| In reply to | #98717 |
On Saturday, December 10, 2016 at 11:28:53 AM UTC-6, Tim Rentsch wrote: > Jens Thoms Toerring writes: > > 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;-) > > I agree. An unnecessary frill, and one likely to make things > worse rather than better. The language should make it harder to > write mysterious magic numbers everywhere, not make it easier to > supply them in a form that is hard to assimilate. Allowing delimiters would make such constants more readable and greatly improve their utility. While it's possible to fake them with macros, anyone trying to proofread code which uses macros to fake binary literals will have to examine the macros carefully as well to identify what kinds of corner cases can trip them up. Having a standard way of writing such things would make such code easier to read.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-14 22:53 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <kfnzijxfzu6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #98722 |
supercat@casperkitty.com writes: > On Saturday, December 10, 2016 at 11:28:53 AM UTC-6, Tim Rentsch wrote: >> Jens Thoms Toerring writes: >>> 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;-) >> >> I agree. An unnecessary frill, and one likely to make things >> worse rather than better. The language should make it harder to >> write mysterious magic numbers everywhere, not make it easier to >> supply them in a form that is hard to assimilate. > > Allowing delimiters would make such constants more readable and greatly > improve their utility. While it's possible to fake them with macros, > anyone trying to proofread code which uses macros to fake binary literals > will have to examine the macros carefully as well to identify what kinds > of corner cases can trip them up. Having a standard way of writing such > things would make such code easier to read. Again, there is no logical necessity to read the definition of something - whether a function or a macro - to be able to use it. The whole point of writing interface documentation is so that definitions do /not/ have to be read. Macros can be documented just as much as functions can.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-11 03:10 -0600 |
| Subject | Re: micro-architectural details |
| Message-ID | <as5q4cdlj28n69j7a9m23cq57r90oqroqf@4ax.com> |
| In reply to | #98717 |
On Sat, 10 Dec 2016 09:28:46 -0800, Tim Rentsch <txr@alumni.caltech.edu> wrote: >jt@toerring.de (Jens Thoms Toerring) writes: > >> 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;-) > >I agree. An unnecessary frill, and one likely to make things >worse rather than better. The language should make it harder to >write mysterious magic numbers everywhere, not make it easier to >supply them in a form that is hard to assimilate. I want binary literals for those places where I define the constants, not because I want to distribute binary magic numbers all over my program.
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2016-12-11 13:48 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <eb53pbFh02gU1@mid.uni-berlin.de> |
| In reply to | #98766 |
Robert Wessel <robertwessel2@yahoo.com> wrote:
> I want binary literals for those places where I define the constants,
> not because I want to distribute binary magic numbers all over my
> program.
To me something like
#define ALL_MAGIC ((1 << 23) | (1 << 17) | (1 << 6))
or, even better,
#define SOME_MAGIC (1 << 6)
#define MORE_MAGIC (1 << 17)
#define HIGHLY_MAGIC (1 << 23)
#define ALL_MAGIC (HIGHLY_MAGIC | MORE_MAGIC | SOME_MAGIG)
much more readable (at least if well-choosen names are used)
than e.g.
#define ALL_MAGIC 0b100000100000000001000000
The latter took me half a minute to type and check and re-
check while I hadn't even to think about the other defines...
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-11 14:43 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2jojc$efj$1@dont-email.me> |
| In reply to | #98792 |
On 11/12/2016 13:48, Jens Thoms Toerring wrote:
> Robert Wessel <robertwessel2@yahoo.com> wrote:
>> I want binary literals for those places where I define the constants,
>> not because I want to distribute binary magic numbers all over my
>> program.
>
> To me something like
>
> #define ALL_MAGIC ((1 << 23) | (1 << 17) | (1 << 6))
>
> or, even better,
>
> #define SOME_MAGIC (1 << 6)
> #define MORE_MAGIC (1 << 17)
> #define HIGHLY_MAGIC (1 << 23)
>
> #define ALL_MAGIC (HIGHLY_MAGIC | MORE_MAGIC | SOME_MAGIG)
>
> much more readable (at least if well-choosen names are used)
> than e.g.
>
> #define ALL_MAGIC 0b100000100000000001000000
> The latter took me half a minute to type and check and re-
> check while I hadn't even to think about the other defines...
You didn't think of using spacing, even if they have to be removed later:
#define ALL_MAGIC 0b 10000010 00000000 01000000
With binary literals need to come separators, which are also handy if
you need to type a billion as 1000000000 without the need to
double-check the number of zeros. (Sorry, 1000*1000*1000 is naff.)
And in binary you get a free map:
char cross5] = {
0B_10001,
0B_01010,
0B_00100,
0B_01010,
0B_10001};
Compare with:
char cross[5] = {
0x_11,
0x_0A,
0x_04,
0x_0A,
0x_11};
Here's an example from another language, coding parameters to functions;
the last entry is a map of optional bits for each of the first 8:
(ks,ks, 0, 0, 0, 0, 0, 0,01000000B), !24 exec[2 params,2nd optional]
(kr, 0, 0, 0, 0, 0, 0, 0,00000000B), !25 fint
(ks,ki,ki, 0, 0, 0, 0, 0,01100000B), !26 openfile
(ks,ki, 0, 0, 0, 0, 0, 0,01000000B), !27 createfile
(ki, 0, 0, 0, 0, 0, 0, 0,10000000B), !28 closefile
And another, part of a disassembler, where the binary fields are linked
to binary values specified in the 8087 data sheet:
(00_1_000B, fld_opc, 4),
(01_1_000B, fild_opc, 4),
(10_1_000B, fld_opc, 8),
(11_1_000B, fild_opc, 2),
(11_1_101B, fild_opc, 8),
(01_1_101B, fld_opc, 10),
(11_1_100B, fld_opc, 20),
But somehow I don't think it matters how many examples anyone brings up;
there will always be another way to do things that doesn't involve
binary constants, or there will be some workaround using macros.
Therefore this trivial extension to a language is completely unnecessary.
Fine. Meanwhile, if I want an easy way to compactly represent the
sequence 3,0,3,2,3,2,3,3,2,3,2,3 in a single int, I can just write:
4x'3032'3233'2323 # base-4
while you guys are still thinking up suitable macros!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 16:23 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <87lgvmxwn3.fsf@bsb.me.uk> |
| In reply to | #98800 |
BartC <bc@freeuk.com> writes: <snip> > With binary literals need to come separators, which are also handy if > you need to type a billion as 1000000000 without the need to > double-check the number of zeros. (Sorry, 1000*1000*1000 is naff.) You can also use 1e9. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-11 12:53 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <ln8trmtcgd.fsf@kst-u.example.com> |
| In reply to | #98828 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> BartC <bc@freeuk.com> writes:
> <snip>
>> With binary literals need to come separators, which are also handy if
>> you need to type a billion as 1000000000 without the need to
>> double-check the number of zeros. (Sorry, 1000*1000*1000 is naff.)
>
> You can also use 1e9.
1e9 is a floating-point constant.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 21:27 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <87k2b6upfk.fsf@bsb.me.uk> |
| In reply to | #98890 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> BartC <bc@freeuk.com> writes: >> <snip> >>> With binary literals need to come separators, which are also handy if >>> you need to type a billion as 1000000000 without the need to >>> double-check the number of zeros. (Sorry, 1000*1000*1000 is naff.) >> >> You can also use 1e9. > > 1e9 is a floating-point constant. Yes, I know. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-11 08:46 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <beed6061-d086-4bca-8189-7f1aeb687554@googlegroups.com> |
| In reply to | #98800 |
On Sunday, December 11, 2016 at 8:43:18 AM UTC-6, Bart wrote: > But somehow I don't think it matters how many examples anyone brings up; > there will always be another way to do things that doesn't involve > binary constants, or there will be some workaround using macros. > Therefore this trivial extension to a language is completely unnecessary. Of course, the counter-argument to the fact that something can be done with macros is that someone who is reading code that uses 0b0000010000100001 would have no doubt about how the compiler that supports binary literals will interpret it, while someone who sees AS_BIN(00000010000100001) would have to look at the macro definition to see how it worked and whether it had any restrictions. Such macros are generally not easy to read, and someone who examines ten programs that each use different macros would have to spend time studying all ten forms. > Fine. Meanwhile, if I want an easy way to compactly represent the > sequence 3,0,3,2,3,2,3,3,2,3,2,3 in a single int, I can just write: > > 4x'3032'3233'2323 # base-4 > > while you guys are still thinking up suitable macros! On a related note, I'd like to see the syntax 01234 deprecated for octal in favor of something else; using 8x1234 would seem a natural choice along the same vein as the base-4 example you give above. It could also be helpful to allow 10x0123 as a representation of the number one hundred twenty-three [for use in token-pasting macros].
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-14 21:14 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <kfnpokthiyo.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #98832 |
supercat@casperkitty.com writes: > someone who sees > AS_BIN(00000010000100001) would have to look at the > macro definition to see how it worked and whether it > had any restrictions. Obviously wrong, in the same way that one doesn't have to read source code for printf() to use printf().
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-15 08:25 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <3a37f51d-5caa-46e0-85c8-0bd79b8f3f5e@googlegroups.com> |
| In reply to | #99441 |
On Wednesday, December 14, 2016 at 11:14:47 PM UTC-6, Tim Rentsch wrote: > supercat writes: > > > someone who sees > > AS_BIN(00000010000100001) would have to look at the > > macro definition to see how it worked and whether it > > had any restrictions. > > Obviously wrong, in the same way that one doesn't have to read > source code for printf() to use printf(). The reason one doesn't generally have to look at the source code of printf to know whether a piece of code is using it correctly is that *the Standard specifies its behavior*. The same would be true for AS_BIN if it were defined in a standard header. Since it isn't, however, I'm curious how you think someone should know whether the above code would be valid, or whether the AS_BIN macro only works with eight-bit values, or requires that its input be exactly 16 digits (not seventeen), or has any other restrictions.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-14 21:11 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <kfntwa5hj39.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #98800 |
BartC <bc@freeuk.com> writes: > [binary literals redux] > > Meanwhile, if I want an easy way to compactly represent the > sequence 3,0,3,2,3,2,3,3,2,3,2,3 in a single int, I can just write: > > 4x'3032'3233'2323 # base-4 > > while you guys are still thinking up suitable macros! I already have a macro for that. It works great, and no language extensions required.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-15 14:28 +0000 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2u96v$717$1@dont-email.me> |
| In reply to | #99440 |
On 15/12/2016 05:11, Tim Rentsch wrote: > BartC <bc@freeuk.com> writes: > >> [binary literals redux] >> >> Meanwhile, if I want an easy way to compactly represent the >> sequence 3,0,3,2,3,2,3,3,2,3,2,3 in a single int, I can just write: >> >> 4x'3032'3233'2323 # base-4 >> >> while you guys are still thinking up suitable macros! > > I already have a macro for that. It works great, and no > language extensions required. I see. You have your own private stash of macros to use as ad hoc language extensions. But you want to deny that productivity to anyone else! As well as block standardisation of such techniques.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-11 18:38 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2k2sj$vke$1@dont-email.me> |
| In reply to | #98792 |
On 11/12/16 14:48, Jens Thoms Toerring wrote:
> Robert Wessel <robertwessel2@yahoo.com> wrote:
>> I want binary literals for those places where I define the constants,
>> not because I want to distribute binary magic numbers all over my
>> program.
>
> To me something like
>
> #define ALL_MAGIC ((1 << 23) | (1 << 17) | (1 << 6))
>
> or, even better,
>
> #define SOME_MAGIC (1 << 6)
> #define MORE_MAGIC (1 << 17)
> #define HIGHLY_MAGIC (1 << 23)
>
> #define ALL_MAGIC (HIGHLY_MAGIC | MORE_MAGIC | SOME_MAGIG)
>
> much more readable (at least if well-choosen names are used)
> than e.g.
>
> #define ALL_MAGIC 0b100000100000000001000000
>
> The latter took me half a minute to type and check and re-
> check while I hadn't even to think about the other defines...
>
That's all true.
But on the other hand, what about:
switch (x) {
case 0b00011111 : ...
case 0b00111110 : ...
case 0b01111100 : ...
case 0b11111000 : ...
case 0b11110001 : ...
case 0b11100011 : ...
case 0b11000111 : ...
case 0b10001111 : ...
}
}
That is a easier to write and understand in binary, than with hex, or
combinations of shifts.
The point is not that all magic numbers are best written in binary, or
even that /most/ magic numbers are best written in binary. The point is
merely that /some/ magic numbers are best written in binary, and it is
convenient when the language (C++14, or gcc C) has a clear and simple
way to do so without needing piles of macros and other complications.
And the use of 0b binaries is simple, consistent, easy to explain, and
easy to implement in compilers (for those that don't have them already
implemented).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-15 00:25 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <kfnvaulfvjg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #98766 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Sat, 10 Dec 2016 09:28:46 -0800, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >> jt@toerring.de (Jens Thoms Toerring) writes: >> >>> 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;-) >> >> I agree. An unnecessary frill, and one likely to make things >> worse rather than better. The language should make it harder to >> write mysterious magic numbers everywhere, not make it easier to >> supply them in a form that is hard to assimilate. > > I want binary literals for those places where I define the > constants, not because I want to distribute binary magic numbers > all over my program. Let me take a step back and try to offer a better phrasing. I believe it is almost always true that a place where a binary constant might be written it is better to express the value in some other form, though not always the same form. Often there is a good symbolic form, such as those shown in Jens Toerring's posting. Other times we want a value made up of fields in a particular format, such as a computer instruction - these might be done using function-like macro. In other cases we might want groups of two, four, or eight bits (almost never more), which can be done using other macros. For small constants, it doesn't make much difference whether the constant is written in binary or hex (or sometimes octal). For large constants, binary is unwieldy. My opposition to binary constants is based mostly on the observation that programmers are lazy - if there is an easy way, most will take it, even if a more expressive writing is a better choice. I acknowledge your principle of limiting use of binary constants to define symbolic values, which is a step in the right direction. My fear is that those who adhere to such a principle will be the exception rather than the rule. By making it a bit harder to use binary constants directly, I hope to encourage developers to seek better ways to express the values used in a meaningful and comprehensible way. Note that we can write what looks very much like a binary constant if we really have to, by making use of #define or enumeration constants, etc. I'm not dogmatic in saying that values should /never/ be written in binary - only that a binary form should be used only where appropriate, which is less often than it would be used if binary constants could be written anywhere with no special effort.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-09 07:42 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <1163d763-2725-4066-b03d-ee8bdd7f8e6f@googlegroups.com> |
| In reply to | #98430 |
On Thursday, December 8, 2016 at 4:59:50 PM UTC-6, Noob wrote: > On 08/12/2016 23:34, supercat 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. If the authors of the Standard had neglected to add binary literals on the basis that the implementations where they would be useful were already supporting them even without the Standard mandating such support, and there was insufficient cause to mandate that all other implementations do so as well, I would have disagreed with their judgment but respected it. It is their claim of insufficient precedent that I find implausible. I can't really imagine how much more precedent the Committee could want, unless they are blind to the world of embedded compilers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-09 11:54 -0800 |
| Subject | Re: micro-architectural details |
| Message-ID | <lnk2b8yj37.fsf@kst-u.example.com> |
| In reply to | #98532 |
supercat@casperkitty.com writes:
> On Thursday, December 8, 2016 at 4:59:50 PM UTC-6, Noob wrote:
>> On 08/12/2016 23:34, supercat 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.
>
> If the authors of the Standard had neglected to add binary literals on the
> basis that the implementations where they would be useful were already
> supporting them even without the Standard mandating such support, and there
> was insufficient cause to mandate that all other implementations do so as
> well, I would have disagreed with their judgment but respected it. It is
> their claim of insufficient precedent that I find implausible. I can't
> really imagine how much more precedent the Committee could want, unless they
> are blind to the world of embedded compilers.
That statement is in the C99 Rationale
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
which was published in 2003 but refers to decisions made several years
earlier. How much precedent was there for binary constants in the
mid-to-late 1990s? I don't know when the proposal was made and
rejected; it doesn't seem to be one of the C90 DRs at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr.htm
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 10:27 +0100 |
| Subject | Re: micro-architectural details |
| Message-ID | <o2dtba$bvi$1@dont-email.me> |
| In reply to | #98426 |
On 08/12/16 23:25, Noob wrote: > 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. To save anyone checking, binary literals of the form 0b0101 are in C++11, but not C11 (or any other C standard). > >> 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 It has been a gcc extension for a /long/ time now. This was sufficient "precedence and utility" to get binary literals included in the C++ standards, but not in the C standards. The C standards folks are always more conservative than the C++ standards folks (and that is a good thing for both languages). Personally, I think the C folks were /too/ conservative in rejecting 0b0101 literals in C11, but that's their decision. > > There are also clever macro hacks to support binary constants. > http://embeddedgurus.com/barr-code/2009/09/binary-literals-in-c/ "Clever", or "ugly". I can't say I use binary literals very often, even though I work in small embedded systems, but when I need them I am glad they are supported directly by my compiler and that I don't need such hacks. > > 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? gcc has had them for years, and other embedded compilers have had them even longer. To be fair, some of those older embedded compilers used a different format for binary literals (I can't think why - 0b0101 is the obvious choice for consistency with 0x literals). > > Regards. >
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-12-09 17:05 +0100 |
| Subject | Re: other missing features (no-brainers) |
| Message-ID | <o2eklc$td6$1@dont-email.me> |
| In reply to | #98419 |
On 08/12/2016 22:59, BartC wrote: > There are many things that are no-brainers yet which haven't made it > into the language, despite their 30 years' experience. OK, we've covered the bike shed. (I like mine red!) Now let's discuss the nuclear power plant. What other no-brainers haven't made it into the language? Regards.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web