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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 16:04 -0700 |
| Message-ID | <575735ea-8e50-4443-95be-a9d2f71afc39@googlegroups.com> |
| In reply to | #91340 |
On Friday, July 29, 2016 at 5:36:26 PM UTC-5, Ben Bacarisse wrote:
> supercat writes:
>
> > unsigned mul(unsigned short x, unsigned short y) { return x*y; }
Someone might write such code because they dislike excess verbosity, and
expect--like the authors of the C89 Standard--that a quality implementation
which targets silent-wraparound two's-complement hardware and doesn't
expressly document any contrary behavior would tread signed and unsigned
promotions identically except in a few particular situations, none of
which apply here.
> Why would you write a signed multiply where you seem to be doing
> unsigned arithmetic? It looks like you intended to write
>
> unsigned mul(unsigned short x, unsigned short y) { return (unsigned)x*y; }
The C89 notes, when discussing promotions of short unsigned values to
signed or unsigned:
Both schemes give the same answer in the vast majority of cases,
and both give the same effective result in even more cases in
implementations with twos-complement arithmetic and quiet wraparound
on signed overflow --- that is, in most current implementations. In
such implementations, differences between the two only appear when
these two conditions are both true:
1. An expression involving an unsigned char or unsigned short
produces an int-wide result in which the sign bit is set:
i.e., either a unary operation on such a type, or a binary
operation in which the other operand is an int or ``narrower''
type.
2. The result of the preceding expression is used in a context
in which its signedness is significant:
- sizeof(int) < sizeof(long) and it is in a context where it
must be widened to a long type, or
- it is the left operand of the right-shift operator (in an
implementation where this shift is defined as arithmetic), or
- it is either operand of /, %, <, <=, >, or >=.
Given that condition (1) would imply that UB has occurred, why would the
authors bother writing condition (2) unless they regarded such behavior
as desirable and expected that quality general-purpose implementations
for two's- complement silent-wraparound hardware would continue to work
as described?
> Maybe the compiler developers wanted to optimise code based on undefined
> signed arithmetic whilst providing a way for programmers to write
> unsigned arithmetic if there is what they want. That seems reasonable
> to me.
What fraction of "optimizations" achieved by treating overflows as UB even
when condition #2 above doesn't apply are genuinely useful, and what
fraction of the "code savings" vanish once the programmer adds the formerly-
unnecessary verbosity needed to help the modern compiler yield the same
behavior as a 1980s compiler could manage without trouble?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-07-30 11:22 +1200 |
| Message-ID | <e026pvFbb39U1@mid.individual.net> |
| In reply to | #91341 |
On 07/30/16 11:04 AM, supercat@casperkitty.com wrote:
> On Friday, July 29, 2016 at 5:36:26 PM UTC-5, Ben Bacarisse wrote:
>> supercat writes:
>>
>>> unsigned mul(unsigned short x, unsigned short y) { return x*y; }
> Someone might write such code because they dislike excess verbosity, and
> expect--like the authors of the C89 Standard--that a quality implementation
> which targets silent-wraparound two's-complement hardware and doesn't
> expressly document any contrary behavior would tread signed and unsigned
> promotions identically except in a few particular situations, none of
> which apply here.
I would hope that an experienced reviewer who understands C's (sometimes
less then obvious) promotion rules would reject such code.
>> Why would you write a signed multiply where you seem to be doing
>> unsigned arithmetic? It looks like you intended to write
>>
>> unsigned mul(unsigned short x, unsigned short y) { return (unsigned)x*y; }
I fully agree Ben: the code should reflect the intent. Using a cast to
or my preference, a temporary of, the return type should be used to do so.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-30 01:09 +0100 |
| Message-ID | <87fuqsx9z5.fsf@bsb.me.uk> |
| In reply to | #91341 |
supercat@casperkitty.com writes:
> On Friday, July 29, 2016 at 5:36:26 PM UTC-5, Ben Bacarisse wrote:
>> supercat writes:
>>
>> > unsigned mul(unsigned short x, unsigned short y) { return x*y; }
>
> Someone might write such code because they dislike excess verbosity,
It's yours, not mine. Did you intend this remark to be about my
version?
If so, then it's not "excess verbosity". The extra "(unsigned)" makes
the code work as you intended it to. I'd call that required verbosity.
(It's not minimal since you can get the same effect in fewer
characters.)
> and
> expect--like the authors of the C89 Standard--that a quality implementation
> which targets silent-wraparound two's-complement hardware and doesn't
> expressly document any contrary behavior would tread signed and unsigned
> promotions identically except in a few particular situations, none of
> which apply here.
If they are using such an implementation, they can do exactly as you
describe -- at the expense of portability. UB means the implementation
may define the code as doing what the compiler's customers want.
>> Why would you write a signed multiply where you seem to be doing
>> unsigned arithmetic? It looks like you intended to write
>>
>> unsigned mul(unsigned short x, unsigned short y) { return (unsigned)x*y; }
>
> The C89 notes, when discussing promotions of short unsigned values to
> signed or unsigned:
>
> Both schemes give the same answer in the vast majority of cases,
> and both give the same effective result in even more cases in
> implementations with twos-complement arithmetic and quiet wraparound
> on signed overflow --- that is, in most current implementations. In
> such implementations, differences between the two only appear when
> these two conditions are both true:
>
> 1. An expression involving an unsigned char or unsigned short
> produces an int-wide result in which the sign bit is set:
> i.e., either a unary operation on such a type, or a binary
> operation in which the other operand is an int or ``narrower''
> type.
>
> 2. The result of the preceding expression is used in a context
> in which its signedness is significant:
>
> - sizeof(int) < sizeof(long) and it is in a context where it
> must be widened to a long type, or
>
> - it is the left operand of the right-shift operator (in an
> implementation where this shift is defined as arithmetic), or
>
> - it is either operand of /, %, <, <=, >, or >=.
>
> Given that condition (1) would imply that UB has occurred, why would the
> authors bother writing condition (2) unless they regarded such behavior
> as desirable and expected that quality general-purpose implementations
> for two's- complement silent-wraparound hardware would continue to work
> as described?
Why are you asking me?
>> Maybe the compiler developers wanted to optimise code based on undefined
>> signed arithmetic whilst providing a way for programmers to write
>> unsigned arithmetic if there is what they want. That seems reasonable
>> to me.
>
> What fraction of "optimizations" achieved by treating overflows as UB even
> when condition #2 above doesn't apply are genuinely useful, and what
> fraction of the "code savings" vanish once the programmer adds the formerly-
> unnecessary verbosity needed to help the modern compiler yield the same
> behavior as a 1980s compiler could manage without trouble?
I don't know (did you think I might?). In this particular case I see no
cost at all (at least on most architectures).
By the way, what are the scare quotes for? They come over as sneering.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 08:08 -0700 |
| Message-ID | <41886286-9a3e-44ef-b2d2-f83073cf2c6a@googlegroups.com> |
| In reply to | #91343 |
On Friday, July 29, 2016 at 7:09:42 PM UTC-5, Ben Bacarisse wrote:
> supercat writes:
> >> > unsigned mul(unsigned short x, unsigned short y) { return x*y; }
> >
> > Someone might write such code because they dislike excess verbosity,
> If so, then it's not "excess verbosity". The extra "(unsigned)" makes
> the code work as you intended it to. I'd call that required verbosity.
> (It's not minimal since you can get the same effect in fewer
> characters.)
The authors of the C Standard say in the rationale that signed and
unsigned types behaved equivalently on platforms with two's-complement
silent-wraparound behavior, i.e. [according to them] the majority of
[then-] current implementations, in many cases where a result is between
INT_MAX+1u and UINT_MAX; they then describe the cases where signed and
unsigned behaviors would differ.
Why do you suppose they would have mentioned such a thing if they did
not expect and intend that quality implementations which had no
particularly compelling reason to do otherwise would continue to behave
likewise?
Can you identify any general-purpose compilers from the twentieth century
which which targeted two's-complement silent-wraparound machines and did
not explicitly trap integer overflow, which would not generate functionally
identical code with and without the cast? Is there any reason anyone in
the twentieth century should have expected that compilers for such machines
would not continue to behave in that fashion forevermore?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-01 21:16 +0100 |
| Message-ID | <87bn1cutx1.fsf@bsb.me.uk> |
| In reply to | #91486 |
supercat@casperkitty.com writes:
> On Friday, July 29, 2016 at 7:09:42 PM UTC-5, Ben Bacarisse wrote:
>> supercat writes:
>> >> > unsigned mul(unsigned short x, unsigned short y) { return x*y; }
>> >
>> > Someone might write such code because they dislike excess verbosity,
>
>> If so, then it's not "excess verbosity". The extra "(unsigned)" makes
>> the code work as you intended it to. I'd call that required verbosity.
>> (It's not minimal since you can get the same effect in fewer
>> characters.)
>
> The authors of the C Standard say in the rationale that
"all of these ambiguities can be avoided by a judicious use of casts"
as above.
> signed and
> unsigned types behaved equivalently on platforms with two's-complement
> silent-wraparound behavior, i.e. [according to them] the majority of
> [then-] current implementations, in many cases where a result is between
> INT_MAX+1u and UINT_MAX; they then describe the cases where signed and
> unsigned behaviors would differ.
>
> Why do you suppose they would have mentioned such a thing if they did
> not expect and intend that quality implementations which had no
> particularly compelling reason to do otherwise would continue to behave
> likewise?
My answer to this question is the same as it was the last time you asked
it. I don't think you are any more interested in the answer this time.
<more rhetorical questions snipped>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 22:13 -0700 |
| Message-ID | <7ba4e6ea-cfb5-407f-bcb0-93a61fc1dcd4@googlegroups.com> |
| In reply to | #91524 |
On Monday, August 1, 2016 at 3:16:19 PM UTC-5, Ben Bacarisse wrote: > supercat writes: > > The authors of the C Standard say in the rationale that > > "all of these ambiguities can be avoided by a judicious use of casts" The behavior of a multiplication whose result is coerced to an unsigned type is not one of the ambiguities listed. > My answer to this question is the same as it was the last time you asked > it. I don't think you are any more interested in the answer this time. Returning to the subject of the thread, which is more popular--invocation of compilers using settings that will cause overflow to negate the laws of time and causality, or invocation of compilers in ways that do not enable such treatment?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-02 13:33 +0100 |
| Message-ID | <8760rjuz94.fsf@bsb.me.uk> |
| In reply to | #91556 |
supercat@casperkitty.com writes: > On Monday, August 1, 2016 at 3:16:19 PM UTC-5, Ben Bacarisse wrote: >> supercat writes: >> > The authors of the C Standard say in the rationale that >> >> "all of these ambiguities can be avoided by a judicious use of casts" > > The behavior of a multiplication whose result is coerced to an unsigned > type is not one of the ambiguities listed. No, but controlling what the promoted type is, and that's the thing that fixes your example. >> My answer to this question is the same as it was the last time you asked >> it. I don't think you are any more interested in the answer this time. > > Returning to the subject of the thread, which is more popular--invocation > of compilers using settings that will cause overflow to negate the laws of > time and causality, or invocation of compilers in ways that do not enable > such treatment? Which is more popular -- asking loaded questions whose answers you don't care about, or having a serious exchange of view about C and it's implementations? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-28 08:11 -0700 |
| Message-ID | <ce3b7ce4-60db-42e3-bd1d-92754a7c2853@googlegroups.com> |
| In reply to | #91221 |
On Thursday, July 28, 2016 at 7:03:50 AM UTC-5, David Brown wrote:
> What he means is that in C, casting a uint16_t pointer to a uint32_t
> pointer and using that to access the data is undefined behaviour
> (assuming uint16_t is not the same type as unsigned char). For some
> reason, known only to himself, Supercat believes that older C standards
> (pre C89, I think) /did/ allow this sort of thing. He also believes
> that many older compilers and embedded compilers also allow it.
There exists a large corpus of code, including much of the original
Macintosh OS, that relies upon the existence of a universal "pointer to
pointer" type. There is also a large corpus of code that relies upon
the ability to use a pointer to a structure to access identically-placed
members of other structure types the accessing code may know nothing
about.
I'm not sure what people find puzzling about the notion that if a
compiler's documentation says that an "short" is stored as two bytes
LSB-first and a "long" is stored as four bytes LSB-first, those two
statements together would *define* the behavior of
void clear_lower_bits(long *p) { *((short*)&p) = 0; }
as clearing out the two lower bytes of "p" in the absence of anything
that would select otherwise (prior to C89, there was nothing in the
documentation of most implementations to suggest otherwise, and I've
seen no indication that the authors of the C Standard intended that
behaviors which would be supported on quality implementations for
platform X before C89 should only continue to be supported on quality
C89-compliant implementations for platform X in cases where the Standard
mandated such continuation.
The authors of the Standard recognized that an obtuse implementation
could be fully-compliant but quite useless, and made no effort to define
everything about the behaviors that a quality implementation for any
particular platform. I'm nor sure whence came the notion that they
didn't intend that quality implementations would go beyond the mandates
given by the Standard in cases where the most efficient general-case
way of doing something on a given platform would naturally offer useful
guarantees which might be expensive to support on other platforms.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-28 07:36 -0700 |
| Message-ID | <7e71b60a-c7e3-42f6-a866-b4842cd25ea2@googlegroups.com> |
| In reply to | #91186 |
On Wednesday, July 27, 2016 at 8:03:50 PM UTC-5, Rick C. Hodgin wrote:
> How is this not supported by gcc? Or any C compiler through the cast? And,
> even if the target address is not 32-bit aligned, you can still access the
> data in 32-bit or 64-bit chunks (incurring the extra read and write penalties
> associated if they are unaligned).
On some platforms, misaligned accesses will cause unrecoverable traps,
which could have arbitrary consequences if trap handlers aren't configured.
The problem is that unless one disables all aliasing based optimizations,
including those where a compiler would have no plausible reason to expect
aliasing (such as the example given in the rationale for the C89 Standard,
where a global variable of one type was accessed via pointer which a
compiler would have no reason to expect might access anything of that type)
which would represent the majority of optimizations that would be achievable
via type-based aliasing, gcc will assume that things can't alias even when
anyone who isn't obtuse would recognize optimization as likely, e.g.
uint32_t get_float_bits(float *f)
{ return *((uint32_t*)&f); }
Such a function will often work in gcc, but if gcc sees such a function
called on a float, the float is modified via float*, and the function is
called again, gcc may not bother reading the bits a second time.
Incidentally, gcc even applies such optimizations in cases where the two
types have the same representation (e.g. "int" and "long" on platforms
where they're both 32 bits, or "long" and "long long" on platforms where
those are both 64 bits).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 07:51 -0700 |
| Message-ID | <6a36435c-2987-42d6-b83c-3ba5545e207d@googlegroups.com> |
| In reply to | #91234 |
On Thursday, July 28, 2016 at 10:36:08 AM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, July 27, 2016 at 8:03:50 PM UTC-5, Rick C. Hodgin wrote:
> > How is this not supported by gcc? Or any C compiler through the cast? And,
> > even if the target address is not 32-bit aligned, you can still access the
> > data in 32-bit or 64-bit chunks (incurring the extra read and write penalties
> > associated if they are unaligned).
>
> On some platforms, misaligned accesses will cause unrecoverable traps,
> which could have arbitrary consequences if trap handlers aren't configured.
>
> The problem is that unless one disables all aliasing based optimizations,
> including those where a compiler would have no plausible reason to expect
> aliasing (such as the example given in the rationale for the C89 Standard,
> where a global variable of one type was accessed via pointer which a
> compiler would have no reason to expect might access anything of that type)
> which would represent the majority of optimizations that would be achievable
> via type-based aliasing, gcc will assume that things can't alias even when
> anyone who isn't obtuse would recognize optimization as likely, e.g.
>
> uint32_t get_float_bits(float *f)
> { return *((uint32_t*)&f); }
>
> Such a function will often work in gcc, but if gcc sees such a function
> called on a float, the float is modified via float*, and the function is
> called again, gcc may not bother reading the bits a second time.
I believe GCC also states that the preferred method for handling this
type of untranslated conversion is through a union.
I think I remember seeing it in a video by Google staff Ian Lance Taylor
regarding GCC?
[virtual pause while I search for it]
https://www.youtube.com/watch?v=AfwNbUxbKr0&t=9m35s
https://www.youtube.com/watch?v=AfwNbUxbKr0&t=11m16s
And there it is. I'm amazed I remembered that.
> Incidentally, gcc even applies such optimizations in cases where the two
> types have the same representation (e.g. "int" and "long" on platforms
> where they're both 32 bits, or "long" and "long long" on platforms where
> those are both 64 bits).
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-28 08:19 -0700 |
| Message-ID | <3b9ae09c-2f64-4a00-aea1-12b23619ebc9@googlegroups.com> |
| In reply to | #91238 |
On Thursday, July 28, 2016 at 9:51:59 AM UTC-5, Rick C. Hodgin wrote:
> I believe GCC also states that the preferred method for handling this
> type of untranslated conversion is through a union.
Write a function which, when given a pointer to an arbitrary union
of the form:
union whatever { uint32_t w[N]; uint16_t h[N*2]; };
will return the uint16_t at index N. I don't think that's possible under
gcc's interpretation of the aliasing rules (except by disabling aliasing,
of course). Can you prove me wrong?
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 10:18 -0700 |
| Message-ID | <39f7f115-c67f-4d95-9172-fbcef28fa30e@googlegroups.com> |
| In reply to | #91240 |
On Thursday, July 28, 2016 at 11:20:31 AM UTC-4, supe...@casperkitty.com wrote:
> On Thursday, July 28, 2016 at 9:51:59 AM UTC-5, Rick C. Hodgin wrote:
> > I believe GCC also states that the preferred method for handling this
> > type of untranslated conversion is through a union.
>
> Write a function which, when given a pointer to an arbitrary union
> of the form:
>
> union whatever { uint32_t w[N]; uint16_t h[N*2]; };
>
> will return the uint16_t at index N. I don't think that's possible under
> gcc's interpretation of the aliasing rules (except by disabling aliasing,
> of course). Can you prove me wrong?
I'm not sure if this is what you mean:
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#define N 4
typedef union {
uint32_t w[N];
uint16_t h[N*2];
} whatever;
whatever w = {
{ 0x11112222, 0x33334444, 0x55556666, 0x77778888 }
};
int main(int argc, char* argv[])
{
whatever* p = &w;
printf("0x%x, 0x%x\n", p->w[N-1], (uint32_t)p->h[N]);
}
Produces the output:
0x77778888, 0x6666
In this version of GCC I happen to have on this computer:
gcc (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-28 11:16 -0700 |
| Message-ID | <9e0209c8-e21c-4582-8e04-44d02381c306@googlegroups.com> |
| In reply to | #91254 |
On Thursday, July 28, 2016 at 12:19:00 PM UTC-5, Rick C. Hodgin wrote:
> I'm not sure if this is what you mean:
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <stdint.h>
>
> #define N 4
>
> typedef union {
> uint32_t w[N];
> uint16_t h[N*2];
> } whatever;
I mean a single function that could be used with a statically,
automatically, or heap-allocated object that's 4 bytes long, 8 bytes
long, 400 bytes long, or four million bytes long, assuming that the
passed-in index is within range for whatever size of object is passed
in.
One could write code using memcpy, or a pair of char-type accesses, or
various other things, but any such approaches would require that the
compiler recognize potential aliasing with every imaginable type in the
universe, including pointers. I would suggest that there's no reason a
sane compiler for a system which has suitable integer types shouldn't
allow a programmer to use something like:
uint16_t get_uint16t(uint32_t *array, int index;)
{ return ( (uint16_t*)array)[index]; }
and have the compiler recognize that the function might access things of
type "uint32_t" or "uint16_t". A moderately-simplistic compiler that
regarded a cast from uint32_t* to any other type as a potential read
or write access to any exposed object of type "uint32_t" might lose some
real optimization opportunities, but the number of opportunities lost
would be far lower than for a compiler which forced a programmer to use
character-type accesses [preventing a compiler from caching any exposed
object of any type across the access].
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 11:49 -0700 |
| Message-ID | <e446d2a8-de74-4b90-866c-5cd08388f3a1@googlegroups.com> |
| In reply to | #91259 |
On Thursday, July 28, 2016 at 2:16:30 PM UTC-4, supe...@casperkitty.com wrote:
> On Thursday, July 28, 2016 at 12:19:00 PM UTC-5, Rick C. Hodgin wrote:
> > I'm not sure if this is what you mean:
> >
> > #include <stdlib.h>
> > #include <stdio.h>
> > #include <stdint.h>
> >
> > #define N 4
> >
> > typedef union {
> > uint32_t w[N];
> > uint16_t h[N*2];
> > } whatever;
>
> I mean a single function that could be used with a statically,
> automatically, or heap-allocated object that's 4 bytes long, 8 bytes
> long, 400 bytes long, or four million bytes long, assuming that the
> passed-in index is within range for whatever size of object is passed
> in.
>
> One could write code using memcpy, or a pair of char-type accesses, or
> various other things, but any such approaches would require that the
> compiler recognize potential aliasing with every imaginable type in the
> universe, including pointers. I would suggest that there's no reason a
> sane compiler for a system which has suitable integer types shouldn't
> allow a programmer to use something like:
>
> uint16_t get_uint16t(uint32_t *array, int index;)
> { return ( (uint16_t*)array)[index]; }
>
> and have the compiler recognize that the function might access things of
> type "uint32_t" or "uint16_t". A moderately-simplistic compiler that
> regarded a cast from uint32_t* to any other type as a potential read
> or write access to any exposed object of type "uint32_t" might lose some
> real optimization opportunities, but the number of opportunities lost
> would be far lower than for a compiler which forced a programmer to use
> character-type accesses [preventing a compiler from caching any exposed
> object of any type across the access].
The code I wrote could be refactored to be a function:
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>
#define N 4
typedef union {
uint32_t w[N];
uint16_t h[N*2];
} whatever;
whatever w[] = {
{ { 0x11112222, 0x33334444, 0x55556666, 0x77778888 } },
{ { 0x22223333, 0x44445555, 0x66667777, 0x88889999 } },
{ { 0x11223344, 0x55667788, 0x99aabbcc, 0xddeeff00 } },
{ { 0x12345678, 0x23456789, 0x34567890, 0x4567890a } },
};
void myfunc(whatever* p, char* text, int index)
{
printf("%s -- 0x%x, 0x%x\n", text, p->w[index], (uint32_t)p->h[index]);
}
int main(int argc, char* argv[])
{
whatever* p;
p = &w[0]; myfunc(p, "p->h[0][N]", N);
p = &w[1]; myfunc(p, "p->h[1][2]", 2);
p = &w[2]; myfunc(p, "p->h[2][7]", 7);
return(0);
}
Produces the output:
p->h[0][N] -- 0x22223333, 0x6666
p->h[1][2] -- 0x66667777, 0x5555
p->h[2][7] -- 0x4567890a, 0xddee
-----
But in this case, it is not fully arbitrary. In order to make it fully
arbitrary you'd have to remove hard bounds known by the compiler and
place the data into only something like your example, which is of express
fundamental types accessing a block array of data. And in that case, why
do you think the compiler would either (1) care how the data is accessed,
or (2) be able to resolve anything about the block of data that's there,
thereby missing out on optimization opportunities?
If you were concerned about optimization opportunities, you could pass
the incoming arbitrary pointer through a union which includes some known
size thing which would allow the compiler to visualize the optimization
opportunity, and access the data through that member.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-28 12:37 -0700 |
| Message-ID | <2cecb0ac-df90-4885-8e3c-2e687f715893@googlegroups.com> |
| In reply to | #91264 |
On Thursday, July 28, 2016 at 1:50:01 PM UTC-5, Rick C. Hodgin wrote:
> But in this case, it is not fully arbitrary. In order to make it fully
> arbitrary you'd have to remove hard bounds known by the compiler and
> place the data into only something like your example, which is of express
> fundamental types accessing a block array of data. And in that case, why
> do you think the compiler would either (1) care how the data is accessed,
> or (2) be able to resolve anything about the block of data that's there,
> thereby missing out on optimization opportunities?
If a variable has a declared type of type uint32_t[], a compiler is
entitled to assume, in the absence of contrary evidence, that accesses
via a seemingly-unrelated pointer to a union type cannot involve that
variable. Using union types to facilitate access via different types
would require that all declared objects use that union type.
It would be possible to do something like:
typedef union { uint16_t as16[2]; uint32_t as32[1]; } pair16;
pair16 smallArray[2], bigArray[1000000];
uint16_t read16(pair16 *array, int index)
{ return array[index >> 1].as16[index & 1]; }
but requiring double indexing for everything isn't good for readability;
some compilers could generate decent code for such constructs, but
requiring such compiler sophistication to yield decent code seems
antithetical to the idea of a language which is supposed to allow even
a simplistic compiler to yield decent performance. Further, it will often
end up necessary to pass around a pointer plus an index in cases where it
would otherwise be possible to simply pass around a uint16_t*.
> If you were concerned about optimization opportunities, you could pass
> the incoming arbitrary pointer through a union which includes some known
> size thing which would allow the compiler to visualize the optimization
> opportunity, and access the data through that member.
That only works with things of static or automatic duration if all such
data is declared using the same union type; that gets rather awkward
rather quickly.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 13:15 -0700 |
| Message-ID | <a46b5b16-d048-4db5-a0d6-0a7b6f9d7950@googlegroups.com> |
| In reply to | #91271 |
On Thursday, July 28, 2016 at 3:37:34 PM UTC-4, supe...@casperkitty.com wrote:
> On Thursday, July 28, 2016 at 1:50:01 PM UTC-5, Rick C. Hodgin wrote:
> > But in this case, it is not fully arbitrary. In order to make it fully
> > arbitrary you'd have to remove hard bounds known by the compiler and
> > place the data into only something like your example, which is of express
> > fundamental types accessing a block array of data. And in that case, why
> > do you think the compiler would either (1) care how the data is accessed,
> > or (2) be able to resolve anything about the block of data that's there,
> > thereby missing out on optimization opportunities?
>
> If a variable has a declared type of type uint32_t[], a compiler is
> entitled to assume, in the absence of contrary evidence, that accesses
> via a seemingly-unrelated pointer to a union type cannot involve that
> variable. Using union types to facilitate access via different types
> would require that all declared objects use that union type.
>
> It would be possible to do something like:
>
> typedef union { uint16_t as16[2]; uint32_t as32[1]; } pair16;
>
> pair16 smallArray[2], bigArray[1000000];
>
> uint16_t read16(pair16 *array, int index)
> { return array[index >> 1].as16[index & 1]; }
>
> but requiring double indexing for everything isn't good for readability;
> some compilers could generate decent code for such constructs, but
> requiring such compiler sophistication to yield decent code seems
> antithetical to the idea of a language which is supposed to allow even
> a simplistic compiler to yield decent performance.
#1 - Is this such a use case that it's really a matter of consideration
for you regarding potential speed differences in optimization in the
resulting code? How often is code accessed that way? I can't think of
any time I've ever done it apart from discriminating unions. I would
sooner access it as a uint32_t and then & and >> it into the other
uint32_t when compared to reading two uint16_t values.
#2 I do think any average C compiler would yield "decent" performance on
double-indexed arrays. And if readability is an issue, simplify it for
development, debugging, maintenance, and general aesthetics:
// Assumes all members begin at the same offset
uint16_t read16(pair16* array, int index)
{
uint16_t* p = &array[index >> 1];
return p[index & 1];
}
#3 I disagree that complexities in compiler design and implementation
should be a factor in someone's thinking about whether or not a feature
is desirable for a language. The feature itself should provide a useful
contribution that then makes the time spent on the compiler design a true
non-issue.
As Dave Ditzel said in this video (paraphrased): "Compilers issues are
only an issues until they're written. After that, they're no longer
issues":
https://www.youtube.com/watch?v=etta_NYCVxA
> Further, it will often
> end up necessary to pass around a pointer plus an index in cases where it
> would otherwise be possible to simply pass around a uint16_t*.
Exactly. A far better solution in my opinion. And any optimization
lost in so doing is trivial. And if it's not trivial, then do some
hand-coding on those portions to get the 95% / 5% rule working in
your favor.
> > If you were concerned about optimization opportunities, you could pass
> > the incoming arbitrary pointer through a union which includes some known
> > size thing which would allow the compiler to visualize the optimization
> > opportunity, and access the data through that member.
>
> That only works with things of static or automatic duration if all such
> data is declared using the same union type; that gets rather awkward
> rather quickly.
If you're accessing small blocks of data as your examples indicated,
then creating a wider window to peer through would give the compiler
the opportunity to expose optimizations in each window of use. It will
not be as good as a perfect solution, but it will get you closer with
almost zero effort.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-28 14:05 -0700 |
| Message-ID | <e097f511-0416-4c02-b84a-ad8cdf6db445@googlegroups.com> |
| In reply to | #91276 |
On Thursday, July 28, 2016 at 3:15:29 PM UTC-5, Rick C. Hodgin wrote:
> On Thursday, July 28, 2016 at 3:37:34 PM UTC-4, supercat wrote:
> > but requiring double indexing for everything isn't good for readability;
> > some compilers could generate decent code for such constructs, but
> > requiring such compiler sophistication to yield decent code seems
> > antithetical to the idea of a language which is supposed to allow even
> > a simplistic compiler to yield decent performance.
>
> #1 - Is this such a use case that it's really a matter of consideration
> for you regarding potential speed differences in optimization in the
> resulting code? How often is code accessed that way? I can't think of
> any time I've ever done it apart from discriminating unions. I would
> sooner access it as a uint32_t and then & and >> it into the other
> uint32_t when compared to reading two uint16_t values.
Such things can arise pretty often in things like graphics-related code.
If one has a bitmap with 16 bits per pixel, C code which can process
pairs of pixels using 32-bit types can perform block operations twice
as fast as code using 16-bit types, while code which manipulates
individual pixels using 16-bit types can be more than twice as fast as
code which needs to use read-modify-write sequences with 32-bit types.
On a modern PC one would use dedicated graphics hardware for most things,
of course, but in the embedded world 16-bit-per-pixel displays are a
dime a dozen as are low-end ARM chips like the Cortex-M0.
> #2 I do think any average C compiler would yield "decent" performance on
> double-indexed arrays. And if readability is an issue, simplify it for
> development, debugging, maintenance, and general aesthetics:
>
> // Assumes all members begin at the same offset
> uint16_t read16(pair16* array, int index)
> {
> uint16_t* p = &array[index >> 1];
>
> return p[index & 1];
> }
>
I'm not clear why you think adding a new temporary pointer improves things.
> #3 I disagree that complexities in compiler design and implementation
> should be a factor in someone's thinking about whether or not a feature
> is desirable for a language. The feature itself should provide a useful
> contribution that then makes the time spent on the compiler design a true
> non-issue.
I would suggest that the ability to treat storage as different types is
a useful feature. I recognize that efficient code generation will require
that a programmer indicate when things will be accessed in unusual ways,
but compilers shouldn't be blind to obvious indications.
I would also suggest that, as a general principle, a good programming
language should not require a programmer to write code that's more
complicated than the optimal machine code to accomplish the task. Even
if a compiler can convert the double indexing into a single indexing
operation (gcc mangages that in the indicated case), I think there is
something backward about the idea that programmers should need to write
code with unwanted complexity in the hopes that compilers will filter it
out.
> > Further, it will often
> > end up necessary to pass around a pointer plus an index in cases where it
> > would otherwise be possible to simply pass around a uint16_t*.
>
> Exactly. A far better solution in my opinion. And any optimization
> lost in so doing is trivial. And if it's not trivial, then do some
> hand-coding on those portions to get the 95% / 5% rule working in
> your favor.
One would then have to make all of the code which uses the graphics buffers
use the union type, and use two-part indexing operations all the time when
accessing them. Using `uint16_t*` when accessesing data as 16 bits and
uint32_t* when accessing as 32 bits, and performing casts between the
pointer types in ways a compiler can see would seem like a much cleaner
approach.
> If you're accessing small blocks of data as your examples indicated,
> then creating a wider window to peer through would give the compiler
> the opportunity to expose optimizations in each window of use. It will
> not be as good as a perfect solution, but it will get you closer with
> almost zero effort.
Consider a graphics library that needs to work with bitmaps of various
sizes. The size of "window" should vary depending upon the size of the
bitmap, but that may not be known until runtime.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-28 15:53 -0700 |
| Message-ID | <ed7ed293-fc55-4a38-90d6-f38579104f3a@googlegroups.com> |
| In reply to | #91277 |
On Thursday, July 28, 2016 at 10:06:22 PM UTC+1, supe...@casperkitty.com wrote: > > Such things can arise pretty often in things like graphics-related code. > If one has a bitmap with 16 bits per pixel, C code which can process > pairs of pixels using 32-bit types can perform block operations twice > as fast as code using 16-bit types, while code which manipulates > individual pixels using 16-bit types can be more than twice as fast as > code which needs to use read-modify-write sequences with 32-bit types. > That is handy, yes. Generally you can guarantee that pixels will be 32-bit aligned if rgbas. However you don't want a special "pixel" type, because every single graphics routine then has to be written to use that non-standard symbol. It's a lot easier to pass things about as unsigned char *s. And any routine of any complexity will usually need to access the channels. But not dumb pasting.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 18:03 -0700 |
| Message-ID | <4377368c-8e8e-4677-aa75-930c4a64b95a@googlegroups.com> |
| In reply to | #91277 |
On Thursday, July 28, 2016 at 5:06:22 PM UTC-4, supe...@casperkitty.com wrote:
> On Thursday, July 28, 2016 at 3:15:29 PM UTC-5, Rick C. Hodgin wrote:
> > On Thursday, July 28, 2016 at 3:37:34 PM UTC-4, supercat wrote:
> > > but requiring double indexing for everything isn't good for readability;
> > > some compilers could generate decent code for such constructs, but
> > > requiring such compiler sophistication to yield decent code seems
> > > antithetical to the idea of a language which is supposed to allow even
> > > a simplistic compiler to yield decent performance.
> >
> > #1 - Is this such a use case that it's really a matter of consideration
> > for you regarding potential speed differences in optimization in the
> > resulting code? How often is code accessed that way? I can't think of
> > any time I've ever done it apart from discriminating unions. I would
> > sooner access it as a uint32_t and then & and >> it into the other
> > uint32_t when compared to reading two uint16_t values.
>
> Such things can arise pretty often in things like graphics-related code.
> If one has a bitmap with 16 bits per pixel, C code which can process
> pairs of pixels using 32-bit types can perform block operations twice
> as fast as code using 16-bit types, while code which manipulates
> individual pixels using 16-bit types can be more than twice as fast as
> code which needs to use read-modify-write sequences with 32-bit types.
> On a modern PC one would use dedicated graphics hardware for most things,
> of course, but in the embedded world 16-bit-per-pixel displays are a
> dime a dozen as are low-end ARM chips like the Cortex-M0.
I have written graphics code for my Visual FreePro and Visual FreePro, Jr.
systems. I haven't used 16-bit quantities, but only 24-bit and 32-bit. In
moving forward, I've pretty much resolved to only use 32-bit, and then down-
or up-sample to the target architecture when/where I do graphics through the
CPU and not on the GPU.
I think often times in CPU-based graphics processing you're constrained by
the memory bus anyway. You can't pull/push as much data as you need through
the CPU when you have large frame buffers which greatly exceed the cache
sizes.
> > #2 I do think any average C compiler would yield "decent" performance on
> > double-indexed arrays. And if readability is an issue, simplify it for
> > development, debugging, maintenance, and general aesthetics:
> >
> > // Assumes all members begin at the same offset
> > uint16_t read16(pair16* array, int index)
> > {
> > uint16_t* p = &array[index >> 1];
> >
> > return p[index & 1];
> > }
>
> I'm not clear why you think adding a new temporary pointer improves things.
It makes the expression much easier to understand. It requires less manual
parsing and can be known at a glance how it is operating. It's more complex
in the form you had.
It also outlines, as you indicated, the ability to pass a pointer to things
without having to use the union. I view that solution as making far more
sense than trying to demonstrate to the compiler an array, which I also
think, in this case, makes the code more complex looking.
> > #3 I disagree that complexities in compiler design and implementation
> > should be a factor in someone's thinking about whether or not a feature
> > is desirable for a language. The feature itself should provide a useful
> > contribution that then makes the time spent on the compiler design a true
> > non-issue.
>
> I would suggest that the ability to treat storage as different types is
> a useful feature.
I agree. I make extensive use of unions in my code. I even wrote a song
about unions here in the clc group a while back. Something like "The
Mighty Union Brigade."
> I recognize that efficient code generation will require
> that a programmer indicate when things will be accessed in unusual ways,
> but compilers shouldn't be blind to obvious indications.
I think it should not be a major concern, but it's enough to have close /
near optimizations in a case like this. And if it is a bottleneck in the
performance of your app, spend some extra time then rewriting it.
My views are always on the developer's needs first, and then the app's
needs second. I look to make code readable, maintainable, debuggable, so
that it can persist and has maximum value.
The speed of the code is almost always secondary for me during initial
development. Once I get things developed, however, then I can focus in
on the 5% of the code that is actually causing the slowdown, while always
having the "safe and clunky" form to fall back on should I ever break
something in my optimization attempts.
> I would also suggest that, as a general principle, a good programming
> language should not require a programmer to write code that's more
> complicated than the optimal machine code to accomplish the task. Even
> if a compiler can convert the double indexing into a single indexing
> operation (gcc mangages that in the indicated case), I think there is
> something backward about the idea that programmers should need to write
> code with unwanted complexity in the hopes that compilers will filter it
> out.
If you think that's my position, something was lost in translation. I do
not think developers should write complex code.
What I was referring to is that compiler authors should go the extra mile
to write more complex code if need be, so that the code written by the
developers who will use that compiler can be easier, and cleaner.
I believe that compiler writers shoulder a certain responsibility to those
developers who would use their tools. They owe it to those developers to
give them the best set of tools possible. And I believe that with all of
my soul. It's why I say it should not be a consideration of the compiler
author that implementing a particular thing might be more difficult. You
do what is required to make it easier for the developers who will use your
tools. That's just the cost of "doing business" as a compiler author.
> > > Further, it will often
> > > end up necessary to pass around a pointer plus an index in cases where it
> > > would otherwise be possible to simply pass around a uint16_t*.
> >
> > Exactly. A far better solution in my opinion. And any optimization
> > lost in so doing is trivial. And if it's not trivial, then do some
> > hand-coding on those portions to get the 95% / 5% rule working in
> > your favor.
>
> One would then have to make all of the code which uses the graphics buffers
> use the union type, and use two-part indexing operations all the time when
> accessing them. Using `uint16_t*` when accessesing data as 16 bits and
> uint32_t* when accessing as 32 bits, and performing casts between the
> pointer types in ways a compiler can see would seem like a much cleaner
> approach.
Why not make it all uint16_t and then optimize by casting the uint16_t-only
types to unint32_t or uint64_t on the respective machines? In that way you
are simply multi-processing.
And in the case of machines with SIMD languages, you're really just loading
and swizzling the data into the forms the SIMD engine can handle anyway,
doing essentially that.
I think passing by uint16_t would be enough if there is a graphics system
that requires 16-bit forms. And if it requires 16-bit or 32-bit forms,
then write parallel algorithms, each of which handles its own thing, but
does so within its size. 16-bit encodings will be notably different than
32-bit encodings, for example, so they demand special algorithm consideration
anyway.
> > If you're accessing small blocks of data as your examples indicated,
> > then creating a wider window to peer through would give the compiler
> > the opportunity to expose optimizations in each window of use. It will
> > not be as good as a perfect solution, but it will get you closer with
> > almost zero effort.
>
> Consider a graphics library that needs to work with bitmaps of various
> sizes. The size of "window" should vary depending upon the size of the
> bitmap, but that may not be known until runtime.
I think you could govern the optimization to a certain size, such as a
1920 x 1080, or 2560 x 1600 maximum size, and then anything outside of that
range is just slower.
You might also consider working with multiple threads in such a case, as
the number of cores we have to perform this kind of work, that can actually
be performed in parallel, is only increasing. It might make more sense to
work on developing those software algorithms, rather than spending time
optimizing access to data which, if done in parallel, likely becomes a far
less consideration anyway.
In any event, I think there is the 95% / 5% rule where 5% of your code
accounts for 95% of the slowdown. Developing straight-forward algorithms
and then optimizing those 5% is a good thing. And those can be done more
globally by using common libraries which then, if you spend time optimizing
their operation, will result in a global speedup at each place where they're
used. I have done that with my fundamental building blocks for what will
become the backbone of the language-supplied tools for CAlive. I want to
give a common set of algorithms which, through an API, provide a specific
set of abilities. But, the underlying mechanics are somewhat abstracted so
that minor changes in performance will affect everything globally as time
goes on.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 10:50 -0700 |
| Message-ID | <78063069-e823-4bb5-ade0-721d8b95897d@googlegroups.com> |
| In reply to | #91292 |
On Thursday, July 28, 2016 at 8:04:29 PM UTC-5, Rick C. Hodgin wrote: > I think often times in CPU-based graphics processing you're constrained by > the memory bus anyway. You can't pull/push as much data as you need through > the CPU when you have large frame buffers which greatly exceed the cache > sizes. The embedded graphics work I've done has been on CPUs where an 8x8 bitmap would exceed the cache size (because there was no cache beyond the data bus latches). Processing a word of data would take no longer than processing a smaller chunk, and in many cases processing two-word chunks of data would take much less than twice as long as two single-word chunks, so using larger chunks was a major win. C code might not have been quite as fast as optimized assembly code, but if C code which processed four pixels at a time was 3 times as fast as code which processed one at a time, and only 33% slower than optimized assembly code, I'd say "chunking" C code should be the most logical way to code the graphics (and in fact the commercial compiler I used had no problem with it). > It also outlines, as you indicated, the ability to pass a pointer to things > without having to use the union. I view that solution as making far more > sense than trying to demonstrate to the compiler an array, which I also > think, in this case, makes the code more complex looking. It also treads dangerously close to UB, without any clear indication of what compilers will and will not recognized as defined behavior. If the last code to write a pixel did so using a uint32_t*, rather than going through the union type, code which reads it using a uint16_t* that isn't the *direct* result of subscripting a union member will invoke UB; even if the last write was done with the uint32_t member of the union, it's not clear whether a read done through a uint16_t* that isn't directly obtained by subscripting the union member will be defined. > Why not make it all uint16_t and then optimize by casting the uint16_t-only > types to unint32_t or uint64_t on the respective machines? In that way you > are simply multi-processing. That's how I actually code it when using a sane commercial compiler, but the Standard doesn't require compilers to allow that, and in the absence of non-standard directives or flags like -fno-strict-aliasing option, gcc doesn't. The Standard doesn't define any means by which code can say "within this block, I'm going to use pointers of type uint32_t* to access data within a uint16_t[]". A sane compiler should have no trouble recognizing that if a function receives a uint16_t*, casts it to uint32_t*, and then uses it, the pointer will likely be used to access things in a uint16_t[], at least within the context of that function. > I think you could govern the optimization to a certain size, such as a > 1920 x 1080, or 2560 x 1600 maximum size, and then anything outside of that > range is just slower. I code for embedded systems with pretty small amounts of RAM; for me, 128K would be big. If code needs a number of bitmaps of different sizes, most of which are pretty small, padding them all to a common size may require far more RAM than exists. > In any event, I think there is the 95% / 5% rule where 5% of your code > accounts for 95% of the slowdown. Developing straight-forward algorithms > and then optimizing those 5% is a good thing. And those can be done more > globally by using common libraries which then, if you spend time optimizing > their operation, will result in a global speedup at each place where they're > used. I have done that with my fundamental building blocks for what will > become the backbone of the language-supplied tools for CAlive. I want to > give a common set of algorithms which, through an API, provide a specific > set of abilities. But, the underlying mechanics are somewhat abstracted so > that minor changes in performance will affect everything globally as time > goes on. Bulk graphics rendering speed can quite often be a limiting factor for performance, and improvements to hot rendering loop which should be simple can yield big payoffs.
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web