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 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 12:17 -0500 |
| Message-ID | <250220191217487233%nospam@nospam.invalid> |
| In reply to | #141313 |
In article <6ITcE.119027$G52.102800@fx39.iad>, Wolf K <wolfmac@sympatico.ca> wrote: > > About ten years ago, I was startled, speaking to a new graduate with a > > computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER. > > Thinking about it afterwards, I decided that the computing world is > > certainly big enough that he'd have no difficulty in finding employment, > > but it did throw me at the time; I'd come up through (7-bit serial then) > > 8-bit, 6800 and 6502, then in professional life some work in bit-slice > > processors (AMD 2901, 2960, etc., and the IDT copies thereof), where we > > had to _create_ our assembly tools as we assembled our processors. > > > > Maybe nowadays assembler is _rare_? > > I think human-created assembler is becoming rare. it is indeed. machine created assembly is almost always better than anything humans can do, plus developers do not want to be tied to a single processor. > However, I have the > impression that robotics requires machine-coded assembler, translated > from whatever human-readable language was used to program the machine. > Those neat videos of dog=like robots loping through the building are > misleading. Their abilities are not only severely limited, but those > abilities were programmed on large machines cabled to the robot. The > programs were tweaked and compressed before being copied to the on-board > chips that control the "dog". where did you get that impression? that is wrong on multiple levels. > Maybe someone from MIT or Boston Dynamics can clarify and correct. maybe.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-25 13:52 -0800 |
| Message-ID | <lnr2bvo7sk.fsf@kst-u.example.com> |
| In reply to | #141313 |
Wolf K <wolfmac@sympatico.ca> writes:
[...]
> I think human-created assembler is becoming rare. However, I have the
> impression that robotics requires machine-coded assembler, translated
> from whatever human-readable language was used to program the machine.
That's true of compiled languages in general, and is not specific to
robotics.
Most compiled languages are translated to assembly language
(or directly to machine language, depending on how the compiler
is designed). (Some, such as Java, are compiled to some kind of
byte code which is then interpreted, but Java can also be compiled
to assembly or machine code.)
[...]
[Followups to comp.programming, which is the only one of the
cross-posted newsgroups that seems appropriate.]
--
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 | "NY" <me@privacy.net> |
|---|---|
| Date | 2019-02-25 15:20 +0000 |
| Message-ID | <zoidnfqlAvoHmunBnZ2dnUU78L3NnZ2d@brightview.co.uk> |
| In reply to | #141311 |
"J. P. Gilliver (John)" <G6JPG-255@255soft.uk> wrote in message news:+BH$Xu6fFAdcFwF7@255soft.uk... > In message <j8TcE.148893$c46.43996@fx07.iad>, Wolf K > <wolfmac@sympatico.ca> writes: > [] >>FTR, I took an IBM assembler about 40 years ago. Can still read maybe 20% >>of an assembler printout, but couldn't code my way out of paper bag. But >>by the end of the course, I could write 15-20 lines without a bug. The >>instructor said this was pretty good. >> > About ten years ago, I was startled, speaking to a new graduate with a > computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER. > Thinking about it afterwards, I decided that the computing world is > certainly big enough that he'd have no difficulty in finding employment, > but it did throw me at the time; I'd come up through (7-bit serial then) > 8-bit, 6800 and 6502, then in professional life some work in bit-slice > processors (AMD 2901, 2960, etc., and the IDT copies thereof), where we > had to _create_ our assembly tools as we assembled our processors. > > Maybe nowadays assembler is _rare_? When I was at university, doing electronic engineering, in the early 1980s, we did a bit of assembler programming, in 6809. Everyone was very frustrated at the choice of CPU because those who had their own computer had either a CP/M-based (Z80) or Commodore Pet (6502); no-one had a computer that used a 6809 that they could practice on out of hours. Of course, a few years later, 8086 and its successors (386, 486 etc) would have been fairly universal ;-) Nowadays they'd probably also teach RISC (eg SPARC and ARM) processors. I remember as a project we had to write software which allowed serial data to be written to a tape and to be read from it, and I don't think anyone go their equipment working: as a project it was a bit too advanced for the amount of practical time allocated to it. I *think* the high-level language we were taught was Pascal. Certainly we didn't learn C because I remember having to learn that from scratch when I started my first job. As a little exercise I managed to code a bubble sort in Z80 on my Wren CP/M 3 computer in the mid 80s. I wrote a BASIC program which allowed a user to enter intergers into an array, then passed the address of that array to a Z80 sort routine and then returned control to the BASIC program to print it out. Developing it was fairly thankless because any mistake in the Z80 crashed the computer, requiring it to be rebooted (from floppy). But I got it working. I forget the actual timings, but I know that the Z80 routine was several orders of magnitude faster than the same algorithm in interpreted BASIC and several times faster than a compiled Pascal program with the same algorithm. I would imagine that the ability to write assembler for any given CPU is nowadays fairly specialised and only done for specific routines that need the absolute maximum speed.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 12:17 -0500 |
| Message-ID | <250220191217517376%nospam@nospam.invalid> |
| In reply to | #141314 |
In article <zoidnfqlAvoHmunBnZ2dnUU78L3NnZ2d@brightview.co.uk>, NY <me@privacy.net> wrote: > When I was at university, doing electronic engineering, in the early 1980s, > we did a bit of assembler programming, in 6809. Everyone was very frustrated > at the choice of CPU because those who had their own computer had either a > CP/M-based (Z80) or Commodore Pet (6502); no-one had a computer that used a > 6809 that they could practice on out of hours. Of course, a few years later, > 8086 and its successors (386, 486 etc) would have been fairly universal ;-) > Nowadays they'd probably also teach RISC (eg SPARC and ARM) processors. their frustration was unfamiliarity and inability to learn new things. the 6809 was a *very* good processor, along with its successor, the 68000 series,*far* easier to write code than the z80 and x86. > I remember as a project we had to write software which allowed serial data > to be written to a tape and to be read from it, and I don't think anyone go > their equipment working: as a project it was a bit too advanced for the > amount of practical time allocated to it. > > I *think* the high-level language we were taught was Pascal. Certainly we > didn't learn C because I remember having to learn that from scratch when I > started my first job. pascal was designed to be taught, but ended up being used for much, much more than that. > As a little exercise I managed to code a bubble sort in Z80 on my Wren CP/M > 3 computer in the mid 80s. I wrote a BASIC program which allowed a user to > enter intergers into an array, then passed the address of that array to a > Z80 sort routine and then returned control to the BASIC program to print it > out. Developing it was fairly thankless because any mistake in the Z80 > crashed the computer, requiring it to be rebooted (from floppy). But I got > it working. I forget the actual timings, but I know that the Z80 routine was > several orders of magnitude faster than the same algorithm in interpreted > BASIC and several times faster than a compiled Pascal program with the same > algorithm. that just means the compiler wasn't any good. > I would imagine that the ability to write assembler for any given CPU is > nowadays fairly specialised and only done for specific routines that need > the absolute maximum speed. yep, and it's *really* hard to beat a modern compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-25 18:47 +0000 |
| Message-ID | <OKWcE.4572$jw5.3521@fx25.am4> |
| In reply to | #141332 |
On 25/02/2019 17:17, nospam wrote: > In article <zoidnfqlAvoHmunBnZ2dnUU78L3NnZ2d@brightview.co.uk>, NY > <me@privacy.net> wrote: >> As a little exercise I managed to code a bubble sort in Z80 on my Wren CP/M >> 3 computer in the mid 80s. I wrote a BASIC program which allowed a user to >> enter intergers into an array, then passed the address of that array to a >> Z80 sort routine and then returned control to the BASIC program to print it >> out. Developing it was fairly thankless because any mistake in the Z80 >> crashed the computer, requiring it to be rebooted (from floppy). But I got >> it working. I forget the actual timings, but I know that the Z80 routine was >> several orders of magnitude faster than the same algorithm in interpreted >> BASIC and several times faster than a compiled Pascal program with the same >> algorithm. > > that just means the compiler wasn't any good. 'Several times faster than compiled' sounds about par for the time. >> I would imagine that the ability to write assembler for any given CPU is >> nowadays fairly specialised and only done for specific routines that need >> the absolute maximum speed. > > yep, and it's *really* hard to beat a modern compiler. When writing my interpreters I can routinely get double the performance of gcc-O3, using a non-optimising compiler for 90% of the code coupled with in-line assembly for the main byte-code handlers. In this case it works through having knowledge of the big picture, not available to gcc, and using that to maintain a tight register-based ASM environment.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 13:50 -0500 |
| Message-ID | <250220191350140024%nospam@nospam.invalid> |
| In reply to | #141334 |
In article <OKWcE.4572$jw5.3521@fx25.am4>, Bart <bc@freeuk.com> wrote: > >> I would imagine that the ability to write assembler for any given CPU is > >> nowadays fairly specialised and only done for specific routines that need > >> the absolute maximum speed. > > > > yep, and it's *really* hard to beat a modern compiler. > > When writing my interpreters I can routinely get double the performance > of gcc-O3, using a non-optimising compiler for 90% of the code coupled > with in-line assembly for the main byte-code handlers. > > In this case it works through having knowledge of the big picture, not > available to gcc, and using that to maintain a tight register-based ASM > environment. gcc is not an example of a modern compiler. pretty much anything is faster, it's that bad.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-25 18:59 +0000 |
| Message-ID | <jWWcE.1315$ON.1014@fx38.am4> |
| In reply to | #141364 |
On 25/02/2019 18:50, nospam wrote: > In article <OKWcE.4572$jw5.3521@fx25.am4>, Bart <bc@freeuk.com> wrote: > >>>> I would imagine that the ability to write assembler for any given CPU is >>>> nowadays fairly specialised and only done for specific routines that need >>>> the absolute maximum speed. >>> >>> yep, and it's *really* hard to beat a modern compiler. >> >> When writing my interpreters I can routinely get double the performance >> of gcc-O3, using a non-optimising compiler for 90% of the code coupled >> with in-line assembly for the main byte-code handlers. >> >> In this case it works through having knowledge of the big picture, not >> available to gcc, and using that to maintain a tight register-based ASM >> environment. > > gcc is not an example of a modern compiler. pretty much anything is > faster, it's that bad. I got similar results with clang and MSVC. I don't have access to anything else other than smaller compilers which are much worse. Are there any freely available C compilers that could generate code that is /twice/ as fast as gcc-O3 (for the app in my example)? (The performance of gcc in this case can be probably be tweaked by messing around with specialist options, adding attributes, selectively inlining etc, but then you end up spending as much effort as writing the ASM, and it still would not get anywhere near that speed-up.)
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-25 20:15 +0200 |
| Message-ID | <rundkf-l8n.ln1@gangtai.home.grep.be> |
| In reply to | #141332 |
On 25/02/2019 20:05, nospam wrote: > code that is not called can't slow anything down. That's actually not true. Code that is not called but is compiled in will use up space in a memory page. If that means the code segment of the program grows beyond a page boundary, that may then mean an extra page fault will need to be handled when part of the program is swapped out, which would otherwise not be necessary. Also, code that is not called but is compiled in may confuse the speculative execution bits of modern microarchitectures into believing the code will do something when it cannot possibly do so. I remember a blog post (can't find it now) from a guy who wrote about a broken opcode on a particular PowerPC-derived processor which will always cause the processor to lock up. Due to speculative execution, even *including* that opcode in the program, even if it's not ever called, could cause the processor to lock up.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-02-25 18:38 +0000 |
| Message-ID | <tCWcE.24897$Js6.2488@fx16.iad> |
| In reply to | #141339 |
Wouter Verhelst <w@uter.be> writes: >On 25/02/2019 20:05, nospam wrote: >> code that is not called can't slow anything down. > >That's actually not true. > >Code that is not called but is compiled in will use up space in a memory >page. If that means the code segment of the program grows beyond a page >boundary, that may then mean an extra page fault will need to be handled >when part of the program is swapped out, which would otherwise not be >necessary. This is true, but less damaging than the effect on instruction cache footprint, which effect is much larger than the effect on the TLB due to additional pages. > >Also, code that is not called but is compiled in may confuse the >speculative execution bits of modern microarchitectures into believing >the code will do something when it cannot possibly do so. Only to the extent that the code is in the execution path (e.g. a seldom executed 'else' clause), but most compilers will elide uncallable and unreachable code completely from the resutling executable. > >I remember a blog post (can't find it now) from a guy who wrote about a >broken opcode on a particular PowerPC-derived processor which will >always cause the processor to lock up. Due to speculative execution, >even *including* that opcode in the program, even if it's not ever >called, could cause the processor to lock up. Again, it would need to be included in a code path that _could_ have been executed (e.g. on a conditional branch) for speculative execution to have caused any issues. Speculative execution doesn't just pick up random bits of the instruction stream and start executing them.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-26 12:49 +0200 |
| Message-ID | <07ifkf-tqb.ln1@gangtai.home.grep.be> |
| In reply to | #141357 |
On 25/02/2019 20:38, Scott Lurndal wrote: > Again, it would need to be included in a code path that _could_ > have been executed (e.g. on a conditional branch) for speculative > execution to have caused any issues. That is true; but the code in question was behind a "this really shouldn't happen, but in case it does, ..." type of test. Speculative execution will still pick that up, and it caused the program in question to crash. The unlikely condition abstract enough that the compiler could not optimize it out, let alone the speculative execution in the processor, but beyond that it was never going to be actually executed. Except speculatively, which caused the crash. I should have been clearer about that. > Speculative execution doesn't > just pick up random bits of the instruction stream and start executing > them. Sure.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 13:40 -0500 |
| Message-ID | <250220191340475998%nospam@nospam.invalid> |
| In reply to | #141339 |
In article <rundkf-l8n.ln1@gangtai.home.grep.be>, Wouter Verhelst <w@uter.be> wrote: > > code that is not called can't slow anything down. > > That's actually not true. it is true. what matters is the code that *is* called. > Code that is not called but is compiled in will use up space in a memory > page. If that means the code segment of the program grows beyond a page > boundary, that may then mean an extra page fault will need to be handled > when part of the program is swapped out, which would otherwise not be > necessary. that's more theoretical than anything real. nearly everything is i/o bound, and then there are all the other processes... > Also, code that is not called but is compiled in may confuse the > speculative execution bits of modern microarchitectures into believing > the code will do something when it cannot possibly do so. modern compilers already handle that, and one reason why writing assembly that's better than what a compiler can output is *extremely* difficult. > I remember a blog post (can't find it now) from a guy who wrote about a > broken opcode on a particular PowerPC-derived processor which will > always cause the processor to lock up. Due to speculative execution, > even *including* that opcode in the program, even if it's not ever > called, could cause the processor to lock up. that's called 'a bug'.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-26 12:55 +0200 |
| Message-ID | <siifkf-tqb.ln1@gangtai.home.grep.be> |
| In reply to | #141365 |
On 25/02/2019 20:40, nospam wrote: > In article <rundkf-l8n.ln1@gangtai.home.grep.be>, Wouter Verhelst > <w@uter.be> wrote: > >>> code that is not called can't slow anything down. >> >> That's actually not true. > > it is true. what matters is the code that *is* called. You're saying that the code can't slow thing down if it's not called. That's a fairly absolute statement; I just showed you a counter-example, and so did Scott. So your absolute statement is just *wrong*. >> Code that is not called but is compiled in will use up space in a memory >> page. If that means the code segment of the program grows beyond a page >> boundary, that may then mean an extra page fault will need to be handled >> when part of the program is swapped out, which would otherwise not be >> necessary. > > that's more theoretical than anything real. It does happen though, and the more "not called" code you add to a program the larger the chances of this happening. Also, it pollutes the processor cache, as Scott pointed out, which will be more likely. > nearly everything is i/o bound, and then there are all the other > processes... It's precisely the other processes which will cause (part of) your program to get (partially) paged out if it is huge, which will cause your slowdowns.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-02-26 16:29 +0000 |
| Message-ID | <8QddE.167$8k5.40@fx33.iad> |
| In reply to | #141437 |
Wouter Verhelst <w@uter.be> writes: >On 25/02/2019 20:40, nospam wrote: >> In article <rundkf-l8n.ln1@gangtai.home.grep.be>, Wouter Verhelst >> <w@uter.be> wrote: >> >>>> code that is not called can't slow anything down. >>> >>> That's actually not true. >> >> it is true. what matters is the code that *is* called. > >You're saying that the code can't slow thing down if it's not called. >That's a fairly absolute statement; I just showed you a counter-example, >and so did Scott. So your absolute statement is just *wrong*. > >>> Code that is not called but is compiled in will use up space in a memory >>> page. If that means the code segment of the program grows beyond a page >>> boundary, that may then mean an extra page fault will need to be handled >>> when part of the program is swapped out, which would otherwise not be >>> necessary. >> >> that's more theoretical than anything real. > >It does happen though, and the more "not called" code you add to a >program the larger the chances of this happening. Actually it happens more often than you think, which is one reason that execution-driven feedback into code layout is so effective in increasing application performance for certain classes of applications. > >> nearly everything is i/o bound, and then there are all the other >> processes... Not at all true, particularly with respect to the applications where performance matters (HPC, in-memory databases, etc). Windows desktop applications aren't the whole world, you know.
[toc] | [prev] | [next] | [standalone]
| From | Diesel <nobody@haph.org> |
|---|---|
| Date | 2019-03-05 04:29 +0000 |
| Message-ID | <XnsAA08EFC8FEB41HT1@doCX0.74.zmu4y91> |
| In reply to | #141440 |
scott@slp53.sl.home (Scott Lurndal) news:8QddE.167$8k5.40@fx33.iad Tue, 26 Feb 2019 16:29:56 GMT in alt.windows7.general, wrote: > Windows desktop applications aren't the whole world, you know. nospam doesn't, afaik, write windows desktop applications. They write apps for Apple based products. cell phones primarily I believe, in a scripting language. So...I dunno what level of programmer or coder you'd actually consider the individual to be. -- I just reversed the polarity flow.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-03-04 23:43 -0500 |
| Message-ID | <040320192343236896%nospam@nospam.invalid> |
| In reply to | #141679 |
In article <XnsAA08EFC8FEB41HT1@doCX0.74.zmu4y91>, Diesel <nobody@haph.org> wrote: > > Windows desktop applications aren't the whole world, you know. > > nospam doesn't, afaik, write windows desktop applications. not currently, but i have in the past. > They write > apps for Apple based products. cell phones primarily I believe, in a > scripting language. not even close to correct, and not even possible, given that both android and ios apps are not written in a scripting language. > So...I dunno what level of programmer or coder > you'd actually consider the individual to be. a rather successful one.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-02-25 10:01 -0800 |
| Message-ID | <0af1eecc-aaa9-459c-b45e-c12058aa99a5@googlegroups.com> |
| In reply to | #141332 |
On Monday, February 25, 2019 at 7:44:55 PM UTC+2, NY wrote: > "nospam" <nospam@nospam.invalid> wrote in message > news:250220191217517376%nospam@nospam.invalid... > >> but I know that the Z80 routine was > >> several orders of magnitude faster than the same algorithm in interpreted > >> BASIC and several times faster than a compiled Pascal program with the > >> same > >> algorithm. > > > > that just means the compiler wasn't any good. > > > > yep, and it's *really* hard to beat a modern compiler > > The compiler in question was Turbo Pascal of mid- to late-1980s vintage, > running on a Z80 under CP/M 3. I'm not sure how efficient that was. As you > say, modern compilers may well be more efficient - but they may also bloat > the code with code that was never actually called but was compiled in > nevertheless ;-) > > I should have tried to code a more efficient sort algorithm than bubble > sort, to see how much improvement there was, but bubble is simple to > remember (*) and to code, and I was doing it as a programming exercise > rather than with a real-life application that needed the fastest sort > available. > > > (*) I can remember it without needing to look it up every time, and I can > visualise exactly what it's doing, whereas shell sorts start to make my > brain hurt working out what they are doing ;-) Straight selection and straight insertions sorts are both simpler than bubble sorts to understand and remember and faster in all situations except for sorting already almost sorted input. Which is faster between the too "straights" depends on relative cost of comparison vs record movement.
[toc] | [prev] | [next] | [standalone]
| From | "NY" <me@privacy.net> |
|---|---|
| Date | 2019-02-25 18:16 +0000 |
| Message-ID | <FLudnZ66S65BrenBnZ2dnUU78TXNnZ2d@brightview.co.uk> |
| In reply to | #141332 |
"nospam" <nospam@nospam.invalid> wrote in message news:250220191305329065%nospam@nospam.invalid... > In article <yL2dnUP1iNIStOnBnZ2dnUU78dnNnZ2d@brightview.co.uk>, NY > <me@privacy.net> wrote: > >> >> but I know that the Z80 routine was >> >> several orders of magnitude faster than the same algorithm in >> >> interpreted >> >> BASIC and several times faster than a compiled Pascal program with the >> >> same >> >> algorithm. >> > >> > that just means the compiler wasn't any good. >> > >> > yep, and it's *really* hard to beat a modern compiler >> >> The compiler in question was Turbo Pascal of mid- to late-1980s vintage, >> running on a Z80 under CP/M 3. I'm not sure how efficient that was. > > that's not a modern compiler nor a modern processor either. Exactly. I imagine that a modern compiler and processor may achieve a result which was closer to the native assembly language for that processor. >> As you >> say, modern compilers may well be more efficient - but they may also >> bloat >> the code with code that was never actually called but was compiled in >> nevertheless ;-) > > they don't, but even if that were true, code that is not called can't > slow anything down. I was using "efficient" in both senses - both in terms of speed and in terms of small executable size. > bubble sort is very easy to write, it's just not fast. Is it any quicker if alternate passes are in opposite directions, to make the largest number bubble to the top and then the smallest number bubble to the bottom? As long as in both cases you stop the loop one number less/greater than you did last time to exclude testing the number that is now at the top/bottom of the list.
[toc] | [prev] | [next] | [standalone]
| From | "NY" <me@privacy.net> |
|---|---|
| Date | 2019-02-25 17:44 +0000 |
| Message-ID | <yL2dnUP1iNIStOnBnZ2dnUU78dnNnZ2d@brightview.co.uk> |
| In reply to | #141332 |
"nospam" <nospam@nospam.invalid> wrote in message news:250220191217517376%nospam@nospam.invalid... >> but I know that the Z80 routine was >> several orders of magnitude faster than the same algorithm in interpreted >> BASIC and several times faster than a compiled Pascal program with the >> same >> algorithm. > > that just means the compiler wasn't any good. > > yep, and it's *really* hard to beat a modern compiler The compiler in question was Turbo Pascal of mid- to late-1980s vintage, running on a Z80 under CP/M 3. I'm not sure how efficient that was. As you say, modern compilers may well be more efficient - but they may also bloat the code with code that was never actually called but was compiled in nevertheless ;-) I should have tried to code a more efficient sort algorithm than bubble sort, to see how much improvement there was, but bubble is simple to remember (*) and to code, and I was doing it as a programming exercise rather than with a real-life application that needed the fastest sort available. (*) I can remember it without needing to look it up every time, and I can visualise exactly what it's doing, whereas shell sorts start to make my brain hurt working out what they are doing ;-)
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 13:05 -0500 |
| Message-ID | <250220191305329065%nospam@nospam.invalid> |
| In reply to | #141362 |
In article <yL2dnUP1iNIStOnBnZ2dnUU78dnNnZ2d@brightview.co.uk>, NY <me@privacy.net> wrote: > >> but I know that the Z80 routine was > >> several orders of magnitude faster than the same algorithm in interpreted > >> BASIC and several times faster than a compiled Pascal program with the > >> same > >> algorithm. > > > > that just means the compiler wasn't any good. > > > > yep, and it's *really* hard to beat a modern compiler > > The compiler in question was Turbo Pascal of mid- to late-1980s vintage, > running on a Z80 under CP/M 3. I'm not sure how efficient that was. that's not a modern compiler nor a modern processor either. > As you > say, modern compilers may well be more efficient - but they may also bloat > the code with code that was never actually called but was compiled in > nevertheless ;-) they don't, but even if that were true, code that is not called can't slow anything down. > I should have tried to code a more efficient sort algorithm than bubble > sort, to see how much improvement there was, but bubble is simple to > remember (*) and to code, and I was doing it as a programming exercise > rather than with a real-life application that needed the fastest sort > available. > > (*) I can remember it without needing to look it up every time, and I can > visualise exactly what it's doing, whereas shell sorts start to make my > brain hurt working out what they are doing ;-) bubble sort is very easy to write, it's just not fast.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-02-26 00:51 -0600 |
| Message-ID | <0do97etnq9hsqr954ci8aak1q1gc74hkbd@4ax.com> |
| In reply to | #141370 |
On Mon, 25 Feb 2019 13:05:32 -0500, nospam <nospam@nospam.invalid> wrote: >In article <yL2dnUP1iNIStOnBnZ2dnUU78dnNnZ2d@brightview.co.uk>, NY ><me@privacy.net> wrote: > >> >> but I know that the Z80 routine was >> >> several orders of magnitude faster than the same algorithm in interpreted >> >> BASIC and several times faster than a compiled Pascal program with the >> >> same >> >> algorithm. >> > >> > that just means the compiler wasn't any good. >> > >> > yep, and it's *really* hard to beat a modern compiler >> >> The compiler in question was Turbo Pascal of mid- to late-1980s vintage, >> running on a Z80 under CP/M 3. I'm not sure how efficient that was. > >that's not a modern compiler nor a modern processor either. > >> As you >> say, modern compilers may well be more efficient - but they may also bloat >> the code with code that was never actually called but was compiled in >> nevertheless ;-) > >they don't, but even if that were true, code that is not called can't >slow anything down. > >> I should have tried to code a more efficient sort algorithm than bubble >> sort, to see how much improvement there was, but bubble is simple to >> remember (*) and to code, and I was doing it as a programming exercise >> rather than with a real-life application that needed the fastest sort >> available. >> >> (*) I can remember it without needing to look it up every time, and I can >> visualise exactly what it's doing, whereas shell sorts start to make my >> brain hurt working out what they are doing ;-) > >bubble sort is very easy to write, it's just not fast. Insertion sort is even easier to write. And it's usually twice as fast as bubble sort.
[toc] | [prev] | [next] | [standalone]
Page 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web