Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #96073 > unrolled thread
| Started by | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| First post | 2016-11-08 22:17 +0800 |
| Last post | 2016-11-08 18:25 -0800 |
| Articles | 20 on this page of 296 — 29 participants |
Back to article view | Back to comp.lang.c
Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:17 +0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 14:25 +0000
[OI] chat "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:26 +0800
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:29 +0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-08 20:48 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 11:51 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-08 21:12 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 20:43 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 13:20 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:04 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:04 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-08 14:30 -0800
Re: Compiler design in C? Noob <root@127.0.0.1> - 2016-11-12 01:25 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-11 17:08 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-12 07:52 +0000
Re: Compiler design in C? Noob <root@127.0.0.1> - 2016-11-12 15:18 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:00 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-08 22:33 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 22:56 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-08 23:40 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 19:54 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:47 -0600
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:46 +0000
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:19 -0500
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:46 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-08 23:00 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 11:30 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 11:14 +0000
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-09 19:15 +0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 13:59 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:15 -0800
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 05:44 -0600
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:57 -0800
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:19 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 07:59 -0500
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 13:13 +0000
Re: Compiler design in C? Robert Spanjaard <spamtrap@arumes.com> - 2016-11-09 14:06 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 14:46 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 08:33 -0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 17:28 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:22 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 10:55 -0500
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-10 00:01 +0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 17:11 +0000
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 13:37 -0500
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:16 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 22:36 -0500
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 23:40 -0600
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 08:49 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 14:02 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 05:40 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 15:47 +0100
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-09 19:32 +0300
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:34 -0600
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-10 00:43 +0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 20:00 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-09 13:25 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 11:18 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-09 19:57 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 12:10 -0800
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 20:32 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:56 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:04 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:16 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:18 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:29 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 21:35 +0100
Re: Compiler design in C? Melzzzzz <mel@zzzzz.com> - 2016-11-09 21:55 +0100
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 15:49 -0600
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 11:31 +0100
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 10:42 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:03 +0100
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-10 15:37 +0300
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 08:13 -0800
Re: Compiler design in C? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-11-10 20:22 +0300
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 12:29 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:02 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 20:24 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 12:18 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-10 12:36 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:43 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:18 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 21:06 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:12 +0100
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-09 22:18 +0000
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-09 14:35 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:10 +0100
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-09 21:28 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-09 21:32 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:36 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 07:10 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 20:32 +1300
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:05 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 08:06 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:14 +0000
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 08:33 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 09:20 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 02:15 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 10:29 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 02:58 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:09 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:25 -0800
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:35 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:29 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 21:59 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:10 +1300
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:27 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:42 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:46 +1300
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 16:27 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:47 +0100
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-10 19:29 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 09:17 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 13:45 -0800
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:58 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 16:31 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 21:41 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 20:57 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:16 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 13:35 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:43 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 21:58 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 14:28 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 14:47 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 22:51 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:27 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-10 15:57 -0800
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:38 +1300
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 22:46 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-11 10:51 +1300
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 22:04 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:18 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-11 05:45 +0000
Re: Compiler design in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-14 00:27 -0600
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-14 21:24 +1300
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-14 09:45 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 21:54 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:19 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-11 05:47 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-11 00:22 +0100
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:01 -0500
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:49 -0800
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:02 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:10 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:17 -0800
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 06:56 -0500
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:05 -0800
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 08:09 -0500
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-11 16:56 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 07:37 +0000
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 08:07 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 22:43 +1300
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 09:50 +0000
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 11:43 +0000
Re: Compiler design in C? gwowen <gwowen@gmail.com> - 2016-11-10 06:36 -0800
Re: Compiler design in C? BartC <bc@freeuk.com> - 2016-11-10 15:05 +0000
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 16:25 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:14 +0100
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:23 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 23:01 +0100
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:35 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 08:08 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 20:30 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 12:20 -0800
Re: Compiler design in C? me <crisdunbar@gmail.com> - 2016-11-10 13:48 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 22:53 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-10 14:38 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 09:52 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-11 06:09 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-11 21:54 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-11 14:10 -0800
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-12 14:17 +0100
Re: Compiler design in C? supercat <flatfinger@casperkitty.com> - 2016-11-12 10:42 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-12 19:04 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-12 16:13 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 00:28 +0000
Re: Compiler design in C? supercat <flatfinger@casperkitty.com> - 2016-11-12 17:36 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 10:20 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-13 14:37 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-13 22:42 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-13 18:26 -0500
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 07:08 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-13 15:52 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 07:10 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 07:33 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 18:42 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 11:42 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-14 19:49 +0000
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-14 12:24 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-14 12:32 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-16 08:18 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-16 08:50 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-17 12:02 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-17 12:22 -0800
Re: Compiler design in C? Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-16 10:35 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-13 10:52 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 14:28 -0800
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-09 13:27 -0800
Re: Compiler design in C? Robert Spanjaard <spamtrap@arumes.com> - 2016-11-09 23:43 +0100
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 17:57 +1300
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-09 21:26 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:39 +0000
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:54 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 15:08 -0800
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:50 +0000
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-08 13:44 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:07 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:15 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:26 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:44 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 14:48 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 15:34 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 15:57 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:17 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:18 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-08 16:24 -0800
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-08 19:59 -0500
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-09 15:44 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-10 00:51 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-09 15:59 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:08 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-11 14:41 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:55 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:21 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:32 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-11 16:11 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:12 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:03 +0000
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:21 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:30 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-12 21:51 +0100
Re: Compiler design in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-12 13:16 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-12 23:04 +0100
Re: Compiler design in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-12 14:12 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:05 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:43 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:49 -0800
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 14:33 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 22:45 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-12 18:14 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-13 00:12 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-13 11:38 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 00:44 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-14 11:45 -0500
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-14 09:42 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 14:14 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 22:59 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:15 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 19:11 +0000
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-14 15:40 -0500
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-14 20:45 +0000
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-12 17:20 -0800
Re: Compiler design in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-09 19:49 -0500
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:14 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-11 15:28 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 00:45 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:40 -0800
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-12 11:42 -0800
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-12 20:18 +0000
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-14 15:23 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-13 11:46 +0100
Re: Compiler design in C? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-10 16:22 -0800
Re: Compiler design in C? jameskuyper@verizon.net - 2016-11-11 16:52 -0800
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-08 14:57 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 00:13 +0100
Re: Compiler design in C? Keith Thompson <kst-u@mib.org> - 2016-11-08 15:46 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-08 20:04 -0500
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:23 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 08:01 -0500
Re: Compiler design in C? John Bode <jfbode1029@gmail.com> - 2016-11-09 12:27 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-09 22:32 +0100
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 06:43 +0000
Re: Compiler design in C? Ian Collins <ian-news@hotmail.com> - 2016-11-10 20:30 +1300
Re: Compiler design in C? Gareth Owen <gwowen@gmail.com> - 2016-11-10 07:35 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:12 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-10 11:19 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 03:46 -0800
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-10 04:01 -0800
Re: Compiler design in C? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-11 16:04 +0000
Re: Compiler design in C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-11 08:36 -0800
Re: Compiler design in C? Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-09 17:41 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 13:58 +0100
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 08:10 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-09 10:35 -0800
Re: Compiler design in C? supercat@casperkitty.com - 2016-11-08 14:21 -0800
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 23:28 +0100
Re: Compiler design in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-08 22:47 +0000
Re: Compiler design in C? Richard Heathfield <rjh@cpax.org.uk> - 2016-11-10 09:52 +0000
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 07:33 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 14:03 +0100
Re: Compiler design in C? James Kuyper <jameskuyper@verizon.net> - 2016-11-10 08:15 -0500
Re: Compiler design in C? David Brown <david.brown@hesbynett.no> - 2016-11-10 14:47 +0100
Re: Compiler design in C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 22:55 +0100
Re: Compiler design in C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-09 19:44 +0800
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-08 18:18 -0800
Re: Compiler design in C? luser droog <luser.droog@gmail.com> - 2016-11-08 18:25 -0800
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-13 18:26 -0500 |
| Message-ID | <6967f10d-555c-55ca-a5c8-9f2ca24a7446@verizon.net> |
| In reply to | #96514 |
On 11/13/2016 05:42 PM, Gareth Owen wrote:
...
> Under your translating compiler, should the following two programs
> compile to different assembler?
>
> int main()
> {
> int x = 3;
> int y = 6;
> printf("%d\n",x+y);
> }
>
> int main()
> {
> puts("7");
> }
>
> Is the former obliged to store, load and then add x and y?
Was that 7 supposed to be a 9? If not, I don't quite see the point of
the question.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-14 07:08 +0000 |
| Message-ID | <87zil2h72y.fsf@gmail.com> |
| In reply to | #96515 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 11/13/2016 05:42 PM, Gareth Owen wrote:
> ...
>> Under your translating compiler, should the following two programs
>> compile to different assembler?
>>
>> int main()
>> {
>> int x = 3;
>> int y = 6;
>> printf("%d\n",x+y);
>> }
>>
>> int main()
>> {
>> puts("7");
>> }
>>
>> Is the former obliged to store, load and then add x and y?
>
> Was that 7 supposed to be a 9? If not, I don't quite see the point of
> the question.
No, the 6 was supposed to be a 4
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-13 15:52 -0800 |
| Message-ID | <65a37d5b-1c93-41ad-95f4-321c05397d43@googlegroups.com> |
| In reply to | #96514 |
On Sunday, November 13, 2016 at 4:42:44 PM UTC-6, gwowen wrote:
> Under your translating compiler, should the following two programs
> compile to different assembler?
>
> int main()
> {
> int x = 3;
> int y = 6;
> printf("%d\n",x+y);
> }
>
> int main()
> {
> puts("7");
> }
>
> Is the former obliged to store, load and then add x and y?
Since neither x nor y has its address taken, a compiler could easily
recognize that there is no possible means by which x can hold anything other
than 3, or y can hold anything other than 6, when the printf is executed.
So replacing the expression x+y with 9 would not be an observable change in
any respect (replacing it with 7, of course, would be invalid).
As to whether the implementation could further replace the printf with a puts,
that would depend upon how it defined those functions. Since the amount of
code for a full-fledged printf would exceed the total code capacity of some
small microcontrollers, implementations targeting small systems often allow
a programmer various ways of customizing them or substituting user-written
alternatives. The indicated substitution would be compatible with some such
documented features, but not others.
To offer a somewhat more illustrative example, if an implementation
documents that it may behave as though loads get consolidated with preceding
accesses or hoisted to the start of an enclosing loop, and stores may be
deferred until the next time the memory might be read (or abandoned if the
value will be destroyed before it is read), but operations will not be moved
across constructs that would suggest aliasing might occur, then given the
code:
float f1,f2,f3;
void foo(int *ip, float *fp)
{
int *ip2;
f1 = 1.0f; f2=2.0f; // A
*ip = 1;
f1+=1.0f; // B
ip2 = (int*)fp;
*ip2 = 2;
f2+=1.0f; // C
f3 = 1.0f; // D
*ip2 = 3;
return f1+f2+f3; // E
}
a compiler would be allowed to consolidate the load in B with the store in
A, since nothing happens between them that would suggest that anything would
happen to anything of type "float". Between A and C, however, a compiler
could easily see that a pointer of type "float*" is being used in a manner
that suggests aliasing, and thus would not be allowed to consolidate the
load in C with the store in A.
Note that for the described model, a compiler would not be required to keep
track of where pointer values came from in cases where it would be easier
to simply regard casts as implying potential accesses. Between D and
E, nothing is done with an float*, so a compiler would have no reason to
expect that the value read in E would not be the value written in E. If
between D and E there had been something like: ip = (int*)(float*)ip, that
would have given a compiler notice that code is likely using a float*, and
thus blocked that optimization.
Note that the above example assumes that the programmer and implementation
have agreed on an execution model that offers the compiler a lot more room
for optimization than the "mindless translator" model, but would still allow
a programmer to do just about anything that could be done under that model
provided that casts were placed in such a way as to be visible to the
compiler at appropriate times.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-14 07:10 +0000 |
| Message-ID | <87vavqh6zf.fsf@gmail.com> |
| In reply to | #96516 |
supercat@casperkitty.com writes: > On Sunday, November 13, 2016 at 4:42:44 PM UTC-6, gwowen wrote: > Since neither x nor y has its address taken, a compiler could easily > recognize that there is no possible means by which x can hold anything other > than 3, or y can hold anything other than 6, when the printf is executed. This entirely at odds with your previous description of how variable reads / writes should map to loads and stores.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-14 07:33 -0800 |
| Message-ID | <f4ce9545-c5e7-4db8-8e46-dcaafa2bbd01@googlegroups.com> |
| In reply to | #96528 |
On Monday, November 14, 2016 at 1:10:35 AM UTC-6, gwowen wrote:
> supercat writes:
>
> > On Sunday, November 13, 2016 at 4:42:44 PM UTC-6, gwowen wrote:
> > Since neither x nor y has its address taken, a compiler could easily
> > recognize that there is no possible means by which x can hold anything other
> > than 3, or y can hold anything other than 6, when the printf is executed.
>
> This entirely at odds with your previous description of how variable
> reads / writes should map to loads and stores.
They should behave *as if* they are being read from and written to memory.
I should perhaps have clarified that aspect more before leading on to ways
that programmers might waive such a precise behavioral specification, but
the key point is that even if one adopts a strict load-store model (btw,
N1570 notes that some implementations do that, but offers no way for source
code to test whether a given implementation promises to work that way) there
would still be room for a compiler to simplify code while producing the
same behaviors as would be produced under that model.
Some hardware platforms have, at least in the past, had separate caches for
the integer and floating-point units, and on those platforms the instruction
sequence
store floating point number at address X
store integer to address X
load floating-point number from address X
might not result in the floating-point load seeing the bits that were
written by the integer store; a compiler could force the hardware to see
the update by adding a "flush cache" instruction after the integer store,
but that would be much more expensive than a redundant load. On such a
platform, one shouldn't expect aliasing to work unless one explicitly
forces a cache flush either via some platform-dependent means or by
exploiting fact that C compilers would have to perform such flushes,
regardless of cost, when switching between using floating-point types and
any character pointers that might possibly alias them.
Most hardware platforms, of course, don't have separate integer and floating-
point caches, however, so a midnless decomposition of a program into loads,
stores, and computations would yield a definite behavior on most platforms
if a compiler were not allowed to reorder accesses for the purpose of
consolidating them.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-14 18:42 +0000 |
| Message-ID | <874m39ykb4.fsf@gmail.com> |
| In reply to | #96536 |
supercat@casperkitty.com writes:
> On Monday, November 14, 2016 at 1:10:35 AM UTC-6, gwowen wrote:
>> supercat writes:
>>
>> > On Sunday, November 13, 2016 at 4:42:44 PM UTC-6, gwowen wrote:
>> > Since neither x nor y has its address taken, a compiler could easily
>> > recognize that there is no possible means by which x can hold anything other
>> > than 3, or y can hold anything other than 6, when the printf is executed.
>>
>> This entirely at odds with your previous description of how variable
>> reads / writes should map to loads and stores.
>
> They should behave *as if* they are being read from and written to memory.
I don't understand.
How does
printf("7\n");
behave as if x=3 and y=4 have been read and written from memory
(in a sense not already covered by C's as if rule, which you reject as
not being the correct model for optimisation)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-14 11:42 -0800 |
| Message-ID | <5c07d760-4246-4ff1-b34c-1a32eb69d49b@googlegroups.com> |
| In reply to | #96555 |
On Monday, November 14, 2016 at 12:43:04 PM UTC-6, gwowen wrote:
> supercat writes:
>
> > On Monday, November 14, 2016 at 1:10:35 AM UTC-6, gwowen wrote:
> >> supercat writes:
> >>
> >> > On Sunday, November 13, 2016 at 4:42:44 PM UTC-6, gwowen wrote:
> >> > Since neither x nor y has its address taken, a compiler could easily
> >> > recognize that there is no possible means by which x can hold anything other
> >> > than 3, or y can hold anything other than 6, when the printf is executed.
> >>
> >> This entirely at odds with your previous description of how variable
> >> reads / writes should map to loads and stores.
> >
> > They should behave *as if* they are being read from and written to memory.
>
> I don't understand.
> How does
>
> printf("7\n");
>
> behave as if x=3 and y=4 have been read and written from memory
> (in a sense not already covered by C's as if rule, which you reject as
> not being the correct model for optimisation)
The behavior of a program which stores 3 in one temporary location and 4
in another, reads the contents of those locations, adds them, and prints
the sum, would be indistinguishable from that of a program which simply
outputs 7.
Given something like:
float f;
float test(uint32_t *p)
{
f = 1.0f;
*p = 0;
return f;
}
Under a pure load-store model, code should behave as though it performs
a floating-point store of the value 1.0f into f, then performs a pointer
load from the address of p, does a 32-bit integer store of 0 to that
address, and then performs a floating-point load from the address of f.
Most platforms define integer and floating-point operations as acting
directly upon bits in the same memory array, and so if "p" held the
address of f, the above code would yield 0.0f; otherwise it would yield
1.0f. If code was run on a platform where the integer unit has a cache
which is not shared with the floating-point unit, the function might
return 1.0f even if p holds the address of f, but such platforms are very
rare.
Except in cases where storage is observable or changeable via means outside
the compiler's control (typically indicated by accessing a "volatile"
variable, or calling outside code, either of which could trigger outside
accesses to everything that is reachable from an address which has been
passed to outside code or stored in a "volatile" variable observable), the
only effect of a store to a location is to affect the value yielded by
future loads, and the effect of a load is to yield the value set by a
previous store (or an arbitrary value if there is no previous store). If
a compiler can compute in side-effect free fashion the last value that was
stored to a location, it may substitute that computation for the load. If
it can determine that a store to some location will always be followed by
another store to that location before the next load from that location, it
may omit the first store.
A lot of code can get by with an execution model which is slightly less
strict than the above model, and permits loads and stores to behave as
though performed in a somewhat different sequence than implied by the code,
provided that the compiler preserves the relative ordering of certain
operations. Introducing that concept in my earlier post before establishing
how the "pure" model works was probably a mistake.
My basic premise is that every C program can be decomposed into a sequence
of loads, stores, computations, and calls to outside code, and on most
platforms those map to constructs which define behavior in many cases where
the C Standard does not. In some cases a platform may offer more than one
way to map a behavior to code, programmers shouldn't particularly expect
that a even a mindless translator will consistently favor one versus the
other, but in cases where the result from any such approach would meet
requirements a programmer shouldn't be required to force one or the other
[e.g. on the 8086 or 68000, when using 16-bit "int", there would be some
contexts in which
long mul(int x, int y) { return x*y; }
could be most efficiently processed as a 16x16->16 multiply followed by a
sign extension, and others where it could be more efficiently handled by a
32-bit multiply with no sign extension. If either approach would meet
requirements, casting an operand to long, or casting to unsigned and then
casting the result to int, would degrade performance in cases where the
other choice would have been more efficient].
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-14 19:49 +0000 |
| Message-ID | <87d1hx6dur.fsf@gmail.com> |
| In reply to | #96564 |
supercat@casperkitty.com writes: > The behavior of a program which stores 3 in one temporary location and 4 > in another, reads the contents of those locations, adds them, and prints > the sum, would be indistinguishable from that of a program which simply > outputs 7. This is true of every optimisation against which you have been ranting. That's essentially the *definition* in the standard, that you seem to have a problem with. Now you're using it to say "No, these optimisations are OK, even though the program seems to have loads/stores I'm perfectly OK for *these* loads and stores not to happen." Again, what is it about the elision/rearrangement of these loads/stores that's acceptable to you, that isn't the case for the others? How does *your* "as if" rule differ from the Standard's version? I genuinely cannot discern what it is that you wish to codify. From the word salad that followed, I don't think you're sure either.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-14 12:24 -0800 |
| Message-ID | <f3344321-d854-4731-a210-bdab6cfdae73@googlegroups.com> |
| In reply to | #96565 |
On Monday, November 14, 2016 at 1:49:56 PM UTC-6, gwowen wrote:
> supercat writes:
>
> > The behavior of a program which stores 3 in one temporary location and 4
> > in another, reads the contents of those locations, adds them, and prints
> > the sum, would be indistinguishable from that of a program which simply
> > outputs 7.
>
> This is true of every optimisation against which you have been ranting.
> That's essentially the *definition* in the standard, that you seem to
> have a problem with.
On most hardware platforms, the operation sequence:
Store 32-bit floating-point value 1.0f to address f.
Prepare to access a "float" as a 32-bit integer [typically a no-op].
Store 32-bit integer value 0 to address f
Load 32-bit float value from address f
will 100% of the time yield the floating-point value 0.0f. There are some
platforms where it would not, and code which would require such behavior
could not be expected to work on such platforms. My point of contention is
that if hardware defines the effects of a 32-bit floating-point load purely
in terms of the bit value of the underlying storage, then the behavior of
a mindless translator would be defined as doing likewise. If a compiler
were to behave as though the floating-point load were performed before the
integer store, such a change should be considered observable on hardware
which supported the aforementioned guarantee.
> Now you're using it to say "No, these optimisations are OK, even though
> the program seems to have loads/stores I'm perfectly OK for *these*
> loads and stores not to happen."
>
> Again, what is it about the elision/rearrangement of these loads/stores
> that's acceptable to you, that isn't the case for the others?
If the output with certain loads and stores omitted is the same as output
that could have been produced with loads and stores performed exactly as
indicated, then the omission of such loads and stores is not observable.
If the output is one which could have resulted with the loads and stores
as indicated, the change is observable.
A compiler should not generally be required to shield a programmer from
hardware with unusual restrictions, but nor should it use the fact that
some platforms have unusual restrictions as a basis for requiring that
programmers code around those restrictions even when targeting hardware
without them.
> How does *your* "as if" rule differ from the Standard's version?
The difference is that on hardware which defines the effect of an integer
store followed by a floating-point load, my version would specify that the
output must be consistent with such hardware-defined effect, while the
Standard's version would say that because *some* hardware platforms may not
define the effect, compilers for all hardware platforms--even those where
the effect would be defined--can do anything they like.
When the authors of C89 listed the common effects of Undefined Behavior,
they did not prohibit implementations from doing anything else, but I've
seen no evidence that they intended that implementations for hardware which
would naturally behave in a useful fashion should not allow programmers to
exploit that behavior.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-14 12:32 -0800 |
| Message-ID | <lnfumtkdkf.fsf@kst-u.example.com> |
| In reply to | #96570 |
supercat@casperkitty.com writes:
> On Monday, November 14, 2016 at 1:49:56 PM UTC-6, gwowen wrote:
[...]
>> How does *your* "as if" rule differ from the Standard's version?
>
> The difference is that on hardware which defines the effect of an integer
> store followed by a floating-point load, my version would specify that the
> output must be consistent with such hardware-defined effect, while the
> Standard's version would say that because *some* hardware platforms may not
> define the effect, compilers for all hardware platforms--even those where
> the effect would be defined--can do anything they like.
So if a hardware platform makes certain guarantees about the behavior of
its LOAD and STORE instructions (however they're spelled in the
preferred assembly language for that platform), those guarantees should
be imposed on the behavior of assignments and other expressions in the C
programming language. (Only C, or should other languages be required to
follow suit?)
Certainly a given implementation is free to make such guarantees, as
long as they don't conflict with the requirements of the standard.
> When the authors of C89 listed the common effects of Undefined Behavior,
> they did not prohibit implementations from doing anything else, but I've
> seen no evidence that they intended that implementations for hardware which
> would naturally behave in a useful fashion should not allow programmers to
> exploit that behavior.
One more time, I urge you to write up your proposals in a coherent form
and post them somewhere.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-16 08:18 -0800 |
| Message-ID | <378c6265-3bfd-4d85-9e8a-591564c28c67@googlegroups.com> |
| In reply to | #96571 |
On Monday, November 14, 2016 at 2:32:22 PM UTC-6, Keith Thompson wrote: > So if a hardware platform makes certain guarantees about the behavior of > its LOAD and STORE instructions (however they're spelled in the > preferred assembly language for that platform), those guarantees should > be imposed on the behavior of assignments and other expressions in the C > programming language. (Only C, or should other languages be required to > follow suit?) A quality implementation should document ways in which its behavior may differ from that of the sequence of loads, stores, and computations implied by a literal translation of the program. Further, unless the implementation is not intended to be usable for embedded or systems programming, it should also provide and document practical means via which a programmer can achieve any behavior that could be achieved via sequence of such operations. An implementation for a particular platform which behaves in fashion consistent with such a literal translation will be able to run any code which uses standard syntax but relies upon platform features that would be exposed by such translation. The code may not be optimally efficient, but if it is efficient enough to meet requirements, no further work would be required. If it is not efficient enough, simple profiling should be able to identify what parts need to run faster, and a programmer can then focus on those parts to determine which optimizations may safely be employed. Suppose a 2006 version of a compiler could only achieve acceptable performance if a programmer manually-applied chunking optimizations, but a 2016 version gains the ability to perform such optimizations itself. Since many projects contain a mixture of old and new code, the ability of the compiler to perform such optimizations itself would not eliminate the need to have it support chunking constructs as efficiently as the 2006 version. The authors of the Standard openly acknowledge that it does not describe all the requirements of quality implementation, nor does it even make much effort to describe things that would cause one implementation to be of higher quality than another. It implies that e.g. an implementation which supports Annex F would likely superior to one which does not claim to do so but is otherwise identical, but doesn't say much else with regard to quality. > One more time, I urge you to write up your proposals in a coherent form > and post them somewhere. Do you have any particular recommendations as to form?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-16 08:50 -0800 |
| Message-ID | <lnshqrgyig.fsf@kst-u.example.com> |
| In reply to | #96691 |
supercat@casperkitty.com writes:
> On Monday, November 14, 2016 at 2:32:22 PM UTC-6, Keith Thompson wrote:
>> So if a hardware platform makes certain guarantees about the behavior of
>> its LOAD and STORE instructions (however they're spelled in the
>> preferred assembly language for that platform), those guarantees should
>> be imposed on the behavior of assignments and other expressions in the C
>> programming language. (Only C, or should other languages be required to
>> follow suit?)
>
> A quality implementation should document ways in which its behavior may
> differ from that of the sequence of loads, stores, and computations implied
> by a literal translation of the program.
There is no "literal translation". A statement like `x = y + z;`
does not specify a sequence of LOAD, STORE, and ADD instructions.
It specifies runtime behavior. Any generated instructions are a
means to achieve that behavior, and the standard quite properly
says nothing specific about them.
[...]
>> One more time, I urge you to write up your proposals in a coherent form
>> and post them somewhere.
>
> Do you have any particular recommendations as to form?
English.
Ideally, if you're serious about such a writeup, I'd suggest that it
should include, but not necessarily be limited to, text that could be
included in a future edition of the C standard.
There are several technical reports linked from
http://www.open-std.org/jtc1/sc22/wg14/
You might consider using them as a model.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-17 12:02 -0800 |
| Message-ID | <cc6b7e78-9d22-4acb-8fd1-626ca83a260e@googlegroups.com> |
| In reply to | #96696 |
On Wednesday, November 16, 2016 at 10:50:18 AM UTC-6, Keith Thompson wrote:
> There is no "literal translation". A statement like `x = y + z;`
> does not specify a sequence of LOAD, STORE, and ADD instructions.
> It specifies runtime behavior. Any generated instructions are a
> means to achieve that behavior, and the standard quite properly
> says nothing specific about them.
The vast majority of implementations contain a compiler and an execution
environment which are under the control of different entities, and define
means via which code can interface with things that behave in ways outside
the compiler's control. Because implementations can be useful for some
purposes even if they can't offer such abilities, the Standard does not
mandate such capabilities. Nonetheless, there are many purposes for which
any compiler lacking such abilities would be totally useless.
Given the code:
extern void opaque_function(void*, ...);
int test(void)
{
int32_t x,y,z;
opaque_function(&x,&y,&z);
x=y+z; // ***
opaque_function(&x,&y,&z);
}
is there any way in which a compiler that knows nothing about
opaque_function other than its signature could generate code for
x=y+z; that did anything other than read the values in the storage
allocated to y and z, adding those values, and storing the result
into the storage allocated to x?
If the actual code for opaque_function never actually does anything, would
there be any situation in which adding calls to opaque_function from code
which has defined behavior in its absence would cause it to yield a
contrary behavior?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-17 12:22 -0800 |
| Message-ID | <lny40hg8le.fsf@kst-u.example.com> |
| In reply to | #96768 |
supercat@casperkitty.com writes:
> On Wednesday, November 16, 2016 at 10:50:18 AM UTC-6, Keith Thompson wrote:
>> There is no "literal translation". A statement like `x = y + z;`
>> does not specify a sequence of LOAD, STORE, and ADD instructions.
>> It specifies runtime behavior. Any generated instructions are a
>> means to achieve that behavior, and the standard quite properly
>> says nothing specific about them.
>
> The vast majority of implementations contain a compiler and an execution
> environment which are under the control of different entities, and define
> means via which code can interface with things that behave in ways outside
> the compiler's control. Because implementations can be useful for some
> purposes even if they can't offer such abilities, the Standard does not
> mandate such capabilities. Nonetheless, there are many purposes for which
> any compiler lacking such abilities would be totally useless.
>
> Given the code:
>
> extern void opaque_function(void*, ...);
>
> int test(void)
> {
> int32_t x,y,z;
> opaque_function(&x,&y,&z);
> x=y+z; // ***
> opaque_function(&x,&y,&z);
> }
>
> is there any way in which a compiler that knows nothing about
> opaque_function other than its signature could generate code for
> x=y+z; that did anything other than read the values in the storage
> allocated to y and z, adding those values, and storing the result
> into the storage allocated to x?
Perhaps not. I fail to see how that addresses what I wrote above.
> If the actual code for opaque_function never actually does anything, would
> there be any situation in which adding calls to opaque_function from code
> which has defined behavior in its absence would cause it to yield a
> contrary behavior?
I can't think of any such cases, but since I have no idea what point
you're trying to make here I could be missing something.
I stand by what I wrote previously.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-11-16 10:35 -0800 |
| Message-ID | <kfnk2c3qnm4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #96691 |
supercat@casperkitty.com writes: > On Monday, November 14, 2016 at 2:32:22 PM UTC-6, Keith Thompson wrote: >> So if a hardware platform makes certain guarantees about the behavior of >> its LOAD and STORE instructions (however they're spelled in the >> preferred assembly language for that platform), those guarantees should >> be imposed on the behavior of assignments and other expressions in the C >> programming language. (Only C, or should other languages be required to >> follow suit?) > > A quality implementation should [...] What is being described is a supercat-quality implementation, which differs from what "quality implemenation" means to anyone else.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-13 10:52 +0000 |
| Message-ID | <871syf64a5.fsf@gmail.com> |
| In reply to | #96448 |
supercat <flatfinger@casperkitty.com> writes: > As above, such optimizations would be expected and desirable in cases where > they would be consistent with the model, if you want all your variables to be volatile, declare them as such.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-12 14:28 -0800 |
| Message-ID | <ln37iwmiy3.fsf@kst-u.example.com> |
| In reply to | #96416 |
supercat <flatfinger@casperkitty.com> writes:
[...]
> What I have called for would be standard conventions via which programmers
> could indicate what features and guarantees they require, and ensure that
> an attempt to process the program with an incompatible implementation would
> be rejected outright rather than yielding unreliable behavior.
[...]
Let me encourage you to write up a coherent specification for what
you're proposing and make it available somewhere on the web.
--
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 | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-09 13:27 -0800 |
| Message-ID | <7024bd37-5f93-4265-913a-03421be2dc55@googlegroups.com> |
| In reply to | #96218 |
On Wednesday, November 9, 2016 at 3:10:38 PM UTC-5, Thiago Adams wrote: > I never thought I would had to give arguments to use C in a list of C. I am > starting to think this list has no C programmers, but maybe curious people > about C. This is not a "list", but a usenet newsgroup. Everyone here is showing an unusual interest in C, just by choosing this group to monitor. Most of them are C programmers. However, most C programmers who are sufficiently experienced or well-educated don't belive that everything should be written in C. The best language to use for a given task should always be decided based upon what that task is. I write mainly in C90, that being one of the three languages permitted by our contract with our client for delivered science code on one of the projects I'm working on. The other project I'm working on uses almost exclusively C++2003 for the science code, though there's no formal requirement that it do so. A large fraction of my work involves updating perl scripts that execute our C/C++ programs, and one of the key things those scripts do is construct SQL queries. In each of those cases, the decision about what language to use was made long before I started working on the project, but those decisions seem reasonable to me. I wouldn't care to replace any of the non-C code mentioned above with equivalent C code.
[toc] | [prev] | [next] | [standalone]
| From | Robert Spanjaard <spamtrap@arumes.com> |
|---|---|
| Date | 2016-11-09 23:43 +0100 |
| Message-ID | <o008qc$uod$1@gioia.aioe.org> |
| In reply to | #96218 |
On 09-11-16 21:10, Thiago Adams wrote: > I never thought I would had to give arguments to use C in a list of C. I > am starting to think this list has no C programmers, but maybe curious > people about C. I'm a C programmer, but only a hobbyist. Don't use it to do anything useful. I've had experience with higher-level languages too (long ago), and I think I agree that C doesn't make much sense for most applications anymore. For me, it's nice because it's a challenging language (so I actually like it because it is hard, which is the opposite of what any professional would do) and because I have an interest in computer history (so I like doing things the way they were done 30+ years ago). So I know it's not the best choice, but when I used higher-level languages long ago I stopped programming at a certain point because there was no challenge in it anymore, and I lost interest. I also don't use an IDE, just nano and gcc which further proves the futility of my work. :) If I had to do anything 'serious', for modern application development, my main choice would probably be Python because I'm using a couple of apps written in it that work well and fast enough, even on an Atom-based netbook, and from what I've seen the language is easy to learn. For code that requires speed (probably most server-sided work like the web server you mentioned), I'd probably stick to C because that's what I know (a bit) and I know it's fast. -- Robert Spanjaard
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-10 17:57 +1300 |
| Message-ID | <e8id22Fd9i7U1@mid.individual.net> |
| In reply to | #96218 |
On 11/10/16 09:10 AM, Thiago Adams wrote: > On Wednesday, November 9, 2016 at 5:57:58 PM UTC-2, gwowen wrote: > >> No. Honestly, I don't think C is a sensible implementation language for >> anything but constrained embedded work and hardcore bit-banging these days. > > What do you thing about these: > > - web servers > - javascript engines The most widely used opensource JavaScript engine (v8) is written in C++. > I never thought I would had to give arguments to use C in a list of > C. I am starting to think this list has no C programmers, but maybe curious > people about C. There are plenty of C++ programmers here, but there are almost as many who are multilingual! -- Ian
[toc] | [prev] | [next] | [standalone]
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web