Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91178 > unrolled thread
| Started by | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-27 22:36 +0200 |
| Last post | 2016-08-01 07:20 -0700 |
| Articles | 20 on this page of 193 — 30 participants |
Back to article view | Back to comp.lang.c
IEEE: C is the first programming language jacob navia <jacob@jacob.remcomp.fr> - 2016-07-27 22:36 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-27 16:42 -0700
Re: IEEE: C is the first programming language jacob navia <jacob@jacob.remcomp.fr> - 2016-07-28 01:47 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-27 17:20 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-27 18:03 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 00:43 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 05:12 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 05:41 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 06:02 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 06:26 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 06:45 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 09:11 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 09:30 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-28 14:03 +0200
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 05:24 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 01:14 +0200
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 18:27 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 12:08 +0200
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-29 11:37 +0100
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 12:51 +0200
Re: IEEE: C is the first programming language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-29 08:36 -0600
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 05:32 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 14:42 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 06:59 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 16:08 +0100
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-29 09:16 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 09:21 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 17:55 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 11:00 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 11:48 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 21:12 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 19:39 -0700
Re: IEEE: C is the first programming language luser droog <luser.droog@gmail.com> - 2016-07-29 14:56 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 08:54 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-01 10:30 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 08:13 -0700
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:18 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 07:34 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 14:10 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-29 23:36 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 16:04 -0700
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-07-30 11:22 +1200
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-30 01:09 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 08:08 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 21:16 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 22:13 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-02 13:33 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 08:11 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:36 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 07:51 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 08:19 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 10:18 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 11:16 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 11:49 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 12:37 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 13:15 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 14:05 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 15:53 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 18:03 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 10:50 -0700
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-07-28 10:50 +0200
Re: IEEE: C is the first programming language "Osmium" <r124c4u102@comcast.net> - 2016-07-28 08:11 -0500
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:46 -0700
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 16:50 +0200
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-01 11:18 +0200
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 05:37 -0700
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 14:02 +0100
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 07:05 -0700
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 16:04 +0100
Re: Setting architectural features in stone Ivan Godard <ivan@millcomputing.com> - 2016-08-01 09:26 -0700
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 10:12 -0700
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-01 10:21 -0700
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 11:01 -0700
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-01 11:44 -0700
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-02 12:05 +0200
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 15:48 +0000
Re: Setting architectural features in stone Walter Banks <walter@bytecraft.com> - 2016-08-02 20:09 -0400
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 06:42 +0000
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-03 11:02 +0100
Re: Setting architectural features in stone Ivan Godard <ivan@millcomputing.com> - 2016-08-03 03:15 -0700
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 11:53 +0000
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-03 08:57 -0700
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-03 10:52 +0200
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-03 11:09 +0100
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-03 08:51 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 10:51 +0100
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-08-01 13:13 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 05:27 -0700
Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-01 10:00 -0700
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 10:29 +0000
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-01 16:29 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 15:53 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-04 16:37 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-04 16:07 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-04 20:38 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:52 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:00 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 03:12 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 21:48 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 20:07 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:03 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-05 13:09 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:38 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 11:24 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 15:28 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 08:25 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 16:36 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 08:41 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 16:45 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 09:41 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 19:45 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 09:47 +1200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-06 16:11 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 21:50 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 19:12 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 22:38 -0400
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 14:06 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:04 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:27 +0200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 20:24 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:30 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:03 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:36 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:11 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:02 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 07:35 +1200
Re: IEEE: C is the first programming language "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-08 16:00 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 08:07 +1200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-08 21:22 +0100
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:08 +0200
Re: IEEE: C is the first programming language jameskuyper@verizon.net - 2016-08-08 13:39 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:54 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:50 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 15:19 +0200
Re: IEEE: C is the first programming language already5chosen@yahoo.com - 2016-08-09 09:14 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 19:22 +0200
Re: IEEE: C is the first programming language James Kuyper <jameskuyper@verizon.net> - 2016-08-09 11:12 -0400
Re: IEEE: C is the first programming language cross@spitfire.i.gajendra.net (Dan Cross) - 2016-08-09 15:25 +0000
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 19:50 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 16:44 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 17:38 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:51 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 20:06 +0200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:57 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:51 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 12:15 +0200
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-08-08 11:57 +0100
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-08 23:04 +1200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 15:20 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:27 -0400
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:21 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 17:33 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 14:35 -0400
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-08-05 14:06 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 14:37 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 13:53 +0200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 14:09 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:08 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:34 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:37 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 19:18 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 12:31 +0200
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 03:55 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-08 08:28 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 09:44 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-08 10:13 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 07:51 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:39 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 11:27 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 15:29 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 08:38 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:40 -0400
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-28 21:27 +0200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 00:19 +0200
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-08-01 11:49 +0200
Re: IEEE: C is the first programming language raltbos@xs4all.nl (Richard Bos) - 2016-07-28 10:01 +0000
Re: IEEE: C is the first programming language Les Cargill <lcargill99@comcast.com> - 2016-07-28 01:57 -0500
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:27 -0700
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-07-28 09:06 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 09:39 -0700
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-07-28 11:56 -0700
Re: IEEE: C is the first programming language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-07-28 15:19 -0400
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:15 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 05:25 -0700
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:37 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 08:21 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-27 17:17 -0700
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 14:17 +0200
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-28 18:43 +0200
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 18:58 +0200
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 21:46 +0200
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-01 16:37 +1200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 07:20 -0700
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-03 11:53 +0000 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <2016Aug3.135348@mips.complang.tuwien.ac.at> |
| In reply to | #91591 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >I'll just add a note to say that it's not always clear if an >architecture is byte addressed or word addressed. I worked on a machine >whose underlying hardware used word addresses but, because it was >microcoded, so the instruction set that was designed for C could have >byte addresses. To keep compares simple, the low order-bit was used to >identify the byte (words were 16 bit), but to keep most accesses fast, >word addresses were used wherever possible. The result was a systems >where some address conversions generated code. Sure, we can have all kinds of perverse architectures. This particular case seems to be some disconnect between hardware design and instruction set on the transition from word-addressed to byte-addressed machines. That part has been sorted out by now, or at least I would hope so. If you make a word-addressed machine these days, it's because you don't want to process characters, and accept that you use one character per word for the few cases where you need to process characters (at least if you are sane). But the C standard still wants to be future-proof for the time when such misdesigns are coming back. >This was a long time ago (the early 80s) so there was no standard C and >a very large amount of C code extant at the time made assumptions that >were not compatible with this design, so even simple Unix utilities that >could have been almost 100% portable needed a lot of work to get them to >run (sort was a nightmare). I am sure that this has not changed. >Experience of odd machines and of pre-standard C gives one a different >perspective, I find. My main worry about ignoring this perspective is >not that new code won't run on old machines (who cares?) but that new >architectures might come along where the pressure to design for speed, >or concurrency or security or some other as yet un-envisioned goal makes >today's safe assumptions unsafe. Hardware designers make hard-to-program nonsense all the time, e.g., the Cell architecture or weak memory consistency models; they also make special-purpose architectural features like X and Y address spaces and the accumulators in DSPs. Has retro-proofing the C standard by not standardizing common-practice features helped with any of that? No. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-03 08:57 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <1864e358-791a-454b-a659-d8eea09431f9@googlegroups.com> |
| In reply to | #91591 |
On Wednesday, August 3, 2016 at 5:02:45 AM UTC-5, Ben Bacarisse wrote: > This was a long time ago (the early 80s) so there was no standard C and > a very large amount of C code extant at the time made assumptions that > were not compatible with this design, so even simple Unix utilities that > could have been almost 100% portable needed a lot of work to get them to > run (sort was a nightmare). When I used a machine with a word-addressed architecture, about half of the things I would have stored as `char[]` remained char, and half of them were stored in octet-packed arrays which could be packed and unpacked via some small machine-language functions. While it might have been convenient to have had compiler support for a octet-packed format, C's type system would have made it difficult to write code that would be efficient on both the word-addressed DSP and on a byte-addressed CPU, since that would require that a compiler support an addressable type smaller than "char"--a concept the Standard cannot recognize even on hardware that could support it.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-08-03 10:52 +0200 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <nnsbd9$djj$1@dont-email.me> |
| In reply to | #91588 |
[ Adding comp.lang.c back since we're discussing C ] On 03/08/2016 04:37, Quadibloc wrote: > However, C does specify that string constants may include things like \n and > this means that char values must be able to represent lower-case letters. I don't follow your logic. What does '\n' have to do with lower-case? On DOS systems, '\n' is encoded as CR-LF. > Therefore, a system where characters are six bits long would conflict with > the C standard [...] Right, there is a lower limit; a C char must be *at least* 8 bits wide. (Because CHAR_BIT >= 8 and UCHAR_MAX >= 255) Regards.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-03 11:09 +0100 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <87wpjytb80.fsf@bsb.me.uk> |
| In reply to | #91590 |
Noob <root@127.0.0.1> writes: > [ Adding comp.lang.c back since we're discussing C ] > > On 03/08/2016 04:37, Quadibloc wrote: > >> However, C does specify that string constants may include things like \n and >> this means that char values must be able to represent lower-case letters. > > I don't follow your logic. What does '\n' have to do with lower-case? Maybe all that's being said is that C source code needs lower case? I would not have picked on \n for that since the language is simple full of the need for lower case so I may be misunderstand what Quadibloc means here. > On DOS systems, '\n' is encoded as CR-LF. Just to clarify... A C implementation by translate '\n' into a sequence like CR-LF on output to a text stream, but '\n' must be an integer value in the range of char, and "\n" must be a string of length one. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-03 08:51 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <lna8gt3l7b.fsf@kst-u.example.com> |
| In reply to | #91590 |
Noob <root@127.0.0.1> writes:
> [ Adding comp.lang.c back since we're discussing C ]
>
> On 03/08/2016 04:37, Quadibloc wrote:
>
>> However, C does specify that string constants may include things like \n and
>> this means that char values must be able to represent lower-case letters.
>
> I don't follow your logic. What does '\n' have to do with lower-case?
> On DOS systems, '\n' is encoded as CR-LF.
>
>> Therefore, a system where characters are six bits long would conflict with
>> the C standard [...]
>
> Right, there is a lower limit; a C char must be *at least* 8 bits wide.
>
> (Because CHAR_BIT >= 8 and UCHAR_MAX >= 255)
And the basic character set includes both uppercase and lowecase
letters, and an implementation must distinguish between them both at
compile time and at run time.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-01 10:51 +0100 |
| Message-ID | <8737mox1ev.fsf@bsb.me.uk> |
| In reply to | #91236 |
supercat@casperkitty.com writes: > On Thursday, July 28, 2016 at 3:50:28 AM UTC-5, Noob wrote: >> Overflow flag? "All the world's an x86", eh? > > The majority of C code written will never need to be targeted for anything > other than a general-purpose reprogrammable microcomputer, and the > overwhelming majority of such devices share a number of architectural > features with the PDP-11: > > 1. Integer sizes are power-of-two multiples of an 8-bit character type. > > 2. Each size of integer larger than the character type is stored as two > halves in either big-endian or little-endian order. The PDP-11 uses both at once. I'm not sure if that's covered by your wording. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-08-01 13:13 +0200 |
| Message-ID | <nnnasp$ok5$1@dont-email.me> |
| In reply to | #91463 |
On 01/08/2016 11:51, Ben Bacarisse wrote: > supercat@casperkitty.com writes: > >> The majority of C code written will never need to be targeted for anything >> other than a general-purpose reprogrammable microcomputer, and the >> overwhelming majority of such devices share a number of architectural >> features with the PDP-11: >> >> 1. Integer sizes are power-of-two multiples of an 8-bit character type. >> >> 2. Each size of integer larger than the character type is stored as two >> halves in either big-endian or little-endian order. > > The PDP-11 uses both at once. I'm not sure if that's covered by your > wording. aka "middle-endian" :-) https://en.wikipedia.org/wiki/Endianness#Middle-endian Regards.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 05:27 -0700 |
| Message-ID | <a4762831-964d-46e2-a221-0dc8e8b111b5@googlegroups.com> |
| In reply to | #91463 |
On Monday, August 1, 2016 at 4:51:27 AM UTC-5, Ben Bacarisse wrote: > supercat writes: > > The majority of C code written will never need to be targeted for anything > > other than a general-purpose reprogrammable microcomputer, and the > > overwhelming majority of such devices share a number of architectural > > features with the PDP-11: > > > > 1. Integer sizes are power-of-two multiples of an 8-bit character type. > > > > 2. Each size of integer larger than the character type is stored as two > > halves in either big-endian or little-endian order. > > The PDP-11 uses both at once. I'm not sure if that's covered by your > wording. Are 32-bit longs stored as two 16-bit halves in either big-endian or little-endian order? Are 16-bit shorts stored as two 8-bit halves in either big-endian or little-endian order? The wording covers four possible orderings for bytes in a word, though 0-1-2-3 and 3-2-1-0 are more common than 1-0-3-2 or 2-3-0-1; the wording does not allow for the other 20 theoretically-possible orderings.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-08-01 10:00 -0700 |
| Subject | Setting architectural features in stone |
| Message-ID | <909ab710-8489-4fdf-88b6-15ffb67181ea@googlegroups.com> |
| In reply to | #91236 |
On Thursday, July 28, 2016 at 8:47:21 AM UTC-6, supe...@casperkitty.com wrote: > On Thursday, July 28, 2016 at 3:50:28 AM UTC-5, Noob wrote: > > Overflow flag? "All the world's an x86", eh? > The majority of C code written will never need to be targeted for anything > other than a general-purpose reprogrammable microcomputer, and the > overwhelming majority of such devices share a number of architectural > features with the PDP-11: > 1. Integer sizes are power-of-two multiples of an 8-bit character type. > 2. Each size of integer larger than the character type is stored as two > halves in either big-endian or little-endian order. > 3. A relational comparison between pointers will never have any effect > other than to either indicate that the a particular pointer is higher > or that it isn't, in a fashion that forms a ranking (on some older > computers, the relation tested by equality operators might not be > consistent with that tested by relational operators, but the relational > operators would be consistent among themselves). > 4. Integer arithmetic operations are performed in sign-agnostic fashion > except for promotion, division, right-shift, and relational operators; > thus the default hardware behavior is two's-complement silent > wraparound. > Can you suggest any remotely-common general-purpose reprogrammable > microcomputers where any of the above do not apply? I think that the bigger question here would be: is there any good reason for any of those features not to apply to any architecture? (3) does not apply to some architectures because they provide a high level of isolation between data belonging to different processes, and that is a good and useful thing. Some historical systems used integer formats other than two's complement, thus missing (4), but that is pretty much dead today. It is true, though, that "wraparound" arithmetic is only useful for stuff like pseudorandom number generation, and usually catching overflow as an error for integers as is done for floats would make more sense. I can think of good reasons for breaking (1) and hence (2). When the IBM 360 came along to replace the IBM 7090, a lot of people complained that they had to switch their scientific programs to use double precision, where before they produced useful results with only single precision. So a computer that, say, had 36-bit single precision floats, 48-bit intermediate precision floats, and 60-bit double precision floats (since 64 bits is already overly long, and the Control Data 6600, with a 60 bit word, seemed to make everyone happy) - as multiples of a 12-bit unit, and, hence, presumably a 48-bit word length with fancy features to make accessing of unaligned operands efficient - would offer the highest possible floating-point performance by not using any more precision than is actually needed to get the job done! As for (2) by itself, though, why wouldn't a computer be either consistently big-endian (my preference, as that's then consistent with packed and unpacked decimal too) or consistently little-endian? What useful purpose would something like the original PDP-11's floating-point format serve? John Savard
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-02 10:29 +0000 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <2016Aug2.122926@mips.complang.tuwien.ac.at> |
| In reply to | #91501 |
Quadibloc <jsavard@ecn.ab.ca> writes: >On Thursday, July 28, 2016 at 8:47:21 AM UTC-6, supe...@casperkitty.com wro= >te: >> The majority of C code written will never need to be targeted for anythin= >g >> other than a general-purpose reprogrammable microcomputer, and the >> overwhelming majority of such devices share a number of architectural >> features with the PDP-11: > >> 1. Integer sizes are power-of-two multiples of an 8-bit character type. > >> 2. Each size of integer larger than the character type is stored as two >> halves in either big-endian or little-endian order. > >> 3. A relational comparison between pointers will never have any effect >> other than to either indicate that the a particular pointer is highe= >r >> or that it isn't, in a fashion that forms a ranking (on some older >> computers, the relation tested by equality operators might not be >> consistent with that tested by relational operators, but the relatio= >nal >> operators would be consistent among themselves). > >> 4. Integer arithmetic operations are performed in sign-agnostic fashion >> except for promotion, division, right-shift, and relational operator= >s; >> thus the default hardware behavior is two's-complement silent >> wraparound. > >> Can you suggest any remotely-common general-purpose reprogrammable >> microcomputers where any of the above do not apply? > >I think that the bigger question here would be: is there any good reason fo= >r any of those features not to apply to any architecture? > >(3) does not apply to some architectures because they provide a high level = >of isolation between data belonging to different processes, and that is a g= >ood and useful thing. Which architectures? How do different processes come into play? Do you expect a C compiler to compile a standard C program into running several processes, especially on a machine with a high level of isolation between data belonging to different processes? >Some historical systems used integer formats other than two's complement, t= >hus missing (4), but that is pretty much dead today. Right. No new architectures of this kind for over 40 years, maybe even 50. And even Unisys, the last holdout of non-twos-complement hardware, now emulates the Univac 1100 successor's ones-complement architecture on Intel Xeon based hardware. >It is true, though, th= >at "wraparound" arithmetic is only useful for stuff like pseudorandom numbe= >r generation The significant number of programs that require -fwrapv to compile as intended and that don't do PRNG using singed integers are counterevidence for this claim. >I can think of good reasons for breaking (1) and hence (2). When the IBM 36= >0=20 >came along to replace the IBM 7090, a lot of people complained that they ha= >d to=20 >switch their scientific programs to use double precision, where before they= >=20 >produced useful results with only single precision. > >So a computer that, say, had 36-bit single precision floats, 48-bit=20 >intermediate precision floats, and 60-bit double precision floats (since 64= >=20 >bits is already overly long, and the Control Data 6600, with a 60 bit word,= >=20 >seemed to make everyone happy) - as multiples of a 12-bit unit, and, hence,= >=20 >presumably a 48-bit word length with fancy features to make accessing of=20 >unaligned operands efficient - would offer the highest possible floating-po= >int=20 >performance by not using any more precision than is actually needed to get = >the=20 >job done! Just as some programs no longer work when you change 36-bit to 32-bit FP numbers (especially with the IBM 360s broken FP representation, which lost 3 (or 4?) more bits in the worst case, there are programs who will no longer work when you change 64-bit to 60-bit or 48-bit FP. If 48-bit FP was as much of a winner as you believe, hardware companies would have offered 48-bit floats on byte-addressed machines, complete with fast multiply-by-6 instructions or addressing modes. Or if the power-of-2 FP size was more important than the 8-bit byte, they would even go for your 12-bit byte. But don't take my word for it: Prove me wrong by actually building and selling a machine with 48-bit floats, and 12-bit bytes. If you are right, your machine will be a huge success. >As for (2) by itself, though, why wouldn't a computer be either consistentl= >y=20 >big-endian (my preference, as that's then consistent with packed and unpack= >ed=20 >decimal too) or consistently little-endian? Good question, and other than the PDP-11, I don't know of a counter-example. Anyway, even between big-endian and little-endian, there seems to be consolidation towards little-endian: <https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-44a4f27eba32/entry/just_the_faqs_about_little_endian?lang=en> |Why is Linux on Power transitioning from big endian to little endian? | |The Power architecture is bi-endian in that it supports accessing data |in both little endian and big endian modes. Although Power already has |Linux distributions and supporting applications that run in big endian |mode, the Linux application ecosystem for x86 platforms is much larger |and Linux on x86 uses little endian mode. Numerous clients, software |partners, and IBM’s own software developers have told us that porting |their software to Power becomes simpler if the Linux environment on |Power supports little endian mode, more closely matching the |environment provided by Linux on x86. This new level of support will |lower the barrier to entry for porting Linux on x86 software to Linux |on Power. But it will take many decades until that will reach the kind of universality that twos-complement has now. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-01 16:29 -0400 |
| Message-ID | <nnobfg$edt$1@jstuckle.eternal-september.org> |
| In reply to | #91236 |
On 7/28/2016 10:46 AM, supercat@casperkitty.com wrote: > On Thursday, July 28, 2016 at 3:50:28 AM UTC-5, Noob wrote: >> Overflow flag? "All the world's an x86", eh? > > The majority of C code written will never need to be targeted for anything > other than a general-purpose reprogrammable microcomputer, and the > overwhelming majority of such devices share a number of architectural > features with the PDP-11: > > 1. Integer sizes are power-of-two multiples of an 8-bit character type. > > 2. Each size of integer larger than the character type is stored as two > halves in either big-endian or little-endian order. > > 3. A relational comparison between pointers will never have any effect > other than to either indicate that the a particular pointer is higher > or that it isn't, in a fashion that forms a ranking (on some older > computers, the relation tested by equality operators might not be > consistent with that tested by relational operators, but the relational > operators would be consistent among themselves). > > 4. Integer arithmetic operations are performed in sign-agnostic fashion > except for promotion, division, right-shift, and relational operators; > thus the default hardware behavior is two's-complement silent > wraparound. > > Can you suggest any remotely-common general-purpose reprogrammable > microcomputers where any of the above do not apply? > Why does it have to be "remotely-common general-purpose re-programmable microcomputers"? You are leaving out over 90% of the processors that can use C. For instance, there are many DSP chips which have 10 or 12 bit registers. Other embedded MPUs and MCUs have different needs - and different architectures. Integers may or may not be stored as two halves in big-endian or little-endian order. Integer arithmetic may or may not be sign-agnostic. Yet there are C compilers for many of the above. And they far outnumber microprocessors. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 15:53 -0700 |
| Message-ID | <d7a16335-118e-4c8d-a038-36ef0e4a8c51@googlegroups.com> |
| In reply to | #91527 |
On Monday, August 1, 2016 at 3:29:43 PM UTC-5, Jerry Stuckle wrote:
> Why does it have to be "remotely-common general-purpose re-programmable
> microcomputers"? You are leaving out over 90% of the processors that
> can use C.
A lot of code is intended to be used with a variety of commonplace
machines, but is not expected to be used with weird or exotic
architectures. Many embedded systems have architectures which are
similar to general-purpose reprogrammable computers, and code which
is written for commonplace computers will generally work or be readily
adaptable for use on such embedded systems.
> Yet there are C compilers for many of the above. And they far outnumber
> microprocessors.
The most popular embedded architectures, by far, fit with all of the above
except that some compilers for 8-bit targets support a 24-bit "short long"
type [which is not a power-of-two size]. I've worked with some exotic
architectures like a DSP where "char" is 16 bits, and would simultaneously
say that:
1. As a C programmer, it's a lot nicer working in a dialect of C which
is adapted for an exotic system than it would be to work in assembly
code, but ...
2. I would regard "C with 16-bit char" as being a different language
from "C for commonplace platforms". Trying to write many kinds of
code in a fashion that would work equally well on both would take
more time and yield an inferior result compared with writing one
version of the code for use on the 16-bit-char platform and another
for use with commonplace platforms.
What useful purpose is achieved by requiring programmers to bend over
backward to accommodate the behavioral quirks of platforms upon which
nobody will ever want to run their code?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-04 16:37 -0400 |
| Message-ID | <no092e$p1l$1@jstuckle.eternal-september.org> |
| In reply to | #91543 |
On 8/1/2016 6:53 PM, supercat@casperkitty.com wrote: > On Monday, August 1, 2016 at 3:29:43 PM UTC-5, Jerry Stuckle wrote: >> Why does it have to be "remotely-common general-purpose re-programmable >> microcomputers"? You are leaving out over 90% of the processors that >> can use C. > > A lot of code is intended to be used with a variety of commonplace > machines, but is not expected to be used with weird or exotic > architectures. Many embedded systems have architectures which are > similar to general-purpose reprogrammable computers, and code which > is written for commonplace computers will generally work or be readily > adaptable for use on such embedded systems. > And C is intended to be usable by a large number of different processors and architectures. >> Yet there are C compilers for many of the above. And they far outnumber >> microprocessors. > > The most popular embedded architectures, by far, fit with all of the above > except that some compilers for 8-bit targets support a 24-bit "short long" > type [which is not a power-of-two size]. I've worked with some exotic > architectures like a DSP where "char" is 16 bits, and would simultaneously > say that: > Whether they are the "most popular" or not is immaterial. Many programmers still write C code for them - because C works. > 1. As a C programmer, it's a lot nicer working in a dialect of C which > is adapted for an exotic system than it would be to work in assembly > code, but ... > That's YOUR opinion. It is not shared by many programmers - especially the ones on the Standards Committee. > 2. I would regard "C with 16-bit char" as being a different language > from "C for commonplace platforms". Trying to write many kinds of > code in a fashion that would work equally well on both would take > more time and yield an inferior result compared with writing one > version of the code for use on the 16-bit-char platform and another > for use with commonplace platforms. > See above. > What useful purpose is achieved by requiring programmers to bend over > backward to accommodate the behavioral quirks of platforms upon which > nobody will ever want to run their code? > There are more of those platforms out there than those which meet the limitations you would put on C. You would be limiting C to maybe 10% of the MPUs and MCUs in use today (if not even fewer). So, why not just create your own language that meets your specifications? You miss one of the the primary purposes of C - to be usable on a large number of different processors. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-04 16:07 -0700 |
| Message-ID | <e91db178-c83f-443a-9b4c-d0c0d7ad3820@googlegroups.com> |
| In reply to | #91675 |
On Thursday, August 4, 2016 at 3:37:44 PM UTC-5, Jerry Stuckle wrote: > On 8/1/2016 6:53 PM, supercat wrote: > > A lot of code is intended to be used with a variety of commonplace > > machines, but is not expected to be used with weird or exotic > > architectures. Many embedded systems have architectures which are > > similar to general-purpose reprogrammable computers, and code which > > is written for commonplace computers will generally work or be readily > > adaptable for use on such embedded systems. > > And C is intended to be usable by a large number of different processors > and architectures. When have I ever claimed that it wasn't? > > On Monday, August 1, 2016 at 3:29:43 PM UTC-5, Jerry Stuckle wrote: > >> Yet there are C compilers for many of the above. And they far outnumber > >> microprocessors. > > > > The most popular embedded architectures, by far, fit with all of the above > > except that some compilers for 8-bit targets support a 24-bit "short long" > > type [which is not a power-of-two size]. I've worked with some exotic > > architectures like a DSP where "char" is 16 bits, and would simultaneously > > say that: > > Whether they are the "most popular" or not is immaterial. Many > programmers still write C code for them - because C works. Should I have said the embedded architectures with the highest sales volumes (which also happen to be the most popular)? Since the market is dominated by a small number of architectures that have the traits I describe, I'm curious how there can be a higher number of CPUs of any form that don't. > > 1. As a C programmer, it's a lot nicer working in a dialect of C which > > is adapted for an exotic system than it would be to work in assembly > > code, but ... > > That's YOUR opinion. It is not shared by many programmers - especially > the ones on the Standards Committee. You're saying the Standards committee would think that programming exotic architectures in assembly language is nicer than working in C? > > 2. I would regard "C with 16-bit char" as being a different language > > from "C for commonplace platforms". Trying to write many kinds of > > code in a fashion that would work equally well on both would take > > more time and yield an inferior result compared with writing one > > version of the code for use on the 16-bit-char platform and another > > for use with commonplace platforms. > > See above. All Internet communication is octet-based. Any device which needs to communicate with the Internet will thus need to do octet-based I/O. If code needs to store large numbers of octets efficiently, which is more practical: 1. Have code which is running on any kind of machine perform "store octet" and "fetch octet" operations to access the contents of octet buffers, or 2. Have code which is running on octet-based machines use arrays of "uint8_t", and figure that if it is ever necessary to use the code on other kinds of machines it will need to be rewritten to use packed buffers. > > What useful purpose is achieved by requiring programmers to bend over > > backward to accommodate the behavioral quirks of platforms upon which > > nobody will ever want to run their code? > > There are more of those platforms out there than those which meet the > limitations you would put on C. You would be limiting C to maybe 10% of > the MPUs and MCUs in use today (if not even fewer). Do you mean physical machines or architectures? Can you identify some of the supposed 90% of the marketplace that I'm ignoring? > So, why not just create your own language that meets your > specifications? You miss one of the the primary purposes of C - to be > usable on a large number of different processors. Such a language was in use throughout the 1990s, and was called C.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-04 20:38 -0400 |
| Message-ID | <no0n5h$4eb$1@jstuckle.eternal-september.org> |
| In reply to | #91691 |
On 8/4/2016 7:07 PM, supercat@casperkitty.com wrote: > On Thursday, August 4, 2016 at 3:37:44 PM UTC-5, Jerry Stuckle wrote: >> On 8/1/2016 6:53 PM, supercat wrote: >>> A lot of code is intended to be used with a variety of commonplace >>> machines, but is not expected to be used with weird or exotic >>> architectures. Many embedded systems have architectures which are >>> similar to general-purpose reprogrammable computers, and code which >>> is written for commonplace computers will generally work or be readily >>> adaptable for use on such embedded systems. >> >> And C is intended to be usable by a large number of different processors >> and architectures. > > When have I ever claimed that it wasn't? > Yet you want to limit the hardware it runs on. >>> On Monday, August 1, 2016 at 3:29:43 PM UTC-5, Jerry Stuckle wrote: >>>> Yet there are C compilers for many of the above. And they far outnumber >>>> microprocessors. >>> >>> The most popular embedded architectures, by far, fit with all of the above >>> except that some compilers for 8-bit targets support a 24-bit "short long" >>> type [which is not a power-of-two size]. I've worked with some exotic >>> architectures like a DSP where "char" is 16 bits, and would simultaneously >>> say that: >> >> Whether they are the "most popular" or not is immaterial. Many >> programmers still write C code for them - because C works. > > Should I have said the embedded architectures with the highest sales > volumes (which also happen to be the most popular)? Since the market is > dominated by a small number of architectures that have the traits I > describe, I'm curious how there can be a higher number of CPUs of any > form that don't. > You would still be wrong. There are more CPUs and MCUs in your car than computers in your house. Then add in all of the DSP and other specialized processing chips. They are all over the place. And a large number of them use other than multiples of 8 bits. >>> 1. As a C programmer, it's a lot nicer working in a dialect of C which >>> is adapted for an exotic system than it would be to work in assembly >>> code, but ... >> >> That's YOUR opinion. It is not shared by many programmers - especially >> the ones on the Standards Committee. > > You're saying the Standards committee would think that programming exotic > architectures in assembly language is nicer than working in C? > Nope, but they also don't require working in a dialect of C that is adapted to an exotic system. >>> 2. I would regard "C with 16-bit char" as being a different language >>> from "C for commonplace platforms". Trying to write many kinds of >>> code in a fashion that would work equally well on both would take >>> more time and yield an inferior result compared with writing one >>> version of the code for use on the 16-bit-char platform and another >>> for use with commonplace platforms. >> >> See above. > > All Internet communication is octet-based. Any device which needs to > communicate with the Internet will thus need to do octet-based I/O. If > code needs to store large numbers of octets efficiently, which is more > practical: > So what? That's a small portion of the processors out there. > 1. Have code which is running on any kind of machine perform "store octet" > and "fetch octet" operations to access the contents of octet buffers, or > > 2. Have code which is running on octet-based machines use arrays of > "uint8_t", and figure that if it is ever necessary to use the code on > other kinds of machines it will need to be rewritten to use packed > buffers. > Having machines which are well suited for their purpose. There are far more processors out there not connected to the internet then are. >>> What useful purpose is achieved by requiring programmers to bend over >>> backward to accommodate the behavioral quirks of platforms upon which >>> nobody will ever want to run their code? >> >> There are more of those platforms out there than those which meet the >> limitations you would put on C. You would be limiting C to maybe 10% of >> the MPUs and MCUs in use today (if not even fewer). > > Do you mean physical machines or architectures? Can you identify some of > the supposed 90% of the marketplace that I'm ignoring? > Both. DSPs are a start. So are most of the MCUs and many of the CPUs used in embedded systems - such as the computers controlling the various systems in your automobile. >> So, why not just create your own language that meets your >> specifications? You miss one of the the primary purposes of C - to be >> usable on a large number of different processors. > > Such a language was in use throughout the 1990s, and was called C. > Nope, C is a general purpose language that runs on many different architectures - and puts very few limitations on those architectures. What you are proposing is a new language that runs on a very limited number of architectures. You obviously have no idea what the market is outside of Intel-compatible and maybe a few ARM processors. That accounts for only a small percentage of the world. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-04 23:52 -0700 |
| Message-ID | <16ab17e6-2b9b-4487-b821-9cb34beb4999@googlegroups.com> |
| In reply to | #91696 |
On Friday, August 5, 2016 at 1:38:16 AM UTC+1, Jerry Stuckle wrote: > > You obviously have no idea what the market is outside of > Intel-compatible and maybe a few ARM processors. That accounts for only > a small percentage of the world. > The relevant metric is percentage of development time devoted to programming such devices. You might have a little chip in you car that costs fifty cents and emits a bleep if a seat is occupied, the car is in motion, and the seatbelt is not engaged. But that's all it does. Its core logic is just the line if(seatweight > threshold && velocity > thresholdv && !seatbeltin) bleep(); Then you've got to support the sensors which inform it of the three conditions, and the output to the bell. But that's all it does. It will never run more code than that in all its useful life. It's certainly a programming job for someone, but not comparable to the work generated producing software for Windows-based PCs.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-05 13:00 -0400 |
| Message-ID | <no2gn9$e1t$1@jstuckle.eternal-september.org> |
| In reply to | #91704 |
On 8/5/2016 2:52 AM, Malcolm McLean wrote: > On Friday, August 5, 2016 at 1:38:16 AM UTC+1, Jerry Stuckle wrote: >> >> You obviously have no idea what the market is outside of >> Intel-compatible and maybe a few ARM processors. That accounts for only >> a small percentage of the world. >> > The relevant metric is percentage of development time devoted to > programming such devices. > You might have a little chip in you car that costs fifty cents > and emits a bleep if a seat is occupied, the car is in motion, > and the seatbelt is not engaged. But that's all it does. Its > core logic is just the line > > if(seatweight > threshold && velocity > thresholdv && !seatbeltin) > bleep(); > Then you've got to support the sensors which inform it of the > three conditions, and the output to the bell. > But that's all it does. It will never run more code than that > in all its useful life. > It's certainly a programming job for someone, but not comparable > to the work generated producing software for Windows-based PCs. > Manufacturers do not dedicate a chip (even a fifty cent one) to such a trivial example. And many of the operations in an automobile are more complicated than the average Windows program. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-06 03:12 -0700 |
| Message-ID | <ebe535c5-56c0-4b60-bae0-66272666c9fb@googlegroups.com> |
| In reply to | #91745 |
On Friday, August 5, 2016 at 6:00:33 PM UTC+1, Jerry Stuckle wrote: > On 8/5/2016 2:52 AM, Malcolm McLean wrote: > > On Friday, August 5, 2016 at 1:38:16 AM UTC+1, Jerry Stuckle wrote: > >> > >> You obviously have no idea what the market is outside of > >> Intel-compatible and maybe a few ARM processors. That accounts for only > >> a small percentage of the world. > >> > > The relevant metric is percentage of development time devoted to > > programming such devices. > > You might have a little chip in you car that costs fifty cents > > and emits a bleep if a seat is occupied, the car is in motion, > > and the seatbelt is not engaged. But that's all it does. Its > > core logic is just the line > > > > if(seatweight > threshold && velocity > thresholdv && !seatbeltin) > > bleep(); > > Then you've got to support the sensors which inform it of the > > three conditions, and the output to the bell. > > But that's all it does. It will never run more code than that > > in all its useful life. > > It's certainly a programming job for someone, but not comparable > > to the work generated producing software for Windows-based PCs. > > > > Manufacturers do not dedicate a chip (even a fifty cent one) to such a > trivial example. And many of the operations in an automobile are more > complicated than the average Windows program. > You can build an AND gate electrically. But it's easier just to use a chip. Then we can tweak the various threshold values simply be changing numbers in the software rather then by redesigning the electronics.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-06 21:48 -0400 |
| Message-ID | <no6425$21p$2@jstuckle.eternal-september.org> |
| In reply to | #91798 |
On 8/6/2016 6:12 AM, Malcolm McLean wrote: > On Friday, August 5, 2016 at 6:00:33 PM UTC+1, Jerry Stuckle wrote: >> On 8/5/2016 2:52 AM, Malcolm McLean wrote: >>> On Friday, August 5, 2016 at 1:38:16 AM UTC+1, Jerry Stuckle wrote: >>>> >>>> You obviously have no idea what the market is outside of >>>> Intel-compatible and maybe a few ARM processors. That accounts for only >>>> a small percentage of the world. >>>> >>> The relevant metric is percentage of development time devoted to >>> programming such devices. >>> You might have a little chip in you car that costs fifty cents >>> and emits a bleep if a seat is occupied, the car is in motion, >>> and the seatbelt is not engaged. But that's all it does. Its >>> core logic is just the line >>> >>> if(seatweight > threshold && velocity > thresholdv && !seatbeltin) >>> bleep(); >>> Then you've got to support the sensors which inform it of the >>> three conditions, and the output to the bell. >>> But that's all it does. It will never run more code than that >>> in all its useful life. >>> It's certainly a programming job for someone, but not comparable >>> to the work generated producing software for Windows-based PCs. >>> >> >> Manufacturers do not dedicate a chip (even a fifty cent one) to such a >> trivial example. And many of the operations in an automobile are more >> complicated than the average Windows program. >> > You can build an AND gate electrically. > But it's easier just to use a chip. Then we can tweak the various > threshold values simply be changing numbers in the software rather > then by redesigning the electronics. > Which has absolutely what to do with this discussion? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-06 20:07 -0700 |
| Message-ID | <90c5cf0f-5bd5-4720-8de1-35761884e6b5@googlegroups.com> |
| In reply to | #91835 |
On Sunday, August 7, 2016 at 2:49:03 AM UTC+1, Jerry Stuckle wrote: > On 8/6/2016 6:12 AM, Malcolm McLean wrote: > > On Friday, August 5, 2016 at 6:00:33 PM UTC+1, Jerry Stuckle wrote: > > >> Manufacturers do not dedicate a chip (even a fifty cent one) to such a > >> trivial example. And many of the operations in an automobile are more > >> complicated than the average Windows program. > >> > > You can build an AND gate electrically. > > But it's easier just to use a chip. Then we can tweak the various > > threshold values simply be changing numbers in the software rather > > then by redesigning the electronics. > > > > Which has absolutely what to do with this discussion? > The modern way is chips with everything. When I was little, my parents had a non-digital central heating control. It consisted of a clock with four little sliders around the circle. These caused electrical connections to be made or broken as the dial rotated. So you always had to have two periods of heating on, and two periods of heating off. My parents didn't want that, so the heating went off for a few minutes at midday, the slider moved to its minimum setting. Then it was off during the night. But now I have my own system, and its electronic. So it's got a little chip which drives a time display. But the logic is essentially the same - you just set time periods for heating on and periods for heating off. The data processing it is actually doing could hardly be more simple. But the boiler cost well over five hundred pounds and costs hundreds more pounds in gas, water, and servicing charges. The chip in the control panel accounts for very little of that. You can get an 8 bit MCU for between about 50 and 70 cents, and that's in small batches, probably less to a large customer. So you can essentially use them at will in any product that retails for more than a few dollars. Even if all it is really doing is to act as glorified on/off switch.
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web