Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #141169 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2019-02-23 21:59 +0100 |
| Last post | 2019-03-01 19:30 +0100 |
| Articles | 20 on this page of 308 — 53 participants |
Back to article view | Back to comp.lang.c
C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-23 21:59 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-23 22:02 +0100
Re: C is not a low level language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-02-23 16:05 -0500
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-24 08:37 +0100
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:12 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:11 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:40 +0800
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 05:16 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:20 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:24 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 19:45 +0800
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 13:09 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:38 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 15:18 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 17:21 +0100
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:43 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:17 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:02 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 19:26 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 21:36 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 20:47 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:10 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:25 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:24 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 17:04 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 16:52 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 17:59 -0800
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:19 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 09:41 +0100
Re: C is not a low level language Mateusz Viste <mateusz@wont.tell> - 2019-02-25 09:01 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 01:55 -0800
Re: C is not a low level language James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:24 -0800
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 08:46 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:36 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 10:13 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-26 09:56 +0100
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-25 14:12 +0000
Re: C is not a low level language James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:31 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:20 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:36 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 22:57 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:29 +0200
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:41 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:55 +0200
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:24 +0100
Re: C is not a low level language James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:46 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:34 +0200
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:03 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:58 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 09:40 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:01 +0100
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:55 -0800
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:31 +0100
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:42 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-24 17:56 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:23 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:58 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:52 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:31 +0000
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-25 08:48 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 14:01 -0800
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 23:04 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 15:53 -0800
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 00:29 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-26 01:33 -0800
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:07 +0000
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 20:50 +0100
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:04 +0000
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-28 16:25 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-28 11:56 -0500
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-28 19:45 +0000
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 17:55 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:03 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 11:25 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-28 19:30 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 13:18 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-28 21:48 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 17:54 -0800
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-01 20:19 +1300
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 03:05 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-01 11:29 +0000
The extent of Rick's experience (Was: C is not a low level language) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-01 12:19 +0000
Re: The extent of Rick's experience (Was: C is not a low level language) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-01 04:28 -0800
Re: The extent of Rick's experience (Was: C is not a low level language) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 04:34 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 04:32 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 14:28 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 15:57 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 06:24 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 09:21 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 11:23 +0100
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-04 14:47 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 15:58 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-04 07:02 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-05 06:36 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-05 05:14 -0800
Re: C is not a low level language jadill33@gmail.com - 2019-03-05 05:44 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-05 16:47 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-01 14:02 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 15:50 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 06:11 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 16:50 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 07:22 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 07:24 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-03 19:55 +0100
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-02 08:39 +1300
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-02 08:37 +1300
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 11:43 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-02 07:20 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 04:18 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-02 12:28 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 05:19 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-02 23:47 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 18:24 -0800
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-03-02 16:02 +0100
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-03 06:53 +1300
Yep, I'm not surprised. (Was: C is not a low level language) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-01 07:31 +0000
Re: C is not a low level language Wes Newell <w.newell@tx.rr.com> - 2019-03-01 06:13 +0000
Re: C is not a low level language Wes Newell <w.newell@tx.rr.com> - 2019-03-01 06:11 +0000
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:47 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:29 +0000
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-25 20:16 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:53 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 09:49 +0200
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:07 +0100
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 22:59 +0000
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 09:57 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 01:35 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 09:59 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-27 07:20 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-27 07:36 -0800
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 19:54 +1300
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 07:56 +0000
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 21:58 +1300
Re: C is not a low level language "A. Dumas" <alexandre@dumas.fr.invalid> - 2019-02-24 10:57 +0100
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:13 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 10:47 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:48 -0500
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:42 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 07:15 +0000
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-25 02:43 -0800
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:25 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:03 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 12:10 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 17:58 +0000
Re: C is not a low level language Axel Berger <Spam@Berger-Odenthal.De> - 2019-02-25 17:44 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:18 +0200
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:35 +0200
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:44 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:29 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 14:26 +0000
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:08 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:08 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 18:00 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-27 22:37 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 02:25 -0800
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:27 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:36 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:05 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:20 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 23:02 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:41 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 12:20 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 14:01 +0100
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-26 08:48 -0500
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 19:20 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:04 -0500
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 04:33 -0800
Re: C is not a low level language lonelydad <lonelydad58@gmail.com> - 2019-02-24 14:44 +0000
You were not meant to undersand this was: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-26 09:47 -0800
Re: You were not meant to undersand this was: C is not a low level language pjp <pjpoirier_is_located@hotmail.com> - 2019-02-26 16:05 -0400
Re: C is not a low level language luser droog <luser.droog@gmail.com> - 2019-02-26 20:16 -0800
Re: C is not a low level language "U-laptop\\Norah" <Norah@laptop.i-did-not-set--mail-host-address--so-tickle-me> - 2019-02-27 16:16 -0600
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-03-01 12:12 +1300
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-03-01 00:19 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 04:57 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 05:15 -0800
Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 19:59 -0800
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:10 +0000
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-25 09:00 -0800
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:02 +0100
Re: C is not a low level language Lars Enderin <lars.enderin@telia.com> - 2019-02-26 00:37 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 19:09 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:30 -0800
Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:31 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:16 +0000
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 11:22 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:51 -0500
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 07:20 -0800
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 15:35 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 11:05 -0500
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:39 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 19:11 -0800
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 09:41 -0500
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 14:53 +0000
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:19 -0500
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-25 16:38 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 11:20 -0500
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 17:49 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:18 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:25 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:45 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-26 09:11 -0500
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:23 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 17:57 +0200
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 17:42 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 22:33 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:30 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 01:58 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 12:19 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:52 -0800
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 15:20 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:47 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:50 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:59 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:15 +0200
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 18:38 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:49 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:55 +0200
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 16:29 +0000
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-03-04 23:43 -0500
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-25 10:01 -0800
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 18:16 +0000
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:44 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:05 -0500
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 00:51 -0600
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 10:58 +0100
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 10:53 -0600
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 09:04 -0800
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 13:25 -0600
Re: C is not a low level language Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-26 09:16 -0800
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 17:49 +0000
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 18:11 +0000
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-26 18:24 +0000
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 10:29 -0800
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:24 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:44 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-27 03:29 -0800
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 10:26 -0800
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 12:41 -0800
Re: C is not a low level language nobody@example.org (Scott) - 2019-02-26 06:33 +0000
Re: C is not a low level language mark.bluemel@gmail.com - 2019-02-25 07:24 -0800
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 20:03 -0800
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:56 -0800
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:43 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 14:14 +0800
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:45 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 19:04 +0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 09:51 +0100
Re: C is not a low level language Melzzzzz <Melzzzzz@zzzzz.com> - 2019-02-24 09:37 +0000
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-02-24 22:52 +1300
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-24 11:13 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 16:30 +0100
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 07:50 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:14 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:29 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 09:00 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-24 17:16 +0100
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:42 -0800
Re: C is not a low level language bart4858@gmail.com - 2019-02-24 09:38 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:09 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:13 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:23 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:48 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-24 19:07 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 11:10 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-24 19:19 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-25 10:32 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 20:49 +0100
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:59 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 18:02 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-24 21:56 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 23:00 +0100
Re: C is not a low level language BGB <cr88192@hotmail.com> - 2019-02-28 17:07 -0600
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-24 20:34 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 23:04 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-24 14:29 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-25 07:12 +0100
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-24 10:41 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 06:47 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-24 17:30 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 16:32 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-24 03:19 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 04:29 -0800
Re: C is not a low level language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-02-24 11:11 -0500
Re: C is not a low level language Rosario19 <Ros@invalid.invalid> - 2019-02-25 12:57 +0100
Re: C is not a low level language "l.s." <l.s@cryptolab.net> - 2019-02-28 19:17 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-28 21:09 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 13:20 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 10:27 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-03-01 14:18 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 15:10 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-03-01 19:30 +0100
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 11:10 -0800 |
| Message-ID | <9c9137ea-9424-4524-90e7-83de41eb37ea@googlegroups.com> |
| In reply to | #141237 |
W dniu niedziela, 24 lutego 2019 20:07:26 UTC+1 użytkownik Bart napisał: > On 24/02/2019 18:48, fir wrote: > > note i will ad dthis back references all the time (it ios all the time i see people repeats some more exact and deep idea i was talking before not referencing it); in that case indeed this si a bit special case as it is somewhat obvious (though not quite, not totally.. also i was writing wider on some things he 'repeats' hete he writes on clamped int i was writing on whole pack of ints, liek ones that are non defined on overflows, one that rises signal on overflow, ones that satuirates ..etc) also on some more details i was writing a bit wider) other ideas are posiibly a bit less obvious..but if people would repeat it without crediting it its enough striking to add this reference by myself otherwise i would feel like i live in false world > > > > otherwise it is wearing so after adding this reference i not want to spend much time on it as i get better things to do > > > > its btw sad that many things we use today are not properly credited, > > FFS you're still going on about this? > > A lot of the ideas you talk about, apart from the nonsensical stuff, are > very well known. It is is not necessary to search archives to find out > if someone else might have mentioned it before (I notice you don't do that). > > Even if you had come up with something new, probably most people have > kill-filled you, or don't haven't time to waste trying to decipher your > barely legible posts (google groups keeps offering to translate them > into English). > > > i sorta see myself as that kind of academic worker, some ideas cost me much work > > Some people have ideas /and/ implement them, which takes a bit more work. > > Ideas for programming language features are not usually copyrightable. i would like you will kilfile me as you playing hevy idiot so much time..wouldnt you be so nice? i use google groups and cant get rid of your stupidity (like above) automatically
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-24 19:19 +0000 |
| Message-ID | <27CcE.10295$wW6.10122@fx35.am4> |
| In reply to | #141238 |
On 24/02/2019 19:10, fir wrote: > i would like you will kilfile me as you playing hevy idiot so much time..wouldnt you be so nice? i use google groups and cant get rid of your stupidity (like above) automatically Please stop writing stuff like this: > thiose are weeps of terrible c (pseudo) coder who dont understand c.. > so who cares? are you another bartc I usually strive not to get personal in these groups, and talk about ideas and stuff, not people. But sometimes you have to make an exception: You really are an idiot.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-25 10:32 -0800 |
| Message-ID | <ce499171-8c8d-418a-ab9b-b9b81dc3e763@googlegroups.com> |
| In reply to | #141240 |
W dniu niedziela, 24 lutego 2019 20:19:34 UTC+1 użytkownik Bart napisał: > On 24/02/2019 19:10, fir wrote: > > > i would like you will kilfile me as you playing hevy idiot so much time..wouldnt you be so nice? i use google groups and cant get rid of your stupidity (like above) automatically > > Please stop writing stuff like this: > > > thiose are weeps of terrible c (pseudo) coder who dont understand > c.. > so who cares? are you another bartc > > I usually strive not to get personal in these groups, and talk about > ideas and stuff, not people. But sometimes you have to make an exception: > > You really are an idiot. lol, monkeying monkey idiot characterizes by sdressing some stupidity to people, and that is what characterizes you i often see whan i talk to you like i would talk with some demented drunkman from the street, 1) your thinking is so weak, you use primitive and false cliches you adress to me, im weary of answering that kind of stupidity 2) second think is about attitude, you got attitude of a dork, starting talks on something like idiotic trial to show somebody you talk with dont kno what he is saying (this dork attiotude is seen) - in that point you seem like some kind of personality of a worm thats why i must treat you as a primitive monkey tiremaking imbecile with attitude of maniacal usenet dork..thing is simple, you worked on that you got that (and i am obviously not idiot, at leas not on this level you may adress (anybody is sorta stupid so to say, but im not adressing stupidity of that of your level.. so get off primitive moron, i sorta like you showed your lrvel i do not feel obliged as a treat you as a legitimized user of this group no more - you may talk other discussants that will accept your mrntal level (lol) (lolling for compassion)
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-02-24 20:49 +0100 |
| Message-ID | <q4usfl$8bi$1@dont-email.me> |
| In reply to | #141237 |
Le 24/02/2019 à 20:07, Bart a écrit : > A lot of the ideas you talk about, apart from the nonsensical stuff, are > very well known. It is is not necessary to search archives to find out > if someone else might have mentioned it before (I notice you don't do > that). > I *implemented* operator overloading in my compiler system around 2004. I.e. 10 years before I could read what Mr "fir" said... Note the difference between IMPLEMENTING something and talking about it in a newsgroup!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-24 12:59 -0800 |
| Message-ID | <lnftscq4wu.fsf@kst-u.example.com> |
| In reply to | #141237 |
Bart <bc@freeuk.com> writes:
> On 24/02/2019 18:48, fir wrote:
[...]
> FFS you're still going on about this?
[...]
> Even if you had come up with something new, probably most people have
> kill-filled you, or don't haven't time to waste trying to decipher your
> barely legible posts (google groups keeps offering to translate them
> into English).
Exactly. Which is why I never see anything fir writes *unless* someone
like you insists on posting a followup. Which is why I am asking you to
stop doing that.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-02-24 18:02 +0100 |
| Message-ID | <q4uimr$74k$1@dont-email.me> |
| In reply to | #141218 |
Le 24/02/2019 à 17:16, David Brown a écrit :
> On 24/02/2019 16:30, jacobnavia wrote:
>> Le 24/02/2019 à 12:13, Ben Bacarisse a écrit :
>>> Jacob: what's your view? Is there anything either contentious or useful
>>> in it? Why did you post the link?
>>
>> Because it is needed to move C into the direction hardware is going.
>>
>> 1) SIMD operations. This kind of stuff is now in most modern CPUs and
>> can't be ignored. This should be accessible at the operation level in
>> C directly.
>
> This sort of thing is possible in current compilers. In some cases, the
> optimisers will figure things out automatically. In other cases,
> extensions are needed. See for example:
>
> <https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html>
>
I am talking about the C LANGUAGE, not some compiler extensions, and
surely not of the horrible gcc syntax.
> Intel's compiler is particularly good at this sort of thing, and clang
> is particularly enthusiastic about it (whether or not that leads to
> efficient code, I am not sure). I am sure you can find references to
> their extensions in their documentation.
>
Ditto.
> So getting vector operations for basic arithmetic is not a problem with
> these compilers. However, standardisation of these features is another
> matter altogether.
>
That is what I am talking about. Of course there is no need for
standardization if we all use always gcc...
>>
>> For instance suppose a type double2 vector:
>>
>> typedef struct tagdouble2 { double high; double low; } double2;
>>
>> This wpould make the xmm registers accessible from C. We would have
>>
>> double2 vector[256];
>
> I don't think people /want/ xmm registers to be accessible from C. What
> they want is to know that the compiler will handle such operations as
> efficiently as possible on the platform - using SIMD instructions and
> registers if they are available, and other instructions if not. It is
> (IMHO) important that the code works on any target - while working at
> maximal efficiency on the particular target in use.
>
That is of course what the "register" keyword does! Use a register if
possible.
>>
>> A table of double2 that should be mapped easily into x86/arm64
>> hardware: both have a double2 register set.
>>
>> Now, operations would be overloaded, with +, -, *, and /, being
>> overloaded like this:
>>
>> double2 overloaded double2add(double2 a, double2 b)
>> {
>> double2 result;
>> result.high = a.high + b.high;
>> result.low = a.low+b.low;
>> return result;
>> }
>>
>> This whole function would map into a single instruction in ARM64/x86.
>
> My examples here are with gcc, because I know its syntax - not because I
> think it is the best choice of syntax. Assembly is from godbolt.org.
>
> typedef double2 __attribute__((vector_size(16)));
>
> (I am confident a nicer syntax could be found for that!)
>
Sure. What about
typedef struct tagdouble2 { double high; double low; } double2;
???
Ahh I know. It's not gcc :-)
MUCH clearer
> double2 addDouble2(double2 a, double2 b) {
> return a + b;
> }
Sorry but unless the compiler overloads the "+" operation, obviously
that is a syntax error. You can't add two structures/tables.
So, gcc DOES use operator overloading but without giving the user any
leaway to useit whenever it wants. It is only allowed for the COMPILER
to overload basic operations, not for the user.
>
> addDouble2:
> addpd xmm0, xmm1 # tmp85, tmp87
> ret
>
>
> Overloaded operators are not needed. Indeed, overloaded operators are
> exactly what you /don't/ want here.
>
I have demonstrated above that the compiler DOES overloading! Unless the
"+" operation works differently for "vectors of size 16", it is just
impossible to add two structures/tables.
So, operator overloading IS being used here, albeit only by the compiler
and with a horrible syntax.
> double2 addDouble2x(double2 a, double2 b) {
> double2 result;
> result[1] = a[1] + b[1];
> result[0] = a[0] + b[0];
> return result;
> }
>
> addDouble2x:
> movapd xmm4, xmm0 # a, a
> movapd xmm5, xmm1 # b, b
> addsd xmm0, xmm1 # tmp100, tmp99
> unpckhpd xmm4, xmm4 # a
> unpckhpd xmm5, xmm5 # b
> movapd xmm2, xmm4 # tmp93, a
> addsd xmm2, xmm5 # tmp95, tmp94
> unpcklpd xmm0, xmm2 # result, tmp95
> ret
>
Obviously operator overloading is NOT being used as I proposed, and the
compiler generates two sequential adds. Normal, C doesn't support
operator overloading now. But the code I was showing is an outline of
what I am trying to say, OBVIOUSLY!
But you do not want to understand what I am proposing since it is not gcc.
>
> You want the compiler to generate the right code without having to make
> your own overloaded functions.
>
NO.
The compiler can't know all the different vector types around. For
instance ARM64 supports generalized vector extensions with different
vector lengths, and I want to be able to write those extensions in
assembly without any compiler inference. For instance to add horizontal
adds (the reduce operation) or other things.
> (You may want to implement this by having overloaded operators, and a
> header file providing inline assembly for these functions - but that is
> an implementation detail that the user should not have to see.)
>
Of course not. The standard would just allow the user to overload those
functions and use assembly libraries that would fill the gaps.
>
>>
>> All this can be done easily with ONE modification to the language:
>> operator overloading.
>
> I think operator overloading is a nice idea - I just don't think you
> need it here.
Your propose then, that we use gcc extensions. That's not very suprprising.
Using those extensions we have operator overloading bvut only by gcc and
only in some contexts.
And I worry about it being enough on its own - I suspect
> that you would quickly want to add overloading for normal functions, and
> then simple templates, and steadily more features. I appreciate that
> you want to make C plus some extra features without going as far as C++,
> but I find it hard to draw a line here and say "these features are
> useful so we will have them, while these features are less useful but
> more complex and we will omit them".
>
Fortran has operator obverloading. Most languages have it. But C can't
do that because it is already taken by C++ so why not use C++?
I hear the same arguments (by mostly the same people) since 15 years.
>>
>> I know, I have said this too often during the last 15 years in this
>> group. I know that I should program in C++ to be able to do that, etc.
>> But it is still corect, so I say it one more time.
>
> Fair enough.
>
>>
>> 2) Clamped addition, multiplication
>>
>> int overloaded clampedIntAddition(int a,int b)
>> {
>> long long c = a+b;
>> if (c > INT_MAX) c = UINT_MAX;
>> return c;
>> }
>> Again this function collapses into a single instruction. Again,
>> operator overloading would be a solution.
>
> I can't see how the overloading works here. Perhaps I am being dense -
> could you show exactly how this is used? (You might also want to fix
> the obvious bugs in it.)
>
Obviously the "ints" in the declaration should be
typedef struct clampedInt { int data; } ClampedInt;
etc.
>>
>> 3) Access to the CPU cache.
>>
>> int fn(int arg)
>> {
>> register int fastTable[8];
>> }
>>
>> The keyword "register" when applied to a table would mean that the
>> table should be stored in the high speed CPU cache. This would have
>> the same meaning that the keyword "register" has: the compiler would
>> make a "best effort" attempt but not any hard guarantee.
>
> As a practical point, I think it is a bad idea to use "register" for
> this. For a start, it does not have exactly that meaning in C, and I
> think it would be a bad idea to co-opt that keyword for a different
> purpose.
There is NO "different" purpose. Since the standard never specifies what
a "machine register" is, neither its width or other characteristics, it
just says that is a "storage class specifier", this new meaning would
NOT change anything in the language, it would STILL be a storage class
specifier.
And "register" has been deprecated in C++
We are talking about the C language here. In C "register" is defined as
a part of the language.
with an aim to using
> the word for a completely different purpose - like it or not, that would
> be of influence when considering changes to the C standards.
>
Again the C++ overhead that C users should pay for.
> However, as far as I know there is no way to demand that data be put in
> the CPU cache on the x86 or any other cached architecture with which I
> am familiar.
Of course not since there is no way for the programmer to specify that.
All processors have instructions to preload data into the cache to be
able to do in parallel the calculations and the loading of the data!
And the task of language designers is to give the programmer the
capacity of using all the features of the machine.
The best you can do is "touch" the cache for a range of
> memory addresses, asking for them to be prepared either for reading or
> writing.
>
But that is precisely my point. You can do that indirectly and not directly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-24 21:56 +0100 |
| Message-ID | <q4v0e5$1mu$1@dont-email.me> |
| In reply to | #141223 |
On 24/02/2019 18:02, jacobnavia wrote:
> Le 24/02/2019 à 17:16, David Brown a écrit :
>> On 24/02/2019 16:30, jacobnavia wrote:
>>> Le 24/02/2019 à 12:13, Ben Bacarisse a écrit :
>>>> Jacob: what's your view? Is there anything either contentious or
>>>> useful
>>>> in it? Why did you post the link?
>>>
>>> Because it is needed to move C into the direction hardware is going.
>>>
>>> 1) SIMD operations. This kind of stuff is now in most modern CPUs and
>>> can't be ignored. This should be accessible at the operation level in
>>> C directly.
>>
>> This sort of thing is possible in current compilers. In some cases,
>> the optimisers will figure things out automatically. In other cases,
>> extensions are needed. See for example:
>>
>> <https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html>
>>
>
> I am talking about the C LANGUAGE, not some compiler extensions, and
> surely not of the horrible gcc syntax.
>
Neither you nor any other individual gets to change the C language. But
you /do/ get to use compiler extensions, or to make your own in your own
compiler.
And the way the C standards committee works, it is a lot easier to get a
feature included if it has been tried and tested as an extension in an
existing compiler. So most proposed changes start off as compiler
extensions.
(And I agree that the syntax for declaring vector types in gcc is not
particularly pretty or intuitive.)
>> Intel's compiler is particularly good at this sort of thing, and clang
>> is particularly enthusiastic about it (whether or not that leads to
>> efficient code, I am not sure). I am sure you can find references to
>> their extensions in their documentation.
>>
>
> Ditto.
>
>> So getting vector operations for basic arithmetic is not a problem
>> with these compilers. However, standardisation of these features is
>> another matter altogether.
>>
>
> That is what I am talking about. Of course there is no need for
> standardization if we all use always gcc...
>
We don't all use gcc - which is why a standard method would be
preferable. But before inventing your own "standard", it makes sense to
look at the existing ones. I have only discussed gcc in detail because
that is the only compiler whose vector extensions I know - I
specifically recommended you also look at clang and icc. Understand
what other tools do before you decide to do something different - your
own method needs to be /significantly/ better before it would have the
slightest chance of your own preferences becoming part of C. Otherwise
we'll just see a repeat of you making a proposal that seems reasonable
enough, but gets rejected by the C committee - and then you will again
accuse them of bias and conspiracy, and again cry that it is not fair.
Perhaps you are right that it is "not fair" - but crying will not help.
Looking at other compilers, considering other alternatives, and
constructing a rational argument might help.
>>>
>>> For instance suppose a type double2 vector:
>>>
>>> typedef struct tagdouble2 { double high; double low; } double2;
>>>
>>> This wpould make the xmm registers accessible from C. We would have
>>>
>>> double2 vector[256];
>>
>> I don't think people /want/ xmm registers to be accessible from C.
>> What they want is to know that the compiler will handle such
>> operations as efficiently as possible on the platform - using SIMD
>> instructions and registers if they are available, and other
>> instructions if not. It is (IMHO) important that the code works on
>> any target - while working at maximal efficiency on the particular
>> target in use.
>>
>
> That is of course what the "register" keyword does! Use a register if
> possible.
"Register" lost that meaning many, many years ago. Compilers generally
ignore it (except for checking the constraint that you can't take the
address of a register variable). Programmers don't use it. It is a
relic of a bygone era, along with "auto".
Programmers want the compiler to use a register if possible, assuming
that is the most efficient choice for code generation - and they want
that /always/, not just because they used the "register" keyword.
>
>>>
>>> A table of double2 that should be mapped easily into x86/arm64
>>> hardware: both have a double2 register set.
>>>
>>> Now, operations would be overloaded, with +, -, *, and /, being
>>> overloaded like this:
>>>
>>> double2 overloaded double2add(double2 a, double2 b)
>>> {
>>> double2 result;
>>> result.high = a.high + b.high;
>>> result.low = a.low+b.low;
>>> return result;
>>> }
>>>
>>> This whole function would map into a single instruction in ARM64/x86.
>>
>> My examples here are with gcc, because I know its syntax - not because
>> I think it is the best choice of syntax. Assembly is from godbolt.org.
>>
>> typedef double2 __attribute__((vector_size(16)));
Sorry:
typedef double double2 __attribute__((vector_size(16)));
>>
>> (I am confident a nicer syntax could be found for that!)
>>
>
> Sure. What about
>
> typedef struct tagdouble2 { double high; double low; } double2;
>
> ???
No, that is a poor choice. How do you plan to extend that to a vector
of, say, 4 int32_t's, or 8 16-bit values, or 64 8-bit bytes in AVX-512?
The gcc syntax is ugly, but at least it is flexible.
I'd look for something more like:
typedef double double2[vector 2];
That would be simple, obvious, and easily support any combination you
like. And you'd be able to make arrays as big as you want - if they
don't fit in a register, the compiler will split them up.
Some thought would need to go into how to handle returning these vectors
are values.
>
> Ahh I know. It's not gcc :-)
> MUCH clearer
Please drop your paranoia and your sarcasm. I am trying to /help/ you,
and /support/ you. But you are apparently more keen on irritating and
alienating people than on discussing solutions or improving the language
or your tools. Have you never stopped to consider that the problems you
have with influencing the C world is not the standards committee, not
the compiler developers, not the programmers, not your proposed changes
- but your martyr attitude?
>
>
>> double2 addDouble2(double2 a, double2 b) {
>> return a + b;
>> }
>
>
> Sorry but unless the compiler overloads the "+" operation, obviously
> that is a syntax error. You can't add two structures/tables.
>
We are talking about /compiler extensions/ here. We are not talking
about code that the user writes himself - that would be pointless.
> So, gcc DOES use operator overloading but without giving the user any
> leaway to useit whenever it wants. It is only allowed for the COMPILER
> to overload basic operations, not for the user.
>
That is /exactly/ what you have in C. The language supports "+" on a
dozen different types - integer types, floating point types, pointer
types, complex types, etc. These vectors are compiler extensions - or,
in a perfect world, new additions to the C language standards. It is
entirely natural and fitting that the language and tools support
operators on them - it does not need a method for user-defined operator
overloading, because these are not user-defined types.
And as I said, you don't want user-defined operators here - they would
not be optimal.
>
>>
>> addDouble2:
>> addpd xmm0, xmm1 # tmp85, tmp87
>> ret
>>
>>
>> Overloaded operators are not needed. Indeed, overloaded operators are
>> exactly what you /don't/ want here.
>>
>
> I have demonstrated above that the compiler DOES overloading! Unless the
> "+" operation works differently for "vectors of size 16", it is just
> impossible to add two structures/tables.
>
No one wants to add structs or tables here - they want to add vector
types. And no one cares how the compiler implements things - "operator
overloading" is a feature for /programmers/ that is not needed here.
> So, operator overloading IS being used here, albeit only by the compiler
> and with a horrible syntax.
The gcc syntax is as close to perfect as you can get, except for the
declaration of the typedef used. (And that could be hidden in a macro,
or header file.) You add two vectors by writing "c = a + b;", you
extract members of the vectors using "double x = a[1];", etc.
"Operator overloading" refers to /user/ code for overloading operators
for /user/ types. That is not what we are doing here. The compiler
supports operators on the types it supports - just like for any other type.
>
>
>> double2 addDouble2x(double2 a, double2 b) {
>> double2 result;
>> result[1] = a[1] + b[1];
>> result[0] = a[0] + b[0];
>> return result;
>> }
>>
>> addDouble2x:
>> movapd xmm4, xmm0 # a, a
>> movapd xmm5, xmm1 # b, b
>> addsd xmm0, xmm1 # tmp100, tmp99
>> unpckhpd xmm4, xmm4 # a
>> unpckhpd xmm5, xmm5 # b
>> movapd xmm2, xmm4 # tmp93, a
>> addsd xmm2, xmm5 # tmp95, tmp94
>> unpcklpd xmm0, xmm2 # result, tmp95
>> ret
>>
>
> Obviously operator overloading is NOT being used as I proposed, and the
> compiler generates two sequential adds. Normal, C doesn't support
> operator overloading now. But the code I was showing is an outline of
> what I am trying to say, OBVIOUSLY!
>
> But you do not want to understand what I am proposing since it is not gcc.
I am /trying/ to understand what you are proposing, but you are not
helping here. You seem to be suggesting two things - use structs like
you can do today in C, and "do whatever gcc doesn't do because gcc is evil".
I can appreciate that operator overloading would let programmers make
their own types, and operate on them conveniently. In that, operator
overloading is not a bad idea IMHO.
However, it will not do what is needed here, for two reasons. One is
that ABI makes requirements on how data is passed into and out of
functions - a struct with two doubles will be passed as two individual
doubles in separate xmm registers. With a compiler extension (or a
change to the C language) you can have a different underlying type, and
therefore a different calling convention - passing the two doubles as a
single xmm vector. That also allows you to have additional alignment
requirements beyond those of the existing ABI.
Secondly, the whole point here is to let the compiler handle these types
and operations optimally - you don't get that (at least not easily) by
manually messing around with the parts in C code. You get it by having
it built into the compiler.
>
>
>>
>> You want the compiler to generate the right code without having to
>> make your own overloaded functions.
>>
>
> NO.
>
> The compiler can't know all the different vector types around. For
> instance ARM64 supports generalized vector extensions with different
> vector lengths, and I want to be able to write those extensions in
> assembly without any compiler inference. For instance to add horizontal
> adds (the reduce operation) or other things.
>
As a compiler /user/, I don't want to have to write these things in
assembly at all. I want the compiler to handle them. It is the
compiler's job to know these details, so that I can write C code that
gives correct result for any target. Inline assembly should be the last
resort, not the norm - especially since most compilers can't do a decent
job of optimising when there is inline assembly involved. And for
compilers which /can/ optimise the assembly, writing it correctly is no
easy matter.
>
>> (You may want to implement this by having overloaded operators, and a
>> header file providing inline assembly for these functions - but that
>> is an implementation detail that the user should not have to see.)
>>
>
> Of course not. The standard would just allow the user to overload those
> functions and use assembly libraries that would fill the gaps.
>
>>
>>>
>>> All this can be done easily with ONE modification to the language:
>>> operator overloading.
>>
>> I think operator overloading is a nice idea - I just don't think you
>> need it here.
>
> Your propose then, that we use gcc extensions. That's not very suprprising.
>
Why do you have to assume that everything is a gcc conspiracy?
I propose that the language needs to have support for vectors if vectors
and SIMD are to be used simply and efficiently. gcc has extensions to
cover this, as do some other compilers. I can't say what might be the
best syntax for the job - I certainly did not suggest that gcc's was the
nicest method. And I said expressly that I would prefer an addition to
the standard. I don't know if that is a realistic hope - if not, the
compiler extensions may be the best we can get.
And I have said - repeatedly - that I think operator overloading is a
nice idea. However, it is neither necessary nor sufficient for good
handling of SIMD vectors. It is an orthogonal issue.
> Using those extensions we have operator overloading bvut only by gcc and
> only in some contexts.
>
>
> And I worry about it being enough on its own - I suspect
>> that you would quickly want to add overloading for normal functions,
>> and then simple templates, and steadily more features. I appreciate
>> that you want to make C plus some extra features without going as far
>> as C++, but I find it hard to draw a line here and say "these features
>> are useful so we will have them, while these features are less useful
>> but more complex and we will omit them".
>>
>
> Fortran has operator obverloading. Most languages have it. But C can't
> do that because it is already taken by C++ so why not use C++?
>
> I hear the same arguments (by mostly the same people) since 15 years.
>
You hear the same thing all the time, because you never listen to
anyone. You say "C needs operator overloading like my C compiler, as
this will solve all our problems and we won't need the horrors of C++".
Then you stick your fingers in your ears and cry about how unfair it is
that people don't like your ideas, and how it is all down to those evil
buggers at gcc. If you were to stop wailing and listen to other people
for a change, you'd find reality is very different.
>
>>>
>>> I know, I have said this too often during the last 15 years in this
>>> group. I know that I should program in C++ to be able to do that,
>>> etc. But it is still corect, so I say it one more time.
>>
>> Fair enough.
>>
>>>
>>> 2) Clamped addition, multiplication
>>>
>>> int overloaded clampedIntAddition(int a,int b)
>>> {
>>> long long c = a+b;
>>> if (c > INT_MAX) c = UINT_MAX;
>>> return c;
>>> }
>>> Again this function collapses into a single instruction. Again,
>>> operator overloading would be a solution.
>>
>> I can't see how the overloading works here. Perhaps I am being dense
>> - could you show exactly how this is used? (You might also want to
>> fix the obvious bugs in it.)
>>
>
> Obviously the "ints" in the declaration should be
>
> typedef struct clampedInt { int data; } ClampedInt;
>
> etc.
>
OK, that's a little clearer.
>
>>>
>>> 3) Access to the CPU cache.
>>>
>>> int fn(int arg)
>>> {
>>> register int fastTable[8];
>>> }
>>>
>>> The keyword "register" when applied to a table would mean that the
>>> table should be stored in the high speed CPU cache. This would have
>>> the same meaning that the keyword "register" has: the compiler would
>>> make a "best effort" attempt but not any hard guarantee.
>>
>> As a practical point, I think it is a bad idea to use "register" for
>> this. For a start, it does not have exactly that meaning in C, and I
>> think it would be a bad idea to co-opt that keyword for a different
>> purpose.
>
> There is NO "different" purpose. Since the standard never specifies what
> a "machine register" is, neither its width or other characteristics, it
> just says that is a "storage class specifier", this new meaning would
> NOT change anything in the language, it would STILL be a storage class
> specifier.
>
>
> And "register" has been deprecated in C++
>
> We are talking about the C language here. In C "register" is defined as
> a part of the language.
I am trying - against good reason - to bring a little practicality to
your fanaticism. A new use of the word "register" is not going to
happen in C. It will never be enshrined in the C standards. One reason
for that is potential conflicts with older C code that uses it - the
other reason is that it is changing in C++. You might not agree with
that reasoning, but that is reality. You can sit on your throne in the
bay and command the waves to go back, but they are not going to bend to
your will.
>
>
> with an aim to using
>> the word for a completely different purpose - like it or not, that
>> would be of influence when considering changes to the C standards.
>>
>
> Again the C++ overhead that C users should pay for.
>
C has gained things from C++, and it has had occasional limitations
because of C++. One thing most people agree on, however, is that
pointless incompatibilities between the languages help no one.
>> However, as far as I know there is no way to demand that data be put
>> in the CPU cache on the x86 or any other cached architecture with
>> which I am familiar.
> Of course not since there is no way for the programmer to specify that.
> All processors have instructions to preload data into the cache to be
> able to do in parallel the calculations and the loading of the data!
>
Different processors have different features regarding their caches and
what instructions are available. I know of none that let you mark data
as being specifically for the cache (as distinct from preloading or
touching it). That does not mean there are no processors with such
features, merely that I don't know of them.
> And the task of language designers is to give the programmer the
> capacity of using all the features of the machine.
No, it is not. C is a high level language. I want my compiler to
handle this sort of thing - I don't want to have to do it manually.
If you want to support it manually, then that would be a target-specific
intrinsic function.
>
>
>
> The best you can do is "touch" the cache for a range of
>> memory addresses, asking for them to be prepared either for reading or
>> writing.
>>
>
> But that is precisely my point. You can do that indirectly and not
> directly.
>
>
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-02-24 23:00 +0100 |
| Message-ID | <q4v453$otg$1@dont-email.me> |
| In reply to | #141252 |
Le 24/02/2019 à 21:56, David Brown a écrit :
>>> (I am confident a nicer syntax could be found for that!)
>>>
>>
>> Sure. What about
>>
>> typedef struct tagdouble2 { double high; double low; } double2;
>>
>> ???
>
> No, that is a poor choice. How do you plan to extend that to a vector
> of, say, 4 int32_t's, or 8 16-bit values, or 64 8-bit bytes in AVX-512?
> The gcc syntax is ugly, but at least it is flexible.
What I am declaring there is a pair of doubles that should be treated as
a single entity in the register of the machine but semantically they are
double data, i.e. I want to see the data as double.
When I am declaring
typedef struct tagfloat4 { float highhigh; float highlow;
float lowhigh; float lowlow; } float4;
I want to see the data as a single precision data.
What is important in a high level language is to keep a high level of
semantic clarity when using data.
Gcc's syntax emphasizes the size (16) but not the semantic implications.
You do NOT want to use the same data as doubles and then suddenly use
that as characters for a string!!!
Double precision data is double precision data, and that is expressed at
best with the typedef that emphasizes the contents of the data and not
its size.
If I want to use 16 byte units I can use either individual names (as I
did above) or use the vector notation (as proposed by arm):
typedef struct tagfloat4 { float data[4]; } float4;
Now you access the elements as an array.
Both possibilities are possible. Usinbg operator overloading I can
instruct the compiler (or use asm libraries) to generate the fastest
instructions.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-02-28 17:07 -0600 |
| Message-ID | <q59pjg$oqm$1@news.albasani.net> |
| In reply to | #141252 |
(jumping in...)
On 2/24/2019 2:56 PM, David Brown wrote:
> On 24/02/2019 18:02, jacobnavia wrote:
>> Le 24/02/2019 à 17:16, David Brown a écrit :
>>> On 24/02/2019 16:30, jacobnavia wrote:
>>>> Le 24/02/2019 à 12:13, Ben Bacarisse a écrit :
>>>>> Jacob: what's your view? Is there anything either contentious or
>>>>> useful
>>>>> in it? Why did you post the link?
>>>>
>>>> Because it is needed to move C into the direction hardware is going.
>>>>
>>>> 1) SIMD operations. This kind of stuff is now in most modern CPUs
>>>> and can't be ignored. This should be accessible at the operation
>>>> level in C directly.
>>>
>>> This sort of thing is possible in current compilers. In some cases,
>>> the optimisers will figure things out automatically. In other cases,
>>> extensions are needed. See for example:
>>>
>>> <https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html>
>>>
>>
>> I am talking about the C LANGUAGE, not some compiler extensions, and
>> surely not of the horrible gcc syntax.
>>
>
> Neither you nor any other individual gets to change the C language. But
> you /do/ get to use compiler extensions, or to make your own in your own
> compiler.
>
> And the way the C standards committee works, it is a lot easier to get a
> feature included if it has been tried and tested as an extension in an
> existing compiler. So most proposed changes start off as compiler
> extensions.
>
Yep.
> (And I agree that the syntax for declaring vector types in gcc is not
> particularly pretty or intuitive.)
>
I would prefer something other than the GCC syntax.
The syntax seems to have some merits, but also some similar drawbacks to
SSE intrinsics:
Not particularly portable between compilers;
Seems to be hit or miss whether it is supported for a given target;
...
This is, in addition to __attribute__((vector(16))) being kinda ugly
(could be wrapped though).
My preference here:
Ideally, can be supported whether or not the compiler supports it as a
compiler extension, or fakes it on top of standard C;
Works whether or not the target ISA supports SIMD (if it does not, it
"gracefully" falls back to scalar operations);
...
So, my own proposal is mostly for a collection of opaque vector types,
and an API of wrapper functions.
When supported, they are implemented as built-in types and built-in
functions, and otherwise are handled using structs and inline functions.
Granted, this wont give the ability to easily write "a+b" to add two
vectors, it would be something like "vec4f_add(a, b)" or similar.
So, vector types:
vec2f, 2x float
vec2d, 2x double
vec4f, 4x float
vec2i, 2x int32
vec4i, 4x int32
...
Possible:
vec4h, 4x half, may be faked
vec4i, 4x int32
vec4s, 4x int16
...
Operations:
vec4f_add(a, b)
vec4f_sub(a, b)
...
These cases would likely only cover a range of common short-vector
types, rather than attempt to address every possible vector size.
If vectors are named, eg:
float4
float4_add(a, b)
...
Wont complain too much.
Some other cases could be handled with "polyvectors" which could be
represented with array pointers. The magic could come from the handler
functions used, rather than needing special syntax to denote a given
array as a vector (but, a declaration hint could be usedd as an
optimization hint).
The compiler would then be able to implement the array operation as it
is able to do so:
vecpf_add(c, a, b, 16); //perform: "c[i]=a[i]+b[i]" for each element.
vecpf_copy(d, c); //copy vector
...
Conversion of fixed-vectors to/from polyvectors via function calls would
likely be required, as for technical reasons it makes sense to disallow
the ability to take the address of a vector as well as the ability to
directly use it for pointer dereference.
Similarly, any "fields" which may or may not exist within a fixed vector
would be off-limits to application code, so instead:
vec4f_x(a) //get a.x (vector being 'x,y,z,w').
vec4f_wxzy(a) //fixed shuffle (*)
*: while these could potentially add bulk, the main alternatives
("flexible" shuffle), or something like "vec4f_new(vec4f_w(a), ...)"
would risk having an adverse impact on performance absent explicit
compiler support.
While still not pretty, it could potentially be a viable alternative.
Whole mechanism would be exposed by using magic headers (which provides
the API).
Say, "stdsimd/vec4f.h", ...
>>> Intel's compiler is particularly good at this sort of thing, and
>>> clang is particularly enthusiastic about it (whether or not that
>>> leads to efficient code, I am not sure). I am sure you can find
>>> references to their extensions in their documentation.
>>>
>>
>> Ditto.
>>
>>> So getting vector operations for basic arithmetic is not a problem
>>> with these compilers. However, standardisation of these features is
>>> another matter altogether.
>>>
>>
>> That is what I am talking about. Of course there is no need for
>> standardization if we all use always gcc...
>>
>
> We don't all use gcc - which is why a standard method would be
> preferable. But before inventing your own "standard", it makes sense to
> look at the existing ones. I have only discussed gcc in detail because
> that is the only compiler whose vector extensions I know - I
> specifically recommended you also look at clang and icc. Understand
> what other tools do before you decide to do something different - your
> own method needs to be /significantly/ better before it would have the
> slightest chance of your own preferences becoming part of C. Otherwise
> we'll just see a repeat of you making a proposal that seems reasonable
> enough, but gets rejected by the C committee - and then you will again
> accuse them of bias and conspiracy, and again cry that it is not fair.
> Perhaps you are right that it is "not fair" - but crying will not help.
> Looking at other compilers, considering other alternatives, and
> constructing a rational argument might help.
>
Probably it has a better chance if it doesn't require modifying an
existing compiler to add baseline support (the compiler can do so, as
needed, to allow for higher performance).
>>>>
>>>> For instance suppose a type double2 vector:
>>>>
>>>> typedef struct tagdouble2 { double high; double low; } double2;
>>>>
>>>> This wpould make the xmm registers accessible from C. We would have
>>>>
>>>> double2 vector[256];
>>>
>>> I don't think people /want/ xmm registers to be accessible from C.
>>> What they want is to know that the compiler will handle such
>>> operations as efficiently as possible on the platform - using SIMD
>>> instructions and registers if they are available, and other
>>> instructions if not. It is (IMHO) important that the code works on
>>> any target - while working at maximal efficiency on the particular
>>> target in use.
>>>
>>
>> That is of course what the "register" keyword does! Use a register if
>> possible.
>
> "Register" lost that meaning many, many years ago. Compilers generally
> ignore it (except for checking the constraint that you can't take the
> address of a register variable). Programmers don't use it. It is a
> relic of a bygone era, along with "auto".
>
My compiler can make use of it, but mostly treats it as a hint to boost
priority during register allocation (by artificially inflating the
variable's "use count").
> Programmers want the compiler to use a register if possible, assuming
> that is the most efficient choice for code generation - and they want
> that /always/, not just because they used the "register" keyword.
>
This is also true, but the tradeoff here is that the compiler doesn't
necessarily know where the "hot spots" are within a function (nor, which
functions are themselves likely to be hotspots).
Marking a variable as "register" can thus serve two roles:
Indicate that this variable is used as part of the "hot path";
That the enclosing function is likely to itself be a hotspot (and so
should be optimized for speed rather than for code size).
Granted, to be effective, it needs to be used sparingly.
If overused or used in places where it is not needed, it is likely to
make overall performance worse (by reducing the effectiveness of the
register allocator).
Though, another feature is that there is a fixed/finite amount of
"register boost" per-function, so sticking it on one variable will give
a fairly aggressive boost, but sticking it on 10 variables will give a
lot less...
>>
>>>>
>>>> A table of double2 that should be mapped easily into x86/arm64
>>>> hardware: both have a double2 register set.
>>>>
>>>> Now, operations would be overloaded, with +, -, *, and /, being
>>>> overloaded like this:
>>>>
>>>> double2 overloaded double2add(double2 a, double2 b)
>>>> {
>>>> double2 result;
>>>> result.high = a.high + b.high;
>>>> result.low = a.low+b.low;
>>>> return result;
>>>> }
>>>>
>>>> This whole function would map into a single instruction in ARM64/x86.
>>>
>>> My examples here are with gcc, because I know its syntax - not
>>> because I think it is the best choice of syntax. Assembly is from
>>> godbolt.org.
>>>
>>> typedef double2 __attribute__((vector_size(16)));
>
> Sorry:
>
> typedef double double2 __attribute__((vector_size(16)));
>
>>>
>>> (I am confident a nicer syntax could be found for that!)
>>>
>>
>> Sure. What about
>>
>> typedef struct tagdouble2 { double high; double low; } double2;
>>
>> ???
>
> No, that is a poor choice. How do you plan to extend that to a vector
> of, say, 4 int32_t's, or 8 16-bit values, or 64 8-bit bytes in AVX-512?
> The gcc syntax is ugly, but at least it is flexible.
>
> I'd look for something more like:
>
> typedef double double2[vector 2];
>
This syntax could work.
> That would be simple, obvious, and easily support any combination you
> like. And you'd be able to make arrays as big as you want - if they
> don't fit in a register, the compiler will split them up.
>
> Some thought would need to go into how to handle returning these vectors
> are values.
>
I suspect there are two different use-cases:
Using vectors in ways where the length of the vector is significant for
the operation (such as operations involving 3D geometry);
Using vectors in ways where they are mostly being used for parallel
array processing.
In my thinking, there would likely be two slightly different ways of
expressing and using these cases.
In the fixed-vector case, it is likely the compiler would be responsible
for trying to pack them into larger vectors in the SIMD ISA (as is
already done with scalar code).
For array-like vectors, these can be "however large is appropriate".
There would likely be some restrictions as to how the vector may be
accessed when declared this way.
>
>>
>> Ahh I know. It's not gcc :-)
>> MUCH clearer
>
> Please drop your paranoia and your sarcasm. I am trying to /help/ you,
> and /support/ you. But you are apparently more keen on irritating and
> alienating people than on discussing solutions or improving the language
> or your tools. Have you never stopped to consider that the problems you
> have with influencing the C world is not the standards committee, not
> the compiler developers, not the programmers, not your proposed changes
> - but your martyr attitude?
>
>>
>>
>>> double2 addDouble2(double2 a, double2 b) {
>>> return a + b;
>>> }
>>
>>
>> Sorry but unless the compiler overloads the "+" operation, obviously
>> that is a syntax error. You can't add two structures/tables.
>>
>
> We are talking about /compiler extensions/ here. We are not talking
> about code that the user writes himself - that would be pointless.
>
My personal leaning here is "against" having vector operations directly
use the normal operators, because this would prevent it from being used
on compilers which lack explicit compiler support.
This could be allowed as an optional feature though (would depend on the
implementation).
>> So, gcc DOES use operator overloading but without giving the user any
>> leaway to useit whenever it wants. It is only allowed for the COMPILER
>> to overload basic operations, not for the user.
>>
>
> That is /exactly/ what you have in C. The language supports "+" on a
> dozen different types - integer types, floating point types, pointer
> types, complex types, etc. These vectors are compiler extensions - or,
> in a perfect world, new additions to the C language standards. It is
> entirely natural and fitting that the language and tools support
> operators on them - it does not need a method for user-defined operator
> overloading, because these are not user-defined types.
>
> And as I said, you don't want user-defined operators here - they would
> not be optimal.
>
I am inclined to agree.
< snip rest... >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-24 20:34 +0000 |
| Message-ID | <871s3x3oym.fsf@bsb.me.uk> |
| In reply to | #141210 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 24/02/2019 à 12:13, Ben Bacarisse a écrit : >> Jacob: what's your view? Is there anything either contentious or useful >> in it? Why did you post the link? > > Because it is needed to move C into the direction hardware is going. By "hardware", you mean modern x86 cores do you? If you mean all hardware then it may be hard to find a one-size fits all solution. Anyway, is there not a better article one that publishes some actual proposals for such language? If not, I see an opportunity for a good paper! By the way, why must it be C that changes rather have a new C-like language that is targeted at some specific hardware? <cut some examples> I won't comment on these since I can't imagine you care what some random person on Usenet thinks about the details. Good proposals backed up by practical experience you (are one of the few people here who could do that) would seem eminently publishable. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-02-24 23:04 +0100 |
| Message-ID | <q4v4d0$qd3$1@dont-email.me> |
| In reply to | #141243 |
Le 24/02/2019 à 21:34, Ben Bacarisse a écrit : > By "hardware", you mean modern x86 cores do you? x86 and ARM64, since the ARM64 architecture is very similar. You have 128 bit registers with several views, as in the old XMM technology of Intel. In the newer versions of ARM they have figured out an open ended vector extensions with register size open, not fixed to 16 bytes. That is a very interesting development that could be caught with the syntax I propose. Intel proposes a similar extension but always (as I last read) using fixed size registers, not open ended as ARM. Last that I know they were at 512 bit registers, Is that still true?
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-02-24 14:29 -0800 |
| Message-ID | <f0aacf83-e737-45f1-8a1b-f35340de0172@googlegroups.com> |
| In reply to | #141262 |
On Monday, February 25, 2019 at 12:04:23 AM UTC+2, jacobnavia wrote: > Le 24/02/2019 à 21:34, Ben Bacarisse a écrit : > > By "hardware", you mean modern x86 cores do you? > > x86 and ARM64, since the ARM64 architecture is very similar. You have > 128 bit registers with several views, as in the old XMM technology of Intel. > > In the newer versions of ARM they have figured out an open ended vector > extensions with register size open, not fixed to 16 bytes. That is a > very interesting development that could be caught with the syntax I propose. > > Intel proposes a similar extension but always (as I last read) using > fixed size registers, not open ended as ARM. > > Last that I know they were at 512 bit registers, Is that still true? The wording should be opposite. ARM proposes (the first implementation expected next year, by Fujitsu). Intel has (in the mainline Xeons since 2017, in Xeon Phi since 2014). Also don't forget that since 2011 Intel has 256-bit SIMD registers in majority of mainline CPUs.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-02-25 07:12 +0100 |
| Message-ID | <q500vg$ruk$1@dont-email.me> |
| In reply to | #141264 |
Le 24/02/2019 à 23:29, already5chosen@yahoo.com a écrit : > On Monday, February 25, 2019 at 12:04:23 AM UTC+2, jacobnavia wrote: >> Le 24/02/2019 à 21:34, Ben Bacarisse a écrit : >>> By "hardware", you mean modern x86 cores do you? >> >> x86 and ARM64, since the ARM64 architecture is very similar. You have >> 128 bit registers with several views, as in the old XMM technology of Intel. >> >> In the newer versions of ARM they have figured out an open ended vector >> extensions with register size open, not fixed to 16 bytes. That is a >> very interesting development that could be caught with the syntax I propose. >> >> Intel proposes a similar extension but always (as I last read) using >> fixed size registers, not open ended as ARM. >> >> Last that I know they were at 512 bit registers, Is that still true? > > The wording should be opposite. > ARM proposes (the first implementation expected next year, by Fujitsu). > Intel has (in the mainline Xeons since 2017, in Xeon Phi since 2014). > I stand corrected. Thanks > Also don't forget that since 2011 Intel has 256-bit SIMD registers in majority of mainline CPUs. >
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-02-24 10:41 +0000 |
| Message-ID | <slrnq74t7e.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #141183 |
On Sun, 2019-02-24, jacobnavia wrote: > Le 23/02/2019 à 21:59, jacobnavia a écrit : >> http://delivery.acm.org/10.1145/3220000/3212479/p10-chisnall.pdf?ip=90.22.143.233&id=3212479&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&__acm__=1550954647_0d9af87c752b221627509ce89da282a8 >> > > Well, impossible to start a good discussion here. > Nobody seems to have read the article, since none of the arguments put > forward answers the main arguments of the acm article. True. But you would have stood a better chance if you had written more than the article title (which was what triggered people's knee-jerk reactions, I think) and the URL. Like, what /your/ angle is, and why you posted it now (the article is a year old). Then you accidentally triggered the cross-posting troll, and that didn't help either. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 06:47 -0800 |
| Message-ID | <5fd86c76-18c3-4275-8a78-ad54736b60b6@googlegroups.com> |
| In reply to | #141190 |
W dniu niedziela, 24 lutego 2019 11:42:00 UTC+1 użytkownik Jorgen Grahn napisał: > On Sun, 2019-02-24, jacobnavia wrote: > > Le 23/02/2019 à 21:59, jacobnavia a écrit : > >> http://delivery.acm.org/10.1145/3220000/3212479/p10-chisnall.pdf?ip=90.22.143.233&id=3212479&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&__acm__=1550954647_0d9af87c752b221627509ce89da282a8 > >> > > > > Well, impossible to start a good discussion here. > > Nobody seems to have read the article, since none of the arguments put > > forward answers the main arguments of the acm article. > > True. But you would have stood a better chance if you had written > more than the article title (which was what triggered people's > knee-jerk reactions, I think) and the URL. Like, what /your/ angle > is, and why you posted it now (the article is a year old). > > Then you accidentally triggered the cross-posting troll, and that > didn't help either. > thats true, though i would suggesting maybe using a word idiot instead of 'troll' (troll is vague and this allows to some idiot to use it agains some other idiots or non idiots and so on) idiot has at least well defined meaning - and pointing that could help to stop lokal idiots to again play idiots.. so word idiot is much better
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-02-24 17:30 +0000 |
| Message-ID | <slrnq75l4p.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #141207 |
On Sun, 2019-02-24, fir wrote: > W dniu niedziela, 24 lutego 2019 11:42:00 UTC+1 użytkownik Jorgen Grahn napisał: ... >> Then you accidentally triggered the cross-posting troll, and that >> didn't help either. > thats true, though i would suggesting maybe using a word idiot > instead of 'troll' (troll is vague and this allows to some idiot to > use it agains some other idiots or non idiots and so on) It's true that "troll" is overused and means different things to different people. > idiot has at least well defined meaning - and pointing that could > help to stop lokal idiots to again play idiots.. so word idiot is > much better But an "idiot" is someone who acts out of ignorance. I cannot imagine any reason for that crosspost, except intention to disrupt the discussion. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-02-24 16:32 +0100 |
| Message-ID | <q4udf0$5ha$2@dont-email.me> |
| In reply to | #141190 |
Le 24/02/2019 à 11:41, Jorgen Grahn a écrit :
> On Sun, 2019-02-24, jacobnavia wrote:
>> Le 23/02/2019 à 21:59, jacobnavia a écrit :
>>> http://delivery.acm.org/10.1145/3220000/3212479/p10-chisnall.pdf?ip=90.22.143.233&id=3212479&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&__acm__=1550954647_0d9af87c752b221627509ce89da282a8
>>>
>>
>> Well, impossible to start a good discussion here.
>> Nobody seems to have read the article, since none of the arguments put
>> forward answers the main arguments of the acm article.
>
> True. But you would have stood a better chance if you had written
> more than the article title (which was what triggered people's
> knee-jerk reactions, I think) and the URL. Like, what /your/ angle
> is, and why you posted it now (the article is a year old).
>
> Then you accidentally triggered the cross-posting troll, and that
> didn't help either.
>
> /Jorgen
>
Yes, I sent ùmy point of view to Ben becarisse, in another post. You are
right. Here it is (a copy of that message)
----------------------------------------------
Le 24/02/2019 à 12:13, Ben Bacarisse a écrit :
> Jacob: what's your view? Is there anything either contentious or useful
> in it? Why did you post the link?
Because it is needed to move C into the direction hardware is going.
1) SIMD operations. This kind of stuff is now in most modern CPUs and
can't be ignored. This should be accessible at the operation level in C
directly.
For instance suppose a type double2 vector:
typedef struct tagdouble2 { double high; double low; } double2;
This wpould make the xmm registers accessible from C. We would have
double2 vector[256];
A table of double2 that should be mapped easily into x86/arm64 hardware:
both have a double2 register set.
Now, operations would be overloaded, with +, -, *, and /, being
overloaded like this:
double2 overloaded double2add(double2 a, double2 b)
{
double2 result;
result.high = a.high + b.high;
result.low = a.low+b.low;
return result;
}
This whole function would map into a single instruction in ARM64/x86.
All this can be done easily with ONE modification to the language:
operator overloading.
I know, I have said this too often during the last 15 years in this
group. I know that I should program in C++ to be able to do that, etc.
But it is still corect, so I say it one more time.
2) Clamped addition, multiplication
int overloaded clampedIntAddition(int a,int b)
{
long long c = a+b;
if (c > INT_MAX) c = UINT_MAX;
return c;
}
Again this function collapses into a single instruction. Again, operator
overloading would be a solution.
3) Access to the CPU cache.
int fn(int arg)
{
register int fastTable[8];
}
The keyword "register" when applied to a table would mean that the table
should be stored in the high speed CPU cache. This would have the same
meaning that the keyword "register" has: the compiler would make a "best
effort" attempt but not any hard guarantee.
This avoids any new keywords to name the cache memory and it looks like
a completely natural extension for a beginner.
The same caveats apply as in the "register" keyword. You can't take the
address of a cache line, you can't expect that it survives function
calls, and you should use it for intermediate results only.
This incredible small syntactic changes would allow C to follow the
hardware in a still portable way, but MUCH closer to the hardware than now.
The committee doesn't at all consider this kinds of stuff, and is busy
doing things like old thread support, what could be nice but is going
nowhere.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-02-24 03:19 -0800 |
| Message-ID | <bd05c5b9-c319-4619-bafc-040485a81d06@googlegroups.com> |
| In reply to | #141183 |
On Sunday, February 24, 2019 at 3:51:39 AM UTC-5, jacobnavia wrote:
> Well, impossible to start a good discussion here.
> Nobody seems to have read the article, since none of the arguments put
> forward answers the main arguments of the acm article.
We couldn't read it. The 500 character link you posted does not work.
> The problem is that C doesn't represent correctly modern hardware, with
> vector instructions, more parallel SIMD instructions, saturating
> operations etc.
C is a low-level language (too "solely low-level" in my opinion).
C should not address hardware extensions. They are architecture-
specific and out of place for the generic C language itself.
However, C compilers for specific architectures do address those
very hardware extensions via intrinsics and built-in types.
https://en.m.wikipedia.org/wiki/Intrinsic_function
These are common, and appropriately applied keeping assembly close
to C, yet without the physical mechanics.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 04:29 -0800 |
| Message-ID | <5975d759-f954-4ba5-97c3-879b759b0b6f@googlegroups.com> |
| In reply to | #141183 |
W dniu niedziela, 24 lutego 2019 09:51:39 UTC+1 użytkownik jacobnavia napisał: > Le 23/02/2019 à 21:59, jacobnavia a écrit : > > http://delivery.acm.org/10.1145/3220000/3212479/p10-chisnall.pdf?ip=90.22.143.233&id=3212479&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&__acm__=1550954647_0d9af87c752b221627509ce89da282a8 > > > > Well, impossible to start a good discussion here. > Nobody seems to have read the article, since none of the arguments put > forward answers the main arguments of the acm article. > > The problem is that C doesn't represent correctly modern hardware, with > vector instructions, more parallel SIMD instructions, saturating > operations etc. > > But trying to discuss C here is quite impossible. The problem with > USENET is that contributions are designed to portray the social image of > the poster, and not to address any discussion based on facts. > > Look at toylet.toylet@gmail.com, that spreads "one liners" with 0% > content like: > > "Repeat the error message using C compiler mentality!" > > Great. > > I thank Lew Pitcher for correcting the URL, but his contributions > stopped at that. > > In the messages of the others there are general remarks about C, none of > them makes any reference to the article. youre silly, you cant give proper link, not saying anything important and complaying that impossible is to discuss things that were already discussed, also omplaining on building social or osychical image when youre one who do it liek most, etc this more defines you yourself like a so to say idiot, you should maybe rethink this
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2019-02-24 11:11 -0500 |
| Message-ID | <q4ufo7$im6$1@dont-email.me> |
| In reply to | #141183 |
jacobnavia wrote: [snip] > I thank Lew Pitcher for correcting the URL, but his contributions > stopped at that. Jacob, my contributions stopped once I read the article. As far as I am concerned, David Chisnall is barking up the wrong tree. Although I could, I'm not interested in writing and posting a rebuttal to an article that I don't give a rat's *ss about. All I see is an attempt to incite another flame-war. -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web