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 6 of 15 — ← Prev page 1 … 4 5 [6] 7 8 … 15 Next page →
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-11-10 11:09 +0000 |
| Message-ID | <o01kha$20c$6@news.albasani.net> |
| In reply to | #96282 |
On 2016-11-10, gwowen <gwowen@gmail.com> wrote:
> On Thursday, November 10, 2016 at 10:30:04 AM UTC, Melzzzzz wrote:
>> On 2016-11-10, gwowen <gwowen@gmail.com> wrote:
>> > On Thursday, November 10, 2016 at 9:20:09 AM UTC, Melzzzzz wrote:
>> > eadable if I did it with C11 threads.
>> >>
>> >> Ok, I understand that, but for what price? You have to link with C++
>> >> runtime and add lot of bloatware with it...
>> >
>> > I just wrote a version of my sort code for C, and a version of C++.
>> > Here are the results:
>> >
>> > sortc: 6256 bytes
>> > sortcpp: 6256 bytes.
>> >
>> > Exactly the same size.
>> >
>> > gowen@ichiro:src$ ldd sortc sortcpp
>> > sortc:
>> > linux-vdso.so.1 => (0x00007ffd5ddd7000)
>> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa1940f0000)
>> > /lib64/ld-linux-x86-64.so.2 (0x00007fa1944b5000)
>> > sortcpp:
>> > linux-vdso.so.1 => (0x00007fff7374f000)
>> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf64503000)
>> > /lib64/ld-linux-x86-64.so.2 (0x00007fcf648c8000)
>> >
>> > Oh, the bloat.
>> >
>> > For what its worth, as qsort cannot inline the comparator, here are the
>> > timings for sorting an array with 10,000,000 elements.
>>
>> And how you pass C++ template argument to C function?
>
> I can't. C doesn't support generics. So I write a non-generic C++
> function that calls the generic from the library. I have to write a one C
> function for sorting doubles, one for sorting ints, etc. As in my
> original post.
Hm. Your C code just call qsort, no?
>
> extern "C" void sort_array(double arr[],int n)
> {
> std::array(arr,arr+n);
> }
>
>> What, you have showed that C++ templates are faster then C generic
>> functions and you don't have to link this time with C++ runtime?
>
> Yes. So, the literal opposite of what you said.
You can't be serious ;)
>
>> But size in this case is not same, for sure.
>
> Yes, it is.
You claim that call to C qsort is same code size as inlining C++ sort?
>
>> It's just that compiler
>> generates same number of bytes for object files, while in memory , inlined
>> code have to consume more...
>
> This is just wrong. One copy of an inlined function is the same size as a
> non inlined function. And my C++ compiled object file with C linkage
> contains exactly one copy of the inlined function.
How can size of inlined function be same size as call to function?
Something is just wrong here...
--
press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-11-10 03:25 -0800 |
| Message-ID | <85fccac1-f3a0-40f8-90f6-d0ac40b4f780@googlegroups.com> |
| In reply to | #96284 |
On Thursday, November 10, 2016 at 9:09:38 AM UTC-2, Melzzzzz wrote:
> On 2016-11-10, gwowen wrote:
> > On Thursday, November 10, 2016 at 10:30:04 AM UTC, Melzzzzz wrote:
> >> On 2016-11-10, gwowen wrote:
> >> > On Thursday, November 10, 2016 at 9:20:09 AM UTC, Melzzzzz wrote:
> >> > eadable if I did it with C11 threads.
> >> >>
> >> >> Ok, I understand that, but for what price? You have to link with C++
> >> >> runtime and add lot of bloatware with it...
> >> >
> >> > I just wrote a version of my sort code for C, and a version of C++.
> >> > Here are the results:
> >> >
> >> > sortc: 6256 bytes
> >> > sortcpp: 6256 bytes.
> >> >
> >> > Exactly the same size.
> >> >
> >> > gowen@ichiro:src$ ldd sortc sortcpp
> >> > sortc:
> >> > linux-vdso.so.1 => (0x00007ffd5ddd7000)
> >> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa1940f0000)
> >> > /lib64/ld-linux-x86-64.so.2 (0x00007fa1944b5000)
> >> > sortcpp:
> >> > linux-vdso.so.1 => (0x00007fff7374f000)
> >> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf64503000)
> >> > /lib64/ld-linux-x86-64.so.2 (0x00007fcf648c8000)
> >> >
> >> > Oh, the bloat.
> >> >
> >> > For what its worth, as qsort cannot inline the comparator, here are the
> >> > timings for sorting an array with 10,000,000 elements.
>
> >>
> >> And how you pass C++ template argument to C function?
> >
> > I can't. C doesn't support generics. So I write a non-generic C++
> > function that calls the generic from the library. I have to write a one C
> > function for sorting doubles, one for sorting ints, etc. As in my
> > original post.
>
> Hm. Your C code just call qsort, no?
>
> >
> > extern "C" void sort_array(double arr[],int n)
> > {
> > std::array(arr,arr+n);
> > }
> >
> >> What, you have showed that C++ templates are faster then C generic
> >> functions and you don't have to link this time with C++ runtime?
>
> >
> > Yes. So, the literal opposite of what you said.
>
> You can't be serious ;)
>
> >
> >> But size in this case is not same, for sure.
> >
> > Yes, it is.
>
> You claim that call to C qsort is same code size as inlining C++ sort?
>
> >
> >> It's just that compiler
> >> generates same number of bytes for object files, while in memory , inlined
> >> code have to consume more...
> >
> > This is just wrong. One copy of an inlined function is the same size as a
> > non inlined function. And my C++ compiled object file with C linkage
> > contains exactly one copy of the inlined function.
>
> How can size of inlined function be same size as call to function?
> Something is just wrong here...
>
> --
> press any key to continue or any other to quit
Qsort is always the sample of C++ performance versus C.
I think after a few years of C, the programmer is already read to understand that inline is faster than function call if you have an small function. Then, the programmer can improve qsort with it's own specialized qsort or macros without calling the extern compare function.
I have some ideas about this in C.
inline int Comp(void *a, void *b){...}
inline void f( int (*cmp)(void*p, void*P) );
{
...
cmp(&a, &b);
...
}
f(&Comp)
Let's say both are inline. Then, C compilers could optimize and make everything inline. Similar of templates but with normal C code.
Something like: Passing a function pointer of inline function for another inline function could inline everything.
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 06:35 -0800 |
| Message-ID | <fa9b23db-8553-4cab-94d8-e85f9802a649@googlegroups.com> |
| In reply to | #96284 |
On Thursday, November 10, 2016 at 11:09:38 AM UTC, Melzzzzz wrote: > How can size of inlined function be same size as call to function? That's how the binaries turned out (when stripped). > Something is just wrong here... Maybe. Try it yourself and report your results. Here's the source code for you. http://pastebin.com/WDqZqXcB
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-11-10 16:29 +0000 |
| Message-ID | <o0278t$pi3$3@news.albasani.net> |
| In reply to | #96314 |
On 2016-11-10, gwowen <gwowen@gmail.com> wrote:
> On Thursday, November 10, 2016 at 11:09:38 AM UTC, Melzzzzz wrote:
>
>> How can size of inlined function be same size as call to function?
>
> That's how the binaries turned out (when stripped).
>
>> Something is just wrong here...
>
> Maybe. Try it yourself and report your results. Here's the source code for you.
> http://pastebin.com/WDqZqXcB
[bmaxa@maxa-pc examples]$ ldd sortcpp
linux-vdso.so.1 (0x00007ffdce549000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007efd01cd8000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007efd019d4000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007efd017bd000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007efd0141f000)
/lib64/ld-linux-x86-64.so.2 (0x00007efd02060000)
[bmaxa@maxa-pc examples]$ ldd sortc
linux-vdso.so.1 (0x00007fff927d4000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f55b30a9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f55b3447000)
[bmaxa@maxa-pc examples]$ ls -l sortc
-rwxr-xr-x 1 bmaxa users 6248 10.11.2016 17:24 sortc*
[bmaxa@maxa-pc examples]$ ls -l sortcpp
-rwxr-xr-x 1 bmaxa users 6248 10.11.2016 17:24 sortcpp*
[bmaxa@maxa-pc examples]$
Seems that C++ version *does not inline* after all, rather have specialized
versions in runtime, but I can't explain not linking with C++ runtime in
your case. Really can't.
--
press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-10 21:59 +0100 |
| Message-ID | <o02n23$c85$1@dont-email.me> |
| In reply to | #96314 |
Le 10/11/2016 à 15:35, gwowen a écrit : > On Thursday, November 10, 2016 at 11:09:38 AM UTC, Melzzzzz wrote: > >> How can size of inlined function be same size as call to function? > > That's how the binaries turned out (when stripped). > >> Something is just wrong here... > > Maybe. Try it yourself and report your results. Here's the source code for you. > http://pastebin.com/WDqZqXcB > Look: Functions have following overhead: 1: In the calling function, code is written to place the arguments at the places tha called function expects them. Some system pass them in the stack, or in registers, whatever. Code must be generated to move the data into the right position. 2: The call instruction must be issued, followed of an optional stack adjustment after the call. 3: In the called function, code must be generated to push the value of the old frame pointer and establish a frame in the stack. 4: At the end of the called function, code must be generated to restore the previous frame and put the result where the calling function expects it. Inline code could in theory eliminate some of that overhead. To (1): If the arguments are "const" (not modified) a simple renaming would be possible. But if they are modified by the called function, they must be copied anyway somewhere else, possibly in the stack. To (2) the call instruction is always saved in inline of course. But this is a very fast instruction in most processors... To (3): If the inline function is small and doesn't build much internal state it could be frameless, eliminating (3) To (4) the destruction of the frame can be saved if we do not build one. I measured this with lcc-win, and for an inlined strlen call, the generated code was smaller than a call. I generated just a tight loop searching for a zero just using register memory and going byte by byte. The code was smaller but it was awfully slow, of course, since it was going byte by byte. More clever functions for simple things like memcpy can be very fast and very complex and normally they are not inlined since... *CODE BLOAT* This is the plague for inlined code. Code has a high cost since it must be: 1) Read into the CPU i.e. passing through all cache hierarchy, 2) Big inlined code doesn't stay in the cache but a tight loop is. The problem with code bloat is that it is slow, not so much that we do not have enough memory.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-11 10:10 +1300 |
| Message-ID | <e8k61lFl834U4@mid.individual.net> |
| In reply to | #96335 |
On 11/11/16 09:59 AM, jacobnavia wrote: > > Look: Functions have following overhead: > > 1: In the calling function, code is written to place the arguments at > the places tha called function expects them. Some system pass them in > the stack, or in registers, whatever. Code must be generated to move the > data into the right position. > > 2: The call instruction must be issued, followed of an optional stack > adjustment after the call. > > 3: In the called function, code must be generated to push the value of > the old frame pointer and establish a frame in the stack. > > 4: At the end of the called function, code must be generated to restore > the previous frame and put the result where the calling function expects it. > > Inline code could in theory eliminate some of that overhead. > > > To (1): If the arguments are "const" (not modified) a simple renaming > would be possible. But if they are modified by the called function, they > must be copied anyway somewhere else, possibly in the stack. > > To (2) the call instruction is always saved in inline of course. But > this is a very fast instruction in most processors... > > To (3): If the inline function is small and doesn't build much internal > state it could be frameless, eliminating (3) > > To (4) the destruction of the frame can be saved if we do not build one. > > I measured this with lcc-win, and for an inlined strlen call, the > generated code was smaller than a call. > > I generated just a tight loop searching for a zero just using register > memory and going byte by byte. The code was smaller but it was awfully > slow, of course, since it was going byte by byte. More clever functions > for simple things like memcpy can be very fast and very complex and > normally they are not inlined since... > > *CODE BLOAT* > > This is the plague for inlined code. Code has a high cost since it must be: Don't your arguments above show that inline calls can reduce the code size rather than bloat it? That's why compilers use sensible logic to determine what should and what should not be inlined. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-10 22:27 +0100 |
| Message-ID | <o02om8$ing$1@dont-email.me> |
| In reply to | #96336 |
Le 10/11/2016 à 22:10, Ian Collins a écrit : > Don't your arguments above show that inline calls can reduce the code > size rather than bloat it? That's why compilers use sensible logic to > determine what should and what should not be inlined. Yes, inlined code CAN be smaller than a call but in a very specific case and at the expense of speed. The code was slow since iterated byte by byte. A cleverer strlen compares 8 bytes at a time or more, but it is much more complicated since you have to align at the start and at the end of the function. All this shows you the complexity of the decisions. Is it worth? I have tried to use a fast memcpy and not inline big functions... For instance in the case of qsort, much mentioned here, I am not sure if the code bloat of all those inlined qsort calls really justifies the code bloat.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-10 22:42 +0100 |
| Message-ID | <o02pjh$m4i$1@dont-email.me> |
| In reply to | #96338 |
On 10/11/16 22:27, jacobnavia wrote: > Le 10/11/2016 à 22:10, Ian Collins a écrit : >> Don't your arguments above show that inline calls can reduce the code >> size rather than bloat it? That's why compilers use sensible logic to >> determine what should and what should not be inlined. > > Yes, inlined code CAN be smaller than a call but in a very specific case > and at the expense of speed. The code was slow since iterated byte by > byte. A cleverer strlen compares 8 bytes at a time or more, but it is > much more complicated since you have to align at the start and at the > end of the function. > > All this shows you the complexity of the decisions. Is it worth? > > I have tried to use a fast memcpy and not inline big functions... > > For instance in the case of qsort, much mentioned here, I am not sure if > the code bloat of all those inlined qsort calls really justifies the > code bloat. One of the possible advantages of inlining is that at the call site, the compiler may have more information than is being passed on in the function parameters. For example, at the call site the compiler may already know that the parameters to a memcpy call are nicely aligned and that the size is a multiple of 8 - thus a fast loop of 64-byte transfers can be generated inline. You get the advantage of the complex version of the library function (such as you mention) without the overhead of figuring out things like alignment at run-time. Generally speaking, inlining opens up more optimisation opportunities. It is not uncommon for functions to be called with one or more parameters that are known at compile time - with inlining, the compiler can use those for constant propagation to generate code that is a lot better than a mere cut-and-paste from the independent function version. There are no hard and fast rules about this, of course. That is why - as Ian says - compilers use smart logic to figure out when inlining is better than function calls. They don't always get it right, but modern tools usually do quite a good job. (I haven't tried your compiler, so I can't comment on that.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-11 10:46 +1300 |
| Message-ID | <e8k859Fl834U6@mid.individual.net> |
| In reply to | #96338 |
On 11/11/16 10:27 AM, jacobnavia wrote: > Le 10/11/2016 à 22:10, Ian Collins a écrit : >> Don't your arguments above show that inline calls can reduce the code >> size rather than bloat it? That's why compilers use sensible logic to >> determine what should and what should not be inlined. > > Yes, inlined code CAN be smaller than a call but in a very specific case > and at the expense of speed. The code was slow since iterated byte by > byte. A cleverer strlen compares 8 bytes at a time or more, but it is > much more complicated since you have to align at the start and at the > end of the function. > > All this shows you the complexity of the decisions. Is it worth? The question isn't trivial for sure. The more the compiler knows about the target platform, the better it can tune this optimisation. Profile feedback optimisations can also help. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-10 16:27 -0500 |
| Message-ID | <o02onn$it8$1@jstuckle.eternal-september.org> |
| In reply to | #96336 |
On 11/10/2016 4:10 PM, Ian Collins wrote: > On 11/11/16 09:59 AM, jacobnavia wrote: >> >> Look: Functions have following overhead: >> >> 1: In the calling function, code is written to place the arguments at >> the places tha called function expects them. Some system pass them in >> the stack, or in registers, whatever. Code must be generated to move the >> data into the right position. >> >> 2: The call instruction must be issued, followed of an optional stack >> adjustment after the call. >> >> 3: In the called function, code must be generated to push the value of >> the old frame pointer and establish a frame in the stack. >> >> 4: At the end of the called function, code must be generated to restore >> the previous frame and put the result where the calling function >> expects it. >> >> Inline code could in theory eliminate some of that overhead. >> >> >> To (1): If the arguments are "const" (not modified) a simple renaming >> would be possible. But if they are modified by the called function, they >> must be copied anyway somewhere else, possibly in the stack. >> >> To (2) the call instruction is always saved in inline of course. But >> this is a very fast instruction in most processors... >> >> To (3): If the inline function is small and doesn't build much internal >> state it could be frameless, eliminating (3) >> >> To (4) the destruction of the frame can be saved if we do not build one. >> >> I measured this with lcc-win, and for an inlined strlen call, the >> generated code was smaller than a call. >> >> I generated just a tight loop searching for a zero just using register >> memory and going byte by byte. The code was smaller but it was awfully >> slow, of course, since it was going byte by byte. More clever functions >> for simple things like memcpy can be very fast and very complex and >> normally they are not inlined since... >> >> *CODE BLOAT* >> >> This is the plague for inlined code. Code has a high cost since it >> must be: > > Don't your arguments above show that inline calls can reduce the code > size rather than bloat it? That's why compilers use sensible logic to > determine what should and what should not be inlined. > It depends, Ian. If the function is very short - that is, smaller than the code required to call and return - then yes, inlining it would reduce the generated code size. However, in the case of a larger function, inlining the function would increase the code size. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-10 22:47 +0100 |
| Message-ID | <o02ps7$n5h$1@dont-email.me> |
| In reply to | #96339 |
On 10/11/16 22:27, Jerry Stuckle wrote: > On 11/10/2016 4:10 PM, Ian Collins wrote: >> On 11/11/16 09:59 AM, jacobnavia wrote: >>> >>> Look: Functions have following overhead: >>> >>> 1: In the calling function, code is written to place the arguments at >>> the places tha called function expects them. Some system pass them in >>> the stack, or in registers, whatever. Code must be generated to move the >>> data into the right position. >>> >>> 2: The call instruction must be issued, followed of an optional stack >>> adjustment after the call. >>> >>> 3: In the called function, code must be generated to push the value of >>> the old frame pointer and establish a frame in the stack. >>> >>> 4: At the end of the called function, code must be generated to restore >>> the previous frame and put the result where the calling function >>> expects it. >>> >>> Inline code could in theory eliminate some of that overhead. >>> >>> >>> To (1): If the arguments are "const" (not modified) a simple renaming >>> would be possible. But if they are modified by the called function, they >>> must be copied anyway somewhere else, possibly in the stack. >>> >>> To (2) the call instruction is always saved in inline of course. But >>> this is a very fast instruction in most processors... >>> >>> To (3): If the inline function is small and doesn't build much internal >>> state it could be frameless, eliminating (3) >>> >>> To (4) the destruction of the frame can be saved if we do not build one. >>> >>> I measured this with lcc-win, and for an inlined strlen call, the >>> generated code was smaller than a call. >>> >>> I generated just a tight loop searching for a zero just using register >>> memory and going byte by byte. The code was smaller but it was awfully >>> slow, of course, since it was going byte by byte. More clever functions >>> for simple things like memcpy can be very fast and very complex and >>> normally they are not inlined since... >>> >>> *CODE BLOAT* >>> >>> This is the plague for inlined code. Code has a high cost since it >>> must be: >> >> Don't your arguments above show that inline calls can reduce the code >> size rather than bloat it? That's why compilers use sensible logic to >> determine what should and what should not be inlined. >> > > It depends, Ian. If the function is very short - that is, smaller than > the code required to call and return - then yes, inlining it would > reduce the generated code size. However, in the case of a larger > function, inlining the function would increase the code size. > That is sometimes true, but not always. Constant propagation from parameters can often reduce the size (and run time) of the inlined code compared to the independent function's size. Knowledge of the functions return values may let the compiler generate better code for other parts of the calling function. And of course, if the called function is only used once in the program, inlining will always make the code shorter in total (assuming the compiler and/or linker is smart enough to eliminate the unused outlined version). When to inline, and how to inline, is a major area of compiler optimisation effort. Some compilers will even do partial inlining - moving bits of the called function into the caller, and leaving other bits as separate called code.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-10 19:29 -0500 |
| Message-ID | <o033bn$q6l$1@jstuckle.eternal-september.org> |
| In reply to | #96347 |
On 11/10/2016 4:47 PM, David Brown wrote: > On 10/11/16 22:27, Jerry Stuckle wrote: >> On 11/10/2016 4:10 PM, Ian Collins wrote: >>> On 11/11/16 09:59 AM, jacobnavia wrote: >>>> >>>> Look: Functions have following overhead: >>>> >>>> 1: In the calling function, code is written to place the arguments at >>>> the places tha called function expects them. Some system pass them in >>>> the stack, or in registers, whatever. Code must be generated to move >>>> the >>>> data into the right position. >>>> >>>> 2: The call instruction must be issued, followed of an optional stack >>>> adjustment after the call. >>>> >>>> 3: In the called function, code must be generated to push the value of >>>> the old frame pointer and establish a frame in the stack. >>>> >>>> 4: At the end of the called function, code must be generated to restore >>>> the previous frame and put the result where the calling function >>>> expects it. >>>> >>>> Inline code could in theory eliminate some of that overhead. >>>> >>>> >>>> To (1): If the arguments are "const" (not modified) a simple renaming >>>> would be possible. But if they are modified by the called function, >>>> they >>>> must be copied anyway somewhere else, possibly in the stack. >>>> >>>> To (2) the call instruction is always saved in inline of course. But >>>> this is a very fast instruction in most processors... >>>> >>>> To (3): If the inline function is small and doesn't build much internal >>>> state it could be frameless, eliminating (3) >>>> >>>> To (4) the destruction of the frame can be saved if we do not build >>>> one. >>>> >>>> I measured this with lcc-win, and for an inlined strlen call, the >>>> generated code was smaller than a call. >>>> >>>> I generated just a tight loop searching for a zero just using register >>>> memory and going byte by byte. The code was smaller but it was awfully >>>> slow, of course, since it was going byte by byte. More clever functions >>>> for simple things like memcpy can be very fast and very complex and >>>> normally they are not inlined since... >>>> >>>> *CODE BLOAT* >>>> >>>> This is the plague for inlined code. Code has a high cost since it >>>> must be: >>> >>> Don't your arguments above show that inline calls can reduce the code >>> size rather than bloat it? That's why compilers use sensible logic to >>> determine what should and what should not be inlined. >>> >> >> It depends, Ian. If the function is very short - that is, smaller than >> the code required to call and return - then yes, inlining it would >> reduce the generated code size. However, in the case of a larger >> function, inlining the function would increase the code size. >> > > That is sometimes true, but not always. Constant propagation from > parameters can often reduce the size (and run time) of the inlined code > compared to the independent function's size. Knowledge of the functions > return values may let the compiler generate better code for other parts > of the calling function. > Which goes back to my original statement. > And of course, if the called function is only used once in the program, > inlining will always make the code shorter in total (assuming the > compiler and/or linker is smart enough to eliminate the unused outlined > version). > If... dog... rabbit. We aren't talking about a single call here, David. But you feel the need to argue anyway, don't you? > When to inline, and how to inline, is a major area of compiler > optimisation effort. Some compilers will even do partial inlining - > moving bits of the called function into the caller, and leaving other > bits as separate called code. > > Which has nothing to do with the other comments here. But I would be interested in knowing exactly which compilers, and under which circumstances. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-11 09:17 +0100 |
| Message-ID | <o03uqn$74v$1@dont-email.me> |
| In reply to | #96366 |
On 11/11/16 01:29, Jerry Stuckle wrote:
> On 11/10/2016 4:47 PM, David Brown wrote:
>> On 10/11/16 22:27, Jerry Stuckle wrote:
>>> On 11/10/2016 4:10 PM, Ian Collins wrote:
>>>> On 11/11/16 09:59 AM, jacobnavia wrote:
>>>>>
>>>>> Look: Functions have following overhead:
>>>>>
>>>>> 1: In the calling function, code is written to place the arguments at
>>>>> the places tha called function expects them. Some system pass them in
>>>>> the stack, or in registers, whatever. Code must be generated to move
>>>>> the
>>>>> data into the right position.
>>>>>
>>>>> 2: The call instruction must be issued, followed of an optional stack
>>>>> adjustment after the call.
>>>>>
>>>>> 3: In the called function, code must be generated to push the value of
>>>>> the old frame pointer and establish a frame in the stack.
>>>>>
>>>>> 4: At the end of the called function, code must be generated to restore
>>>>> the previous frame and put the result where the calling function
>>>>> expects it.
>>>>>
>>>>> Inline code could in theory eliminate some of that overhead.
>>>>>
>>>>>
>>>>> To (1): If the arguments are "const" (not modified) a simple renaming
>>>>> would be possible. But if they are modified by the called function,
>>>>> they
>>>>> must be copied anyway somewhere else, possibly in the stack.
>>>>>
>>>>> To (2) the call instruction is always saved in inline of course. But
>>>>> this is a very fast instruction in most processors...
>>>>>
>>>>> To (3): If the inline function is small and doesn't build much internal
>>>>> state it could be frameless, eliminating (3)
>>>>>
>>>>> To (4) the destruction of the frame can be saved if we do not build
>>>>> one.
>>>>>
>>>>> I measured this with lcc-win, and for an inlined strlen call, the
>>>>> generated code was smaller than a call.
>>>>>
>>>>> I generated just a tight loop searching for a zero just using register
>>>>> memory and going byte by byte. The code was smaller but it was awfully
>>>>> slow, of course, since it was going byte by byte. More clever functions
>>>>> for simple things like memcpy can be very fast and very complex and
>>>>> normally they are not inlined since...
>>>>>
>>>>> *CODE BLOAT*
>>>>>
>>>>> This is the plague for inlined code. Code has a high cost since it
>>>>> must be:
>>>>
>>>> Don't your arguments above show that inline calls can reduce the code
>>>> size rather than bloat it? That's why compilers use sensible logic to
>>>> determine what should and what should not be inlined.
>>>>
>>>
>>> It depends, Ian. If the function is very short - that is, smaller than
>>> the code required to call and return - then yes, inlining it would
>>> reduce the generated code size. However, in the case of a larger
>>> function, inlining the function would increase the code size.
>>>
>>
>> That is sometimes true, but not always. Constant propagation from
>> parameters can often reduce the size (and run time) of the inlined code
>> compared to the independent function's size. Knowledge of the functions
>> return values may let the compiler generate better code for other parts
>> of the calling function.
>>
>
> Which goes back to my original statement.
>
>> And of course, if the called function is only used once in the program,
>> inlining will always make the code shorter in total (assuming the
>> compiler and/or linker is smart enough to eliminate the unused outlined
>> version).
>>
>
> If... dog... rabbit. We aren't talking about a single call here, David.
> But you feel the need to argue anyway, don't you?
I was not arguing - I was adding more comments. Not everything is an
argument, you know.
>
>> When to inline, and how to inline, is a major area of compiler
>> optimisation effort. Some compilers will even do partial inlining -
>> moving bits of the called function into the caller, and leaving other
>> bits as separate called code.
>>
>>
>
> Which has nothing to do with the other comments here. But I would be
> interested in knowing exactly which compilers, and under which
> circumstances.
>
gcc has partial inlining, introduced in version 4.6.
Just for fun, I tried provoking partial inlining, testing using the
online compiler at <http://gcc.godbolt.org/> with gcc 6.1 (the version
is not that important, but this example only works from 4.8 upwards) and
optimisation -O2. The online compiler is C++, but works fine here.
I made a function "foo" that has a short path and a long path (full of
meaningless calculations) depending on one of the parameters. gcc
inlines this "if (skip) return a + b;" part into the calling functions
x1 and x2, but leaves the long part as a single compiled block.
#include <stdlib.h>
int foo(bool skip, int a, int b, int c) {
if (skip) return a + b;
int x = 1;
int *p = (int*) malloc(a * sizeof(int));
for (int n = 0; n < a; n++) {
p[n] = x * b + rand();
x += c;
}
int y = 0;
for (int n = a - 1; n > 0; n--) {
y <<= 1;
y += p[n];
}
free(p);
return x;
}
int x1(bool skip, int a, int b) {
return foo(skip, a, b, (2*a + b));
}
int x2(bool skip, int a, int b) {
return foo(skip, a, b, (2*a - b));
}
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-10 13:45 -0800 |
| Message-ID | <626639a9-393c-46a4-bdd7-593bb6db5a62@googlegroups.com> |
| In reply to | #96335 |
On Thursday, November 10, 2016 at 2:59:20 PM UTC-6, jacobnavia wrote: > Look: Functions have following overhead: ... > Inline code could in theory eliminate some of that overhead. Another important way in-line expansion can improve efficiency occurs if a compile-time constant is passed to an inline function. Values computed based upon that constant can be computed at compile time. For some kinds of function, it makes sense to in-line them in the case where values are known, but not when they aren't. As a simple example, an in-line function like: pin_out(PIN_PUMP_ENABLE,1); might expand to a single instruction even if much more complicated code would have been required if either argument hadn't been a constant.
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 06:58 -0800 |
| Message-ID | <d1339fae-00f1-4a9c-8d1e-14a5f2bbaf41@googlegroups.com> |
| In reply to | #96284 |
On Thursday, November 10, 2016 at 11:09:38 AM UTC, Melzzzzz wrote: > How can size of inlined function be same size as call to function? > Something is just wrong here... Having dived a bit deeper ... it looks like the linker pads the executable a lot and strip reduce the binary beyond that size. The object sortc.o is 1.5k (just calls qsort()) and sortcpp.o is 3.5k (inlined sort), but when linked to main() the 2k size difference evaporates.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-11-10 16:31 +0000 |
| Message-ID | <o027da$pi3$4@news.albasani.net> |
| In reply to | #96318 |
On 2016-11-10, gwowen <gwowen@gmail.com> wrote: > On Thursday, November 10, 2016 at 11:09:38 AM UTC, Melzzzzz wrote: > >> How can size of inlined function be same size as call to function? >> Something is just wrong here... > > Having dived a bit deeper ... it looks like the linker pads the > executable a lot and strip reduce the binary beyond that size. > > The object sortc.o is 1.5k (just calls qsort()) and sortcpp.o is 3.5k > (inlined sort), but when linked to main() the 2k size difference > evaporates. > Heh, thanks for explaining ;) I thought I must have gone crazy, as it is simple and logical to conclude size can't be same;) -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-10 21:41 +0100 |
| Message-ID | <o02m1p$7nt$1@dont-email.me> |
| In reply to | #96282 |
Le 10/11/2016 à 11:58, gwowen a écrit : > I can't. C doesn't support generics. So I write a non-generic C++ function that calls the generic from the library. I have to write a one C function for sorting doubles, one for sorting ints, etc. No You can do it in C using the preprocessor. Within lcc-win, you have operator overloading (what is a very simple extension of C) and you can have most of generics without much complexity. I did not use operator overloading in the ccl for keeping things simple, but that very small extension to C would simplify things. But all of that would be moot (including templaates in c++) if we devise a language where the programmer could specify the compilation himself, i.e. generate code at compile time according to syntactic events that the compiler generates as it goes through the program text.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-10 20:57 +0000 |
| Message-ID | <87y40ruk7u.fsf@gmail.com> |
| In reply to | #96333 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 10/11/2016 à 11:58, gwowen a écrit : >> I can't. C doesn't support generics. > >> So I write a non-generic C++ function that calls the generic from the >> library. >> I have to write a one C function for sorting doubles, one for sorting >> ints, etc. > No. You can do it in C using the preprocessor. Yes you're right. I actually considered mentioning this, but decided against it.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-10 22:16 +0100 |
| Message-ID | <o02o2a$gd7$1@dont-email.me> |
| In reply to | #96334 |
Le 10/11/2016 à 21:57, Gareth Owen a écrit :
> I actually considered mentioning this, but decided against it.
And the reason was?
Why is the pre-processor such an "evil"?
Look at this for instance: (this is the "valarraygen.c file of the ccl)
81 static int ResizeTo(ValArray *AL,size_t newcapacity)
82 {
83 ElementType *oldcontents;
84
85 if (AL->capacity == newcapacity) return 0;
86 oldcontents = AL->contents;
87 AL->contents = AL->Allocator->realloc(AL->contents,newcapacity
* sizeof(ElementType));
88 if (AL->contents == NULL) {
89 AL->contents = oldcontents;
90 return NoMemory("ResizeTo");
91 }
92 AL->capacity = newcapacity;
93 AL->timestamp++;
94 return 1;
95 }
ElementType is a macro. A plain #define with the name of the underlying
type.
I find it OK, you can do a lot of things with the preprocessor.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-10 13:35 -0800 |
| Message-ID | <lntwbfnhln.fsf@kst-u.example.com> |
| In reply to | #96337 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 10/11/2016 à 21:57, Gareth Owen a écrit :
>> I actually considered mentioning this, but decided against it.
>
> And the reason was?
>
> Why is the pre-processor such an "evil"?
>
> Look at this for instance: (this is the "valarraygen.c file of the ccl)
>
> 81 static int ResizeTo(ValArray *AL,size_t newcapacity)
> 82 {
> 83 ElementType *oldcontents;
> 84
> 85 if (AL->capacity == newcapacity) return 0;
> 86 oldcontents = AL->contents;
> 87 AL->contents = AL->Allocator->realloc(AL->contents,newcapacity
> * sizeof(ElementType));
> 88 if (AL->contents == NULL) {
> 89 AL->contents = oldcontents;
> 90 return NoMemory("ResizeTo");
> 91 }
> 92 AL->capacity = newcapacity;
> 93 AL->timestamp++;
> 94 return 1;
> 95 }
>
> ElementType is a macro. A plain #define with the name of the underlying
> type.
>
> I find it OK, you can do a lot of things with the preprocessor.
I'm probably missing some context here, but what is the advantage of
making ElementType a macro rather than a typedef?
In particular, if ElementType is `int[3]`, then
ElementType *oldcontents;
is a syntax error.
--
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]
Page 6 of 15 — ← Prev page 1 … 4 5 [6] 7 8 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web