Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #88990 > unrolled thread
| Started by | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| First post | 2016-06-13 01:15 +0200 |
| Last post | 2016-08-14 01:32 -0400 |
| Articles | 20 on this page of 382 — 26 participants |
Back to article view | Back to comp.lang.c
Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 01:15 +0200
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 08:47 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-13 02:07 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 13:48 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 10:15 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 13:54 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 13:30 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 15:26 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 17:48 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 10:05 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 20:03 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 14:06 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 22:21 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 22:59 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 11:19 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:32 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 19:32 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 20:28 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 12:45 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:29 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 15:03 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:11 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-15 16:14 -0500
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:04 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-18 16:47 -0500
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-23 20:26 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 21:30 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:54 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 23:33 +0100
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 18:51 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 16:35 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-14 08:38 +0000
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 16:42 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 17:05 -0700
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-19 09:49 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-07-19 15:14 -0700
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 09:20 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 10:31 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 11:20 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 13:38 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 15:21 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 15:44 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 16:15 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 16:32 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 22:09 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 14:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 23:05 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-14 15:12 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 23:16 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 07:45 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 03:02 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 11:39 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:04 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 09:33 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 21:27 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 13:41 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 00:48 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 14:24 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 01:08 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 08:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 09:06 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:12 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 01:31 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 11:03 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 08:42 -0700
Kiki's killfile (Was: Small Device C Compiler 3.6.0 released) gazelle@shell.xmission.com (Kenny McCormack) - 2016-06-16 17:03 +0000
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:16 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-18 16:49 -0500
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 23:42 +0200
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 17:35 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 01:19 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 15:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 08:21 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 23:10 +0100
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-16 16:54 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 19:10 -0700
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-17 06:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 01:09 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 07:13 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 05:29 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 08:12 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:18 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 21:57 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 20:54 -0700
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-17 23:21 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 05:18 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:19 +0000
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 12:40 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 16:37 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 22:08 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 21:02 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-19 00:17 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 22:33 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-19 12:07 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 10:38 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 21:07 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-19 13:36 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 13:50 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 22:42 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 23:16 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 00:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 16:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 01:33 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-20 08:09 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 16:57 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-20 14:23 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 15:56 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 01:24 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 17:51 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 02:33 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 01:40 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 10:10 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 02:22 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 10:51 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 03:12 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-20 11:32 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 03:59 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 12:19 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 04:40 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 13:05 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 05:32 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 15:53 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 16:22 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 17:13 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 10:11 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 21:39 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:10 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 01:14 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-21 17:27 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-22 08:24 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 20:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-22 23:23 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-23 08:15 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-23 20:48 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 23:48 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:02 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-21 03:45 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 20:27 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 10:03 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-21 02:44 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 12:51 +0200
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-21 10:14 -0500
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 16:44 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 19:50 +0200
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 16:33 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-21 10:54 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 20:02 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-21 21:13 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-21 13:45 -0700
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-20 10:00 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 22:07 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:08 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 01:15 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-20 12:38 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 15:48 +0100
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-20 23:17 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 21:43 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-21 06:36 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 10:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 16:03 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 22:28 -0500
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-07-05 07:11 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-05 02:06 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-06 15:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 08:29 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 13:54 -0500
Re: Small Device C Compiler 3.6.0 released Rosario19 <Ros@invalid.invalid> - 2016-07-04 07:18 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 01:58 -0700
Re: Small Device C Compiler 3.6.0 released Rosario19 <Ros@invalid.invalid> - 2016-07-16 19:37 +0200
Re: Small Device C Compiler 3.6.0 released "D. Aaron Sawyer" <aaron@110.net> - 2016-07-16 15:58 -0300
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-07-16 19:25 +0000
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 12:10 -0500
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-18 10:35 -0400
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 12:48 -0500
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-18 23:11 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 21:06 -0700
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-19 08:23 -0400
Re: Small Device C Compiler 3.6.0 released Robert Wessel <robertwessel2@yahoo.com> - 2016-06-18 14:30 -0500
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 09:43 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 14:55 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 16:29 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 15:42 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:23 +0000
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 10:36 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 15:53 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 11:40 -0400
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 09:30 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 17:41 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 08:11 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 11:59 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 09:52 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 18:24 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 14:33 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 12:57 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 16:12 -0400
Re: Small Device C Compiler 3.6.0 released Ian Collins <ian-news@hotmail.com> - 2016-06-18 09:16 +1200
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 14:16 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:32 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 15:02 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 07:45 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 18:34 +0100
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 18:06 +0100
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:06 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-17 21:49 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 15:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-18 02:18 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 19:00 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 22:36 -0400
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:28 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 03:00 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 03:31 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 20:00 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 15:34 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:20 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 02:13 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 11:44 +0200
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 10:47 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 03:41 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 11:49 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 10:52 +0000
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 13:18 +0200
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 23:59 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 10:20 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 10:30 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 12:55 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 12:39 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 14:11 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:44 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 18:38 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:46 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:07 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 12:23 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:43 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 13:38 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 21:59 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 14:42 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 23:28 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 15:35 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 16:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 01:11 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 18:01 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 18:44 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 19:42 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 13:06 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-16 15:06 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 14:40 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 09:09 -0700
Re: Small Device C Compiler 3.6.0 released Reinhardt Behm <rbehm@hushmail.com> - 2016-06-17 20:51 +0800
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:32 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 11:00 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 12:59 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 12:34 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 13:56 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 13:15 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 14:33 +0200
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 08:47 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 11:51 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 20:39 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 16:36 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 21:54 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 17:05 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:05 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:34 +0000
Re: Small Device C Compiler 3.6.0 released Reinhardt Behm <rbehm@hushmail.com> - 2016-06-17 20:43 +0800
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:15 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 15:47 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 07:51 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 11:52 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 14:57 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:37 +0000
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 16:48 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-19 00:50 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 17:30 -0700
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-19 06:35 -0500
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 01:29 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 17:43 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 02:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 18:45 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 17:14 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-19 15:17 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 14:52 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 12:32 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 20:55 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:09 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 16:19 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 01:01 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 17:38 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 21:55 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 10:56 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 06:36 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 16:43 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 09:13 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-18 18:49 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 11:46 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 21:03 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-18 13:30 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 11:17 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 01:18 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 17:53 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 18:20 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 21:37 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 10:30 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-18 07:52 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 13:59 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 22:01 -0700
Re: Small Device C Compiler 3.6.0 released gazelle@shell.xmission.com (Kenny McCormack) - 2016-06-18 10:02 +0000
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 21:10 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 06:45 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 15:00 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 10:35 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 09:07 -0700
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-06-16 15:32 +0000
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 17:03 +0100
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-06-16 22:26 +0000
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 23:44 +0100
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-16 16:56 -0700
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:03 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 13:43 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 16:35 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 20:57 -0400
Re: Small Device C Compiler 3.6.0 released James Kuyper <jameskuyper@verizon.net> - 2016-06-16 21:12 -0400
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 22:31 -0400
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 22:32 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 19:59 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 03:11 -0700
Re: Small Device C Compiler 3.6.0 released James Kuyper <jameskuyper@verizon.net> - 2016-06-17 09:11 -0400
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 12:20 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 12:40 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:24 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 18:16 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 11:15 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:09 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:32 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 12:01 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:15 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:15 +0000
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 03:12 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 13:03 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 04:22 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 14:20 +0200
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:33 +0000
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:00 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:39 +0000
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-13 14:38 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 15:09 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-14 09:51 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 23:19 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 23:46 +0100
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 19:04 -0400
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 20:04 -0400
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 10:59 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 00:23 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 11:17 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 02:08 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 08:37 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 08:56 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 09:14 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-18 11:47 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 10:59 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 12:54 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 05:38 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 22:56 +0200
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-15 10:09 +0200
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 15:09 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 14:39 +0200
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-16 15:11 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 14:28 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 21:25 +0200
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-16 12:40 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 22:00 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 21:14 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-16 14:08 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 22:30 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-17 13:31 +0200
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-17 13:28 +0200
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 21:38 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 10:53 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 08:39 -0700
Re: Small Device C Compiler 3.6.0 released bitrex <bitrex@de.lete.earthlink.net> - 2016-08-14 01:32 -0400
Page 6 of 20 — ← Prev page 1 … 4 5 [6] 7 8 … 20 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-19 23:16 +0100 |
| Message-ID | <nk75jo$8dv$1@dont-email.me> |
| In reply to | #89627 |
On 19/06/2016 22:42, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Sunday, June 19, 2016 at 9:07:20 PM UTC+1, Ben Bacarisse wrote:
>>> void a(void) { b(); d(); }
>>> void b(void) { d(); }
>>> void d(void) { e(); }
>>> void e(void) { }
>>>
>>> Your construction just adds a child (one child) and an edge (one edge)
>>> for every call in the source and I've just added one call to e into the
>>> source, so what tree do I draw?
>>>
>> a
>> / \
>> b d
>> / \e
>> d
>> /
>> e
>>
>> d nodes are identical, but not duplicates.
>
> That's odd.
I've little idea what you two are arguing about. But if the dynamic
calls in your example are displayed, then I get a graph pretty much like
Malcolm's (rotated and flipped and offset, but the same, although
Malcolm has a misplaced 'e' in his.)
What's more odd is what's happened to c().
#include <stdio.h>
int level=0;
void b(void);
void d(void);
void e(void);
void display(char* s) {
printf("%.*s%s\n",level*2,
" ",s);
}
void a(void) {
++level;
display("A");
b(); d();
--level;
}
void b(void) {
++level;
display("B");
d();
--level;
}
void d(void) {
++level;
display("D");
e();
--level;
}
void e(void) {
++level;
display("E");
--level;
}
int main(void){
a();
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 00:12 +0100 |
| Message-ID | <87wplkpyco.fsf@bsb.me.uk> |
| In reply to | #89628 |
BartC <bc@freeuk.com> writes:
<snip>
> I've little idea what you two are arguing about. But if the dynamic
> calls in your example are displayed, then I get a graph pretty much
> like Malcolm's
The Malcolm-call-tree is not the dynamic tree of calls because that does
not have the property he wants for recursive programs (it remains a
tree), and it's not the usual static call graph because that's not
always a tree. It's something in between.
<snip>
> void display(char* s) {
> printf("%.*s%s\n",level*2,
> " ",s);
> }
I use
printf("%*s", level * 2, "");
for things like this.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-19 16:35 -0700 |
| Message-ID | <18a8b9f5-7c4a-48cf-b052-ac81100e4396@googlegroups.com> |
| In reply to | #89632 |
On Monday, June 20, 2016 at 12:12:31 AM UTC+1, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> > > I've little idea what you two are arguing about. But if the dynamic > > calls in your example are displayed, then I get a graph pretty much > > like Malcolm's > > The Malcolm-call-tree is not the dynamic tree of calls because that does > not have the property he wants for recursive programs (it remains a > tree), and it's not the usual static call graph because that's not > always a tree. It's something in between. > Exactly. The Malcolm-call-tree, (I can't see that name sticking, but it's a chance for fame) is the structure of a structured program, with blocks that are not subroutines replaced by spaghetti code. (They won't really be spaghetti code, at least not normally, but they don't appear in the tree). That's how modern structured programming has developed. Subroutines are blocks (single point of entry and of exit), and are heavily used to break the program down into manageable chunks. They are not primarily used so that they can be called from two separate points, though that is an additional property. And the subroutines are not themselves written as strict structured programs, they are nearly structured but not quite.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 01:33 +0100 |
| Message-ID | <87k2hkpulh.fsf@bsb.me.uk> |
| In reply to | #89633 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 12:12:31 AM UTC+1, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> <snip> >> > I've little idea what you two are arguing about. But if the dynamic >> > calls in your example are displayed, then I get a graph pretty much >> > like Malcolm's >> >> The Malcolm-call-tree is not the dynamic tree of calls because that does >> not have the property he wants for recursive programs (it remains a >> tree), and it's not the usual static call graph because that's not >> always a tree. It's something in between. >> > Exactly. > The Malcolm-call-tree, (I can't see that name sticking, but it's a > chance for fame) is the structure of a structured program, ... that has no recursive calls, function pointer arguments, no function values, no higher-order functions and so on. The chance of fame is slim because I don't think there are many people looking for a construct show sole purpose is to rule out recursive calls from being well-structured. If anything the trend is the other way with work to understand how to structure code using higher-order functions. <snip> > That's how modern structured programming has developed. No. It started by permitting recursive calls (and simple function vales for that matter) and has not gone backwards. > Subroutines > are blocks (single point of entry and of exit), and are heavily > used to break the program down into manageable chunks. They > are not primarily used so that they can be called from two > separate points, though that is an additional property. And the > subroutines are not themselves written as strict structured programs, > they are nearly structured but not quite. That's interesting as a person opinion but it does not match my experience. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-20 08:09 -0700 |
| Message-ID | <86daa0a9-7aaa-4aaa-8719-5c5f286e73b9@googlegroups.com> |
| In reply to | #89635 |
On Sunday, June 19, 2016 at 7:33:37 PM UTC-5, Ben Bacarisse wrote: > Malcolm McLean writes: > > Exactly. > > The Malcolm-call-tree, (I can't see that name sticking, but it's a > > chance for fame) is the structure of a structured program, > > ... that has no recursive calls, function pointer arguments, no function > values, no higher-order functions and so on. The HiTech compiler for the PIC series processes a subset of the C language which does not allow recursive calls, and requires that no function which is called directly or indirectly with a particular function pointer type can make a call via a another pointer of that type (dealing with this latter limitation efficiently if there would be two non-overlapping classes of functions that would otherwise have the same signature may require writing the functions to return different structure types, but the machine code generated to return a structure that contains a single primitive is the same as the code to return that primitive). The compiler has had for many years an option to output the "Malcom tree", which I have at times found useful, though I would generally need to run it through a filter program I wrote to discover what I need to know from it (typically what functions are contributing to worst-case auto-variable usage).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 16:57 +0100 |
| Message-ID | <87y45zontf.fsf@bsb.me.uk> |
| In reply to | #89656 |
supercat@casperkitty.com writes: > On Sunday, June 19, 2016 at 7:33:37 PM UTC-5, Ben Bacarisse wrote: >> Malcolm McLean writes: >> > Exactly. >> > The Malcolm-call-tree, (I can't see that name sticking, but it's a >> > chance for fame) is the structure of a structured program, >> >> ... that has no recursive calls, function pointer arguments, no function >> values, no higher-order functions and so on. > > The HiTech compiler for the PIC series processes a subset of the C > language which does not allow recursive calls, Ah. > The compiler has had for many years an option to output the "Malcom > tree", I can't find much documentation about that but some of their IDEs have a "show call graph" option. From the documentation that appears to be the conventional call graph so not what you are talking about. Do you have a link to a document (or the compiler itself) that explains the Malcolm-call-tree option? Since recursion is not supported it won't help with the key question, but the description might provide the rules that are currently missing. > which I have at times found useful, I've found the conventional call graph to be very useful and I'm not sure how Malcolm's duplicating of nodes would help. > though I would generally need to run > it through a filter program I wrote to discover what I need to know from > it (typically what functions are contributing to worst-case auto-variable > usage). You could get that from the usual call graph couldn't you? The "Malcolm-call-tree" just splits paths through the graph into tree paths, doesn't it? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-20 14:23 -0700 |
| Message-ID | <bb0d6b41-3165-4423-b5c2-ad73eec3c9e5@googlegroups.com> |
| In reply to | #89658 |
On Monday, June 20, 2016 at 10:57:41 AM UTC-5, Ben Bacarisse wrote: > I can't find much documentation about that but some of their IDEs have a > "show call graph" option. From the documentation that appears to be the > conventional call graph so not what you are talking about. The call graph outputs for each root-level function (either main() or an interrupt handler) information related to its automatic variable placement and then recursively shows indented lines below it for each function it might call, with each of those recursively including a more-deeply indented line for each function it might call, etc. There are options to include either a full or brief call-graph, neither of which is quite ideal. The full call graph is often huge, since if X calls 5 functions each of which call Y, and X is itself called 7 times, then the line for Y will be repeated 35 times as a result of calls from X (plus more if it's called elsewhere). The brief graph omits the nested function calls for a function on all but the first time it appears. In many cases, what I actually need is a call graph which includes nested calls which contribute to the worst- case auto-variable usage, but the brief graph makes it awkward to find that since in many cases the first call to a function will not be made by from the context with the largest auto-variable usage requirement.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-19 15:56 -0700 |
| Message-ID | <73564705-61ce-4ee4-b976-2f9d386716fc@googlegroups.com> |
| In reply to | #89627 |
On Sunday, June 19, 2016 at 10:42:49 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > d nodes are identical, but not duplicates. > > That's odd. They appear to represent different calls in the source. I > would not call that identical (one is "call d on line 1" the other is > "call of d on line 2") but the construction is yours after all. If > being identical still allows them to be separate, so be it. > They are identical in the source (unless you have made two physical copies). They are not identical in the tree. It's a tree and we have two "d" blocks. We don't have two points of entry into the same d block (that would violate the definition of "block"). > > > (for most purposes, the call graph is fine, but not for example if > > d take a constant parameter in one call and a variable in another, > > and we wish to discuss how to optimise the program). > > Can you write the rule in a way that will let someone draw the > Malcolm-call-tree for themselves? This (which for some reason you cut) > > "we can draw the tree simply by looking through the function source > and adding an edge and a child each time a call appears in the source" > > does not cover that situation. It suggests a one-to-one correspondence > between calls appearing in the source and nodes in the tree. > I don't see your difficulty here. Simply take some C source without gotos, breaks, continues or switches, and indent it in the conventional way. Now inline all the function calls manually. Forget static variables for the moment and function pointers and recursion. Now you have "the tree". The tree is the structure to which "structured programming" refers. The rules create that structure, and conventionally it is represented by indentation for each level. With a special rule for recursion.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 01:24 +0100 |
| Message-ID | <87porcpv0p.fsf@bsb.me.uk> |
| In reply to | #89631 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, June 19, 2016 at 10:42:49 PM UTC+1, Ben Bacarisse wrote: <snip> >> Can you write the rule in a way that will let someone draw the >> Malcolm-call-tree for themselves? This (which for some reason you cut) >> >> "we can draw the tree simply by looking through the function source >> and adding an edge and a child each time a call appears in the source" >> >> does not cover that situation. It suggests a one-to-one correspondence >> between calls appearing in the source and nodes in the tree. >> > I don't see your difficulty here. You don't think your previous description clearly stated a one-to-one correspondence between calls appearing in the source and nodes in the tree? Oh well... > Simply take some C source without gotos, breaks, continues or > switches, and indent it in the conventional way. > Now inline all the function calls manually. Forget static variables > for the moment and function pointers and recursion. > > Now you have "the tree". No I don't. I get a tree if I follow a set of rules that constructs it. For example, my best guess for your rule is that as you inline a function you create a new node and add an edge from the node representing the (inlined) calling function to the new node. But this rule will give you tree even for a recursive program so let me know if this is not how your tree is constructed. > The tree is the structure to which "structured > programming" refers. Only if, as above, you include recursion because no one but you rules it out from structured code. <snip> > With a special rule for recursion. Yes, if you have a special rule for recursion it will seem to be special, so job done. What is the special rule for recursion? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-19 17:51 -0700 |
| Message-ID | <b4689c7c-5d30-489d-8919-0be1d6d4c604@googlegroups.com> |
| In reply to | #89634 |
On Monday, June 20, 2016 at 1:24:31 AM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > Simply take some C source without gotos, breaks, continues or
> > switches, and indent it in the conventional way.
> > Now inline all the function calls manually. Forget static variables
> > for the moment and function pointers and recursion.
> >
> > Now you have "the tree".
>
> No I don't. I get a tree if I follow a set of rules that constructs it.
> For example, my best guess for your rule is that as you inline a
> function you create a new node and add an edge from the node
> representing the (inlined) calling function to the new node.
>
> But this rule will give you tree even for a recursive program so let me
> know if this is not how your tree is constructed.
>
void foo()
{
printf("foo\n");
}
int main(int argc, char **argv)
{
if(argc)
foo(); // this is a "block"
}
Apply the rules
int main(int argc, char **argv
{
if(argc)
{
//foo() // need some syntax here, this is an expanded block
{
printf("foo\n");
}
}
}
Structure of the program
main block
if block
foo block
printf block
Let's consider printf atomic. It's a "black box" block.
If we had the source we could of course expand it in the same manner.
The indentation gives you the structure of the program. Most structured
programming language use indentation. Indentation is also the usual
way of representing a tree.
The tree of blocks is the structure to which "structured" in the term
structured programming refers to. The indentation gives a visual
representation.
> > The tree is the structure to which "structured
> > programming" refers.
>
> Only if, as above, you include recursion because no one but you rules it
> out from structured code.
>
Most structured programming don't have a notation for recursive blocks,
other than subroutine calls. However generally blocks are not
constrained to be subroutines, usually they are represented in the
tree structure as I have explained and described. A subroutine can
replace a block and a block can replace a subroutine, other than
for recursion.
>
> <snip>
> > With a special rule for recursion.
>
> Yes, if you have a special rule for recursion it will seem to be
> special, so job done. What is the special rule for recursion?
>
You write a subroutine that calls itself.
The notation is that the name of the subroutine appears in the
subroutine itself, as a block.
The call tree now has a cycle and is not strictly a tree. We can
no longer write the program without some mechanism for subroutines.
Many properties change.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 02:33 +0100 |
| Message-ID | <nk7h60$4h1$1@dont-email.me> |
| In reply to | #89636 |
On 20/06/16 01:51, Malcolm McLean wrote:
<snip>
> Structure of the program
>
> main block
> if block
> foo block
> printf block
>
> Let's consider printf atomic. It's a "black box" block.
> If we had the source we could of course expand it in the same manner.
Okay, I'm with you so far. So let's consider this program (and I'm
minimising the syntax to beyond breaking-point, to simplify the picture):
foo() { printf("foo\n"); }
bar() { printf("bar\n"); }
main()
{
if(cond)
foo();
bar();
}
becomes:
main
if
foo
printf
bar
printf
Right?
<snip>
> Most structured programming don't have a notation for recursive blocks,
> other than subroutine calls. However generally blocks are not
> constrained to be subroutines, usually they are represented in the
> tree structure as I have explained and described. A subroutine can
> replace a block and a block can replace a subroutine, other than
> for recursion.
But why not for recursion?
<snip>
> You write a subroutine that calls itself.
Yes...
> The notation is that the name of the subroutine appears in the
> subroutine itself, as a block.
> The call tree now has a cycle and is not strictly a tree. We can
> no longer write the program without some mechanism for subroutines.
> Many properties change.
But wait - here's a recursive program:
foo(n) { if(n > 0) foo(n-1); printf("foo\n"); }
main()
{
foo(3);
}
Surely we can now do this:
main
foo
if
foo
if
foo
if
foo
if
printf
printf
printf
printf
The only time we can't do this is when the recursive part of the program
has no base case (which would in any event constitute a broken program).
So it turns out that you don't need a special rule for recursion for
precisely the same reason that you don't need a special rule for
infinitely long main().
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 01:40 -0700 |
| Message-ID | <9ceae564-3066-49c2-b554-71f6fe321725@googlegroups.com> |
| In reply to | #89637 |
On Monday, June 20, 2016 at 2:33:59 AM UTC+1, Richard Heathfield wrote:
> On 20/06/16 01:51, Malcolm McLean wrote:
>
> <snip>
>
> > Structure of the program
> >
> > main block
> > if block
> > foo block
> > printf block
> >
> > Let's consider printf atomic. It's a "black box" block.
> > If we had the source we could of course expand it in the same manner.
>
> Okay, I'm with you so far. So let's consider this program (and I'm
> minimising the syntax to beyond breaking-point, to simplify the picture):
>
> foo() { printf("foo\n"); }
> bar() { printf("bar\n"); }
> main()
> {
> if(cond)
> foo();
> bar();
> }
>
> becomes:
> main
> if
> foo
> printf
> bar
> printf
>
> Right?
>
> <snip>
>
> > Most structured programming don't have a notation for recursive blocks,
> > other than subroutine calls. However generally blocks are not
> > constrained to be subroutines, usually they are represented in the
> > tree structure as I have explained and described. A subroutine can
> > replace a block and a block can replace a subroutine, other than
> > for recursion.
>
> But why not for recursion?
>
> <snip>
>
> > You write a subroutine that calls itself.
>
> Yes...
>
> > The notation is that the name of the subroutine appears in the
> > subroutine itself, as a block.
> > The call tree now has a cycle and is not strictly a tree. We can
> > no longer write the program without some mechanism for subroutines.
> > Many properties change.
>
> But wait - here's a recursive program:
>
> foo(n) { if(n > 0) foo(n-1); printf("foo\n"); }
> main()
> {
> foo(3);
> }
>
> Surely we can now do this:
>
> main
> foo
> if
> foo
> if
> foo
> if
> foo
> if
> printf
> printf
> printf
> printf
>
> The only time we can't do this is when the recursive part of the program
> has no base case (which would in any event constitute a broken program).
> So it turns out that you don't need a special rule for recursion for
> precisely the same reason that you don't need a special rule for
> infinitely long main().
>
If you know the number of iterations at compile time, it can be
expanded. Generally you use recursion when you don't.
The tree becomes dynamic.
Then there's also the requirement for balance.
Recursive functions tend to have many levels, so the tree is no
longer balanced. or, like qsort with a naive partition strategy,
they might be logarithmically deep in the expected case,
but N steps deep in the worst case.
You can say the same about loops - loops can be unrolled
if the number of iterations can be determined at compile
time, and often that's useful, but only if the loop is short.
Loops also destroy many valuable characteristics of the
programs, as do ifs (mathematicians don't like ifs), but we
can't really do without them.
Most small structured programs can be and are written without
recursion, however.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 10:10 +0100 |
| Message-ID | <nk8bv2$7bj$1@dont-email.me> |
| In reply to | #89640 |
On 20/06/16 09:40, Malcolm McLean wrote:
> On Monday, June 20, 2016 at 2:33:59 AM UTC+1, Richard Heathfield wrote:
>> On 20/06/16 01:51, Malcolm McLean wrote:
>>
>> <snip>
>>
>>> Structure of the program
>>>
>>> main block
>>> if block
>>> foo block
>>> printf block
>>>
>>> Let's consider printf atomic. It's a "black box" block.
>>> If we had the source we could of course expand it in the same manner.
>>
>> Okay, I'm with you so far. So let's consider this program (and I'm
>> minimising the syntax to beyond breaking-point, to simplify the picture):
>>
>> foo() { printf("foo\n"); }
>> bar() { printf("bar\n"); }
>> main()
>> {
>> if(cond)
>> foo();
>> bar();
>> }
>>
>> becomes:
>> main
>> if
>> foo
>> printf
>> bar
>> printf
>>
>> Right?
>>
>> <snip>
>>
>>> Most structured programming don't have a notation for recursive blocks,
>>> other than subroutine calls. However generally blocks are not
>>> constrained to be subroutines, usually they are represented in the
>>> tree structure as I have explained and described. A subroutine can
>>> replace a block and a block can replace a subroutine, other than
>>> for recursion.
>>
>> But why not for recursion?
>>
>> <snip>
>>
>>> You write a subroutine that calls itself.
>>
>> Yes...
>>
>>> The notation is that the name of the subroutine appears in the
>>> subroutine itself, as a block.
>>> The call tree now has a cycle and is not strictly a tree. We can
>>> no longer write the program without some mechanism for subroutines.
>>> Many properties change.
>>
>> But wait - here's a recursive program:
>>
>> foo(n) { if(n > 0) foo(n-1); printf("foo\n"); }
>> main()
>> {
>> foo(3);
>> }
>>
>> Surely we can now do this:
>>
>> main
>> foo
>> if
>> foo
>> if
>> foo
>> if
>> foo
>> if
>> printf
>> printf
>> printf
>> printf
>>
>> The only time we can't do this is when the recursive part of the program
>> has no base case (which would in any event constitute a broken program).
>> So it turns out that you don't need a special rule for recursion for
>> precisely the same reason that you don't need a special rule for
>> infinitely long main().
>>
> If you know the number of iterations at compile time, it can be
> expanded. Generally you use recursion when you don't.
> The tree becomes dynamic.
That's all right -- you can get the program to print out the tree at
run-time.
> Then there's also the requirement for balance.
Are you saying that this program isn't structured?
foo()
{
/* leaf */
}
bar()
{
/* leaf */
}
baz()
{
foo();
}
main()
{
bar();
baz();
}
Why does a program have to be balanced in order to be structured?
> Recursive functions tend to have many levels, so the tree is no
> longer balanced. or, like qsort with a naive partition strategy,
> they might be logarithmically deep in the expected case,
> but N steps deep in the worst case.
>
> You can say the same about loops - loops can be unrolled
> if the number of iterations can be determined at compile
> time, and often that's useful, but only if the loop is short.
But you said we can't have loops in a structured program, because flow
can only go down the page.
> Loops also destroy many valuable characteristics of the
> programs, as do ifs (mathematicians don't like ifs), but we
> can't really do without them.
No, we can't, but no, they don't. Loops are a fundamental part of
structured programming and a very real benefit, not an embarrassing
add-on and an unavoidable cost.
> Most small structured programs can be and are written without
> recursion, however.
I conclude from that sentence (and particularly from the word 'most')
that you now agree that recursive programs can be structured programs.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 02:22 -0700 |
| Message-ID | <f0a756e3-b68a-4745-9fe6-34a34d646bca@googlegroups.com> |
| In reply to | #89641 |
On Monday, June 20, 2016 at 10:11:12 AM UTC+1, Richard Heathfield wrote:
> On 20/06/16 09:40, Malcolm McLean wrote:
>
> > If you know the number of iterations at compile time, it can be
> > expanded. Generally you use recursion when you don't.
> > The tree becomes dynamic.
>
> That's all right -- you can get the program to print out the tree at
> run-time.
>
It's all right. The program will run.
It loses some valuable properties and becomes harder to reason
about, test, implement and show to be correct. Also harder to
represent.
>
> > Then there's also the requirement for balance.
>
> Are you saying that this program isn't structured?
>
> foo()
> {
> /* leaf */
> }
> bar()
> {
> /* leaf */
> }
> baz()
> {
> foo();
> }
>
> main()
> {
> bar();
> baz();
> }
>
> Why does a program have to be balanced in order to be structured?
>
A degnerate tree loses most of the desirable characteristics of a
balanced tree.
>
> > Recursive functions tend to have many levels, so the tree is no
> > longer balanced. or, like qsort with a naive partition strategy,
> > they might be logarithmically deep in the expected case,
> > but N steps deep in the worst case.
> >
> > You can say the same about loops - loops can be unrolled
> > if the number of iterations can be determined at compile
> > time, and often that's useful, but only if the loop is short.
>
> But you said we can't have loops in a structured program, because flow
> can only go down the page.
>
> > Loops also destroy many valuable characteristics of the
> > programs, as do ifs (mathematicians don't like ifs), but we
> > can't really do without them.
>
> No, we can't, but no, they don't. Loops are a fundamental part of
> structured programming and a very real benefit, not an embarrassing
> add-on and an unavoidable cost.
>
Flow always goes down the page, with the exception of loops
with go up, with no blocks (rectangles) allowed on the upwards
path. You lose many desirable properties by allowing loops.
Some people go as far as to ban them and demand recursion instead
to achieve the same effect.
>
> > Most small structured programs can be and are written without
> > recursion, however.
>
> I conclude from that sentence (and particularly from the word 'most')
> that you now agree that recursive programs can be structured programs.
>
I've never said that.
I said that recursion breaks many of the desirable characteristics of
structured programs.
(I've just realised that my position is actually very close to the "ban
loops" position taken by some functional programmers, but a mirror
image of it).
The difference is that I don't advocate forcing programmers to simulate
recursion with a data stack, ifs and loops, if recursion would be more
natural.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 10:51 +0100 |
| Message-ID | <nk8eaa$eqj$1@dont-email.me> |
| In reply to | #89642 |
On 20/06/16 10:22, Malcolm McLean wrote:
> On Monday, June 20, 2016 at 10:11:12 AM UTC+1, Richard Heathfield wrote:
>> On 20/06/16 09:40, Malcolm McLean wrote:
>>
>>> If you know the number of iterations at compile time, it can be
>>> expanded. Generally you use recursion when you don't.
>>> The tree becomes dynamic.
>>
>> That's all right -- you can get the program to print out the tree at
>> run-time.
>>
>
> It's all right. The program will run.
> It loses some valuable properties and becomes harder to reason
> about, test, implement and show to be correct. Also harder to
> represent.
It is precisely because recursion gains some valuable properties and
becomes easier to reason about, test, implement and show to be correct
(insofar as anything can be shown to be correct) that it is used in some
important problems. It is no harder to represent than a loop.
>>
>>> Then there's also the requirement for balance.
>>
>> Are you saying that this program isn't structured?
>>
>> foo()
>> {
>> /* leaf */
>> }
>> bar()
>> {
>> /* leaf */
>> }
>> baz()
>> {
>> foo();
>> }
>>
>> main()
>> {
>> bar();
>> baz();
>> }
>>
>> Why does a program have to be balanced in order to be structured?
>>
> A degnerate tree loses most of the desirable characteristics of a
> balanced tree.
Why is it desirable for a program's call graph (or Malcolm-call-tree) to
be balanced?
<snip>
>> [...] Loops are a fundamental part of
>> structured programming and a very real benefit, not an embarrassing
>> add-on and an unavoidable cost.
>>
> Flow always goes down the page, with the exception of loops
Oh, that's new. Loops can go up the page now? Good. Well, if they can,
why can't recursive functions direct the flow up the page too?
> with go up, with no blocks (rectangles) allowed on the upwards
> path. You lose many desirable properties by allowing loops.
No, Malcolm, you *gain* many desirable properties by allowing loops.
What you lose (and what few people miss) by allowing loops is the goto.
> Some people go as far as to ban them and demand recursion instead
> to achieve the same effect.
Oddly, you're right about this. In the early 1990s I worked at a site
(which I will conceal behind the name 'MumbleCo', to protect the guilty)
where:
1) MumbleCo's spec writers were told to write "language-blind", not
incorporating any weird language-specific structures such as loops
(despite being professional mathematicians who had had a reasonable
amount of exposure to programming);
2) the programmers were required to implement the spec as written;
3) the programmers were required to adhere to the MumbleCo house style,
which said (reasonably enough) "no goto".
The people who came up with these rules, as we might be cynical enough
to expect in a relatively large organisation such as MumbleCo, were of
course three separate people who didn't talk to each other.
The consequence of everybody following the rules was a ridiculous
profusion of functions bound together by an array of function pointers
and a whole bunch of mutual recursion. I hope to God that they've ripped
all that code out by now and replaced it with something sensible.
>>
>>> Most small structured programs can be and are written without
>>> recursion, however.
>>
>> I conclude from that sentence (and particularly from the word 'most')
>> that you now agree that recursive programs can be structured programs.
>>
> I've never said that.
You've never said... what? That recursive programs can't be structured?
Okay, fair enough - I'll take you at your word. Obviously I misremembered.
> I said that recursion breaks many of the desirable characteristics of
> structured programs.
But it doesn't. No, Malcolm, it really doesn't. A recursive function is
just a function. Getting the hang of them is a bit weird at first, but
once you've got past that stage (which should happen quite early on in
one's programming experience) they are an extraordinarily useful tool
and one that makes many programs much simpler to encode with a sensible,
manageable structure. Can they be abused? Hell yes. So can anything.
But, used sensibly, they are a blessing and a boon.
> (I've just realised that my position is actually very close to the "ban
> loops" position taken by some functional programmers, but a mirror
> image of it).
> The difference is that I don't advocate forcing programmers to simulate
> recursion with a data stack, ifs and loops, if recursion would be more
> natural.
I wonder what MumbleCo would have made of that... being forced to
simulate loops with recursion AND simulate recursion with loops! :-)
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 03:12 -0700 |
| Message-ID | <4dfa989b-a3ab-44d4-92eb-5f2fefcaf2eb@googlegroups.com> |
| In reply to | #89643 |
On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote: > On 20/06/16 10:22, Malcolm McLean wrote: > > But it doesn't. No, Malcolm, it really doesn't. A recursive function is > just a function. Getting the hang of them is a bit weird at first, but > once you've got past that stage (which should happen quite early on in > one's programming experience) they are an extraordinarily useful tool > and one that makes many programs much simpler to encode with a sensible, > manageable structure. Can they be abused? Hell yes. So can anything. > But, used sensibly, they are a blessing and a boon. > A recursive function is not just another subroutine call. It has properties which are fundamentally different. > > I wonder what MumbleCo would have made of that... being forced to > simulate loops with recursion AND simulate recursion with loops! :-) > You can ban either loops or recursion, but not both.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-20 11:32 +0100 |
| Message-ID | <nk8gol$n20$1@dont-email.me> |
| In reply to | #89644 |
On 20/06/2016 11:12, Malcolm McLean wrote:
> On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote:
>> On 20/06/16 10:22, Malcolm McLean wrote:
>>
>> But it doesn't. No, Malcolm, it really doesn't. A recursive function is
>> just a function. Getting the hang of them is a bit weird at first, but
>> once you've got past that stage (which should happen quite early on in
>> one's programming experience) they are an extraordinarily useful tool
>> and one that makes many programs much simpler to encode with a sensible,
>> manageable structure. Can they be abused? Hell yes. So can anything.
>> But, used sensibly, they are a blessing and a boon.
>>
> A recursive function is not just another subroutine call.
> It has properties which are fundamentally different.
I took the recursive Fibonacci routine and made it not recursive by
duplicating and renaming some functions. The dynamic call structure is
exactly the same, if you ignore the actual names of the functions.
So what's different?
#include <stdio.h>
int fib5(int n) {
if (n<=2)
return 1;
else
puts("'recursion' depth exceeded");
exit(1);
}
int fib4(int n) {
if (n<=2)
return 1;
else
return fib5(n-1)+fib5(n-2);
}
int fib3(int n) {
if (n<=2)
return 1;
else
return fib4(n-1)+fib4(n-2);
}
int fib2(int n) {
if (n<=2)
return 1;
else
return fib3(n-1)+fib3(n-2);
}
int fib(int n) {
if (n<=2)
return 1;
else
return fib2(n-1)+fib2(n-2);
}
int main(void){
printf("%d\n",fib(6));
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 03:59 -0700 |
| Message-ID | <1565e279-cbb4-43e1-93cf-0f7a616cbded@googlegroups.com> |
| In reply to | #89645 |
On Monday, June 20, 2016 at 11:33:02 AM UTC+1, Bart wrote:
> On 20/06/2016 11:12, Malcolm McLean wrote:
>
> > A recursive function is not just another subroutine call.
> > It has properties which are fundamentally different.
>
> I took the recursive Fibonacci routine and made it not recursive by
> duplicating and renaming some functions. The dynamic call structure is
> exactly the same, if you ignore the actual names of the functions.
>
> So what's different?
>
>
> #include <stdio.h>
>
> int fib5(int n) {
> if (n<=2)
> return 1;
> else
> puts("'recursion' depth exceeded");
> exit(1);
> }
>
> int fib4(int n) {
> if (n<=2)
> return 1;
> else
> return fib5(n-1)+fib5(n-2);
> }
>
> int fib3(int n) {
> if (n<=2)
> return 1;
> else
> return fib4(n-1)+fib4(n-2);
> }
>
> int fib2(int n) {
> if (n<=2)
> return 1;
> else
> return fib3(n-1)+fib3(n-2);
> }
>
> int fib(int n) {
> if (n<=2)
> return 1;
> else
> return fib2(n-1)+fib2(n-2);
> }
>
> int main(void){
>
> printf("%d\n",fib(6));
>
> }
>
You've done the equivalent of loop unrolling.
We now know that the function must terminate without dry running it,
for example.
We also know that it has an "error", because of the non-structured exit()
construct. Since we can't hold high fibonacci numbers in an int anyway
(unless you subscribe to the campaign for 64 bit ints), we know that
we need to go a bit deeper.
Having done that the program will hopefully fail at compile time if we don't
have the resources to calculate the solution using that algorithm.
The optimiser can also inline all the calls, not just the tail recursive one.
It also make it a lot easier for it to factor out the constants. So with
any luck, the program will resolve to a single call to printf with a constant.
You can't do this as a general policy with the recursive solution because
there is no guarantee that the function will halt, without running all the
way through it, which of course will optimise any pure function of
a constant. With the non-recursive answer, little local optimisations
such as function inline and trimming of untaken branches will add up to
resolving to a constant).
You can see if I'm right by compiling using different optimisation settings
an examining the machine code.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 12:19 +0100 |
| Message-ID | <nk8jg1$vjv$1@dont-email.me> |
| In reply to | #89644 |
On 20/06/16 11:12, Malcolm McLean wrote: > On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote: <snip> > A recursive function is not just another subroutine call. > It has properties which are fundamentally different. Do please share what these fundamentally different properties are. >> >> I wonder what MumbleCo would have made of that... being forced to >> simulate loops with recursion AND simulate recursion with loops! :-) >> > You can ban either loops or recursion, but not both. Frankly, I'd rather ban neither. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 04:40 -0700 |
| Message-ID | <a2f879b2-2a4b-4dbb-8ffd-d24442c23645@googlegroups.com> |
| In reply to | #89647 |
On Monday, June 20, 2016 at 12:19:36 PM UTC+1, Richard Heathfield wrote: > On 20/06/16 11:12, Malcolm McLean wrote: > > > A recursive function is not just another subroutine call. > > It has properties which are fundamentally different. > > Do please share what these fundamentally different properties are. > A tree with a cycle in it has different properties to a tree without. It's no longer strictly a tree. We can no longer traverse and enumerate nodes. We no longer have a maximum depth. We no longer have a unique path from leaf to root and root to leaf. We can no longer eliminate sub-branches by replacing them with leaf nodes which are equivalent.
[toc] | [prev] | [next] | [standalone]
Page 6 of 20 — ← Prev page 1 … 4 5 [6] 7 8 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web