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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-07-28 10:50 +0200 |
| Message-ID | <nnch0a$6nr$1@dont-email.me> |
| In reply to | #91183 |
On 28/07/2016 01:47, jacob navia wrote: > "pointer-based type punning (prunning maybe) ???? Sacré Jacob... https://en.wikipedia.org/wiki/Type_punning > ??? how can be an overflow "constrained" ??? > Maybe "reported" i.e. compilers giving access to the overflow flag? Overflow flag? "All the world's an x86", eh? http://catb.org/jargon/html/V/vaxocentrism.html
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2016-07-28 08:11 -0500 |
| Message-ID | <dvuekqFkh0vU1@mid.individual.net> |
| In reply to | #91215 |
"Noob" wrote: > On 28/07/2016 01:47, jacob navia wrote: > >> "pointer-based type punning (prunning maybe) ???? > > Sacré Jacob... > > https://en.wikipedia.org/wiki/Type_punning > >> ??? how can be an overflow "constrained" ??? >> Maybe "reported" i.e. compilers giving access to the overflow flag? > > Overflow flag? "All the world's an x86", eh? > > http://catb.org/jargon/html/V/vaxocentrism.html His terminology might possibly have an x86 flavor, but the notion of a CPU detecting and reporting overflow goes way back. Likewise, the notion of a computer language ignoring the message goes way back. Did you have a "good" language in mind?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-28 07:46 -0700 |
| Message-ID | <cb73fb41-fa4c-445b-83f5-25c5edf4b224@googlegroups.com> |
| In reply to | #91215 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-07-28 16:50 +0200 |
| Message-ID | <20160728165021.72543369@maxa-pc> |
| In reply to | #91236 |
On Thu, 28 Jul 2016 07:46:59 -0700 (PDT) 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? Mill, upcoming architecture...
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-08-01 11:18 +0200 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <nnn452$548$1@dont-email.me> |
| In reply to | #91237 |
[ Cross-posting to comp.arch where the Mill guru lives ] On 28/07/2016 16:50, Melzzzzz wrote: > supercat at casperkitty.com wrote: > >> 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? Note: Setting architectural features in stone might very well constrain the potential performance of future architectures. > Mill, upcoming architecture... IMHO, Mill looks very interesting. As in "one in a decade". (The previous two were Itanium and Transmeta, from my PoV.) https://en.wikipedia.org/wiki/Mill_architecture https://en.wikipedia.org/wiki/TriMedia_%28mediaprocessor%29 https://millcomputing.com/docs/ http://millcomputing.com/wiki/Main_Page Regards.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 05:37 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <d35d8241-22c3-47c2-b531-c47e85d2a8ac@googlegroups.com> |
| In reply to | #91461 |
On Monday, August 1, 2016 at 4:18:36 AM UTC-5, Noob wrote:
> Note: Setting architectural features in stone might very well constrain
> the potential performance of future architectures.
Only if compilers and programmers for those architectures don't bother to
use #pragma directives or other such features to waive guarantees that
were applicable to older processors.
As it is, there are a huge number of places where the C Standard locks
things in stone in ways that most code won't need, sometimes in ways
that are significantly detrimental to performance. Two examples to
start with:
1. The rule that requires compilers to treat character types as being
able to alias anything. A lot of code that works with actual byte
data won't use the vast majority of character-type accesses to
alias anything else, but compilers must presume that they might.
2. Compilers for 32-bit platforms must regard most kinds of overflow
involving values as having fully-defined behavior, rather than
fully-constrained behavior (e.g. given:
uint16_t *p; uint32_t x,y;
...
*p *= *p;
x += p;
A compiler would typically be required to sign-extend the bottom
16 bits of p before adding x, rather than being able to arbitrarily
choose between doing that or adding the 32-bit result of the
multiplication.
Adding directives to waive behavioral guarantees which would otherwise be
offered on compilers for certain kinds of platforms would allow more
useful behavioral optimizations than would revoking guarantees that
compilers for such platforms have traditionally offered but still having
to uphold guarantees that are mandated by the Standard but are not useful
for the task at hand.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-01 14:02 +0100 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <87shuove03.fsf@bsb.me.uk> |
| In reply to | #91470 |
supercat@casperkitty.com writes: > On Monday, August 1, 2016 at 4:18:36 AM UTC-5, Noob wrote: >> Note: Setting architectural features in stone might very well constrain >> the potential performance of future architectures. > > Only if compilers and programmers for those architectures don't bother to > use #pragma directives or other such features to waive guarantees that > were applicable to older processors. > > As it is, there are a huge number of places where the C Standard locks > things in stone in ways that most code won't need, sometimes in ways > that are significantly detrimental to performance. Two examples to > start with: > > 1. The rule that requires compilers to treat character types as being > able to alias anything. A lot of code that works with actual byte > data won't use the vast majority of character-type accesses to > alias anything else, but compilers must presume that they might. restrict? > 2. Compilers for 32-bit platforms must regard most kinds of overflow > involving values as having fully-defined behavior, rather than > fully-constrained behavior (e.g. given: > > uint16_t *p; uint32_t x,y; > ... > *p *= *p; > x += p; > > A compiler would typically be required to sign-extend the bottom > 16 bits of p before adding x, rather than being able to arbitrarily > choose between doing that or adding the 32-bit result of the > multiplication. Did you miss out a *? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 07:05 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <6fd02ce8-9a54-441d-999d-db4908c3c22a@googlegroups.com> |
| In reply to | #91472 |
On Monday, August 1, 2016 at 8:02:30 AM UTC-5, Ben Bacarisse wrote: > supercat writes: > > 1. The rule that requires compilers to treat character types as being > > able to alias anything. A lot of code that works with actual byte > > data won't use the vast majority of character-type accesses to > > alias anything else, but compilers must presume that they might. > > restrict? The "restrict" qualifier eliminates 99% of the need for type-based aliasing, which makes it rather ironic that some compilers pursue it with increasing vigor. The few cases where type-based aliasing analysis might remain useful could be better handled by adding more ways of identifying things that won't alias. > > 2. Compilers for 32-bit platforms must regard most kinds of overflow > > involving values as having fully-defined behavior, rather than > > fully-constrained behavior (e.g. given: > > > > uint16_t *p; uint32_t x,y; > > ... > > *p *= *p; > > x += p; > > > > A compiler would typically be required to sign-extend the bottom > > 16 bits of p before adding x, rather than being able to arbitrarily > > choose between doing that or adding the 32-bit result of the > > multiplication. > > Did you miss out a *? Yeah. I'd been dithering between using a variable, structure member, or pointer target and failed to adjust all the code to match my final choice of pointer target. I think the point is clear, though: a compiler for a platform without 16-bit arithmetic instructions would need to add an extra instruction (or on some processors two instructions) to sign-extend the bottom half of the computed value, or else reload the computed value from *p, before adding it to x, even though in most code such sign-extension would serve no useful purpose.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-01 16:04 +0100 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <87mvkwv8d8.fsf@bsb.me.uk> |
| In reply to | #91475 |
supercat@casperkitty.com writes: > On Monday, August 1, 2016 at 8:02:30 AM UTC-5, Ben Bacarisse wrote: >> supercat writes: >> > 1. The rule that requires compilers to treat character types as being >> > able to alias anything. A lot of code that works with actual byte >> > data won't use the vast majority of character-type accesses to >> > alias anything else, but compilers must presume that they might. >> >> restrict? > > The "restrict" qualifier eliminates 99% of the need for type-based > aliasing, which makes it rather ironic that some compilers pursue it > with increasing vigor. The few cases where type-based aliasing analysis > might remain useful could be better handled by adding more ways of > identifying things that won't alias. There never seems to be any progress in these discussions. I know you don't like the type-based aliasing rules, but your point 1 above is about the the problem that char types *must* be assumed to alias anything. I don't think that is true because you can prevent a compiler assuming what you say it must assume by using restrict. It seems to me to be a non-problem. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ivan Godard <ivan@millcomputing.com> |
|---|---|
| Date | 2016-08-01 09:26 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <nnnt87$pg9$1@dont-email.me> |
| In reply to | #91461 |
On 8/1/2016 2:18 AM, Noob wrote: > [ Cross-posting to comp.arch where the Mill guru lives ] Thank you. It is impossible to folly all the possibly-relevant lists :-( Mill per this list: > On 28/07/2016 16:50, Melzzzzz wrote: > >> supercat at casperkitty.com wrote: >> >>> 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. Yes. >>> 2. Each size of integer larger than the character type is stored as >>> two halves in either big-endian or little-endian order. Yes >>> 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). Unclear what this bullet means for any machine. Mill pointer relationals have no side effects if the addresses are within bounds; a total-ordering idiom that ignores bounds is also available. Languages use whichever semantics fits their definition. Equality is consistent with relationals. >>> 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. Silent two's-complement is available. Also available are corresponding forms that saturate the result; fault on numeric overflow; and produce a double-width result. >>> Can you suggest any remotely-common general-purpose reprogrammable >>> microcomputers where any of the above do not apply? The Mill is certainly not common :-) Yet. > Note: Setting architectural features in stone might very well constrain > the potential performance of future architectures. > >> Mill, upcoming architecture... > > IMHO, Mill looks very interesting. As in "one in a decade". > (The previous two were Itanium and Transmeta, from my PoV.) > > https://en.wikipedia.org/wiki/Mill_architecture > https://en.wikipedia.org/wiki/TriMedia_%28mediaprocessor%29 > https://millcomputing.com/docs/ > http://millcomputing.com/wiki/Main_Page > > Regards. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 10:12 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <7d408a14-4549-4816-9289-e99c79e16427@googlegroups.com> |
| In reply to | #91497 |
On Monday, August 1, 2016 at 11:26:56 AM UTC-5, Ivan Godard wrote: > >>> 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). > > Unclear what this bullet means for any machine. Mill pointer relationals > have no side effects if the addresses are within bounds; a > total-ordering idiom that ignores bounds is also available. Languages > use whichever semantics fits their definition. Equality is consistent > with relationals. On compact-model or large-model 8086 compilers, it was common for pointer relational comparisons to examine only the offset part of an address while ignoring the segment. If one had two pointers, p and q, located at addresses 0x0100:0x1234 and 0x0200:0x1234, then the comparions p<=q, p>=q, and p!=q would all be true; the other comparison operators would all report false. Such behavior is the weirdest relational-comparison behavior among remotely-mainstream compilers, and even that behavior won't preclude use of relational operators for things like overlap testing in cases where false positives will have no effect beyond slightly hurting performance. > >>> 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. > > Silent two's-complement is available. Also available are corresponding > forms that saturate the result; fault on numeric overflow; and produce a > double-width result. Saturating arithmetic is not a common default numeric behavior. Using temporary storage larger than "int" is common, as is having the upper bits of such storage spill in non-deterministic fashion, but that should not affect the behavior of code which would force all upper bits to be truncated or ignored. A behavioral model in which integer overflows behave as though they yield numbers which are outside the range of the integer type, but which will be congruent to the correct result mod 2**num_bits, should be readily supportable on all remotely-current hardware, and will allow many kinds of behavioral requirements to be met more cheaply than would be possible under a behavioral model that requires that programmers add whatever code is necessary to prevent overflows at all costs; the Standard only defines the latter, however.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-01 10:21 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <lny44g4d8i.fsf@kst-u.example.com> |
| In reply to | #91502 |
supercat@casperkitty.com writes:
> On Monday, August 1, 2016 at 11:26:56 AM UTC-5, Ivan Godard wrote:
>> >>> 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).
>>
>> Unclear what this bullet means for any machine. Mill pointer relationals
>> have no side effects if the addresses are within bounds; a
>> total-ordering idiom that ignores bounds is also available. Languages
>> use whichever semantics fits their definition. Equality is consistent
>> with relationals.
>
> On compact-model or large-model 8086 compilers, it was common for pointer
> relational comparisons to examine only the offset part of an address
> while ignoring the segment. If one had two pointers, p and q, located at
> addresses 0x0100:0x1234 and 0x0200:0x1234, then the comparions p<=q,
> p>=q, and p!=q would all be true; the other comparison operators would all
> report false.
I'm not sure how the various 8086 memory models work(ed) in practice,
but as far as the C standard is concerned, if p and q point to
different objects then `p != q` must yield 1 (true). The relational
operators (<, <=, >, >=) can examine only the offset parts of their
operands, since if the prefixes differ the behavior is not defined.
But the equality and inequality operators must correctly tell you
whether two pointers point to the same object -- which means in
this case that they must examine the entire pointer values (and
perhaps perform some normalization if needed).
I'd be surprised if real-world 8086 compilers didn't handle this
correctly.
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 11:01 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <0755a071-225c-4c54-9f3b-58f76e8387f0@googlegroups.com> |
| In reply to | #91503 |
On Monday, August 1, 2016 at 12:21:09 PM UTC-5, Keith Thompson wrote: > supercat writes: >> On Monday, August 1, 2016 at 11:26:56 AM UTC-5, Ivan Godard wrote: >>> Unclear what this bullet means for any machine... Equality is >>> consistent with relationals. >> >> On compact-model or large-model 8086 compilers, it was common for pointer >> relational comparisons to examine only the offset part of an address >> while ignoring the segment. If one had two pointers, p and q, located at >> addresses 0x0100:0x1234 and 0x0200:0x1234, then the comparions p<=q, >> p>=q, and p!=q would all be true; the other comparison operators would all >> report false. > > I'm not sure how the various 8086 memory models work(ed) in practice, > but as far as the C standard is concerned, if p and q point to > different objects then `p != q` must yield 1 (true). The relational > operators (<, <=, >, >=) can examine only the offset parts of their > operands, since if the prefixes differ the behavior is not defined. > But the equality and inequality operators must correctly tell you > whether two pointers point to the same object -- which means in > this case that they must examine the entire pointer values (and > perhaps perform some normalization if needed). > > I'd be surprised if real-world 8086 compilers didn't handle this > correctly. I didn't claim 8086 compilers didn't handle that in accordance with the Standard. I had indicated that commonplace general-purpose microcomputer compilers implemented the relational operators so as to report a consistent ordering among *all* pointers (including those for which the standard would impose no requirements), but such ordering was not necessarily consistent with the equality operators. I was offering up the 8086 as an example of an architecture that behaved in a fashion where the relational ordering could be inconsistent with the equality operators.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-01 11:44 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <lntwf449da.fsf@kst-u.example.com> |
| In reply to | #91505 |
supercat@casperkitty.com writes:
> On Monday, August 1, 2016 at 12:21:09 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>>> On Monday, August 1, 2016 at 11:26:56 AM UTC-5, Ivan Godard wrote:
>>>> Unclear what this bullet means for any machine... Equality is
>>>> consistent with relationals.
>>>
>>> On compact-model or large-model 8086 compilers, it was common for pointer
>>> relational comparisons to examine only the offset part of an address
>>> while ignoring the segment. If one had two pointers, p and q, located at
>>> addresses 0x0100:0x1234 and 0x0200:0x1234, then the comparions p<=q,
>>> p>=q, and p!=q would all be true; the other comparison operators would all
>>> report false.
>>
>> I'm not sure how the various 8086 memory models work(ed) in practice,
>> but as far as the C standard is concerned, if p and q point to
>> different objects then `p != q` must yield 1 (true). The relational
>> operators (<, <=, >, >=) can examine only the offset parts of their
>> operands, since if the prefixes differ the behavior is not defined.
>> But the equality and inequality operators must correctly tell you
>> whether two pointers point to the same object -- which means in
>> this case that they must examine the entire pointer values (and
>> perhaps perform some normalization if needed).
>>
>> I'd be surprised if real-world 8086 compilers didn't handle this
>> correctly.
>
> I didn't claim 8086 compilers didn't handle that in accordance with
> the Standard. I had indicated that commonplace general-purpose
> microcomputer compilers implemented the relational operators so as to
> report a consistent ordering among *all* pointers (including those
> for which the standard would impose no requirements), but such ordering
> was not necessarily consistent with the equality operators. I was
> offering up the 8086 as an example of an architecture that behaved in
> a fashion where the relational ordering could be inconsistent with the
> equality operators.
My apologies, I misread what you wrote. Your description is
consistent with the requirements of the C standard, and with what
I would have expected. (I don't think I'd call that a "consistent
ordering". I might call it a consistent partial ordering.)
--
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 | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-08-02 12:05 +0200 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <nnpra6$cbt$1@dont-email.me> |
| In reply to | #91502 |
On 01/08/2016 19:12, supercat at casperkitty.com wrote: > On Monday, August 1, 2016 at 11:26:56 AM UTC-5, Ivan Godard wrote: > >> Unclear what this bullet means for any machine. Mill pointer relationals >> have no side effects if the addresses are within bounds; a >> total-ordering idiom that ignores bounds is also available. Languages >> use whichever semantics fits their definition. Equality is consistent >> with relationals. > > On compact-model or large-model 8086 compilers, [...] I had cross-posted your message to comp.arch . Ivan Godard (lead designer of the Mill architecture) was nice enough to address some of your comments. You then answered his message, *after having dropped* comp.arch (for the second time). IG doesn't follow comp.lang.c I'm dropping out of this sub-thread until you learn proper netiquette. (Such as explaining why you would drop relevant groups from an on-going discussion.) EOT
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-01 15:48 +0000 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <2016Aug1.174809@mips.complang.tuwien.ac.at> |
| In reply to | #91461 |
Noob <root@127.0.0.1> writes: >[ Cross-posting to comp.arch where the Mill guru lives ] > >On 28/07/2016 16:50, Melzzzzz wrote: > >> supercat at casperkitty.com wrote: >> >>> 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? > >Note: Setting architectural features in stone might very well constrain >the potential performance of future architectures. Sure, when quantum computers become mainstream (i.e., probably never), the assumptions most current software makes will probably not be satisfied (except maybe in a compatibility layer), but despite not wanting to settle on the architectural features mentioned above, C will probably be inappropriate for such revolutionary architectures. In the meantime, writing software to avoid making use of these properties costs performance. >IMHO, Mill looks very interesting. As in "one in a decade". >(The previous two were Itanium and Transmeta, from my PoV.) Both not very successful, and I expect a similar fate for the Mill, although it would be nice to see success for an unconventional architecture for a change. Anyway, from what I know about the Mill, it can be used efficiently in a way that satisfies all the properties mentioned above (although people who like to miscompile code will be happy to learn that the Mill can have unconventional handling of integer overflows; but we also have that on MIPS and Alpha, but even undefined-behaviour-fanatics don't compile signed-integer + to (trapping) add on MIPS by default). - 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 | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-08-02 20:09 -0400 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <nnrcnr$267$1@gioia.aioe.org> |
| In reply to | #91461 |
On 2016-08-01 5:18 AM, Noob wrote: > [ Cross-posting to comp.arch where the Mill guru lives ] > > On 28/07/2016 16:50, Melzzzzz wrote: > >> supercat at casperkitty.com wrote: >> >>> 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? Perhaps not generally available. The eTPU used in engine controllers is 24 bit data word and sells in the general area of 20M copies a year. (It is BTW supported with a C compiler) I have worked on processors that had 9 bit, 12 bit, 13 bit, 18 bit and and several 36 bit words. I have never worked with a procwessor that did not use 2's compliment arithmetic. The 12bit and 13bit processpors had no general provision for byte sized character data. The multiple of 9 bit processors all had the ability to support 9 bit data. For what it is worth I am currently working on a project with a non power of two multiple of 8 bits that also does not support character data in any familliar size. C often is used as a reason to support charters and power of two data sizes but there is no language limit that restricts its use for other data formats. w..
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-03 06:42 +0000 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <2016Aug3.084214@mips.complang.tuwien.ac.at> |
| In reply to | #91588 |
Walter Banks <walter@bytecraft.com> writes: >On 2016-08-01 5:18 AM, Noob wrote: >> [ Cross-posting to comp.arch where the Mill guru lives ] >> >> On 28/07/2016 16:50, Melzzzzz wrote: >> >>> supercat at casperkitty.com wrote: >>>> 1. Integer sizes are power-of-two multiples of an 8-bit character >>>> type. ... >Perhaps not generally available. The eTPU used in engine controllers is >24 bit data word and sells in the general area of 20M copies a year. (It >is BTW supported with a C compiler) > >I have worked on processors that had 9 bit, 12 bit, 13 bit, 18 bit and >and several 36 bit words. ... >The 12bit and 13bit processpors had no general provision for byte sized >character data. The multiple of 9 bit processors all had the ability to >support 9 bit data. > >For what it is worth I am currently working on a project with a non >power of two multiple of 8 bits that also does not support character >data in any familliar size. Word-addressed machines still exist (with various bit widths), so the 8-bit character is not universal for C. However, I am not aware of anything from after 1980 that is byte-addressed and has a non-8-bit byte; and AFAIK even the old 36-bit machines were not byte-addressed (although C implementations on such architectures may have simulated byte addressing in order to avoid 36-bit chars). Anyway, architectures seem to fall into two classes: byte addressed with 2^n bytes per word and 8-bit bytes word addressed, with arbitrary bits per word. If anybody knows exceptions, please name them. - 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-03 11:02 +0100 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <8737mmuq4s.fsf@bsb.me.uk> |
| In reply to | #91589 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: <snip> > Word-addressed machines still exist (with various bit widths), so the > 8-bit character is not universal for C. However, I am not aware of > anything from after 1980 that is byte-addressed and has a non-8-bit > byte; and AFAIK even the old 36-bit machines were not byte-addressed > (although C implementations on such architectures may have simulated > byte addressing in order to avoid 36-bit chars). > > Anyway, architectures seem to fall into two classes: > > byte addressed with 2^n bytes per word and 8-bit bytes > word addressed, with arbitrary bits per word. > > If anybody knows exceptions, please name them. 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. 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). 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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ivan Godard <ivan@millcomputing.com> |
|---|---|
| Date | 2016-08-03 03:15 -0700 |
| Subject | Re: Setting architectural features in stone |
| Message-ID | <nnsg95$sn0$1@dont-email.me> |
| In reply to | #91591 |
On 8/3/2016 3:02 AM, Ben Bacarisse wrote: <snip> > 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. > Or that pressure for backward compatibility to the PDP-11 makes it impossible to introduce real improvements in new architectures. The two that have bedeviled us the most are the presumption that pointers are integers and the presumption that program address spaces may alias (a.k.a fork()).
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web