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 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-10 13:35 +0100 |
| Message-ID | <o01ph4$rco$1@dont-email.me> |
| In reply to | #96238 |
On 09/11/16 23:01, jacobnavia wrote: > Le 09/11/2016 à 21:35, David Brown a écrit : >> Maybe C, but you've nothing to lose and a good deal you might gain with >> C++. Remember that once you have enough resources for a little overhead >> in code size, there is almost nothing that can be written in C that >> cannot be written at least as fast and easily in C++, since most all of >> C is a subset of C++. Thus C++ gives you everything that C has, plus a >> good deal more. > > Hello? > > Is there anybody? > > OK. Thanks. It is just to remind you, David, that are people that do not > want that "good deal more" precisely. > > People that think that simpler languages are better than unreadable ones. > > Those people use C, a very good language, mind you. > > True, as you say yourself, nothing that can be written in simple C can't > be rewritten into unreadability. Why make simple when you can complexify > stuff till you yourself doesn't know exactly what you are writing? > > :-) You can write unreadable code in any language - including C (there are several people in this group who seem to take pride in doing so). Similarly, you can write clear and readable code in most programming languages - including C++. So I don't really understand your point. Is that C++ is so full of goodies and exciting features that you feel obliged to use them all and make your code a mess - and you think that applies to everyone who uses C++? C is a useful language - most of my work is done in C. All I am saying is that it is not the best choice for all programming tasks, even though it is usually the best choice for many of /my/ programming tasks.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-10 08:08 -0800 |
| Message-ID | <ce04217b-bcf0-4b29-8a58-9b6ffabf9688@googlegroups.com> |
| In reply to | #96303 |
On Thursday, November 10, 2016 at 6:35:20 AM UTC-6, David Brown wrote: > So I don't really understand your point. Is that C++ is so full of > goodies and exciting features that you feel obliged to use them all and > make your code a mess - and you think that applies to everyone who uses C++? Part of the issue, I think, is that at least when using a C compiler that generates code whose behavior is consistent with a "mindless translator", it's easy to look at code and see at a low level not only what the code is *supposed* to do, but what it *will actually do*. On processors where non-branching instructions can be executed equally fast in any sequence (still common in the embedded world) it's possible for compilers to generate decent code while still offering the semantic benefits that would come from a "mindless translator" implementation. Code which is written well in C++ may allow a reader to ascertain the programmer's intent more easily than would be possible in C, but may make it harder to determine with certainty that the actual behavior of the code will match that intent, especially if the only way to get good performance with such code is to enable more aggressive forms of optimization.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-10 20:30 +0100 |
| Message-ID | <o02hqq$ndk$1@dont-email.me> |
| In reply to | #96322 |
On 10/11/16 17:08, supercat@casperkitty.com wrote: > On Thursday, November 10, 2016 at 6:35:20 AM UTC-6, David Brown wrote: >> So I don't really understand your point. Is that C++ is so full of >> goodies and exciting features that you feel obliged to use them all and >> make your code a mess - and you think that applies to everyone who uses C++? > > Part of the issue, I think, No, repeating the same thing you write in every single thread is /not/ part of the issue - nor is it an indication of any thought on your part. It is an indication of a single-track mind with no interest in learning. If you are going to be a programmer, you need to understand the language you are using to program - and write code that says what it should do in that language. And if you don't like that language - as you apparently do not like C - then pick a different language. There are enough to choose from.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-10 12:20 -0800 |
| Message-ID | <d5d5655d-ff29-4273-8791-1d09c6fbf385@googlegroups.com> |
| In reply to | #96329 |
On Thursday, November 10, 2016 at 1:30:07 PM UTC-6, David Brown wrote: > If you are going to be a programmer, you need to understand the language > you are using to program - and write code that says what it should do in > that language. And if you don't like that language - as you apparently > do not like C - then pick a different language. There are enough to > choose from. By what name would you call the languages (mappings between inputs and behaviors) processed by conforming "mindless translators" for commonplace platforms, to distinguish them from the languages processed by "modern" compilers? There are some platforms and fields for which the former class of languages, possibly with some tweaks to improve efficiency *without forfeiting semantic capabilities*, are better than anything else, and may continue to be better than anything else for another 40 years. I'd like to call that class of languages "C", but if the name is only applicable to "modern" dialects, perhaps you could suggest a retronym for the older ones?
[toc] | [prev] | [next] | [standalone]
| From | me <crisdunbar@gmail.com> |
|---|---|
| Date | 2016-11-10 13:48 -0800 |
| Message-ID | <c99ec48f-6d74-4d55-b573-ba5b38a2f344@googlegroups.com> |
| In reply to | #96330 |
On Thursday, November 10, 2016 at 12:21:14 PM UTC-8, supe...@casperkitty.com wrote: > On Thursday, November 10, 2016 at 1:30:07 PM UTC-6, David Brown wrote: > > If you are going to be a programmer, you need to understand the language > > you are using to program - and write code that says what it should do in > > that language. And if you don't like that language - as you apparently > > do not like C - then pick a different language. There are enough to > > choose from. > > By what name would you call the languages (mappings between inputs and > behaviors) processed by conforming "mindless translators" for commonplace > platforms, <snip> Assembly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-10 22:53 +0100 |
| Message-ID | <o02q7a$oca$1@dont-email.me> |
| In reply to | #96330 |
On 10/11/16 21:20, supercat@casperkitty.com wrote: > On Thursday, November 10, 2016 at 1:30:07 PM UTC-6, David Brown wrote: >> If you are going to be a programmer, you need to understand the language >> you are using to program - and write code that says what it should do in >> that language. And if you don't like that language - as you apparently >> do not like C - then pick a different language. There are enough to >> choose from. > > By what name would you call the languages (mappings between inputs and > behaviors) processed by conforming "mindless translators" for commonplace > platforms, to distinguish them from the languages processed by "modern" > compilers? > I would not give it a name, because it is not a language I use - nor do I know of any tools that implement it. In fact, it only exists in your imagination as far as I know. It is certainly not "C", and never has been. (I do have tools that are mindless translators - but they mindlessly translate C, not a language that is specified as having to be mindlessly translated on a particular target.) And please, how about /not/ rehashing exactly the same debate again? You learned nothing the first few hundred times you brought it up, and failed to listen to the first few dozen people that have tried to explain it to you. I doubt if there will be more success this time, so unless you have had a change of heart, let's drop it from this thread.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-10 14:38 -0800 |
| Message-ID | <23d0f58e-a17c-4ef7-8db6-9cc5b7bcaf04@googlegroups.com> |
| In reply to | #96350 |
On Thursday, November 10, 2016 at 3:53:18 PM UTC-6, David Brown wrote: > On 10/11/16 21:20, supercat wrote: > > By what name would you call the languages (mappings between inputs and > > behaviors) processed by conforming "mindless translators" for commonplace > > platforms, to distinguish them from the languages processed by "modern" > > compilers? > > I would not give it a name, because it is not a language I use - nor do > I know of any tools that implement it. In fact, it only exists in your > imagination as far as I know. It is certainly not "C", and never has been. > > (I do have tools that are mindless translators - but they mindlessly > translate C, not a language that is specified as having to be mindlessly > translated on a particular target.) Many implementations do in fact explicitly document behavioral aspects which go beyond the C Standard, although many of them are rather sloppy about it. For example, the only plausible purpose of gcc's flags "-fno-strict-aliasing", "-fno-strict-overflow", and "-fwrapv", is to make it treat it certain constructs as having defined even though not required by the Standard; so far as I can tell, however, only in the case of -fwrapv does gcc's documentation actually promise that. While gcc indicates that "-fno-strict-aliasing" is to disable certain optimizations, it doesn't explicitly specify that it won't decide to treat aliasing-based code as invoking UB even with those particular optimizations disabled. Normally that would be a non-issue, except that the authors of gcc have very emphatically stated that they make no promise with regard to any behaviors that aren't explicitly documented nor mandated by the Standard. Does the language processed by gcc when the -fno-strict-aliasing flag is used recognize pointer aliasing beyond the forms mandated by the Standard (despite the documentations' failure to actually guarantee that), does it have some other purpose, or does it serve no purpose?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-11 09:52 +0100 |
| Message-ID | <o040re$d5a$1@dont-email.me> |
| In reply to | #96355 |
On 10/11/16 23:38, supercat@casperkitty.com wrote: > On Thursday, November 10, 2016 at 3:53:18 PM UTC-6, David Brown wrote: >> On 10/11/16 21:20, supercat wrote: >>> By what name would you call the languages (mappings between inputs and >>> behaviors) processed by conforming "mindless translators" for commonplace >>> platforms, to distinguish them from the languages processed by "modern" >>> compilers? >> >> I would not give it a name, because it is not a language I use - nor do >> I know of any tools that implement it. In fact, it only exists in your >> imagination as far as I know. It is certainly not "C", and never has been. >> >> (I do have tools that are mindless translators - but they mindlessly >> translate C, not a language that is specified as having to be mindlessly >> translated on a particular target.) > > Many implementations do in fact explicitly document behavioral aspects which > go beyond the C Standard, although many of them are rather sloppy about it. No one doubts that some compilers defined more behaviour than is required by the standards - or that they sometimes document it, or that they sometimes fail to document it. What I doubt is that there are compilers that define behaviour in terms of "the compiler will act like the original C designers expected", or "the compiler will act like the first C standards meant, even though they said something else", or "the compiler will act like a mindless translator", or "the compiler will act by reading the developer's mind". > For example, the only plausible purpose of gcc's flags "-fno-strict-aliasing", > "-fno-strict-overflow", and "-fwrapv", is to make it treat it certain > constructs as having defined even though not required by the Standard; These flags change the behaviour of gcc in certain ways, documented (roughly at least) in the gcc manual. So far, so good - but the do not make the compiler a "mindless translator". > so far > as I can tell, however, only in the case of -fwrapv does gcc's documentation > actually promise that. While gcc indicates that "-fno-strict-aliasing" is > to disable certain optimizations, it doesn't explicitly specify that it won't > decide to treat aliasing-based code as invoking UB even with those particular > optimizations disabled. Normally that would be a non-issue, except that the > authors of gcc have very emphatically stated that they make no promise with > regard to any behaviors that aren't explicitly documented nor mandated by the > Standard. > > Does the language processed by gcc when the -fno-strict-aliasing flag is used > recognize pointer aliasing beyond the forms mandated by the Standard (despite > the documentations' failure to actually guarantee that), does it have some > other purpose, or does it serve no purpose? > It is just C, with the additional of guaranteeing certain behaviour in one particular situation where the C standards do not require defined behaviour. Nothing more, nothing less. Some people find features like this useful on occasion, because (for whatever reasons) they prefer to write code that relies on such behaviour. That's fine too. All I object to is your ideas that this is how C was supposed to work, or that it is how C used to work, or how C used to be specified by the standards, or how C should work. I have nothing against people using compiler or target specific features if it helps them write better code - I do that myself all the time.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-11 06:09 -0800 |
| Message-ID | <9e27a17d-aaab-48e1-9139-95114dea0da6@googlegroups.com> |
| In reply to | #96371 |
On Friday, November 11, 2016 at 2:52:38 AM UTC-6, David Brown wrote: > What I doubt is that there are compilers that define behaviour in terms > of "the compiler will act like the original C designers expected", or > "the compiler will act like the first C standards meant, even though > they said something else", or "the compiler will act like a mindless > translator", or "the compiler will act by reading the developer's mind". What does the phrase "disable ___ optimizations" mean if not, effectively, behave like a mindless translator with respect to ___ ? No mind-reading required. If an implementation defines the bit-level storage of types X and Y, and doesn't do anything to the contrary, the effect of writing something of type X will be to write the bit pattern associated with X, and the effect of reading that storage as type Y will be to yield the value associated with the bits in the storage, without regard for the type used to write those bits. > > For example, the only plausible purpose of gcc's flags "-fno-strict-aliasing", > > "-fno-strict-overflow", and "-fwrapv", is to make it treat it certain > > constructs as having defined even though not required by the Standard; > > These flags change the behaviour of gcc in certain ways, documented > (roughly at least) in the gcc manual. So far, so good - but the do not > make the compiler a "mindless translator". The behavior of the flags is specified in terms of disabling certain optimizations. If that doesn't imply that, the compiler's behavior will match that of a mindless translator with respect to certain issues, what does it mean? > All I object to is your ideas that this is how C was supposed to work, > or that it is how C used to work, or how C used to be specified by the > standards, or how C should work. I have nothing against people using > compiler or target specific features if it helps them write better code > - I do that myself all the time. What I object to is the notions that a language standard should not encourage implementations to support features or guarantees which 99% of implementations could readily support and provide a means of reporting such support or lack thereof, and that programmers should be willing to jump through hoops to avoid features which all target platforms of interest could readily support.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-11 21:54 +0100 |
| Message-ID | <o05b51$81t$1@dont-email.me> |
| In reply to | #96381 |
On 11/11/16 15:09, supercat@casperkitty.com wrote: > On Friday, November 11, 2016 at 2:52:38 AM UTC-6, David Brown wrote: >> What I doubt is that there are compilers that define behaviour in terms >> of "the compiler will act like the original C designers expected", or >> "the compiler will act like the first C standards meant, even though >> they said something else", or "the compiler will act like a mindless >> translator", or "the compiler will act by reading the developer's mind". > > What does the phrase "disable ___ optimizations" mean if not, effectively, > behave like a mindless translator with respect to ___ ? It means the compiler will disable /those/ particular optimisations, and not other ones. It is not in any way "mindless translation". And note that it only does this when you specifically ask the compiler to behave in this way - it is not normal compiler behaviour (and never has been). > > No mind-reading required. If an implementation defines the bit-level > storage of types X and Y, and doesn't do anything to the contrary, the > effect of writing something of type X will be to write the bit pattern > associated with X, and the effect of reading that storage as type Y will > be to yield the value associated with the bits in the storage, without > regard for the type used to write those bits. Yes, in regard to this /one/ aspect of compilation on this /one/ compiler, when that particular flag is set. > >>> For example, the only plausible purpose of gcc's flags "-fno-strict-aliasing", >>> "-fno-strict-overflow", and "-fwrapv", is to make it treat it certain >>> constructs as having defined even though not required by the Standard; >> >> These flags change the behaviour of gcc in certain ways, documented >> (roughly at least) in the gcc manual. So far, so good - but the do not >> make the compiler a "mindless translator". > > The behavior of the flags is specified in terms of disabling certain > optimizations. If that doesn't imply that, the compiler's behavior will > match that of a mindless translator with respect to certain issues, what > does it mean? > >> All I object to is your ideas that this is how C was supposed to work, >> or that it is how C used to work, or how C used to be specified by the >> standards, or how C should work. I have nothing against people using >> compiler or target specific features if it helps them write better code >> - I do that myself all the time. > > What I object to is the notions that a language standard should not > encourage implementations to support features or guarantees which 99% of > implementations could readily support and provide a means of reporting > such support or lack thereof, and that programmers should be willing to > jump through hoops to avoid features which all target platforms of interest > could readily support. > And I (and many others) object to your continual objections of the same things, in every thread - regardless of how relevant or not it may be, and regardless of how many times you have said the same things. You are forever making claims about what implementations could do, or should do, or what programmers expect, or used to rely on, and how difficult it is for programmers to deal with these awkward modern compilers. But "proof by repetition" does not hold. Nor do yet more "examples" of weird hypothetical problems that could be slightly more efficient if certain behaviours were defined. (And please, that is /not/ a call to come with more samples.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-11 14:10 -0800 |
| Message-ID | <3121b7be-aca1-44b0-9dc9-6b23611bbfba@googlegroups.com> |
| In reply to | #96393 |
On Friday, November 11, 2016 at 2:54:33 PM UTC-6, David Brown wrote: > On 11/11/16 15:09, supercat wrote: > > On Friday, November 11, 2016 at 2:52:38 AM UTC-6, David Brown wrote: > >> What I doubt is that there are compilers that define behaviour in terms > >> of "the compiler will act like the original C designers expected", or > >> "the compiler will act like the first C standards meant, even though > >> they said something else", or "the compiler will act like a mindless > >> translator", or "the compiler will act by reading the developer's mind". > > > > What does the phrase "disable ___ optimizations" mean if not, effectively, > > behave like a mindless translator with respect to ___ ? > > It means the compiler will disable /those/ particular optimisations, and > not other ones. It is not in any way "mindless translation". And note > that it only does this when you specifically ask the compiler to behave > in this way - it is not normal compiler behaviour (and never has been). How many compilers provide options to "disable" optimizations which they do not and have never performed? You seem to think that a compiler should be presumed capable of spontaneously applying any optimization which has not been expressly disabled, even if there is no option to "disable" that optimization because the compiler never performed it. It is all well and good to say that because certain techniques may require disabling some optimizations which would otherwise be available in the future, they should be avoided unless the value of those techniques would be greater than the value of foregone optimizations, but it seems silly to say that a programmer should be expected to refrain from using techniques that could double the speed of hot loops, in order to allow for future compilers to perform some optimizations which may or may not offer much useful speed improvement. > > No mind-reading required. If an implementation defines the bit-level > > storage of types X and Y, and doesn't do anything to the contrary, the > > effect of writing something of type X will be to write the bit pattern > > associated with X, and the effect of reading that storage as type Y will > > be to yield the value associated with the bits in the storage, without > > regard for the type used to write those bits. > > Yes, in regard to this /one/ aspect of compilation on this /one/ > compiler, when that particular flag is set. Why would that not be equally applicable to *all* compilers which define the bit-level formats of their data types and refrain from type-based aliasing optimizations?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-12 14:17 +0100 |
| Message-ID | <o074os$61m$1@dont-email.me> |
| In reply to | #96394 |
On 11/11/16 23:10, supercat@casperkitty.com wrote: > On Friday, November 11, 2016 at 2:54:33 PM UTC-6, David Brown wrote: >> On 11/11/16 15:09, supercat wrote: >>> On Friday, November 11, 2016 at 2:52:38 AM UTC-6, David Brown wrote: >>>> What I doubt is that there are compilers that define behaviour in terms >>>> of "the compiler will act like the original C designers expected", or >>>> "the compiler will act like the first C standards meant, even though >>>> they said something else", or "the compiler will act like a mindless >>>> translator", or "the compiler will act by reading the developer's mind". >>> >>> What does the phrase "disable ___ optimizations" mean if not, effectively, >>> behave like a mindless translator with respect to ___ ? >> >> It means the compiler will disable /those/ particular optimisations, and >> not other ones. It is not in any way "mindless translation". And note >> that it only does this when you specifically ask the compiler to behave >> in this way - it is not normal compiler behaviour (and never has been). > > How many compilers provide options to "disable" optimizations which they do > not and have never performed? You seem to think that a compiler should be > presumed capable of spontaneously applying any optimization which has not > been expressly disabled, even if there is no option to "disable" that > optimization because the compiler never performed it. Yes, that is exactly correct. A compiler is free to do any optimisations that do not break the rules defined by the C standards (especially the "as if" rule), and that do not break any documented behaviour for that particular compiler and version. A compiler is free to perform different optimisations in different circumstances - and if you want to write good, safe, robust, and reliable code, you do not make /any/ assumptions about what optimisations a compiler will or will not perform, except when you have clear information in the documentation, the compiler flags you use, and the particular version of the particular tool in question. You think it is unlikely for a compiler to "suddenly" start using an optimisation such as relying on the undefined behaviour of integer overflow or "strict aliasing" effects. In reality, it is quite possible in a variety of circumstances. Maybe you have changed your compiler flags - it is very common (but a bad idea, IMHO) to have "debug builds" and "release builds" with different flags. Maybe you have updated your compiler - optimisation details can easily change between releases. Maybe you have just made a few minor changes to your code, and the changes to register allocations mean that different optimisations take effect. > > It is all well and good to say that because certain techniques may require > disabling some optimizations which would otherwise be available in the > future, they should be avoided unless the value of those techniques would > be greater than the value of foregone optimizations, but it seems silly to > say that a programmer should be expected to refrain from using techniques > that could double the speed of hot loops, in order to allow for future > compilers to perform some optimizations which may or may not offer much > useful speed improvement. As usual, you are making up numbers to try to "prove" how important it is to break the rules of C. As I have said many times, it is /fine/ to use implementation-specific behaviour in order to get the last drops of speed out of your target. This is something that has always existed in C, and always been allowed, encouraged and expected. What is /not/ fine is to write code that relies on particular aspects of an implementation without any way to be sure that this is how the implementation actually works, or to claim it is "portable" because you think other implementations "should" work in that way. > >>> No mind-reading required. If an implementation defines the bit-level >>> storage of types X and Y, and doesn't do anything to the contrary, the >>> effect of writing something of type X will be to write the bit pattern >>> associated with X, and the effect of reading that storage as type Y will >>> be to yield the value associated with the bits in the storage, without >>> regard for the type used to write those bits. >> >> Yes, in regard to this /one/ aspect of compilation on this /one/ >> compiler, when that particular flag is set. > > Why would that not be equally applicable to *all* compilers which define > the bit-level formats of their data types and refrain from type-based > aliasing optimizations? > It might well be applicable to all such compilers. But it is still implementation-dependent behaviour - it just works with more than one particular compiler and set of compilation flags.
[toc] | [prev] | [next] | [standalone]
| From | supercat <flatfinger@casperkitty.com> |
|---|---|
| Date | 2016-11-12 10:42 -0800 |
| Message-ID | <300e8fda-56cf-476f-9bd7-257791357090@googlegroups.com> |
| In reply to | #96412 |
On Saturday, November 12, 2016 at 7:17:55 AM UTC-6, David Brown wrote: > On 11/11/16 23:10, supercat wrote: > > How many compilers provide options to "disable" optimizations which they do > > not and have never performed? You seem to think that a compiler should be > > presumed capable of spontaneously applying any optimization which has not > > been expressly disabled, even if there is no option to "disable" that > > optimization because the compiler never performed it. > > Yes, that is exactly correct. A compiler is free to do any > optimisations that do not break the rules defined by the C standards > (especially the "as if" rule), and that do not break any documented > behaviour for that particular compiler and version. The Standards allow compilers to do many things. I would suggest, however, that people making quality compilers should endeavor to see how they are being used, and provide a means of producing break-proof builds (e.g. have a command-line option that would prevent a compiler from enabling any new optimizations that might break old code, except when such options are expressly enabled). Do you see any disadvantage to a compiler doing those things? > > It is all well and good to say that because certain techniques may require > > disabling some optimizations which would otherwise be available in the > > future, they should be avoided unless the value of those techniques would > > be greater than the value of foregone optimizations, but it seems silly to > > say that a programmer should be expected to refrain from using techniques > > that could double the speed of hot loops, in order to allow for future > > compilers to perform some optimizations which may or may not offer much > > useful speed improvement. > > As usual, you are making up numbers to try to "prove" how important it > is to break the rules of C. Chunking optimizations process small objects in groups of two or four, using the same amount of time per group as would be required for single objects. Since the number of groups to be processed will be 1/2 or 1/4 the number of objects, that will double or quadruple the speed. > As I have said many times, it is /fine/ to use implementation-specific > behaviour in order to get the last drops of speed out of your target. > This is something that has always existed in C, and always been allowed, > encouraged and expected. What is /not/ fine is to write code that > relies on particular aspects of an implementation without any way to be > sure that this is how the implementation actually works, or to claim it > is "portable" because you think other implementations "should" work in > that way. How should one handle the problem that people writing documentation often neglect to explicitly specify things that many consumers would both expect and require to be true? 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. It would have been helpful if the annex of C89 which listed common extensions had included common behavioral definitions in addition to syntactic extension. If the Standard had implied that two's-complement implementations' treatment of "unsigned x=ushort1*ushort2;" in cases where the result exceeded INT_MAX was worthy of explicit documentation (rather than simply being a natural consequence of running on silent-wraparound two's-complement hardware) then many more compiler vendors would have documented such behavior. As it is, though, many vendors only bothered to document such things in cases where they were either stronger or weaker than what someone familiar with the underlying platform would have expected. > >>> No mind-reading required. If an implementation defines the bit-level > >>> storage of types X and Y, and doesn't do anything to the contrary, the > >>> effect of writing something of type X will be to write the bit pattern > >>> associated with X, and the effect of reading that storage as type Y will > >>> be to yield the value associated with the bits in the storage, without > >>> regard for the type used to write those bits. > >> > >> Yes, in regard to this /one/ aspect of compilation on this /one/ > >> compiler, when that particular flag is set. > > > > Why would that not be equally applicable to *all* compilers which define > > the bit-level formats of their data types and refrain from type-based > > aliasing optimizations? > > It might well be applicable to all such compilers. But it is still > implementation-dependent behaviour - it just works with more than one > particular compiler and set of compilation flags. It would clearly be *platform*-dependent behavior, but that doesn't mean that it shouldn't be possible to have code that uses 32-bit types to read aligned pairs of 16-bit values and uses them in order-agnostic fashion shouldn't be usable without difficulty on implementations targeting any remotely-commonplace platforms.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-12 19:04 +0000 |
| Message-ID | <8760nsr02s.fsf@gmail.com> |
| In reply to | #96416 |
supercat <flatfinger@casperkitty.com> writes: > The Standards allow compilers to do many things. I would suggest, however, > that people making quality compilers should endeavor to see how they are > being used, and provide a means of producing break-proof builds (e.g. have > a command-line option that would prevent a compiler from enabling any new > optimizations that might break old code, except when such options are > expressly enabled). There's a compatibility mode in gcc-6 that makes it work like gcc-4.6 Simply install gcc-4.6 alongside gcc-6 and invoke it as gcc-4.6 > Do you see any disadvantage to a compiler doing those things? If they're possible. But optimizers don't really work like that. For example, two different peephole optimizers will produce different code based on the order they're invoked. Would changing the order of invocation qualify as a "new optimization"? If so, you're insisting that the internal structure of the compiler must, essentially, freeze, and that's not going to happen.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-12 16:13 -0800 |
| Message-ID | <0dc796fe-911c-4dc0-952a-7b9e3ed54eae@googlegroups.com> |
| In reply to | #96418 |
On Saturday, November 12, 2016 at 1:05:07 PM UTC-6, gwowen wrote:
> supercat writes:
> > Do you see any disadvantage to a compiler doing those things?
>
> If they're possible. But optimizers don't really work like that. For
> example, two different peephole optimizers will produce different code
> based on the order they're invoked. Would changing the order of
> invocation qualify as a "new optimization"?
If a platform provides multiple essentially-equally-good ways of performing
some task, a programmer should expect that implementations for that platform
may select among them in arbitrary fashion. For example, given the
declaration "int x,y,z;', the code "z=x+y;" should be expected to perform
the following three steps:
1. Load int values from storage at the addresses of x and y, in a manner
characteristic of the underlying platform (iamcotup)
2. Compute the sum of the values loaded in steps #1 and #2, iamcotup.
3. Store the computed sum as int, to the address of z, iamcotup.
Since loading x and then y, or loading y and then x, would both be perfectly
natural ways of accomplishing the task, the choice of which variable to load
first would be up to the compiler. For a compiler to base its choice on
arbitrary factors would be unsurprising; for future compilers to base it on
different arbitrary factors would thus also be unsurprising.
> If so, you're insisting that the internal structure of the compiler
> must, essentially, freeze, and that's not going to happen.
Compilers can have a great deal of freedom while still supporting the same
semantics supported by mindless translators. Further, if one takes such
semantics as a starting point and then grants permission to loosen some
aspects without jumping the rails, compilers can have more freedom than
would be possible with strictly-conforming code.
For example, if code specifies that it is acceptable for signed integer
types to behave non-deterministically as though they can hold values outside
their range, but the effect of overflow must be limited to creating such
non-deterministic values, a compiler would have a lot more freedom than if
the only way to avoid UB was to use unsigned types.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-13 00:28 +0000 |
| Message-ID | <87mvh4kytv.fsf@bsb.me.uk> |
| In reply to | #96444 |
supercat@casperkitty.com writes: > On Saturday, November 12, 2016 at 1:05:07 PM UTC-6, gwowen wrote: >> supercat writes: >> > Do you see any disadvantage to a compiler doing those things? >> >> If they're possible. But optimizers don't really work like that. For >> example, two different peephole optimizers will produce different code >> based on the order they're invoked. Would changing the order of >> invocation qualify as a "new optimization"? > > If a platform provides multiple essentially-equally-good ways of performing > some task, a programmer should expect that implementations for that platform > may select among them in arbitrary fashion. For example, given the > declaration "int x,y,z;', the code "z=x+y;" should be expected to perform > the following three steps: > > 1. Load int values from storage at the addresses of x and y, in a manner > characteristic of the underlying platform (iamcotup) > > 2. Compute the sum of the values loaded in steps #1 and #2, iamcotup. > > 3. Store the computed sum as int, to the address of z, iamcotup. It's possible the mysterious "iamcotup" provides some context that would explain why I'm baffled by this expectation of yours, but *my* expectations are quite different. Since the code works on indeterminate values, I'd expect that not doing anything is also a strong possibility. And if you intended there to be code that gives x and y values, then I'd expect the compiler to know that one or other may already be available without a load. And I'd expect no store to z to be a possibility if it is used in such a way that it's not needed (z = x + y; return z * z;). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat <flatfinger@casperkitty.com> |
|---|---|
| Date | 2016-11-12 17:36 -0800 |
| Message-ID | <7f59dd53-a2fd-4e61-85b9-308790eeab7d@googlegroups.com> |
| In reply to | #96445 |
On Saturday, November 12, 2016 at 6:28:35 PM UTC-6, Ben Bacarisse wrote: > supercat writes: > > 1. Load int values from storage at the addresses of x and y, in a manner > > characteristic of the underlying platform (iamcotup) > > > > 2. Compute the sum of the values loaded in steps #1 and #2, iamcotup. > > > > 3. Store the computed sum as int, to the address of z, iamcotup. > > It's possible the mysterious "iamcotup" provides some context that would > explain why I'm baffled by this expectation of yours, but *my* > expectations are quite different. If the target platform is e.g. an ARM Cortex M0, I would expect that the behavior of the loads would be like that of the LDR instruction, which fetches the bottom 8 bits from the first byte, bits 8-15 from the second byte, 16-23 from the third, and 24-31 from the fourth, without regard for how those bytes got those values. The addition would be performed in wrapping two's-complement format. > Since the code works on indeterminate values, I'd expect that not doing > anything is also a strong possibility. > > And if you intended there to be code that gives x and y values, then I'd > expect the compiler to know that one or other may already be available > without a load. I should have specified the variables were global. Optimizations like you describe would be expected and desirable in cases where code would still behave as though all operations were decomposed like that, or where the programmer had indicated that certain optimizations inconsistent with that model would be acceptable. For example, the programmer may invite the implementation to assume that an lvalue which is read after having been accessed previously will still hold the same value as when it was last accessed, *unless* something has happened in the interim to suggest the value might have changed. > And I'd expect no store to z to be a possibility if it is used in such a > way that it's not needed (z = x + y; return z * z;). As above, such optimizations would be expected and desirable in cases where they would be consistent with the model, or where the programmer has explicitly allowed them (e.g. stores may be deferred provided that loads used the cached value, and provided that stores are not deferred across anything that would suggest that something else might need to read the associated storage.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-13 10:20 +0000 |
| Message-ID | <877f87llzn.fsf@bsb.me.uk> |
| In reply to | #96448 |
supercat <flatfinger@casperkitty.com> writes: > On Saturday, November 12, 2016 at 6:28:35 PM UTC-6, Ben Bacarisse wrote: >> supercat writes: >> > 1. Load int values from storage at the addresses of x and y, in a manner >> > characteristic of the underlying platform (iamcotup) >> > >> > 2. Compute the sum of the values loaded in steps #1 and #2, iamcotup. >> > >> > 3. Store the computed sum as int, to the address of z, iamcotup. >> >> It's possible the mysterious "iamcotup" provides some context that would >> explain why I'm baffled by this expectation of yours, but *my* >> expectations are quite different. > > If the target platform is e.g. an ARM Cortex M0, I would expect that the > behavior of the loads would be like that of the LDR instruction, which > fetches the bottom 8 bits from the first byte, bits 8-15 from the second > byte, 16-23 from the third, and 24-31 from the fourth, without regard for > how those bytes got those values. The addition would be performed in > wrapping two's-complement format. What are "the loads"? You wrote C not assembler presumably deliberately. You are simply repeating your particular expectations (though in more detail) without explaining why you have such expectations and why yours should mine or those of anyone else. >> Since the code works on indeterminate values, I'd expect that not doing >> anything is also a strong possibility. >> >> And if you intended there to be code that gives x and y values, then I'd >> expect the compiler to know that one or other may already be available >> without a load. > > I should have specified the variables were global. Optimizations like you > describe would be expected and desirable in cases where code would still > behave as though all operations were decomposed like that, or where the > programmer had indicated that certain optimizations inconsistent with that > model would be acceptable. > > For example, the programmer may invite the implementation to assume that > an lvalue which is read after having been accessed previously will still > hold the same value as when it was last accessed, *unless* something has > happened in the interim to suggest the value might have changed. > >> And I'd expect no store to z to be a possibility if it is used in such a >> way that it's not needed (z = x + y; return z * z;). > > As above, such optimizations would be expected and desirable in cases where > they would be consistent with the model, They are. The model is called the C programming language. > or where the programmer has > explicitly allowed them (e.g. stores may be deferred provided that loads > used the cached value, and provided that stores are not deferred across > anything that would suggest that something else might need to read the > associated storage. Yes, they were explicitly allowed by your writing in C. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-13 14:37 -0800 |
| Message-ID | <7309d801-64fc-4d2b-961e-1e8b50f11389@googlegroups.com> |
| In reply to | #96458 |
On Sunday, November 13, 2016 at 4:20:35 AM UTC-6, Ben Bacarisse wrote: > supercat writes: > > > On Saturday, November 12, 2016 at 6:28:35 PM UTC-6, Ben Bacarisse wrote: > >> supercat writes: > >> > 1. Load int values from storage at the addresses of x and y, in a manner > >> > characteristic of the underlying platform (iamcotup) > >> > > >> > 2. Compute the sum of the values loaded in steps #1 and #2, iamcotup. > >> > > >> > 3. Store the computed sum as int, to the address of z, iamcotup. > >> > >> It's possible the mysterious "iamcotup" provides some context that would > >> explain why I'm baffled by this expectation of yours, but *my* > >> expectations are quite different. > > > > If the target platform is e.g. an ARM Cortex M0, I would expect that the > > behavior of the loads would be like that of the LDR instruction, which > > fetches the bottom 8 bits from the first byte, bits 8-15 from the second > > byte, 16-23 from the third, and 24-31 from the fourth, without regard for > > how those bytes got those values. The addition would be performed in > > wrapping two's-complement format. > > What are "the loads"? You wrote C not assembler presumably > deliberately. You are simply repeating your particular expectations > (though in more detail) without explaining why you have such > expectations and why yours should mine or those of anyone else. Although the Standard describes behaviors in terms of an abstract machine, nearly all useful implementations are designed to target actual hardware whose behavior is described by their documentation in much more detail than the Standard describes its abstract machine. While the Standard does not require implementations to do so, the vast majority of implementations target hardware with one or more memory units that each include one or more numbered sequences of bytes, and have ways of reading those bytes either individually or as groups that may be interpreted as other data types, and of writing individual bytes or converting other data types to groups of bytes that are then written. While some people may deride the use of C for tasks they think should be done in assembly language, the behavior of a C program on almost any real-world platform can be described as a sequence of loads, stores, and computations which will map very nicely into machine code for that platform, and C fits better with that mapping than any other language. Perhaps there should be some terminology to distinguish the family of languages which conform to the C Standard but support the semantics that are required for embedded and systems programming, from the bare minimum language defined by the Standard. > > As above, such optimizations would be expected and desirable in cases where > > they would be consistent with the model, > > They are. The model is called the C programming language. Many implementations run on real hardware with a programming model that specifies many things beyond what the C Standard requires. Embedded and systems programming would be essentially impossible if an implementation which didn't define anything beyond what the Standard requires. > > or where the programmer has > > explicitly allowed them (e.g. stores may be deferred provided that loads > > used the cached value, and provided that stores are not deferred across > > anything that would suggest that something else might need to read the > > associated storage. > > Yes, they were explicitly allowed by your writing in C. Would that apply even if I were targeting a compiler which explicitly documents behaviors beyond those in the C Standard?
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-13 22:42 +0000 |
| Message-ID | <878tsn2e8z.fsf@gmail.com> |
| In reply to | #96513 |
supercat@casperkitty.com writes:
> While some people may deride the use of C for tasks they think should be done
> in assembly language, the behavior of a C program on almost any real-world
> platform can be described as a sequence of loads, stores, and computations
> which will map very nicely into machine code for that platform, and C fits
> better with that mapping than any other language.
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?
[toc] | [prev] | [next] | [standalone]
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web