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 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2019-02-25 14:14 +0800 |
| Message-ID | <q5013c$s9s$1@toylet.eternal-september.org> |
| In reply to | #141255 |
On 2/25/2019 4:43 AM, Jasen Betts wrote:
>
> dude you you have no fucking clue!
> I'm not falling for your trolling bullshit,
Generic, standard, multi-purpose answer to everything!
You really have the right to remain silent. Why did you respond? :)
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
¤£É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«!
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> |
|---|---|
| Date | 2019-02-25 10:45 +0000 |
| Message-ID | <WvAVsvxGd8ccFwKr@255soft.uk> |
| In reply to | #141273 |
In message <q5013c$s9s$1@toylet.eternal-september.org>, Mr. Man-wai Chang <toylet.toylet@gmail.com> writes: >On 2/25/2019 4:43 AM, Jasen Betts wrote: >> >> dude you you have no fucking clue! >> I'm not falling for your trolling bullshit, > >Generic, standard, multi-purpose answer to everything! I agree, but ... > >You really have the right to remain silent. Why did you respond? :) > ... why did you (-:? -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Science isn't about being right every time, or even most of the time. It is about being more right over time and fixing what it got wrong. - Scott Adams, 2015-2-2
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2019-02-25 19:04 +0800 |
| Message-ID | <q50i45$huc$2@toylet.eternal-september.org> |
| In reply to | #141297 |
On 2/25/2019 6:45 PM, J. P. Gilliver (John) wrote:
>
> I agree, but ...
>>
>> ...
>>
> ... why did you (-:?
Let's get out of the loop! Deep sleep! :)
--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
¤£É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«!
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-02-24 09:51 +0100 |
| Message-ID | <q4tluj$v5v$1@dont-email.me> |
| In reply to | #141169 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-02-24 09:37 +0000 |
| Message-ID | <VBtcE.16591$af1.14311@fx30.am4> |
| In reply to | #141183 |
On 2019-02-24, jacobnavia <jacob@jacob.remcomp.fr> 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. An error occurred while processing your request. Reference #50.14d6f55b.1551000985.14465b09 > > The problem is that C doesn't represent correctly modern hardware, with > vector instructions, more parallel SIMD instructions, saturating > operations etc. That is why assembler is necessary. -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-24 22:52 +1300 |
| Message-ID | <gdf7q8Fke31U12@mid.individual.net> |
| In reply to | #141183 |
On 24/02/2019 21:51, 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. The article is presents plenty of interesting information some factual, some contentious. The reply here http://esr.ibiblio.org/?p=7979 is a well thought out counter. > The problem is that C doesn't represent correctly modern hardware, with > vector instructions, more parallel SIMD instructions, saturating > operations etc. Indeed, I'm gad I don't work on optimisers! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-24 11:13 +0000 |
| Message-ID | <87d0nh4exi.fsf@bsb.me.uk> |
| In reply to | #141186 |
Ian Collins <ian-news@hotmail.com> writes: > On 24/02/2019 21:51, jacobnavia wrote: >> Le 23/02/2019 à 21:59, jacobnavia a écrit : (corrected link) https://queue.acm.org/detail.cfm?id=3212479 >> >> 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 article is presents plenty of interesting information some > factual, some contentious. I did not find it very contentious, and it seems to say very little about C other than the fact that you can't use C to take full advantage of today's CPU's parallelisms. If it offered any solutions, other than a hint that Erlang may be better, I missed them. The title is provocative, since it's one of those that draws a line and puts C on one or other side if that line, but that's probably deliberate. It won't, however, help reasoned debate on Usenet! I'd raise a query about a remark he makes about memcmp, but that would be to focus on a detail, and I'm sure Jacob want's a big picture discussion. Jacob: what's your view? Is there anything either contentious or useful in it? Why did you post the link? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-02-24 16:30 +0100 |
| Message-ID | <q4udb4$5ha$1@dont-email.me> |
| In reply to | #141192 |
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 | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 07:50 -0800 |
| Message-ID | <567f578d-9f08-4e2a-b2a0-39a20cbe228d@googlegroups.com> |
| In reply to | #141210 |
W dniu niedziela, 24 lutego 2019 16:30:51 UTC+1 użytkownik jacobnavia napisał:
> 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.
lol, i postulate it from years, like
float4 a,b,c;
c=a+b;
maybe you didnt read, but the complains nobaody wnats discuss it as it was already 'discussed' (more showed than discussed) is a bit silly (same with other things)
those things liek above are somewhat handled as gcc extension, you have also intrinsics (may be practically used it not hurts to much as you dont need a wast of that kind of code), and finally, it is not so important at all (as bandwidth matters much more than arithmetic)
as it was said so many times i reject discussing it here, with navia user silly enough mentally not so far away from hodgin
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 08:14 -0800 |
| Message-ID | <6a4ff3ab-c0de-436d-9ab1-0d1bd5b16509@googlegroups.com> |
| In reply to | #141213 |
W dniu niedziela, 24 lutego 2019 16:50:29 UTC+1 użytkownik fir napisał: > of that kind of code), and finally, it is not so important at all (as bandwidth matters much more than arithmetic) > by not so important i also mean that this way (i mean n-int or n-float simds in one thread) may be generally a wrong way (though this hardware support might be used in case of 3d or 4d vectors) same as present gpu is also wrong way (by this duplication of memory ram and video-ram for example) by wrong way i mean it forves c program arhitecture to be 2much artifical and non convenient/ugly more rgiht way probably would be a cluster of cheap scalar (or mostly scalar) threads, but not that ones like todays intel ones but much more simple with simple assembly, ubstead a big lot of them, easy to be managed in form af async calls 9see thread on it back then)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 08:29 -0800 |
| Message-ID | <475e5486-8b8f-49bb-84e9-96391041f34c@googlegroups.com> |
| In reply to | #141217 |
W dniu niedziela, 24 lutego 2019 17:14:46 UTC+1 użytkownik fir napisał: > W dniu niedziela, 24 lutego 2019 16:50:29 UTC+1 użytkownik fir napisał: > > of that kind of code), and finally, it is not so important at all (as bandwidth matters much more than arithmetic) > > > > by not so important i also mean that this way (i mean n-int or n-float simds in one thread) may be generally a wrong way (though this hardware support might be used in case of 3d or 4d vectors) > > same as present gpu is also wrong way (by this duplication of memory ram and video-ram for example) > > by wrong way i mean it forves c program arhitecture to be 2much artifical and non convenient/ugly > > more rgiht way probably would be a cluster of cheap scalar (or mostly scalar) threads, but not that ones like todays intel ones but much more simple with simple assembly, ubstead a big lot of them, easy to be managed in form af async calls 9see thread on it back then) i said 'simple', so teh question is if adding basic support for float3 and float4 should be done or not.. im not sure but maybe yes, yhis is btw just some slight etension of an assembler like adding float or double not making great revoilution (maybe,) (, but this needs to be considered) asm 0on that core) should be simple and easy, but also would need to have what is good to get (have) i also think asm coudl have a mnemonic for memcopy, i mean doing memcopy if n bytes as separate sole instruction, like those oldschool lokin ones mov esi, 0x00401000 mov edi, 0x00421000 mov ecx, 0x1000 memcpy or something like that, maybe 3 arg ones to memcpy edx, axc, 0x1000 it imo would allow the cpu to make some optimisations (as for example then could work on optimising this one subblock in cpu, this one under those memcopies, solely)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 09:00 -0800 |
| Message-ID | <e493fced-dbcc-47e6-885f-f4ee905b5f19@googlegroups.com> |
| In reply to | #141220 |
W dniu niedziela, 24 lutego 2019 17:29:11 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 24 lutego 2019 17:14:46 UTC+1 użytkownik fir napisał:
> > W dniu niedziela, 24 lutego 2019 16:50:29 UTC+1 użytkownik fir napisał:
> > > of that kind of code), and finally, it is not so important at all (as bandwidth matters much more than arithmetic)
> > >
> >
> > by not so important i also mean that this way (i mean n-int or n-float simds in one thread) may be generally a wrong way (though this hardware support might be used in case of 3d or 4d vectors)
> >
> > same as present gpu is also wrong way (by this duplication of memory ram and video-ram for example)
> >
> > by wrong way i mean it forves c program arhitecture to be 2much artifical and non convenient/ugly
> >
> > more rgiht way probably would be a cluster of cheap scalar (or mostly scalar) threads, but not that ones like todays intel ones but much more simple with simple assembly, ubstead a big lot of them, easy to be managed in form af async calls 9see thread on it back then)
>
> i said 'simple',
> so teh question is if adding basic support for float3 and float4 should be done or not.. im not sure but maybe yes, yhis is btw just some slight etension of an assembler like adding float or double not making great revoilution (maybe,)
> (, but this needs to be considered)
>
> asm 0on that core) should be simple and easy, but also would need to have what is
> good to get (have)
>
> i also think asm coudl have a mnemonic for memcopy, i mean doing memcopy if n bytes as separate sole instruction, like those oldschool lokin ones
>
> mov esi, 0x00401000
> mov edi, 0x00421000
> mov ecx, 0x1000
> memcpy
>
> or something like that, maybe 3 arg ones to
>
> memcpy edx, axc, 0x1000
>
> it imo would allow the cpu to make some optimisations (as for example then could
> work on optimising this one subblock in cpu, this one under those memcopies, solely)
besides as a side note it may be seen that asm can be seem as a some kind of primitive c with a set of few tens, hundreds or few thousends of predefined
functions, which you may call
mov(eax, 100)
inc(ebx)
cmp(eax, 200)
jz(-10)
call(0x00403020)
besides to functions also thiose few hardcoded variables and also block of static date block (some simpla analogon of arrays with initialisation)
my_string: 61 62 63 64 65 0
('elaborate' assemblers also able to
turn some immediate values into etiquettes)
then its probably to possible of moving gradually and 'softly' from this primitive assembler into c
like by ading user defined functions
def foo()
{
mov(eax, 30)
inc(ecx)
}
(consuming ret and ethiquette (label) and so on
this primitive c elements has some charm imo, i mean it would have advantages as assembler (like physical counting of statements (mnemonics) with c attitude of writing things faster (than in usual assembler as i remenver it)
i should only do some more thinking on this 'soft' steps (it could be practically usefull as i have my own x86 assembler written and i could add some more 'higheer' (c directing) features in it to be su[ported and compiled
but now im too lazy (got other things to do)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-24 17:16 +0100 |
| Message-ID | <q4ug11$m0m$1@dont-email.me> |
| In reply to | #141210 |
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>
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.
So getting vector operations for basic arithmetic is not a problem with
these compilers. However, standardisation of these features is another
matter altogether.
>
> 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.
>
> 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!)
double2 addDouble2(double2 a, double2 b) {
return a + b;
}
addDouble2:
addpd xmm0, xmm1 # tmp85, tmp87
ret
Overloaded operators are not needed. Indeed, overloaded operators are
exactly what you /don't/ want here.
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
You want the compiler to generate the right code without having to make
your own overloaded functions.
(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.)
>
> 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. 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".
>
> 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.)
>
> 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. And "register" has been deprecated in C++ 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.
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. 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.
> 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 | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 08:42 -0800 |
| Message-ID | <ff8c719f-653b-4b12-b7c8-4df2f67aa2f5@googlegroups.com> |
| In reply to | #141218 |
W dniu niedziela, 24 lutego 2019 17:16:40 UTC+1 użytkownik David Brown napisał:
> On 24/02/2019 16:30, jacobnavia wrote:
> > Le 24/02/2019 à 12:13, Ben Bacarisse a écrit :
> > 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
no, this is fully corect (and obvious, i was writing on such things too, sometimes maybe in a bit more generalized spirit of this; ( as far as i remember i proposed considering, more memory 'modifiers' or 'attributes' you could use for variables and arrays or functions, too, like "fast"
(when you want inform compiler this table should be in fast memory) or "slow"(when you want inform it may be in some slow) (some could upthink some more usable) register is an obvious initial case for this kind of thinking ))
what sometimes 'worries' me is what i said when i quite in depth describet osme things 5 years later some come bac and say on the same things not crediting what i wrote (and what they probably readed ;c) (bot fuck em, not that i too much care, i just dont like to make some false facts, lieke it was not already said (exact same things plus a bit more ;c )
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2019-02-24 09:38 -0800 |
| Message-ID | <c946b467-a585-4c51-89eb-d2edee03a4d1@googlegroups.com> |
| In reply to | #141221 |
On Sunday, 24 February 2019 16:42:44 UTC, fir wrote:
> what sometimes 'worries' me is what i said when i quite in depth describet osme things 5 years later some come bac and say on the same things not crediting what i wrote (and what they probably readed ;c) (bot fuck em, not that i too much care, i just dont like to make some false facts, lieke it was not already said (exact same things plus a bit more ;c )
So, 5 years ago was 2014?
I was implementing stuff like this:
p := (100,100)
q := (260,200)
m := (p+q)/2
println m # output (180.0, 150.0, 0.0)
some /25/ years ago. And I'm certain the capability was in plenty of other languages at the time, in some even decades before that.
So when you write stuff like this:
> lol, i postulate it from years, like
>
> float4 a,b,c;
>
> c=a+b;
and then try and claim credit for ideas that have been around for decades, then you really are having a laugh.
AFAIK the OP has already implemented such possibilities in an extended C, and they have long been available in C++; the discussion as I understand it is how far standard C should go with such features rather than keep the language primitive and have to rely on super-optimising compilers.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 10:09 -0800 |
| Message-ID | <af092c2a-dacc-4485-b998-3151ceabc89c@googlegroups.com> |
| In reply to | #141225 |
W dniu niedziela, 24 lutego 2019 18:38:14 UTC+1 użytkownik bart...@gmail.com napisał: > On Sunday, 24 February 2019 16:42:44 UTC, fir wrote: > > > what sometimes 'worries' me is what i said when i quite in depth describet osme things 5 years later some come bac and say on the same things not crediting what i wrote (and what they probably readed ;c) (bot fuck em, not that i too much care, i just dont like to make some false facts, lieke it was not already said (exact same things plus a bit more ;c ) > > So, 5 years ago was 2014? > here i used this 5 years like a bit aproximately or methaphorical (it is to be checked in usenet archives) i said this becouse it began to repeat: when i go to c.l.c and describe some things people not much discuss on this - that 5 years later 'suddenly' they come and exactly repeats what i said before without not 'referencing' this (and navia really repeats it so exactly like he would be proclaiming (?, soory weak englisz "głosić" in polish, 'speaking out') some tutorial he readed on that things, tutorial of which im an author ..and then i feel i must add this words.. as i said its not about that im sole author of thsoe ideas (as some of them are like some ppublic domain of thoughts i think) but that i wrote on this what navie talks (wrote exactly on this all) and this is some fact seing this 'repeated' but not referenced as i said i also not say this that i want to be referenced (i dont much care) but i dont want to make some false facts (and not saying what i say here as i was already writing on this i would find as this false fact creation) so i add this 'disclaimer'/note to stick to history of this topic/propositions on usener (the fact that is spreaded over some years dont much matter as it is more like i was stating it month ago or week ago as i got relatively good memory on what i wrote on usenet when it comes to c improvements) > I was implementing stuff like this: > > p := (100,100) > q := (260,200) > m := (p+q)/2 > println m # output (180.0, 150.0, 0.0) > > some /25/ years ago. And I'm certain the capability was in plenty of other languages at the time, in some even decades before that. > > So when you write stuff like this: > > > lol, i postulate it from years, like > > > > float4 a,b,c; > > > > c=a+b; > > and then try and claim credit for ideas that have been around for decades, then you really are having a laugh. > > AFAIK the OP has already implemented such possibilities in an extended C, and they have long been available in C++; the discussion as I understand it is how far standard C should go with such features rather than keep the language primitive and have to rely on super-optimising compilers.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 10:13 -0800 |
| Message-ID | <3b6f303c-0303-4349-a86e-89b0714c8d2f@googlegroups.com> |
| In reply to | #141225 |
W dniu niedziela, 24 lutego 2019 18:38:14 UTC+1 użytkownik bart...@gmail.com napisał: > > So when you write stuff like this: > > > lol, i postulate it from years, like > > > > float4 a,b,c; > > > > c=a+b; > > and then try and claim credit for ideas that have been around for decades, then you really are having a laugh. > not really, as i dont write on what you suggest,m your head just looks like is to weak to understand the difference and watching of that kind of your conclusion im geting much closer to treat you finaly as a depresing idiot amnd get rid any talk with you as level of your stupidity is just far tu big for me to want to mix into that - thats sad reality, but you hard work on that,
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 10:23 -0800 |
| Message-ID | <d82d0587-27df-4d94-963e-dc94b6636e80@googlegroups.com> |
| In reply to | #141225 |
W dniu niedziela, 24 lutego 2019 18:38:14 UTC+1 użytkownik bart...@gmail.com napisał: > > AFAIK the OP has already implemented such possibilities in an extended C, and they have long been available in C++; the discussion as I understand it is how far standard C should go with such features rather than keep the language primitive and have to rely on super-optimising compilers. and what i was writing you think was on what? it was also on the same, navia repeats all that 1:1, its like 1) he well understands that now 2) but it took him five years 3) and he skipped to give the reference to the 'oryginal copy' of what he writes made by me some years ago here it is possible that he not readed that, or readed it not very carefully etc, but it not just changes the situation..as i say its not about nabie skipping the referency but about me giving that reference (it was really all stated 1:1 by me) other problems is those ideas are like public domain in some way float4 for example was not my own local invention i seen this in shader language... othervise those ides in that case are rather obvious, but repeating it in exact same set is then les probable... the idea what people used what aprts of this idea is not on what i wrote, i wrote on this that as to usenet i was stating exact things like nabia now but back then he besides is free tu use it, wries compiler, use it and fare well, i just as i said feel that this back reference should be added (regardles if he was reading that beck then or no)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-24 10:48 -0800 |
| Message-ID | <ee8e37da-b2cd-4157-ae1e-dd9987386d5a@googlegroups.com> |
| In reply to | #141233 |
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, as present programing world is a conglomerate of thousands of important ideas, but most are not credited..if they would be cradited it could be better maybe (or maybe not, in fact im not sure)..if i would be inventor of say stack and how pass local variables on this i could be angry if i would invented this and it would be tiotally not referenced, hovever i wouldnt insist ofc to make it referenced in all usecase, or all programmers knowing whose idea was that ;c bit soem ideas really has its authors and this may be usefull to reference that if some of those authors want like live some academic life or something and be noted fairly for thise ideas i sorta see myself as that kind of academic worker, some ideas cost me much work (maybe not this which is mostly an act of stylistical choice, but some other are maybe more conboluted) and are most proabably non existant in cultural scope of programmers so if its used not crediting it is false situation (but it is spieakig a bit moge general, here bavia just repaets 1:1 of what i said few years ago, not giving any kind of reference? maybe he not readed, but make that reference myslef and no big deal)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-24 19:07 +0000 |
| Message-ID | <GXBcE.21881$aY4.2749@fx25.am4> |
| In reply to | #141235 |
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.
[toc] | [prev] | [next] | [standalone]
Page 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web