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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-07 19:18 -0700 |
| Message-ID | <1a37f60b-867e-467a-b568-97cfc46ac5b2@googlegroups.com> |
| In reply to | #91848 |
On Sunday, August 7, 2016 at 12:53:29 PM UTC+1, David Brown wrote: > > No one - not even a company making millions of units - is going to think > it is worth the cost in making all their audio codec software in-house > from scratch. There are far too few people in the world who understand > the stuff well enough to write such code, and writing it simply takes > too long - no one can afford the time-to-market costs. > I wrote an MP2 codec about 20 years ago, when I was still a young and inexperienced programmer. It took about two weeks, and I wasn't a huge expert on Fourier transforms. All the algorithms are published and you simply implement them. It's a job, not research. MP3 is harder because of the "injected noise". That basically makes it impossible to just blindly copy down instructions, and it means that every encoder is different. The decoder is what most people want and is easier to write. I found a nice one on the net and so I haven't written on myself. It's about 2,600 lines, of which 700 are data tables copied from the spec. So 2000 lines of admittedly rather tricky C code. About 300 lines are routine bit stream, fast arithmetic, and header checking functions, then there's 150 line of "compute antialias" type functions, I'd guess that's postfiltering, 150 lines Huffman decoder, 500 lines low level frequency transforms, 80 lines or so to drive the frequency transforms, 350 lines that actually implement the MP3 spec, and then 400 lines of high-level object management and driver code. So about 150 + 500 + 80 + 350 lines of challenging code, I make that about 1000 lines. So I'd estimate two weeks solid hard work to write that lot from scratch, if you can get someone else to specify the transform algorithms. (Developing your own optimised DCT from first principles is very hard, but fortunately people publish methods). It's certainly a big job. But it's not undoable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-08 12:31 +0200 |
| Message-ID | <no9n1a$68u$1@dont-email.me> |
| In reply to | #91910 |
On 08/08/16 04:18, Malcolm McLean wrote: > On Sunday, August 7, 2016 at 12:53:29 PM UTC+1, David Brown wrote: >> >> No one - not even a company making millions of units - is going to think >> it is worth the cost in making all their audio codec software in-house >> from scratch. There are far too few people in the world who understand >> the stuff well enough to write such code, and writing it simply takes >> too long - no one can afford the time-to-market costs. >> > I wrote an MP2 codec about 20 years ago, when I was still a young > and inexperienced programmer. It took about two weeks, and I wasn't > a huge expert on Fourier transforms. All the algorithms are published > and you simply implement them. It's a job, not research. > MP3 is harder because of the "injected noise". That basically makes > it impossible to just blindly copy down instructions, and it means > that every encoder is different. The decoder is what most people > want and is easier to write. I found a nice one on the net and so > I haven't written on myself. It's about 2,600 lines, of which 700 > are data tables copied from the spec. > So 2000 lines of admittedly rather tricky C code. About 300 lines > are routine bit stream, fast arithmetic, and header checking functions, > then there's 150 line of "compute antialias" type functions, I'd > guess that's postfiltering, 150 lines Huffman decoder, 500 lines > low level frequency transforms, 80 lines or so to drive the > frequency transforms, 350 lines that actually implement the MP3 > spec, and then 400 lines of high-level object management and driver > code. > So about 150 + 500 + 80 + 350 lines of challenging code, I make > that about 1000 lines. > So I'd estimate two weeks solid hard work to write that lot from > scratch, if you can get someone else to specify the transform > algorithms. (Developing your own optimised DCT from first principles > is very hard, but fortunately people publish methods). > It's certainly a big job. But it's not undoable. > There is no doubt that it is all doable. But these days there are /many/ codecs, many of them making MP3 look simple. Then there are encryption algorithms and other "digital rights management" stuff. Some of these involve specifications that can easily obtained - others require patents, licenses, trade secrets, NDAs, and so on. And even when you have got it all, there is the challenge of getting the quality right (how long do your transforms need to be? Have you got the rounding right?), and of getting it all working optimally within your DSP core. For a lot of DSP programming, small details can quickly make an order of magnitude difference in the execution speed even though your code is giving the correct output. All this means a great deal more than a couple of weeks hard work for modern digital audio. And even if your budget allows for hoards of these expert programmers working in parallel, and the team of lawyers and accountants to deal with the non-technical issues, then by the time it is all in place your competitors have been selling a raspberry pi in a plastic box for months. Instead, you buy pre-written, pre-tested, pre-certified and pre-licensed code for the DSP. You might do the final details and compilation linking these libraries, or you might just buy the ready-made binary image.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-08 03:55 -0700 |
| Message-ID | <2361d1e7-c17c-47bf-b909-adaf673b8359@googlegroups.com> |
| In reply to | #91940 |
On Monday, August 8, 2016 at 11:31:14 AM UTC+1, David Brown wrote: > On 08/08/16 04:18, Malcolm McLean wrote: > > On Sunday, August 7, 2016 at 12:53:29 PM UTC+1, David Brown wrote: > >> > >> No one - not even a company making millions of units - is going to think > >> it is worth the cost in making all their audio codec software in-house > >> from scratch. There are far too few people in the world who understand > >> the stuff well enough to write such code, and writing it simply takes > >> too long - no one can afford the time-to-market costs. > >> > > I wrote an MP2 codec about 20 years ago, when I was still a young > > and inexperienced programmer. It took about two weeks, and I wasn't > > a huge expert on Fourier transforms. All the algorithms are published > > and you simply implement them. It's a job, not research. > > MP3 is harder because of the "injected noise". That basically makes > > it impossible to just blindly copy down instructions, and it means > > that every encoder is different. The decoder is what most people > > want and is easier to write. I found a nice one on the net and so > > I haven't written on myself. It's about 2,600 lines, of which 700 > > are data tables copied from the spec. > > So 2000 lines of admittedly rather tricky C code. About 300 lines > > are routine bit stream, fast arithmetic, and header checking functions, > > then there's 150 line of "compute antialias" type functions, I'd > > guess that's postfiltering, 150 lines Huffman decoder, 500 lines > > low level frequency transforms, 80 lines or so to drive the > > frequency transforms, 350 lines that actually implement the MP3 > > spec, and then 400 lines of high-level object management and driver > > code. > > So about 150 + 500 + 80 + 350 lines of challenging code, I make > > that about 1000 lines. > > So I'd estimate two weeks solid hard work to write that lot from > > scratch, if you can get someone else to specify the transform > > algorithms. (Developing your own optimised DCT from first principles > > is very hard, but fortunately people publish methods). > > It's certainly a big job. But it's not undoable. > > > > There is no doubt that it is all doable. But these days there are > /many/ codecs, many of them making MP3 look simple. Then there are > encryption algorithms and other "digital rights management" stuff. Some > of these involve specifications that can easily obtained - others > require patents, licenses, trade secrets, NDAs, and so on. And even > when you have got it all, there is the challenge of getting the quality > right (how long do your transforms need to be? Have you got the > rounding right?), and of getting it all working optimally within your > DSP core. For a lot of DSP programming, small details can quickly make > an order of magnitude difference in the execution speed even though your > code is giving the correct output. > > All this means a great deal more than a couple of weeks hard work for > modern digital audio. And even if your budget allows for hoards of > these expert programmers working in parallel, and the team of lawyers > and accountants to deal with the non-technical issues, then by the time > it is all in place your competitors have been selling a raspberry pi in > a plastic box for months. > > Instead, you buy pre-written, pre-tested, pre-certified and pre-licensed > code for the DSP. You might do the final details and compilation > linking these libraries, or you might just buy the ready-made binary image. > It does depend what you want. I've run the code I have on a Windows box, and it plays stereo MP3 with, to my ears, no audio artifacts, and without skipping. But considering it's got a modern Intel 64 bit processor in it, that's not saying much. The code works and it's fine for what I'm using it for. Now if the job is to make it run on a DSP which is operating at close to its capacity, then it's hard to say how long it would take to retarget that code. But again I wouldn't pencil in a huge block of time. So it depends how much the licensing costs, how much you need to pay someone who knows what he is doing, and whether you want skills in house or to rely on second party suppliers.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-08 08:28 -0700 |
| Message-ID | <e0b57521-24a2-4aec-8e9a-6787ca6561ac@googlegroups.com> |
| In reply to | #91940 |
On Monday, August 8, 2016 at 5:31:14 AM UTC-5, David Brown wrote:
> There is no doubt that it is all doable. But these days there are
> /many/ codecs, many of them making MP3 look simple. Then there are
> encryption algorithms and other "digital rights management" stuff. Some
> of these involve specifications that can easily obtained - others
> require patents, licenses, trade secrets, NDAs, and so on. And even
> when you have got it all, there is the challenge of getting the quality
> right (how long do your transforms need to be? Have you got the
> rounding right?), and of getting it all working optimally within your
> DSP core. For a lot of DSP programming, small details can quickly make
> an order of magnitude difference in the execution speed even though your
> code is giving the correct output.
Another fun little wrinkle is that many CODECs are subject to three
constraints:
1. They are performance-critical.
2. They will receive data from untrustworthy sources, and while it is
acceptable for garbage data in to yield garbage data out, it is
imperative that maliciously-constructed data not have other side-
effects like arbitrary remote code execution.
3. Determining whether data is valid may be as expensive if not more
expensive than decoding it when it is valid.
A consequence of #3 is that any bounds-checks which are performed must
be distributed throughout the code; a consequence of #2 is that some
bounds checks absolutely positively must be present in the generated
machine code. A consequence of #1 is that some bounds checks which
aren't necessary to meet #2 should be omitted from the machine code.
If a compiler includes within the machine code any bounds checks which
are present in the source, and omits those which are not present in the
source, then a programmer can include precisely those bounds checks which
are needed to meet all three requirements. It is imperative, however,
that a compiler not decide when given code like:
// When given valid input, x will be less than foo[y] 99% of the
// time, and even when given invalid input, the type of "y" will be
// such that foo+y will be in an address range which is not used to
// hold confidential information, and where reads have no side-effects.
if (x > foo[y] && y < ARRAY_SIZE)
foo[y] = x;
that it should omit the bounds check because the only way y could be outside
the array would be if the preceding line had already invoked Undefined
Behavior (albeit behavior which, if ignored by the compiler, would be
benign on the target system).
Optimal machine code should keep the comparison of y with ARRAY_SIZE
outside the common case, but there's no way to indicate that in Standard
C. On the other hand, having a compiler interpret the above code in such
a fashion would be pretty straightforward.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-08 09:44 -0700 |
| Message-ID | <c1b4022b-bd83-4e25-abeb-f04bd59e0e94@googlegroups.com> |
| In reply to | #91961 |
On Monday, August 8, 2016 at 4:28:31 PM UTC+1, supe...@casperkitty.com wrote: > > Another fun little wrinkle is that many CODECs are subject to three > constraints: > > 1. They are performance-critical. > > 2. They will receive data from untrustworthy sources, and while it is > acceptable for garbage data in to yield garbage data out, it is > imperative that maliciously-constructed data not have other side- > effects like arbitrary remote code execution. > > 3. Determining whether data is valid may be as expensive if not more > expensive than decoding it when it is valid. > > A consequence of #3 is that any bounds-checks which are performed must > be distributed throughout the code; a consequence of #2 is that some > bounds checks absolutely positively must be present in the generated > machine code. A consequence of #1 is that some bounds checks which > aren't necessary to meet #2 should be omitted from the machine code. > Most of the data is Huffman coded. Since the Huffman codes are then mapped to integers, the integers are inherently within range, and whilst garbage data will be garbage, there are relatively few points where the code can overflow buffers. A frequency transform, which is the heart of the codec, just transforms scaled shorts and back into fixed buffer. It can't generate a memory access error. You do have to be careful if there's a risk of malicious input, of course.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-08 10:13 -0700 |
| Message-ID | <e89a4071-ad50-4b29-9731-b78caa313983@googlegroups.com> |
| In reply to | #91973 |
On Monday, August 8, 2016 at 11:44:11 AM UTC-5, Malcolm McLean wrote: > On Monday, August 8, 2016 at 4:28:31 PM UTC+1, supercat wrote: > > A consequence of #3 is that any bounds-checks which are performed must > > be distributed throughout the code; a consequence of #2 is that some > > bounds checks absolutely positively must be present in the generated > > machine code. A consequence of #1 is that some bounds checks which > > aren't necessary to meet #2 should be omitted from the machine code. > > > Most of the data is Huffman coded. > Since the Huffman codes are then mapped to integers, the integers are inherently > within range, and whilst garbage data will be garbage, there are relatively few > points where the code can overflow buffers. Many audiovisual formats don't allow things to go massively out of range (since the bit-coding space that would be necessary for that could be used more productively for other purposes), but since they often store differences between values, or between individual values and a base, rather than storing absolute numbers, the sum of a maximum positive difference plus a maximum base could yield a result which exceeds the maximum legitimate value. The net effect is often to cause large numbers of potential out-of-bounds reads or integer overflows which would be expensive to try to trap but would generally be harmless. The problem is that there's no way of knowing whether a future compiler might use such behaviors as justification for bypassing safety checks which the Standard would regard as unnecessary (but which are in fact critical). If a compiler would be extremely unlikely to make an optimization whether or not it was allowed to, the value of allowing the optimization will be minimal, and the opportunity cost of forbidding it would thus also be minimal. The level of danger such an optimization would pose, however, would be magnified by its rarity. I find it ironic that compilers go to great lengths to find comparatively rare optimizations, when they require large effort, have small payoff, and severe risk.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-05 07:51 -0700 |
| Message-ID | <9cdacdff-2433-4440-9214-e4cfed0095d3@googlegroups.com> |
| In reply to | #91696 |
On Thursday, August 4, 2016 at 7:38:16 PM UTC-5, Jerry Stuckle wrote: > On 8/4/2016 7:07 PM, supercat wrote: > > When have I ever claimed that it wasn't? > > > > Yet you want to limit the hardware it runs on. I no more want to forbid C implementations on obscure hardware than the authors of Annex F wanted to forbid C implementations from using non-IEEE floating-point. If an implementation supports Annex F, the code "double x=0.0, y=1.0/x;" would not invoke Undefined Behavior, but would instead be required to set y to positive infinity. It is considered perfectly acceptable for programmers targeting Annex-F platforms to let overflows, divisions by zero, etc. happen if they programmers are prepared to accept the results of such operations. Likewise, I would like to see an annex which covered many behaviors of commonplace compilers, such that many things which are not defined by the Standard would be defined on all implementations that legitimately claim support for the annex.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-05 13:39 -0400 |
| Message-ID | <no2j0r$ni3$2@jstuckle.eternal-september.org> |
| In reply to | #91728 |
On 8/5/2016 10:51 AM, supercat@casperkitty.com wrote: > On Thursday, August 4, 2016 at 7:38:16 PM UTC-5, Jerry Stuckle wrote: >> On 8/4/2016 7:07 PM, supercat wrote: >>> When have I ever claimed that it wasn't? >>> >> >> Yet you want to limit the hardware it runs on. > > I no more want to forbid C implementations on obscure hardware than the > authors of Annex F wanted to forbid C implementations from using non-IEEE > floating-point. > Even when that "obscure hardware" is many times more prevalent than what you're used to working on. > If an implementation supports Annex F, the code "double x=0.0, y=1.0/x;" > would not invoke Undefined Behavior, but would instead be required to set > y to positive infinity. It is considered perfectly acceptable for > programmers targeting Annex-F platforms to let overflows, divisions by > zero, etc. happen if they programmers are prepared to accept the results > of such operations. > > Likewise, I would like to see an annex which covered many behaviors of > commonplace compilers, such that many things which are not defined by the > Standard would be defined on all implementations that legitimately claim > support for the annex. > You can't have a language with different rules for different processors. If you do, it's a different language. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-05 11:27 -0700 |
| Message-ID | <ca209e13-7b49-400c-87c3-44075f7e0e62@googlegroups.com> |
| In reply to | #91749 |
On Friday, August 5, 2016 at 12:39:46 PM UTC-5, Jerry Stuckle wrote:
> You can't have a language with different rules for different processors.
> If you do, it's a different language.
Given:
int diffcomp(uint16_t a, uint16_t b, uint16_c) { return a-b > c; }
what is the value of diffcomp(1,2,3); If implementations targeting
different processors use the same language, they should all yield the
same result, right?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-05 15:29 -0400 |
| Message-ID | <no2peh$f01$2@jstuckle.eternal-september.org> |
| In reply to | #91755 |
On 8/5/2016 2:27 PM, supercat@casperkitty.com wrote:
> On Friday, August 5, 2016 at 12:39:46 PM UTC-5, Jerry Stuckle wrote:
>> You can't have a language with different rules for different processors.
>> If you do, it's a different language.
>
> Given:
>
> int diffcomp(uint16_t a, uint16_t b, uint16_c) { return a-b > c; }
>
> what is the value of diffcomp(1,2,3); If implementations targeting
> different processors use the same language, they should all yield the
> same result, right?
>
If the standard says they should, then yet. But only if.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-05 08:38 -0700 |
| Message-ID | <ffc0091d-fcaa-40e4-88ee-6755ee202560@googlegroups.com> |
| In reply to | #91696 |
On Thursday, August 4, 2016 at 7:38:16 PM UTC-5, Jerry Stuckle wrote:
> Yet you want to limit the hardware it runs on.
As a further note, I'd like to see the Standard define a term for
"selectively-conforming" code. Presently, it defines two kinds of
conformance for programs:
1. A program is strictly conforming if it would run correctly without UB
on any implementation that complies with the C Standard and does not
happen to get tripped up by translation limits. The Standard is not
clear as to how much a strictly-conforming program is allowed to tax
an implementation (e.g. could a strictly-conforming program have 127
automatic variables of type char[32767] within a single function?
That would blow the stack on a lot of systems even if it wasn't
invoked recursively.)
2. A program is conforming if there exists something that calls itself a
C compiler that will process it in a fashion meeting its self-
proclaimed requirements. A text file containing two underscores and
a newline could thus be a "conforming program" if there exists a C
compiler which predefines a macro "__" as "int main(void) { return 0;}"
I'd like to see a third kind: a program would be "selectively-conforming"
if any implementation which was incapable of processing without UB it in
a fashion meeting requirements would be required to reject it, and there
existed at least one implementation which was not required to reject it
(and would thus process it correctly and without UB).
Presently, the Standard says almost nothing useful about the behavior of
most C programs, but adding "selectively-conforming" to the mix could
change that. Rather than trying to pretend that all programs should be
able to run on all platforms (an unrealistic goal), it would be much more
helpful to focus on allowing programs to provide a guarantee of correct
operation on platforms that can accept them. While it would not be
practical to make all useful programs in selectively-conforming fashion,
it should be possible to write a Standard such that the vast majority of
practical programs could be made "selectively conforming" without having
to compromise performance nor readability.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-05 13:40 -0400 |
| Message-ID | <no2j28$ni3$3@jstuckle.eternal-september.org> |
| In reply to | #91736 |
On 8/5/2016 11:38 AM, supercat@casperkitty.com wrote:
> On Thursday, August 4, 2016 at 7:38:16 PM UTC-5, Jerry Stuckle wrote:
>> Yet you want to limit the hardware it runs on.
>
> As a further note, I'd like to see the Standard define a term for
> "selectively-conforming" code. Presently, it defines two kinds of
> conformance for programs:
>
> 1. A program is strictly conforming if it would run correctly without UB
> on any implementation that complies with the C Standard and does not
> happen to get tripped up by translation limits. The Standard is not
> clear as to how much a strictly-conforming program is allowed to tax
> an implementation (e.g. could a strictly-conforming program have 127
> automatic variables of type char[32767] within a single function?
> That would blow the stack on a lot of systems even if it wasn't
> invoked recursively.)
>
> 2. A program is conforming if there exists something that calls itself a
> C compiler that will process it in a fashion meeting its self-
> proclaimed requirements. A text file containing two underscores and
> a newline could thus be a "conforming program" if there exists a C
> compiler which predefines a macro "__" as "int main(void) { return 0;}"
>
> I'd like to see a third kind: a program would be "selectively-conforming"
> if any implementation which was incapable of processing without UB it in
> a fashion meeting requirements would be required to reject it, and there
> existed at least one implementation which was not required to reject it
> (and would thus process it correctly and without UB).
>
> Presently, the Standard says almost nothing useful about the behavior of
> most C programs, but adding "selectively-conforming" to the mix could
> change that. Rather than trying to pretend that all programs should be
> able to run on all platforms (an unrealistic goal), it would be much more
> helpful to focus on allowing programs to provide a guarantee of correct
> operation on platforms that can accept them. While it would not be
> practical to make all useful programs in selectively-conforming fashion,
> it should be possible to write a Standard such that the vast majority of
> practical programs could be made "selectively conforming" without having
> to compromise performance nor readability.
>
You keep making these claims. But it seems the Standard works for
millions of programmers around the world. You are by far in the minority.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-28 21:27 +0200 |
| Message-ID | <nndmba$ac4$1@dont-email.me> |
| In reply to | #91215 |
Le 28/07/2016 à 10:50, Noob a écrit : > On 28/07/2016 01:47, jacob navia wrote: > > Overflow flag? "All the world's an x86", eh? > All processors have an overflow detection method. IN RISC machines there are different ionstructions for multiply for instance, one sets the flags the other doesn't. There is nothing in the overflow detection that is only to be found in the x86 Thoose are FACTS, but here in this newsgroup it is a sport to make a polemic out of anything even the most banal things like a question from my part what "constrained overflow" could be.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-29 00:19 +0200 |
| Message-ID | <nne0di$i8n$1@dont-email.me> |
| In reply to | #91270 |
On 28/07/16 21:27, jacobnavia wrote: > Le 28/07/2016 à 10:50, Noob a écrit : >> On 28/07/2016 01:47, jacob navia wrote: > >> >> Overflow flag? "All the world's an x86", eh? >> > > All processors have an overflow detection method. IN RISC machines there > are different ionstructions for multiply for instance, one sets the > flags the other doesn't. There is nothing in the overflow detection that > is only to be found in the x86 > At the risk of being labelled banal or pedantic, you might be interested to know that not all cpus have a direct method of detecting overflow. Some RISC processors (such as MIPS, Alpha, and RISC-V) don't have any sort of flag register. Of course, you can still detect overflow. For example, to do a double-length addition you do the equivalent of: uint32_t aHi, aLo; uint32_t bHi, bLo; uint32_t resHi, resLo; resLo = aLo + bLo; resHi = (resLo < aLo); resHi += aHi; resHi += bHi; Each line here corresponds to a single assembly instruction in MIPS (I'm guessing the same applies to other cpus). Such code sequences are easier to schedule (both static instruction scheduling, and dynamic scheduling or out-of-order processing) than using a flag register. It is still a method of overflow detection, of course - and it will work on any processor. > Thoose are FACTS, but here in this newsgroup it is a sport to make a > polemic out of anything even the most banal things like a question from > my part what "constrained overflow" could be. >
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-08-01 11:49 +0200 |
| Message-ID | <nnn608$a9d$1@dont-email.me> |
| In reply to | #91270 |
On 28/07/2016 21:27, jacobnavia wrote: > Le 28/07/2016 à 10:50, Noob a écrit : > >> On 28/07/2016 01:47, jacob navia wrote: > >> Overflow flag? "All the world's an x86", eh? > > All processors have an overflow detection method. Really? And you've checked all processors? IIRC, on MIPS32, 'add' traps on overflow, 'addu' wraps around. Some MIPS variants also have a saturating add. I agree that "trap on overflow" qualifies as an overflow detection method. I haven't checked the hundreds of other architectures though. > IN RISC machines there are different instructions for multiply > for instance, AFAIU, processors with a widening multiply have to offer signed and unsigned variants. This has nothing to do with overflow. > one sets the flags the other doesn't. So which MIPS mul instruction sets which flags? > Those are FACTS, but here in this newsgroup it is a sport to make a > polemic out of anything even the most banal things like a question from > my part what "constrained overflow" could be. Yeah, you're a precious little flower, and everyone's out to get you. /me rolls eyes
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-28 10:01 +0000 |
| Message-ID | <5799d7c8.1742375@news.xs4all.nl> |
| In reply to | #91183 |
jacob navia <jacob@jacob.remcomp.fr> wrote: > Le 28/07/2016 à 01:42, supercat@casperkitty.com a écrit : > > On Wednesday, July 27, 2016 at 3:37:07 PM UTC-5, jacob navia wrote: > >> After two years in second place, C has finally edged out Java for the > >> top spot. Staying in the top five, Python has swapped places with C++ to > >> take the No. 3 position, and C# has fallen out of the top five to be > >> replaced with R > > > > I wonder how that breaks down into the dialect favored by gcc, clang, et al. > > versus dialects that support pointer-based type punning, > > ??? What's that??? > > "pointer-based type punning (prunning maybe) ???? It's the bee in supercat's bonnet. Don't worry about it. Richard
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-28 01:57 -0500 |
| Message-ID | <nnca3a$ikn$1@dont-email.me> |
| In reply to | #91182 |
supercat@casperkitty.com wrote: > On Wednesday, July 27, 2016 at 3:37:07 PM UTC-5, jacob navia wrote: >> After two years in second place, C has finally edged out Java for the >> top spot. Staying in the top five, Python has swapped places with C++ to >> take the No. 3 position, and C# has fallen out of the top five to be >> replaced with R > > I wonder how that breaks down into the dialect favored by gcc, clang, et al. > versus dialects that support pointer-based type punning, constrained overflow > semantics, etc.? > Which "dialect" of 'C' supports constrained overflow? You talking about the saturation overflow semantics of certain DSPs? I hate to be that guy, but overflow isn't actually a problem in real life. It makes for (possibly) uglier code, but it's completely manageable. The problem is when people don't expect it and it catches 'em - just like everything else about 'C'. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-28 07:27 -0700 |
| Message-ID | <025b517e-bd9e-4464-ab32-0d5cadb4bf99@googlegroups.com> |
| In reply to | #91207 |
On Thursday, July 28, 2016 at 1:52:34 AM UTC-5, Les Cargill wrote:> Which "dialect" of 'C' supports constrained overflow? You talking about > the saturation overflow semantics of certain DSPs? How about the very first one? Dennis Ritchie's "printf" function given in his documentation very clearly relies upon the fact that -(-327678) yields -32768. I would consider him the first and foremost authority on what was and was not guaranteed in his language at the time, and I would not expect him to write such code if he didn't think his compiler would reliably support it. That would be at least one dialect, but there are many more besides. How about the majority of C compilers when the C Standard was written, according to the authors of the C89 rationale (I don't know that every individual involved in the Standard was involved in the rationale nor vice versa, so I don't know that it would be 100% accurate to say "the authors of the C Standard", but the thinking expressed in the rationale should be pretty close to what the authors of the Standard intended. According to the C89 rationale, the majority of then-current implementations only differentiated between signed and unsigned addition or multiplication in cases where the result was in the range INT_MAX+1u and UINT_MAX, and the result was either: 1. Promoted to a longer type. 2. Used as the left operand of the >> operator. 3. Used as either operand of /, %, >, >=, ==, !=, <, or <= I don't think I've seen anyone offer a plausible reason the authors of the C89 might have mentioned such a thing unless all the following were true: 1. They regarded such behavior as desirable. 2. Such behavior factored into their reasoning when deciding to make short unsigned types promote as signed. 3. They expected that such behavior would remain reliable on the majority of C implementations going forward. Can anyone offer any other reason why the authors of the C Standard/rationale would have bothered writing the above if the following weren't true?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-28 09:06 -0700 |
| Message-ID | <lnfuqt9275.fsf@kst-u.example.com> |
| In reply to | #91233 |
supercat@casperkitty.com writes:
> On Thursday, July 28, 2016 at 1:52:34 AM UTC-5, Les Cargill wrote:
>> Which "dialect" of 'C' supports constrained overflow? You talking about
>> the saturation overflow semantics of certain DSPs?
>
> How about the very first one? Dennis Ritchie's "printf" function given in
> his documentation very clearly relies upon the fact that -(-327678) yields
> -32768. I would consider him the first and foremost authority on what was
> and was not guaranteed in his language at the time, and I would not expect
> him to write such code if he didn't think his compiler would reliably
> support it. That would be at least one dialect, but there are many more
> besides.
So by "constrained overflow" you meant 2's-complement wraparound
semantics. That wasn't at all clear.
In modern terms, printf is part of the implementation, and its code is
free to depend on any compiler-specific behavior it likes. Ritchie
presumably would not have relied on that assumption if he were writing
code intended to run on one's-complement systems.
[...]
--
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-07-28 09:39 -0700 |
| Message-ID | <89da2b68-5170-4c9c-8cd8-ab7e552b0fce@googlegroups.com> |
| In reply to | #91244 |
On Thursday, July 28, 2016 at 11:07:00 AM UTC-5, Keith Thompson wrote:
> So by "constrained overflow" you meant 2's-complement wraparound
> semantics. That wasn't at all clear.
Precise two's-complement wrapping (if computations go out of range, add
or subtract whatever multiple of (2*INT_MAX+2) would bring them back into
range) would qualify as "constrained overflow behavior", but so too would
"if computations go out of range, add or subtract any arbitrary multiple
of (2*INT_MAX+2) and treat the result as that number even if it's outside
the range of int". Even back in the day, it was not uncommon for compilers
to treat things like "x+1 > y" as "x >= y"--a substitution which would be
legitimate under "constrained overflow behavior" semantics, but would not
be legitimate under "precise wraparound" semantics. Basically, constrained
overflow semantics would allow a compiler freedom to do whatever it wants
subject to three constraints:
1. Casting the result to any type (even its own) or converting it to any
other type (explicitly or implicitly) must yield something that behaves
as a number of the destination type (if converted to a longer type, the
higher-order bits would be Unspecified rather than Indeterminate)
2. The result must behave as though its low-order bits are correct, but it
may behave as though it has Indeterminate higher-order bits when it is
used in computations of its own type without a cast.
3. The computation must have no side-effects other than producing a result
as described above.
In cases where any code meeting the above constraints would meet
requirements, giving a compiler the freedom to generate any code meeting
those constraints may allow far more optimizations than will be possible
if programmers have to prevent overflow at all costs.
> In modern terms, printf is part of the implementation, and its code is
> free to depend on any compiler-specific behavior it likes. Ritchie
> presumably would not have relied on that assumption if he were writing
> code intended to run on one's-complement systems.
Clearly Dennis Ritchie didn't expect that the code would work as written on
platforms with 32-bit two's-complement integers (it would work just fine
given ones'-complement or sign-magnitude integers of any size). On the
other hand, I think he would have expected that it should work on any 16-bit
system whose hardware uses two's-complement silent-wraparound semantics.
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web