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-06-18 08:39 -0700 |
| Articles | 20 on this page of 364 — 23 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 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 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
Page 1 of 19 [1] 2 3 … 19 Next page →
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2016-06-13 01:15 +0200 |
| Subject | Small Device C Compiler 3.6.0 released |
| Message-ID | <njkqfd$imt$1@solani.org> |
A few hours ago, SDCC 3.6.0 was released. SDCC is a free C implementation targeting various 8-bit architectures. In particular, it targets architectures that would be hard to target for GCC or LLVM: Few registers, highly irregular register and instruction sets, etc. With this release SDCC improved standard compliance (all the mandatory features introduced in C95 and C11 should be there now). The default language dialect is now C11 with some SDCC-specific stuff. But there are still some gaps wrt. features from the C90 and C99 standards. Most notably: union and struct can not be assigned, passed or returned; variable declarations may only appear where C90 allows them; no standard-compliant double or long double; no compound literals. > Today a new release of SDCC was made. We are now at version 3.6.0. > You can get it at: > http://sourceforge.net/projects/sdcc/files/ > > So what's new? > * Merged upstream binutils 2.25 > * New memory management with lower overhead > * Changed default language dialect to --std-sdcc11 > * Diagnostic for missing type specifier: No implicit int outside of C90 > mode anymore > * C11 generic selections > * char type is now unsigned by default (old behaviour can be restored > using --fsigned-char) > * Character constants are now of type int instead of char. > * ISO C95 and ISO C11 wide character constants > * ISO C95 and ISO C11 wide string literals > * Basic standard library support for wide characters: c16rtomb(), > mbrtoc16(), mbsinit(), mbtowc(), mbrlen(), mbrtoc32, c32rtomb(), > mbrtowc(), wcrtomb(), mblen(), wctomb() > * Treat all ports the same in the manual (i.e. mcs51-specific stuff is now > clearly described as such) > * Reorganized interrupt handling for z80, z180, r2k, r3ka, tlcs90, gbz80 > backends > * Workaround for stm8 division hardware bug > * ELF/DWARF support for stm8 > * Output symbol table for ELF > * pic16 port now uses standard-compliant crt0iz that initializes static > and globals to 0 by default > > And of course numerous feature requests and bug fixes are included as well. > > Once again I hope you will enjoy using this new release. > > Maarten Brock > SDCC 3.6.0 Release Manager Alan Cox' FUZIX uses SDCC as the reference platform, and makes relatively heavy use of long long, a data type otherwise not used much in embedded software. This resulted in some long long bugs being found and fixed, and thus improved long long support in SDCC a lot. Philipp P.S.: Two years ago, in SDCC 3.5.0, support for the STM8 appeared in SDCC.A comparison of current C compilers for the STM8 can be found at: http://colecovision.eu/stm8/compilers.shtml SDCC is already doing well in standard compliance, host OS support, license. But size and speed of the generated code need to improve further. P.P.S.: At FOSDEM 2015, there was a talk on SDCC, that should still give a good introduction today (https://archive.fosdem.org/2015/schedule/event/8bit_compiler/).
[toc] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-13 08:47 +0200 |
| Message-ID | <njlkup$1s0$1@dont-email.me> |
| In reply to | #88990 |
On 13/06/16 01:15, Philipp Klaus Krause wrote: > A few hours ago, SDCC 3.6.0 was released. SDCC is a free C > implementation targeting various 8-bit architectures. In particular, it > targets architectures that would be hard to target for GCC or LLVM: Few > registers, highly irregular register and instruction sets, etc. Congratulations on the release! It is not a compiler I have used myself, because the chips I use /are/ supported by gcc, but I think it is a good think for the embedded community that this compiler exists. > > With this release SDCC improved standard compliance (all the mandatory > features introduced in C95 and C11 should be there now). The default > language dialect is now C11 with some SDCC-specific stuff. But there are > still some gaps wrt. features from the C90 and C99 standards. Most > notably: union and struct can not be assigned, passed or returned; > variable declarations may only appear where C90 allows them; no > standard-compliant double or long double; no compound literals. > Surely it should be a small matter to support mixing variable declarations and statements? If I were to use SDCC, the lack of this feature would be extremely annoying - I would consider it far more important than wide character support or C11 generics. Supporting it should be a minor issue in the parser and early stages of the compiler - when you see something like "int x = 123;" after a statement in a block, you treat it as "int x;" at the head of the block, and do a normal "x = 123;". Other than that, I am glad to see steady progress towards standard C support here - though it is a bit "marketing speak" to boast that all the /new/ mandatory features of C95 (which no one ever used) and C11 are supported, but some important /old/ features of C90 and C99 are not yet in place.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-13 02:07 -0700 |
| Message-ID | <5a890a92-c3ef-4086-8290-62d105702512@googlegroups.com> |
| In reply to | #88999 |
On Monday, June 13, 2016 at 7:47:59 AM UTC+1, David Brown wrote: > On 13/06/16 01:15, Philipp Klaus Krause wrote: > > Surely it should be a small matter to support mixing variable > declarations and statements? If I were to use SDCC, the lack of this > feature would be extremely annoying - I would consider it far more > important than wide character support or C11 generics. Supporting it > should be a minor issue in the parser and early stages of the compiler - > when you see something like "int x = 123;" after a statement in a block, > you treat it as "int x;" at the head of the block, and do a normal "x = > 123;". > Not necessarily. If all declarations are at the start of the block, the logic is "get the variables in scope, assign operations and state to those variables, write out code that achieves the final state (assuming no calls or side effects), finish block". If declarations are mixed, then you've got to mix the first two operations. Whist not entailing a total rewrite, it could mean rather deep changes to your logic to build a graph of variables and transitions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-13 13:48 +0200 |
| Message-ID | <njm6if$tt8$1@dont-email.me> |
| In reply to | #89000 |
On 13/06/16 11:07, Malcolm McLean wrote:
> On Monday, June 13, 2016 at 7:47:59 AM UTC+1, David Brown wrote:
>> On 13/06/16 01:15, Philipp Klaus Krause wrote:
>>
>> Surely it should be a small matter to support mixing variable
>> declarations and statements? If I were to use SDCC, the lack of this
>> feature would be extremely annoying - I would consider it far more
>> important than wide character support or C11 generics. Supporting it
>> should be a minor issue in the parser and early stages of the compiler -
>> when you see something like "int x = 123;" after a statement in a block,
>> you treat it as "int x;" at the head of the block, and do a normal "x =
>> 123;".
>>
> Not necessarily.
> If all declarations are at the start of the block, the logic is "get the variables
> in scope, assign operations and state to those variables, write out code
> that achieves the final state (assuming no calls or side effects), finish
> block". If declarations are mixed, then you've got to mix the first two
> operations. Whist not entailing a total rewrite, it could mean rather
> deep changes to your logic to build a graph of variables and transitions.
>
Can you think of any reason why code like this:
{
int x;
foo1();
x = foo2();
int y = bar(x);
bar2(y);
bar3(x, y);
}
cannot be simply transformed into:
{
int x;
int y;
foo1();
x = foo2();
y = bar(x);
bar2(y);
bar3(x, y);
}
The only case that I can think of is if you have a VLA whose size
depends on calculations earlier in the block. And I don't think it
would be unreasonable to say that this particular case is not supported yet.
(It would not be legal in normal C to split "const int x = y;" into
"const int x;" at the start of the block and "x = y;" later on. But the
compiler could easily "cheat" internally in its implementation.)
Other than that, moving definitions or declarations of variables to the
start of the block should be a simple matter within the front end of the
compiler - thus avoiding any mixing.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-13 10:15 +0100 |
| Message-ID | <njltk7$t36$1@dont-email.me> |
| In reply to | #88999 |
On 13/06/2016 07:47, David Brown wrote:
> On 13/06/16 01:15, Philipp Klaus Krause wrote:
>> A few hours ago, SDCC 3.6.0 was released. SDCC is a free C
> Surely it should be a small matter to support mixing variable
> declarations and statements? If I were to use SDCC, the lack of this
> feature would be extremely annoying - I would consider it far more
> important than wide character support or C11 generics. Supporting it
> should be a minor issue in the parser and early stages of the compiler -
> when you see something like "int x = 123;" after a statement in a block,
> you treat it as "int x;" at the head of the block, and do a normal "x =
> 123;".
I don't think you can. Here:
{int x=10;
{ printf("x1=%d\n",x);
int x=20;
printf("x2=%d\n",x);
}
}
the first printf needs to see the outer x. That won't work if the 'int
x=20' is placed at the start of the inner block.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-13 13:54 +0200 |
| Message-ID | <njm6u5$v6g$1@dont-email.me> |
| In reply to | #89001 |
On 13/06/16 11:15, BartC wrote:
> On 13/06/2016 07:47, David Brown wrote:
>> On 13/06/16 01:15, Philipp Klaus Krause wrote:
>>> A few hours ago, SDCC 3.6.0 was released. SDCC is a free C
>
>> Surely it should be a small matter to support mixing variable
>> declarations and statements? If I were to use SDCC, the lack of this
>> feature would be extremely annoying - I would consider it far more
>> important than wide character support or C11 generics. Supporting it
>> should be a minor issue in the parser and early stages of the compiler -
>> when you see something like "int x = 123;" after a statement in a block,
>> you treat it as "int x;" at the head of the block, and do a normal "x =
>> 123;".
>
> I don't think you can. Here:
>
>
> {int x=10;
>
> { printf("x1=%d\n",x);
> int x=20;
> printf("x2=%d\n",x);
> }
> }
>
> the first printf needs to see the outer x. That won't work if the 'int
> x=20' is placed at the start of the inner block.
>
That is solved by a simple rename.
I don't know anything about how the SDCC is actually implemented, but I
have a hard time understanding that developers who are capable of
putting together such a complicated and quality compiler implementation
as SDCC would have trouble supporting mixed declarations and statements.
An alternative solution, which would solve your worry here (as well as
the VLA and const issues I mentioned in another post), would be that
every time the compiler sees a declaration following a statement, it
simply inserts a { before the declaration and adds an extra } at the
next }. Again, it is possible that I am missing some special cases here
- but I think such tricks should be relatively simple to implement and
would give the compiler significantly better C99 support.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-13 13:30 +0100 |
| Message-ID | <njm90p$766$1@dont-email.me> |
| In reply to | #89012 |
On 13/06/2016 12:54, David Brown wrote:
> On 13/06/16 11:15, BartC wrote:
>> On 13/06/2016 07:47, David Brown wrote:
>>> Surely it should be a small matter to support mixing variable
>>> declarations and statements? If I were to use SDCC, the lack of this
>>> feature would be extremely annoying - I would consider it far more
>>> important than wide character support or C11 generics. Supporting it
>>> should be a minor issue in the parser and early stages of the compiler -
>>> when you see something like "int x = 123;" after a statement in a block,
>>> you treat it as "int x;" at the head of the block, and do a normal "x =
>>> 123;".
>>
>> I don't think you can. Here:
>>
>>
>> {int x=10;
>>
>> { printf("x1=%d\n",x);
>> int x=20;
>> printf("x2=%d\n",x);
>> }
>> }
>>
>> the first printf needs to see the outer x. That won't work if the 'int
>> x=20' is placed at the start of the inner block.
>>
>
> That is solved by a simple rename.
By the programmer, or the compiler?
The former would be unacceptable (you might as well ask him or her not
to use mixed statements and declarations in the first place).
With the compiler, this is still part of the extra difficulty of
accommodating this feature.
> I don't know anything about how the SDCC is actually implemented, but I
> have a hard time understanding that developers who are capable of
> putting together such a complicated and quality compiler implementation
> as SDCC would have trouble supporting mixed declarations and statements.
>
> An alternative solution, which would solve your worry here
It's not a worry; the language /requires/ the two x's in the printf
calls above to be distinct.
(as well as
> the VLA and const issues I mentioned in another post), would be that
> every time the compiler sees a declaration following a statement, it
> simply inserts a { before the declaration and adds an extra } at the
> next }. Again, it is possible that I am missing some special cases here
> - but I think such tricks should be relatively simple to implement and
> would give the compiler significantly better C99 support.
Maybe. Internally it would be a pretty ugly thing to do though:
switch (x) {
case 1:
{int y;
case 2:
{int z;
default: ;
}}
}
Here you have the artificial blocks making nonsense of the perceived
structure of the switch statement.
Then, here:
{ int z;
z=0;
int w[]={..........}, // hundreds of lines of data
z;
presumably you would report the duplicate z first rather than just have
it in its own block. However, you don't see the second z until after
you've processed the considerable amount of code for w. At what point
does the compiler insert the extra block?
It gets messy.
(Also the "next }" is not so easy to find either: it's not the "}" at
end of the w data in my example! It would be the next unmatched "}". And
if the source has missing or superfluous } anyway, it can confuse matters.)
I think you can't just say a feature is trivial to add until you've
successfully done it.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-13 15:26 +0200 |
| Message-ID | <njmc9u$j4f$1@dont-email.me> |
| In reply to | #89014 |
On 13/06/16 14:30, BartC wrote:
> On 13/06/2016 12:54, David Brown wrote:
>> On 13/06/16 11:15, BartC wrote:
>>> On 13/06/2016 07:47, David Brown wrote:
>
>>>> Surely it should be a small matter to support mixing variable
>>>> declarations and statements? If I were to use SDCC, the lack of this
>>>> feature would be extremely annoying - I would consider it far more
>>>> important than wide character support or C11 generics. Supporting it
>>>> should be a minor issue in the parser and early stages of the
>>>> compiler -
>>>> when you see something like "int x = 123;" after a statement in a
>>>> block,
>>>> you treat it as "int x;" at the head of the block, and do a normal "x =
>>>> 123;".
>>>
>>> I don't think you can. Here:
>>>
>>>
>>> {int x=10;
>>>
>>> { printf("x1=%d\n",x);
>>> int x=20;
>>> printf("x2=%d\n",x);
>>> }
>>> }
>>>
>>> the first printf needs to see the outer x. That won't work if the 'int
>>> x=20' is placed at the start of the inner block.
>>>
>>
>> That is solved by a simple rename.
>
> By the programmer, or the compiler?
The compiler, obviously. The point is that the compiler should let the
programmer use commonly used features of C99.
>
> The former would be unacceptable (you might as well ask him or her not
> to use mixed statements and declarations in the first place).
>
> With the compiler, this is still part of the extra difficulty of
> accommodating this feature.
My belief is that it is a very minor issue (in comparison to the vast
amounts of work needed for the rest of the compiler), and should be a
simple matter for the SDCC developers.
>
>> I don't know anything about how the SDCC is actually implemented, but I
>> have a hard time understanding that developers who are capable of
>> putting together such a complicated and quality compiler implementation
>> as SDCC would have trouble supporting mixed declarations and statements.
>>
>> An alternative solution, which would solve your worry here
>
> It's not a worry; the language /requires/ the two x's in the printf
> calls above to be distinct.
>
> (as well as
>> the VLA and const issues I mentioned in another post), would be that
>> every time the compiler sees a declaration following a statement, it
>> simply inserts a { before the declaration and adds an extra } at the
>> next }. Again, it is possible that I am missing some special cases here
>> - but I think such tricks should be relatively simple to implement and
>> would give the compiler significantly better C99 support.
>
> Maybe. Internally it would be a pretty ugly thing to do though:
>
> switch (x) {
> case 1:
> {int y;
> case 2:
> {int z;
> default: ;
> }}
> }
>
> Here you have the artificial blocks making nonsense of the perceived
> structure of the switch statement.
It is only an internal mechanism - I don't mean that the SDCC folks
should include some sort of pre-processor that literally adds { and }
characters to the code!
>
> Then, here:
>
> { int z;
> z=0;
> int w[]={..........}, // hundreds of lines of data
> z;
>
> presumably you would report the duplicate z first rather than just have
> it in its own block. However, you don't see the second z until after
> you've processed the considerable amount of code for w. At what point
> does the compiler insert the extra block?
{ int z;
z=0;
{ // Add an extra open-block here
int w[]={..........}, // hundreds of lines of data
z;
} // Add an extra close-block here
>
> It gets messy.
I can't see why it would be particularly messy. It makes no difference
to the logic if there is one line of data or hundreds.
>
> (Also the "next }" is not so easy to find either: it's not the "}" at
> end of the w data in my example! It would be the next unmatched "}". And
> if the source has missing or superfluous } anyway, it can confuse matters.)
Correct - I was inaccurate in saying "the next }". It should be the }
to close the current block. And that should be simple to find.
Remember, the compiler already has parsers and builds up some sort of
tree structure from the code anyway. It is not (as far as I understand
it) a simple line by line C-to-assembly translator.
>
> I think you can't just say a feature is trivial to add until you've
> successfully done it.
>
I have only made one domain-specific language, which was a long time
ago. It was not remotely C like - but it supported blocks and mixing
declarations and statements, because they were simple to do and very
useful in working with the language. I managed that fine as a newly
educated programmer, working in Visual Basic - while the SDCC developers
have long experience in compiler development.
If I were planning to develop a cross-platform multi-target C compiler
aimed at efficient code generation for a range of unpleasant small 8-bit
devices, and were listing up the top 50 subtasks in order of difficulty,
I really don't think mixing statements and declarations would make the
list. But if I were listing features that would be useful to users, it
would come high up - certainly /much/ higher than wide character support
or C11 generics, which are now supported by SDCC.
Of course, my opinions here are not based on experience with the SDCC
code - unless the OP responds, or we take it up with the SDCC developers
directly, this is just idle speculation.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-13 17:48 +0100 |
| Message-ID | <njmo5h$ami$1@dont-email.me> |
| In reply to | #89016 |
On 13/06/2016 14:26, David Brown wrote: > On 13/06/16 14:30, BartC wrote: >> With the compiler, this is still part of the extra difficulty of >> accommodating this feature. > > My belief is that it is a very minor issue It sounds like it ought to be, but I would find it challenging. (That is, having unlimited, arbitrary nested scopes, full of names with anonymous owners, and having mixed statements and declarations where a name scope can start halfway through a block because the first half has a different version of the same name! I can do mixed statements and declarations but where the scope of a declared name is always a single scope: the current function body. Function bodies are supposed to kept small, right? Then why are so many block scopes needed?) > Of course, my opinions here are not based on experience with the SDCC > code - unless the OP responds, or we take it up with the SDCC developers > directly, this is just idle speculation. Perhaps you can tell them how to do it then! (There might be other reasons than difficulty, such as reluctance to mess about with a part of the project that is currently working fine.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-13 10:05 -0700 |
| Message-ID | <b1f9385c-9195-46ed-81c8-845b2b4b42e4@googlegroups.com> |
| In reply to | #89024 |
On Monday, June 13, 2016 at 11:48:58 AM UTC-5, Bart wrote: > I can do mixed statements and declarations but where the scope of a > declared name is always a single scope: the current function body. > Function bodies are supposed to kept small, right? Then why are so many > block scopes needed?) If a function calls a function that will need lots of stack space, and will need an automatic variable whose lifetime need not bracket that function call, it may be possible to adjust the stack pointer entering a block that defines new variables and adjust it back when leaving such a block. I don't know to what extent compilers have done this or do it (I don't think it's fashionable today, but stack space used to be at more of a premium than it is now). How does SDCC handle such things? My inclination is that it would probably be most useful to have a command-line option to set the maximum "excess" stack usage that would be considered tolerable surrounding a function call, and hoist variable definitions from inner blocks in cases where the added stack usage would be tolerable, but allocate/release the stack storage in cases where doing so would reduce a nested call's stack space requirement considerably.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-13 20:03 +0100 |
| Message-ID | <njn026$alr$1@dont-email.me> |
| In reply to | #89025 |
On 13/06/2016 18:05, supercat@casperkitty.com wrote: > On Monday, June 13, 2016 at 11:48:58 AM UTC-5, Bart wrote: >> I can do mixed statements and declarations but where the scope of a >> declared name is always a single scope: the current function body. >> Function bodies are supposed to kept small, right? Then why are so many >> block scopes needed?) > > If a function calls a function that will need lots of stack space, and will > need an automatic variable whose lifetime need not bracket that function call, > it may be possible to adjust the stack pointer entering a block that defines > new variables and adjust it back when leaving such a block. I don't know to > what extent compilers have done this or do it (I don't think it's fashionable > today, but stack space used to be at more of a premium than it is now). But this would just another optimisation that a compiler can choose to do by itself without requiring programmers to go out of their way just so that can provide hints. (And some of whom will then take advantage by having half a dozen large local arrays in separate scopes. Now the compiler /has/ to mess about with stack allocation on each block entry and exit, to save stack space, instead of just allocating everything on function entry.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-13 14:06 -0700 |
| Message-ID | <f705fae4-f1a8-4236-a852-73e8198da49d@googlegroups.com> |
| In reply to | #89033 |
On Monday, June 13, 2016 at 2:03:41 PM UTC-5, Bart wrote: > But this would just another optimisation that a compiler can choose to > do by itself without requiring programmers to go out of their way just > so that can provide hints. The C language was designed to be amenable to a very simple compilation process. A one-pass compiler could accommodate mid-function variable creation by unconditionally adjusting the stack pointer on block entry and setting it back on exit. A programmer wanting to avoid having such operations performed in the middle of a function could simply hoist variables to the top of the function manually. Consolidating such allocations in cases where doing so would not overly affect stack usage could still be done with a one-pass compiler if its output was feeding a two-pass assembler (the code at the start of a function to adjust the stack pointer would adjust it by an amount specified by a label defined at the end of that function). Trying to make inferences about variable lifetimes based upon usage would require a much more sophisticated compiler. Further, no matter how sophisticated a compiler might be, I don't know of any way of saying that the contents of an array of unsigned char don't need to be maintained between iterations of a loop except by declaring the array in a nested scope. Accessing an element which has not been written since the start of the block where it is declared does not invoke Undefined Behavior, but merely yields an Unspecified value. If the array's lifetime couldn't end within the loop, there would be no way of saying that it would be acceptable for a read near the start of the loop body to yield an Unspecified value even if that element had been written in an earlier iteration in the loop.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-13 22:21 +0100 |
| Message-ID | <njn84g$c94$1@dont-email.me> |
| In reply to | #89044 |
On 13/06/2016 22:06, supercat@casperkitty.com wrote:
> On Monday, June 13, 2016 at 2:03:41 PM UTC-5, Bart wrote:
>> But this would just another optimisation that a compiler can choose to
>> do by itself without requiring programmers to go out of their way just
>> so that can provide hints.
>
> The C language was designed to be amenable to a very simple compilation
> process. A one-pass compiler could accommodate mid-function variable
> creation by unconditionally adjusting the stack pointer on block entry
> and setting it back on exit.
The trouble is that 'mid-function' can be a constantly altering point,
unlike the boundary between declarations at the start and the rest of code.
It's not so much mixing declarations, but the need to introduce
block-scopes with {,}, otherwise the tricks with stack allocation can't
be done.
And the body of a function under development is always changing, so that
suddenly, a variable existing in one scope is now in too narrow a scope,
or a too broad one, or is not visible when it should be visible, or
you've created a shadow you don't want, or what should be the same
variable is now in two separate scopes...
Just put the declarations at the top out of the bloody way! Then you can
see what you're doing too, as can the reader of the code when it's finished.
> A programmer wanting to avoid having such
> operations performed in the middle of a function could simply hoist
> variables to the top of the function manually. Consolidating such
> allocations in cases where doing so would not overly affect stack usage
It would be interesting to see what actual difference that makes. But I
suspect most people like to mix up declarations because they want to,
not for reasons of performance.
> Further, no matter how sophisticated a compiler might be, I don't know of
> any way of saying that the contents of an array of unsigned char don't
> need to be maintained between iterations of a loop except by declaring
> the array in a nested scope.
Then it runs the risk of the array actually be reallocated each time.
(But not a good example as, if the plan is to iterate over the elements
in that loop, the declaration should be outside the loop.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2016-06-13 22:59 +0200 |
| Message-ID | <njn6sf$p5t$2@solani.org> |
| In reply to | #89025 |
On 13.06.2016 19:05, supercat@casperkitty.com wrote: > On Monday, June 13, 2016 at 11:48:58 AM UTC-5, Bart wrote: >> I can do mixed statements and declarations but where the scope of a >> declared name is always a single scope: the current function body. >> Function bodies are supposed to kept small, right? Then why are so many >> block scopes needed?) > > If a function calls a function that will need lots of stack space, and will > need an automatic variable whose lifetime need not bracket that function call, > it may be possible to adjust the stack pointer entering a block that defines > new variables and adjust it back when leaving such a block. I don't know to > what extent compilers have done this or do it (I don't think it's fashionable > today, but stack space used to be at more of a premium than it is now). > > How does SDCC handle such things? It tries to allocate non-overlapping silt variables to the same stack locations to save stack space. Then the required amount of stack space is allocated at function entry and released at function exit. The only exception is very short-term stack usage, e.g. some push/pop instructions with just a few other instructions in between. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-13 11:19 -0700 |
| Message-ID | <lneg813q9z.fsf@kst-u.example.com> |
| In reply to | #89024 |
BartC <bc@freeuk.com> writes:
> On 13/06/2016 14:26, David Brown wrote:
>> On 13/06/16 14:30, BartC wrote:
>>> With the compiler, this is still part of the extra difficulty of
>>> accommodating this feature.
>>
>> My belief is that it is a very minor issue
>
> It sounds like it ought to be, but I would find it challenging.
>
> (That is, having unlimited, arbitrary nested scopes, full of names with
> anonymous owners, and having mixed statements and declarations where a
> name scope can start halfway through a block because the first half has
> a different version of the same name!
Even without mixed declarations and statements, C already permits
"unlimited, arbitrary nested scopes, full of names with anonymous
owners".
You can't have two declarations in the same block with the same name.
You can have a declaration in an inner scope that hides a declaration
with the same name in an outer scope:
{
int foo;
{
int foo;
/* ... */
}
}
Note that this is perfectly valid C90. It's even valid in the version
of C described in K&R1.
The *scope* of a declaration in a block starts at the declaration an
extends to the end of the block. Scope is about the compile-time
visibility of a name. The *lifetime* of, for example, the outer `foo`
above starts on entry to the enclosing block, but the name doesn't
become visible until the point of declaration.
> I can do mixed statements and declarations but where the scope of a
> declared name is always a single scope: the current function body.
> Function bodies are supposed to kept small, right? Then why are so many
> block scopes needed?)
Are you talking about some language other than C?
[...]
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-13 21:32 +0100 |
| Message-ID | <njn59l$113$1@dont-email.me> |
| In reply to | #89028 |
On 13/06/2016 19:19, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> I can do mixed statements and declarations but where the scope of a >> declared name is always a single scope: the current function body. >> Function bodies are supposed to kept small, right? Then why are so many >> block scopes needed?) > > Are you talking about some language other than C? I'm talking about implementing any such language. Doing it C's way I would find much harder. (And my other remark questions why it needs to be like that at all.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-13 19:32 +0100 |
| Message-ID | <874m8x2b3m.fsf@bsb.me.uk> |
| In reply to | #89024 |
BartC <bc@freeuk.com> writes: > On 13/06/2016 14:26, David Brown wrote: >> On 13/06/16 14:30, BartC wrote: > > >>> With the compiler, this is still part of the extra difficulty of >>> accommodating this feature. >> >> My belief is that it is a very minor issue > > It sounds like it ought to be, but I would find it challenging. > > (That is, having unlimited, arbitrary nested scopes, full of names > with anonymous owners, and having mixed statements and declarations > where a name scope can start halfway through a block because the first > half has a different version of the same name! Did you once work as a political speech writer? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-13 20:28 +0100 |
| Message-ID | <njn1hj$gfa$1@dont-email.me> |
| In reply to | #89032 |
On 13/06/2016 19:32, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 13/06/2016 14:26, David Brown wrote:
>>> On 13/06/16 14:30, BartC wrote:
>>
>>
>>>> With the compiler, this is still part of the extra difficulty of
>>>> accommodating this feature.
>>>
>>> My belief is that it is a very minor issue
>>
>> It sounds like it ought to be, but I would find it challenging.
>>
>> (That is, having unlimited, arbitrary nested scopes, full of names
>> with anonymous owners, and having mixed statements and declarations
>> where a name scope can start halfway through a block because the first
>> half has a different version of the same name!
>
> Did you once work as a political speech writer?
No; why?
If you mean you can't understand what I'm on about, I'm referring to this:
int a; {X.... int a; Y....}
The scope of the second 'int a' is not just limited to the X-Y block,
but only to the Y-half, as the X-half has the first 'int a' in scope.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-13 12:45 -0700 |
| Message-ID | <lnshwg3mb9.fsf@kst-u.example.com> |
| In reply to | #89035 |
BartC <bc@freeuk.com> writes:
[...]
> If you mean you can't understand what I'm on about, I'm referring to this:
>
> int a; {X.... int a; Y....}
>
> The scope of the second 'int a' is not just limited to the X-Y block,
> but only to the Y-half, as the X-half has the first 'int a' in scope.
Correct. And if X consists entirely of declarations, then your example
is valid C89 (and quite possibly valid K&R C).
For example:
#include <stdio.h>
int main(void) {
int a = 10;
{
int dummy = printf("a = %d\n", a);
int a = 20;
printf("a = %d\n", a);
}
printf("a = %d\n", a);
return 0;
}
Output:
a = 10
a = 20
a = 10
Can you explain the point you're trying to make?
"Shadowing" of declarations (giving a declaration in an inner scope the
same name as a declaration in an outer scope) is permitted, and it has
been for a very long time, but it's usually not a great idea.
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-13 21:29 +0100 |
| Message-ID | <njn52s$voc$1@dont-email.me> |
| In reply to | #89036 |
On 13/06/2016 20:45, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> If you mean you can't understand what I'm on about, I'm referring to this:
>>
>> int a; {X.... int a; Y....}
>>
>> The scope of the second 'int a' is not just limited to the X-Y block,
>> but only to the Y-half, as the X-half has the first 'int a' in scope.
> Can you explain the point you're trying to make?
That mixed declarations and statements, /as defined in C/, are an
inelegant feature. Probably fiddly to implement too, although I don't
know if that's why they're not in SDCC as most C compilers manage it,
and SDCC is not a small system.
(I had it mixed up with the Smaller C compiler briefly, a much simpler
project.)
> "Shadowing" of declarations (giving a declaration in an inner scope the
> same name as a declaration in an outer scope) is permitted, and it has
> been for a very long time, but it's usually not a great idea.
But the way C declarations and scopes work make it easier for such
shadowing to be done inadvertently (although no doubt there is some gcc
option to detect that).
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 1 of 19 [1] 2 3 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web