Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106884 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2017-03-24 11:25 +0100 |
| Last post | 2017-03-30 00:50 -0700 |
| Articles | 20 on this page of 287 — 34 participants |
Back to article view | Back to comp.lang.c
Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 11:25 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 11:04 +0000
Re: Even more problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 11:44 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 12:59 +0100
Re: Even more problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 14:06 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 13:01 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 12:39 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:17 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 13:38 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:50 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 14:06 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 14:20 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:49 +0100
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-24 16:35 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 14:51 +0000
Re: Even more problems with lcc-win Noob <root@127.0.0.1> - 2017-03-24 23:36 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:43 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 17:57 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 18:13 +0000
Re: Even more problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 18:32 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 12:11 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 19:56 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 13:48 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 21:17 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 22:40 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 21:56 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:14 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 01:19 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 01:30 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-25 12:46 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 20:10 +0000
Re: Even more problems with lcc-win gordonb.l3ybu@burditt.org (Gordon Burditt) - 2017-03-27 03:34 -0500
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 11:41 +0100
Re: Even more problems with lcc-win gordonb.15yss@burditt.org (Gordon Burditt) - 2017-03-27 14:48 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 13:31 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-27 22:22 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 15:05 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-27 23:22 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-28 00:35 +0200
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 19:09 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-21 21:01 +0200
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 12:33 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-21 21:44 +0200
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 13:37 -0700
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:03 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-21 13:15 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-21 13:35 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-21 15:30 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-21 18:44 -0500
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:08 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 10:26 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-23 19:08 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 14:26 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 16:52 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 16:31 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-23 20:42 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-23 22:32 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:37 +0000
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 07:13 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-27 07:54 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-27 18:20 -0500
Re: Even more problems with lcc-win Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:23 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-30 18:18 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:12 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-05-01 11:14 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:29 -0500
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-27 16:00 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-28 13:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 15:20 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 16:50 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 09:28 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 19:45 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 12:06 -0700
Re: Even more problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-28 20:14 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 20:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 21:33 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-28 13:10 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 22:15 +0200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:23 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 21:29 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 20:47 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-28 22:46 +0200
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-28 23:46 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 00:53 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 02:00 +0100
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:05 -0700
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-29 10:57 -0400
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 17:06 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 08:39 -0700
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-30 18:29 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-28 23:44 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 12:33 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 08:54 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 17:38 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 16:42 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 10:28 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 20:09 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 13:29 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:18 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-30 08:22 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 00:20 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 15:38 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:19 +0000
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 18:29 -0500
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 01:36 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 22:36 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 23:50 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 10:57 +1300
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-29 15:10 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 11:15 +1300
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-30 09:22 -0700
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 18:50 +0200
Re: Even more problems with lcc-win David Kleinecke <dkleinecke@gmail.com> - 2017-03-31 09:31 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 10:26 +0200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 13:23 +0000
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:01 -0500
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-02 13:51 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-02 23:04 +0200
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:45 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-03 22:09 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 23:24 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 15:52 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-30 12:26 +1300
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 12:00 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 12:43 +0200
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-30 13:38 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 14:21 +0200
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-31 04:30 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-31 09:39 +0200
Re: Even more problems with lcc-win jadill33@gmail.com - 2017-03-30 07:12 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 12:10 -0500
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-29 13:25 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 14:55 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 16:11 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 16:40 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-29 18:14 +0200
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-30 18:32 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 20:53 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-21 00:36 +0100
Re: Even more problems with lcc-win Thiago Adams <thiago.adams@gmail.com> - 2017-04-24 05:41 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-24 15:14 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-04-26 14:02 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-26 16:04 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-27 12:24 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-27 14:43 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-29 23:21 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-29 23:58 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 11:10 +0200
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 00:09 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 01:51 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 01:58 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 12:24 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:29 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 14:36 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 16:23 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-01 11:59 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-01 14:41 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 11:08 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-03 12:02 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 14:32 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-03 14:40 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 16:47 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 16:56 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 18:06 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-07 20:02 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 19:49 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-08 13:26 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 13:33 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-08 16:27 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 22:28 +0100
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-09 13:54 +1200
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-04-09 07:55 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:24 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:45 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-09 10:53 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-09 14:03 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-10 16:17 -0700
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-14 10:24 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-14 12:29 -0700
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-09 13:04 +0000
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-04-08 14:13 +0100
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 14:33 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-04-08 07:36 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-08 10:22 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-07 11:11 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 19:28 +0100
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-04-07 11:44 -0700
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-04-08 08:00 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 12:29 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-07 13:46 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-07 14:10 +0100
Re: Even more problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-30 21:59 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-31 00:19 +0100
Re: Even more problems with lcc-win me <crisdunbar@gmail.com> - 2017-03-30 17:53 -0700
Re: Even more problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-31 11:34 +0200
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 12:35 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 04:38 -0700
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 13:14 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:38 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-31 08:52 +1300
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-02 13:58 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-02 17:02 +0200
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-04-03 17:50 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-04-03 23:10 +0200
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-03 07:20 +1200
Optimized? (Was: Even more problems with lcc-win) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-02 19:39 +0000
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-02 15:59 -0400
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-02 14:11 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-04-03 17:08 +1200
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-04-03 13:42 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 13:06 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 14:58 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 14:50 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 16:27 +0200
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 16:57 +0100
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 14:31 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 15:54 -0500
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-28 08:07 -0700
Re: Even more problems with lcc-win gordonb.uls6t@burditt.org (Gordon Burditt) - 2017-03-29 18:17 -0500
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 19:20 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-30 18:49 +0000
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-03-30 20:07 +0100
Re: Even more problems with lcc-win gordonb.b709o@burditt.org (Gordon Burditt) - 2017-04-16 03:45 -0500
Re: Even more problems with lcc-win bartc <bc@freeuk.com> - 2017-04-16 16:34 +0100
Re: Even more problems with lcc-win Noob <root@127.0.0.1> - 2017-04-16 20:27 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-04-16 12:16 -0700
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-04-17 02:29 -0500
Re: Even more problems with lcc-win Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-27 19:01 -0400
Re: Even more problems with lcc-win raltbos@xs4all.nl (Richard Bos) - 2017-03-25 21:45 +0000
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 23:19 +0100
Re: Even more problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-25 19:10 -0400
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-26 00:54 +0100
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-03-25 19:48 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-26 05:12 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-26 14:00 -0700
Re: Even more problems with lcc-win gordonb.zdxct@burditt.org (Gordon Burditt) - 2017-03-27 02:03 -0500
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:39 -0500
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 09:13 +0100
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 11:24 +0000
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 08:42 +1300
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 19:51 +0000
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 09:10 +1300
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-25 20:24 +0000
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-25 13:43 -0700
Re: Even more problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-26 10:30 +1300
Re: Even more problems with lcc-win Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-26 10:23 +0200
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 15:08 -0700
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-24 22:43 +0000
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 15:55 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 16:27 -0700
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:17 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-25 01:18 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 15:06 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 16:37 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 16:25 +0000
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 17:57 +0000
Re: Even more problems with lcc-win BartC <bc@freeuk.com> - 2017-03-27 19:12 +0100
Re: Even more problems with lcc-win Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 14:19 -0500
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 19:25 +0100
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 08:10 -0700
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 13:01 +0000
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 15:50 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 13:07 +0100
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 15:48 +0100
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-24 16:26 +0100
Re: Even more problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-24 16:32 +0000
Re: Even more problems with lcc-win James Kuyper <jameskuyper@verizon.net> - 2017-03-24 12:53 -0400
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-24 18:24 +0100
Re: Even more problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 17:29 +0000
Re: Even more problems with lcc-win jameskuyper@verizon.net - 2017-03-24 10:55 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-24 10:47 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-24 09:37 -0700
Re: Even more problems with lcc-win Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:07 -0500
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 09:56 -0700
Re: Even more problems with lcc-win supercat@casperkitty.com - 2017-03-29 10:39 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-29 12:22 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-29 15:10 -0700
Re: Even more problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-29 16:58 -0700
Re: Even more problems with Seed7 jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-30 01:02 +0200
Re: Even more problems with Seed7 Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 01:05 -0500
Re: Even more problems with Seed7 Robert Wessel <robertwessel2@yahoo.com> - 2017-03-30 01:19 -0500
Re: Even more problems with Seed7 mertesthomas@gmail.com - 2017-04-02 04:19 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 00:34 -0700
Re: Even more problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-30 13:05 +0200
Re: Even more problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-31 00:00 +0200
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-04-02 00:28 -0700
Re: Even more problems with lcc-win mertesthomas@gmail.com - 2017-03-30 00:50 -0700
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-24 15:14 +0100 |
| Message-ID | <zLnLA.1204021$Pm3.527193@fx42.am4> |
| In reply to | #108401 |
On 24/04/2017 13:41, Thiago Adams wrote:
> On Thursday, April 20, 2017 at 8:36:05 PM UTC-3, Bart wrote:
>> I managed a version a few days early, that could compile 'hello world'.
>> But it's taken a further week to get it to compile itself. The project
>> is here:
>>
>> https://github.com/bartg/langs/tree/master/bccproj
> I would like to understand how to generate assembly and executable files.
> What's is the output of your compiler?
The output is assembly source code.
That's not ideal, as it requires extra steps to use the output, which
here are not automatic, not if running the compiler directly.
(With my IDE, it doesn't care, as it /will/ apply the extra step, and an
object file is generated just like any other C compiler. But it wasn't
meant to be like any other compiler. I will change that but apply it
first to another project, then see how if I can port that into this C
compiler.)
But at the minute, input like this (hello.c):
#include <stdio.h>
int main(void) {
printf("Hello World!\n");
}
generates this output file (hello.asm64 using Nasm syntax):
; Module:hello
%include "mccasm.inc"
extern printf
global main
; Proc:main
segment .text
main:
sub Dstack,8
sub Dstack,32
mov D0,KK1
mov [Dstack],D0
mov D10,[Dstack]
call printf
add Dstack,32
L1:
add Dstack,8
mov A0,0
extern exit
sub Dstack,40
call exit
extern exit
sub Dstack,40
call exit
; End
segment .data
;string table:
KK1: db 'Hello World!',10,0
You can see the code needs some attention. (Also Nasm is a terrible
assembler, performance-wise, and I might replace it.)
> What is the link for the aims of your other static language?
(Nothing much, except I will redo the module system as I don't like how
it works now. And do a fast compiler for it like the C one.)
> For thouse interested in languages I also recommend other works.
> https://github.com/gingerBill/Odin
>
> and Rust language.
I looked at Rust. It looked great at first until I read more and more of
it. I think it would make coding harder than easier.
> I have used C and C++, but the language I would like to have is something in between compatible with C.
My experience of implementing C hasn't been positive. It's such an
untidy, sprawling language with lots of little known features (few of
which I've bothered to implement, yet my programs still work!).
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-04-26 14:02 +0000 |
| Message-ID | <odq9aj$e1g$1@z-news.wcss.wroc.pl> |
| In reply to | #108315 |
bartc <bc@freeuk.com> wrote:
>
> I managed a version a few days early, that could compile 'hello world'.
> But it's taken a further week to get it to compile itself. The project
> is here:
>
> https://github.com/bartg/langs/tree/master/bccproj
>
> But I can't promise it will manage to compile anything other than the
> test programs I've used.
ATM it was unable to compile _any_ my program without changes.
'fmax' is missing (trivial to work around), 'jmp_buf' (from
'setjmp.h') is missing (hard to compile any notrivial program
without this one and workarounds are rather unpractical).
There seem to be at least two independent bugs in the preprocessor.
You may wish to look at
http://www.math.uni.wroc.pl/~hebisch/tex/texinc-0.1.tar.gz
This is multifile project using Makefile, but compared to modern
projects build is very simple -- if you prefer you can just follow
instructions in the makefile. The main thing is tex.c. This
is Don Knuth TeX program converted to C. With current gcc as is
build fails due to use of 'round' function which conflicts with
C99 functions. With '-std=c89' it build OK. In a sense the code
is very stightforward. But in the past Tiny C failed to compile
it due to heavy use of structs -- code hit bug in Tiny C struct
handling. Also, original code was macroprocessed before passing
it to Pascal compiler. Convertion retains most macros from
the orignal.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-26 16:04 +0100 |
| Message-ID | <JF2MA.473312$QG3.345287@fx17.am4> |
| In reply to | #108529 |
On 26/04/2017 15:02, antispam@math.uni.wroc.pl wrote: > bartc <bc@freeuk.com> wrote: >> >> I managed a version a few days early, that could compile 'hello world'. >> But it's taken a further week to get it to compile itself. The project >> is here: >> >> https://github.com/bartg/langs/tree/master/bccproj >> >> But I can't promise it will manage to compile anything other than the >> test programs I've used. > > ATM it was unable to compile _any_ my program without changes. > 'fmax' is missing (trivial to work around), 'jmp_buf' (from > 'setjmp.h') is missing (hard to compile any notrivial program > without this one and workarounds are rather unpractical). It will necessarily be limited in what can be compiled as the supplied standard headers are so incomplete. (They only total 250 lines, and that /includes/ windows.h!) (For some testing I used headers from other compilers. For example, for sqlite3.c (some 170,000 lines), I used the standard headers and windows.h from lccwin32, and that still needed some extra #defines to get around problems. With other compilers' headers (even those from lccwin64 which I ought to use because my program is for 64 bits), that approach becomes impractical due to compiler extensions. Eg. operator overloads in lccwin64, or inline assembly in gcc/mingw.) So my headers need to be expanded. > There seem to be at least two independent bugs in the preprocessor. > > You may wish to look at > > http://www.math.uni.wroc.pl/~hebisch/tex/texinc-0.1.tar.gz I'm short of suitable test programs (which I haven't written myself, because my code is not usually challenging) to work with. The first test though is whether that code will work with any compiler (otherwise mine hasn't got a chance). Your example passes that, and it builds and runs, so thanks! I'll have a go at compiling that and hopefully my headers will become more complete. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-27 12:24 +0100 |
| Message-ID | <QxkMA.1065063$F83.228037@fx38.am4> |
| In reply to | #108529 |
On 26/04/2017 15:02, antispam@math.uni.wroc.pl wrote: > There seem to be at least two independent bugs in the preprocessor. I've found three, although the last two are related. I've fixed (1), added a bodge for (2), and will shortly do another for (3). But ... > http://www.math.uni.wroc.pl/~hebisch/tex/texinc-0.1.tar.gz (Excellent test code this. I'm working my way through it.) > This is multifile project using Makefile, but compared to modern > projects build is very simple -- if you prefer you can just follow > instructions in the makefile. The main thing is tex.c. This > is Don Knuth TeX program converted to C. With current gcc as is > build fails due to use of 'round' function which conflicts with > C99 functions. With '-std=c89' it build OK. In a sense the code > is very stightforward. But in the past Tiny C failed to compile > it due to heavy use of structs -- code hit bug in Tiny C struct > handling. ... I think Tiny C also has a bug with (3). That PP bug is this (simplified from the version in the code): #define info(x) (mem(x)) #define llink(x) info(x+1) #define prevbreak llink #define serial info serial(prevbreak(10)); Preprocessed output should be: (mem((mem(10 +1)))); But Tiny C (and my compiler at the minute) generate: (mem(info(10+1) )); However, I signal an error due to the unknown info(), but Tiny C (as is common) treats info() as an implicit function, so there is no error. This ought to be picked up at link-time, but that somehow works. So presumably there is an unrelated 'info' entity defined somewhere. Interestingly, if the preprocessed output is fed back into the compiler, it would probably work this time around! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-27 14:43 +0100 |
| Message-ID | <PzmMA.14251$MR.1092@fx35.am4> |
| In reply to | #108529 |
On 26/04/2017 15:02, antispam@math.uni.wroc.pl wrote:
> bartc <bc@freeuk.com> wrote:
>> But I can't promise it will manage to compile anything other than the
>> test programs I've used.
>
> ATM it was unable to compile _any_ my program without changes.
> 'fmax' is missing (trivial to work around), 'jmp_buf' (from
> 'setjmp.h') is missing (hard to compile any notrivial program
> without this one and workarounds are rather unpractical).
(Workarounds - making changes to programs being compiled - ought not to
be necessary. The compiler and/or headers need to change.
I've done an interim update (it won't fully compile your test yet), but
it has an option to write out the headers it's using [see the readme].
Then it becomes possible to patch those if necessary. Or simply to look
at what there is. They will be easier to understand than typical headers.
It might seem funny having DIY headers in a 'C compiler', but one
well-known one ('clang' on Windows), doesn't have any at all. That's
expected to use those from another compiler. It does make itself
compatible with any special features of that host implementation to make
that possible.
But then, it is 250 times the size of mine. Adding complexity to A to
match that of B is what I try and avoid.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-29 23:21 +0200 |
| Message-ID | <obh8c1$grl$1@dont-email.me> |
| In reply to | #107397 |
On 29/03/17 17:40, bartc wrote:
> On 29/03/2017 15:11, David Brown wrote:
>> On 29/03/17 15:55, bartc wrote:
>
>>>
>>> It seems more to be these big compilers doing exactly that: taking what
>>> could be a concise set of declarations and bloating them to unwieldy
>>> dimensions.
>>
>> Who says these are unwieldy or bloated? Except for you, of course? Has
>> it never occurred to you that there may be good reasons behind the way
>> these headers are written?
>
> And is it ever occured to /you/ that maybe, just maybe, they really
> /are/ bloated?
Oh, yes - that has occurred to me. And I have no doubt that there are
more lines or files here than might be necessary. But I also have no
doubt that it is no significant disadvantage in practice, because I have
no doubt that folks behind these headers have vastly more knowledge and
experience than you do in these matters.
All things being equal, I fully agree that fewer and smaller headers are
better than bigger ones. But all things are /not/ equal - there are
many reasons for the headers being the way they are, and many advantages
in them over simple and limited headers. And contrary to your beliefs,
it is not a significant overhead.
Just to test, I took this C file:
#include <stdio.h>
#include <stdlib.h>
#include <linux/fuse.h>
int main(void) {
return 0;
}
"fuse.h" is just a randomly picked Linux header that brings in a good
deal more header files. 46 headers in total, including duplicates - 38
without duplicates. The total is 10.6 K lines, or 336 KB of include files.
The compile time for this file was about 20 - 25 ms on my machine.
I removed the include files, so /no/ pre-processing or includes are needed.
The compile time for /this/ file was about 20 - 25 ms on my machine.
All these massive, bloated include files, with all their includes of
other files makes /no/ measurable difference whatsoever. None.
>
>> And by "reasonable expectations", you mean "what Bart thinks despite not
>> knowing why other compilers' headers are the way they are, or what they
>> do" ? Certainly it seems your concept of "reasonable expectations" is
>> highly subjective and wholly unrelated to what anyone else thinks about
>> headers.
>
> It's based on my experience of writing programs, mainly graphics apps,
> on small systems (eg 64KB, 256KB or 640KB main memory, 8 or 16-bit
> processors, with floppy disk storage, no graphics software support, no
> floating point hardware) and seeing what could be achieved with such
> limited means.
I write programs for far smaller targets than you do, and over a far
wider range. But if you are talking about the host for compiling,
rather than the target, then guess what? Normal people don't use 64K
computers for compilation any more. Fitting headers onto a floppy is
not a worry these days - and has not been for a good many years.
>
> That 700MHz ARM for RPi, with 500,000KB memory and 16 32-bit registers
> is the equivalent of a Cray supercomputer compared with what I've been
> used to, and yet a C compiler struggles to achieve 500 lines per second
> - unopotimised. Well below expectations.
Have you looked at what might be the reason for slow compiles on a Pi?
It is the file system, running off a slow SD card, that is the key
bottleneck.
But that's okay. Compilers are no longer made to run on such limited
targets - because people don't use them for compilation.
>
> Mine will work at 40-50,000 lines per second - much more within
> /expectations/. But if that has to be squandered compiling 500,000-line
> headers in 100 different files /per module/, then what's the point?
>
Well, I presume you are having fun writing your compiler - because
otherwise I really cannot see the point of it.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-29 23:58 +0100 |
| Message-ID | <VZWCA.613165$w46.3240@fx39.am4> |
| In reply to | #107421 |
On 29/03/2017 22:21, David Brown wrote: > On 29/03/17 17:40, bartc wrote: > All these massive, bloated include files, with all their includes of > other files makes /no/ measurable difference whatsoever. None. You're right. Those people who implemented precompiled headers for gcc have wasted their time! >> It's based on my experience of writing programs, mainly graphics apps, >> on small systems > I write programs for far smaller targets than you do, and over a far > wider range. End-user applications? But if you are talking about the host for compiling, > rather than the target, then guess what? Normal people don't use 64K > computers for compilation any more. Fitting headers onto a floppy is > not a worry these days - and has not been for a good many years. Maybe they should try. The quality of software could improve. Bloat could disappear. Some of it could even become efficient and responsive. But having all these resources makes people lazy, and they only take action when things grind to a halt. Usually by adding an extra layer of bloat. >> That 700MHz ARM for RPi, with 500,000KB memory and 16 32-bit registers >> is the equivalent of a Cray supercomputer compared with what I've been >> used to, and yet a C compiler struggles to achieve 500 lines per second >> - unopotimised. Well below expectations. > > Have you looked at what might be the reason for slow compiles on a Pi? > It is the file system, running off a slow SD card, that is the key > bottleneck. My system runs off the same card. It has to read the same files. But can be nearly two magnitudes faster. What is the throughput of such a SD card on USB 2.0>? It needed to read 10MB of source code, and write 1MB of output, on one test that took gcc 140 seconds. About 80KB/sec transfer rate, if that was the main bottleneck. Slightly faster than a 1.44MB floppy disk. > But that's okay. Compilers are no longer made to run on such limited > targets - because people don't use them for compilation. If this was a bare microprocessor you'd be right. But this RPi device is NOT limited, it can have a keyboard, mouse, hi-def GUI display and runs things like browsers and can play video and music. It also has 400 times as much RAM as my college mainframe which ran an assortment of compilers and supported 100 timesharing users. Compilation is a simpler task; why shouldn't it be up to it? >> Mine will work at 40-50,000 lines per second - much more within >> /expectations/. But if that has to be squandered compiling 500,000-line >> headers in 100 different files /per module/, then what's the point? >> > > Well, I presume you are having fun writing your compiler - because > otherwise I really cannot see the point of it. It will show what can be done. -- bartc --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-30 11:10 +0200 |
| Message-ID | <obihs0$lt9$1@dont-email.me> |
| In reply to | #107435 |
On 30/03/17 00:58, bartc wrote: > On 29/03/2017 22:21, David Brown wrote: >> On 29/03/17 17:40, bartc wrote: > >> All these massive, bloated include files, with all their includes of >> other files makes /no/ measurable difference whatsoever. None. > > You're right. Those people who implemented precompiled headers for gcc > have wasted their time! People don't use precompiled headers for C. They use them for C++, where you might end up with millions of lines of headers with templates and other code that really does take significant time to process. There is a huge difference between racing through function declarations, struct definitions, #define's, comments and #ifdef's, and digesting templates, inline functions, class definitions, etc. > >>> It's based on my experience of writing programs, mainly graphics apps, >>> on small systems > >> I write programs for far smaller targets than you do, and over a far >> wider range. > > End-user applications? I don't do many big end-user applications in C - but I have worked with some of the smallest 8-bit microcontrollers around, and some of the biggest. > > But if you are talking about the host for compiling, >> rather than the target, then guess what? Normal people don't use 64K >> computers for compilation any more. Fitting headers onto a floppy is >> not a worry these days - and has not been for a good many years. > > Maybe they should try. The quality of software could improve. Bloat > could disappear. Some of it could even become efficient and responsive. My code is efficient and responsive - /that/ is what is important. It does not matter if the compiler uses 100K of headers in every compile, almost all of which is ignored by any given C file. It does not matter if it takes 1 second to do the compile, or 0.5 seconds. What matters in my world at least, is that the end result is correct, the source code (/my/ code) is clear, and the resulting binaries is at least as small and fast as it needs to be. I have worked with compilers that take a few hundred KB disk space, and compilers that take a few GB disk space - what matters is that they have the features needed to let me write good code, not how big they are. > But having all these resources makes people lazy, and they only take > action when things grind to a halt. Usually by adding an extra layer of > bloat. You are mixing up the efficiency of the tools with the efficiency of the end code. And what you call "laziness", other people call "developer efficiency". Processor time is cheap - human developer time is not. > >>> That 700MHz ARM for RPi, with 500,000KB memory and 16 32-bit registers >>> is the equivalent of a Cray supercomputer compared with what I've been >>> used to, and yet a C compiler struggles to achieve 500 lines per second >>> - unopotimised. Well below expectations. >> >> Have you looked at what might be the reason for slow compiles on a Pi? >> It is the file system, running off a slow SD card, that is the key >> bottleneck. > > My system runs off the same card. It has to read the same files. But can > be nearly two magnitudes faster. What is the throughput of such a SD > card on USB 2.0>? The SD Card interface on the Pi is a good deal slower than a USB 2 based reader would be, and even that is a good deal slower than a USB flash stick or a network filessytem. > > It needed to read 10MB of source code, and write 1MB of output, on one > test that took gcc 140 seconds. About 80KB/sec transfer rate, if that > was the main bottleneck. Slightly faster than a 1.44MB floppy disk. I don't have a Pi connected at the moment, so I can't do any measurements. But I make sensible choices about my tools - it is simply daft to use a Pi for compilation when I have a desktop PC beside it. I have worked with a number of embedded Linux systems with various levels of computing resources (cpu, memory, disk). In every case, I work on my desktop where I have a couple of big monitors, lots of cpu power, memory, disk space, lots of programs and utilities, etc. I compile on the desktop, into a NFS shared area on my machine. On the embedded Linux system, it looks like a local disk - except it is a /lot/ faster than using the SD Card. > >> But that's okay. Compilers are no longer made to run on such limited >> targets - because people don't use them for compilation. > > If this was a bare microprocessor you'd be right. But this RPi device is > NOT limited, it can have a keyboard, mouse, hi-def GUI display and runs > things like browsers and can play video and music. Yes, the Pi /is/ limited. It has very slow disk speed, very limited ram, and a weak cpu in comparison to a normal PC. For some tasks, such as playing a video, it is fast enough - and once you get "fast enough" for a task like that, any speed increase is unnecessary. But it is slow for complex tasks or those that involve a lot of memory or I/O, and slow for doing several things at once. > > It also has 400 times as much RAM as my college mainframe which ran an > assortment of compilers and supported 100 timesharing users. > > Compilation is a simpler task; why shouldn't it be up to it? Compilation /can/ be a simple task, if you have a simple compiler for a simple language and have little in the way of analysis, static error checking, optimisation, extensions, etc. gcc is not a simple compiler, and it is not limited to a simple language. Even if you are compiling C, you have substantial parts of the toolchain for C++ involved (and no doubt influence from Fortran and Ada). > >>> Mine will work at 40-50,000 lines per second - much more within >>> /expectations/. But if that has to be squandered compiling 500,000-line >>> headers in 100 different files /per module/, then what's the point? >>> >> >> Well, I presume you are having fun writing your compiler - because >> otherwise I really cannot see the point of it. > > It will show what can be done. > The early aviation pioneers built their planes from sailcloth and string, to show it could be done. The early practical planes had propellers, open cockpits and two sets of wings. We don't use these any more for anything but highly specialised use. But people who build airports don't complain about having to build 10 km long runways, saying "80 years ago we had planes that could land in a 500 m field - why do we have to put up with the bloat and inefficiency of these jumbo jets?". The don't say "50 years ago we could store a plan in a shed - these modern planes are a waste of space". They don't say "60 years ago a plane could be maintained by 1 person. Now they need a crew of mechanics - it's just laziness on the part of the designers".
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-03-30 00:09 +0000 |
| Message-ID | <obhib0$stn$1@z-news.wcss.wroc.pl> |
| In reply to | #107421 |
David Brown <david.brown@hesbynett.no> wrote:
>
> Just to test, I took this C file:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <linux/fuse.h>
>
> int main(void) {
> return 0;
> }
>
> "fuse.h" is just a randomly picked Linux header that brings in a good
> deal more header files. 46 headers in total, including duplicates - 38
> without duplicates. The total is 10.6 K lines, or 336 KB of include files.
>
> The compile time for this file was about 20 - 25 ms on my machine.
>
> I removed the include files, so /no/ pre-processing or includes are needed.
>
> The compile time for /this/ file was about 20 - 25 ms on my machine.
On may machine (2.4 GHz Core 2, Debian gcc 4.9.2-10) version with
headers gave 44-46 ms. Without headers 29-31 ms. gcc -E reports
50 kB for version with headers. So cost of headers is measurable
on my machine (OTOH small enough that without measurement I would
not notice the difference).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 01:51 +0100 |
| Message-ID | <NDYCA.678492$vF2.570445@fx46.am4> |
| In reply to | #107444 |
On 30/03/2017 01:09, antispam@math.uni.wroc.pl wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> Just to test, I took this C file:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <linux/fuse.h>
>>
>> int main(void) {
>> return 0;
>> }
>>
>> "fuse.h" is just a randomly picked Linux header that brings in a good
>> deal more header files. 46 headers in total, including duplicates - 38
>> without duplicates. The total is 10.6 K lines, or 336 KB of include files.
>>
>> The compile time for this file was about 20 - 25 ms on my machine.
>>
>> I removed the include files, so /no/ pre-processing or includes are needed.
>>
>> The compile time for /this/ file was about 20 - 25 ms on my machine.
>
> On may machine (2.4 GHz Core 2, Debian gcc 4.9.2-10) version with
> headers gave 44-46 ms. Without headers 29-31 ms. gcc -E reports
> 50 kB for version with headers. So cost of headers is measurable
> on my machine (OTOH small enough that without measurement I would
> not notice the difference).
The following sets of includes take 700ms to compile with gcc -O0 on
Windows.
(Precompiling (when the following was placed in a containing header)
didn't work or didn't make any difference. If the latter, that would be
due to the overheads of reading the pch file.)
Other compilers all take less time: 570ms, 220ms, while lccwin was
around 100ms. But all are using different headers, all different sizes.
Tiny C was too small to measure.
If you multiply these figures by N modules then it can add up. And there
are user headers, and other libraries' headers to factor in.
(David Brown will now try and blame Windows OS for being so inefficient;
it's a never an inefficient compiler or a sprawling set of header files.)
#include <assert.h>
#include <complex.h>
#include <ctype.h>
#include <errno.h>
#include <fenv.h>
#include <float.h>
#include <inttypes.h>
#include <iso646.h>
#include <limits.h>
#include <locale.h>
#include <math.h>
#include <setjmp.h>
#include <signal.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <wchar.h>
#include <wctype.h>
#include <windows.h>
--
bartc
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-03-30 01:58 +0000 |
| Message-ID | <obhoon$df2$1@z-news.wcss.wroc.pl> |
| In reply to | #107446 |
bartc <bc@freeuk.com> wrote:
> On 30/03/2017 01:09, antispam@math.uni.wroc.pl wrote:
> > David Brown <david.brown@hesbynett.no> wrote:
> >>
> >> Just to test, I took this C file:
> >>
> >> #include <stdio.h>
> >> #include <stdlib.h>
> >> #include <linux/fuse.h>
> >>
> >> int main(void) {
> >> return 0;
> >> }
> >>
> >> "fuse.h" is just a randomly picked Linux header that brings in a good
> >> deal more header files. 46 headers in total, including duplicates - 38
> >> without duplicates. The total is 10.6 K lines, or 336 KB of include files.
> >>
> >> The compile time for this file was about 20 - 25 ms on my machine.
> >>
> >> I removed the include files, so /no/ pre-processing or includes are needed.
> >>
> >> The compile time for /this/ file was about 20 - 25 ms on my machine.
> >
> > On may machine (2.4 GHz Core 2, Debian gcc 4.9.2-10) version with
> > headers gave 44-46 ms. Without headers 29-31 ms. gcc -E reports
> > 50 kB for version with headers. So cost of headers is measurable
> > on my machine (OTOH small enough that without measurement I would
> > not notice the difference).
>
> The following sets of includes take 700ms to compile with gcc -O0 on
> Windows.
On my machine (as above) after removing windows.h (not present on
Linux) I get 61-89 ms (7 succesive trials give: 86, 87, 87, 86, 85, 87,
62, one of earlier trials gave 61 another earlier trial gave 89).
I also tried on Orange Pi (1.2 GHz ARM), first run was 418ms,
second 362ms.
> (Precompiling (when the following was placed in a containing header)
> didn't work or didn't make any difference. If the latter, that would be
> due to the overheads of reading the pch file.)
>
> Other compilers all take less time: 570ms, 220ms, while lccwin was
> around 100ms. But all are using different headers, all different sizes.
> Tiny C was too small to measure.
>
> If you multiply these figures by N modules then it can add up. And there
> are user headers, and other libraries' headers to factor in.
>
> (David Brown will now try and blame Windows OS for being so inefficient;
> it's a never an inefficient compiler or a sprawling set of header files.)
The timings have something to do with Windows. Either windows.h
is so bloated, or other headers are more bloated (on Linux gcc -E
gives me about 156 kB) or gcc on Windows is less efficient, or
Windows file handling is less efficient.
> #include <assert.h>
> #include <complex.h>
> #include <ctype.h>
> #include <errno.h>
> #include <fenv.h>
> #include <float.h>
> #include <inttypes.h>
> #include <iso646.h>
> #include <limits.h>
> #include <locale.h>
> #include <math.h>
> #include <setjmp.h>
> #include <signal.h>
> #include <stdarg.h>
> #include <stdbool.h>
> #include <stddef.h>
> #include <stdint.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <time.h>
> #include <wchar.h>
> #include <wctype.h>
> #include <windows.h>
>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 12:24 +0100 |
| Message-ID | <IV5DA.211948$PU6.150214@fx13.am4> |
| In reply to | #107448 |
On 30/03/2017 02:58, antispam@math.uni.wroc.pl wrote: > bartc <bc@freeuk.com> wrote: >> The following sets of includes take 700ms to compile with gcc -O0 on >> Windows. > > On my machine (as above) after removing windows.h (not present on > Linux) I get 61-89 ms (7 succesive trials give: 86, 87, 87, 86, 85, 87, > 62, one of earlier trials gave 61 another earlier trial gave 89). Which C compiler, gcc? If I remove windows.h, my gcc still gives nearly 300ms. (This is gcc/tdm/mingw 5.1. Maybe they forgot to specify -O3 when building it! Or maybe, I don't know, perhaps the port from Linux involves emulating POSIX on top of Windows calls or something, so that file ops are inefficient.) > I also tried on Orange Pi (1.2 GHz ARM), first run was 418ms, > second 362ms. On my 700MHz Pi, 'time' gives me 1.5/1.2 seconds (real/user; I don't know what the difference is.) (I used also my program, but on a smaller set of headers (still no windows.h) borrowed from lccwin32. The program tells me it took 40-70ms, but 'time' reports 0.25/0.05 seconds. However my program also displays some stats, and writing to the screen affects timings when only tens of msec are involved. If I add in <windows.h>, I get 250ms. But, stop and I think about that: I just said I compiled windows.h on Linux, and on a Pi. That was easy because in lccwin32 versions of windows.h, only 3 files I think are involved: windows.h, win.h, and basetsd.h. This shows another advantage of keeping things simple. For MSVC headers I would need to disentangle 80 files out of hundreds that pertain to windows.h. On gcc/mingw, there are 147 files, but some of those are standard headers, *and* they are split across multiple directory levels. Not quite so simple.) > The timings have something to do with Windows. Either windows.h > is so bloated, or other headers are more bloated (on Linux gcc -E > gives me about 156 kB) or gcc on Windows is less efficient, or > Windows file handling is less efficient. Some windows.h header sets are bloated (because the C implementations they go with are themselves so big and sprawling that it makes little difference). (However, the Loc figures I reported in a previous post should be clarified: they are the total source lines scanned (whether in a true or false #if block), but they are not unique lines. Because the same lines will be scanned for duplicate headers for example. So in the case of gcc's windows.h, there are 650 #includes, but only 150 unique headers (some of which are standard). The number of unique lines is the total lines in the files pertaining only to windows.h. Which I don't know. For MSVC, unique lines in windows.h-related files are just over 200Kloc, compared with over 500Kloc that are actually scanned.) -- bartc --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-30 14:29 +0200 |
| Message-ID | <obiti6$qpf$1@dont-email.me> |
| In reply to | #107468 |
On 30/03/17 13:24, bartc wrote: > On 30/03/2017 02:58, antispam@math.uni.wroc.pl wrote: >> bartc <bc@freeuk.com> wrote: > >>> The following sets of includes take 700ms to compile with gcc -O0 on >>> Windows. >> >> On my machine (as above) after removing windows.h (not present on >> Linux) I get 61-89 ms (7 succesive trials give: 86, 87, 87, 86, 85, 87, >> 62, one of earlier trials gave 61 another earlier trial gave 89). > > Which C compiler, gcc? > > If I remove windows.h, my gcc still gives nearly 300ms. (This is > gcc/tdm/mingw 5.1. Maybe they forgot to specify -O3 when building it! Or > maybe, I don't know, perhaps the port from Linux involves emulating > POSIX on top of Windows calls or something, so that file ops are > inefficient.) > >> I also tried on Orange Pi (1.2 GHz ARM), first run was 418ms, >> second 362ms. > > On my 700MHz Pi, 'time' gives me 1.5/1.2 seconds (real/user; I don't > know what the difference is.) > > (I used also my program, but on a smaller set of headers (still no > windows.h) borrowed from lccwin32. > > The program tells me it took 40-70ms, but 'time' reports 0.25/0.05 > seconds. However my program also displays some stats, and writing to the > screen affects timings when only tens of msec are involved. > > If I add in <windows.h>, I get 250ms. > > But, stop and I think about that: I just said I compiled windows.h on > Linux, and on a Pi. That was easy because in lccwin32 versions of > windows.h, only 3 files I think are involved: windows.h, win.h, and > basetsd.h. Does your compiler here generate Windows executables when running on the Pi, as a cross compiler? If not, then the ability to read some version of a "windows.h" header is totally and completely useless. It is perfectly possible to use Linux to cross-compile for Windows - most Linux distros will have a package for doing "mingw" cross-compilation, including "windows.h" files with all the bits needed. I don't have such a package installed at the moment, because I don't need to do such cross-compilation. > > This shows another advantage of keeping things simple. No, it shows another fabricated and irrelevant "advantage". > For MSVC headers > I would need to disentangle 80 files out of hundreds that pertain to > windows.h. On gcc/mingw, there are 147 files, but some of those are > standard headers, *and* they are split across multiple directory levels. > > Not quite so simple.) The MSVC headers are irrelevant to Linux, unless MS have a cross-compiler. The gcc/mingw ones /are/ relevant, and you may well find that the ability to cross-compile affects some of the conditionals, extra attributes, or structure of the include files. But the number of files and directories involved is completely irrelevant - when I type "apt-get install mingw-w64", I could not care less whether that installs 3 header files or 300 header files. > >> The timings have something to do with Windows. Either windows.h >> is so bloated, or other headers are more bloated (on Linux gcc -E >> gives me about 156 kB) or gcc on Windows is less efficient, or >> Windows file handling is less efficient. > > Some windows.h header sets are bloated (because the C implementations > they go with are themselves so big and sprawling that it makes little > difference). > > (However, the Loc figures I reported in a previous post should be > clarified: they are the total source lines scanned (whether in a true or > false #if block), but they are not unique lines. Because the same lines > will be scanned for duplicate headers for example. > > So in the case of gcc's windows.h, there are 650 #includes, but only 150 > unique headers (some of which are standard). The number of unique lines > is the total lines in the files pertaining only to windows.h. Which I > don't know. Note that on Linux and with gcc, re-reading a header file that has a suitable inclusion guard is extremely fast. The data is all there in ram and the contents of the file are skipped with almost no work - this is a case that is highly optimised in gcc. On Windows, it takes a good deal longer to read the file even if it is cached (but again, gcc will skip the contents quickly). > > For MSVC, unique lines in windows.h-related files are just over 200Kloc, > compared with over 500Kloc that are actually scanned.) >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 14:36 +0100 |
| Message-ID | <2R7DA.679006$vF2.481444@fx46.am4> |
| In reply to | #107475 |
On 30/03/2017 13:29, David Brown wrote: > On 30/03/17 13:24, bartc wrote: >> If I add in <windows.h>, I get 250ms. >> >> But, stop and I think about that: I just said I compiled windows.h on >> Linux, and on a Pi. That was easy because in lccwin32 versions of >> windows.h, only 3 files I think are involved: windows.h, win.h, and >> basetsd.h. > > Does your compiler here generate Windows executables when running on the > Pi, as a cross compiler? It doesn't generate ARM code, if that's what you mean, but there is no code involved in processing headers. But yes, it could act as a cross-compiler, if run in the mode where it generates ASM (I'll be doing that next week). But the intended mode of operation is that the compiler will generate code in-memory then execute it. For that it would need to be ARM32 code not x64. But any dependencies on gdi32.dll for example would cause problems. In short, this is just a compiler test. > If not, then the ability to read some version > of a "windows.h" header is totally and completely useless. There are several points of interest: (1) I was able to get an idea of how long my program took to perform the job of compiler all those includes plus <windows.h>, on the slow RPi Linux platform. (2) It was faster than gcc under Windows on a normal desktop PC, even though it was running on the same Linux (not Windows) machine that is apparently 300 times slower than your machine compiling those standard headers. (3) I was able to trivially port the compiler I'd been using on Windows, /and/ to trivially port the Windows-specific headers it was using. To do the equivalent using gcc from Windows and /its/ headers from Windows, just to see how long it would take to run on this board computer, would be a major undertaking. (Maybe you could do something using 'wine', and port the entire gcc/tdm directory across, but I can also see a dozen reasons why it wouldn't work.) So apart from anything else, it illustrates the advantages of having small, tidy and simple programs, and having small, tidy and compact headers. > It is perfectly possible to use Linux to cross-compile for Windows - > most Linux distros will have a package for doing "mingw" > cross-compilation, including "windows.h" files with all the bits needed. > I don't have such a package installed at the moment, because I don't > need to do such cross-compilation. > >> >> This shows another advantage of keeping things simple. > > No, it shows another fabricated and irrelevant "advantage". See my point (3) above. What is true of unnecessarily large and sprawling headers can also be true of anything else. > when I type > "apt-get install mingw-w64", I could not care less whether that installs > 3 header files or 300 header files. And look where that has got us. When I first used the Raspberry Pi, it's Debian had apparently 54,000 files installed - but I still couldn't /do/ anything! Everything needed an 'apt-get install' and loads of packages needing to be downloaded or upgraded. Then you get stalled again and you need install something else. And yet again. (On one such process, an apt-get install ran for 90 minutes. Then it crashed. But by then I'd long forgotten whatever the hell it was I'd been trying to do, and no longer cared.) > Note that on Linux and with gcc, re-reading a header file that has a > suitable inclusion guard is extremely fast. The data is all there in > ram and the contents of the file are skipped with almost no work - this > is a case that is highly optimised in gcc. Yes, skipping false #if/#ifdef/#elif/#else blocks can be fast. But is still not completely trivial, as some tokenising is still involved. You're looking for the next #elif/#else/#endif, but have to ignore those that are inside comments, string literals, or are not at the start of a line. You also have to keep track of nested #if/#ifdefs to ensure the next #endif matches the one you're looking for. Given a choice, you wouldn't process 240K lines of this stuff (what is skipped in gcc's windows.h). (Or maybe gcc has hit on optimisations for this, of which I can think of several; I don't know.) > On Windows, it takes a good > deal longer to read the file even if it is cached (but again, gcc will > skip the contents quickly). That depends. In my tokeniser, a repeated header is already in the program's memory; it doesn't need file functions to re-read it. -- bartc --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-30 16:23 +0200 |
| Message-ID | <obj474$iml$1@dont-email.me> |
| In reply to | #107487 |
On 30/03/17 15:36, bartc wrote: > On 30/03/2017 13:29, David Brown wrote: >> On 30/03/17 13:24, bartc wrote: > >>> If I add in <windows.h>, I get 250ms. >>> >>> But, stop and I think about that: I just said I compiled windows.h on >>> Linux, and on a Pi. That was easy because in lccwin32 versions of >>> windows.h, only 3 files I think are involved: windows.h, win.h, and >>> basetsd.h. >> >> Does your compiler here generate Windows executables when running on the >> Pi, as a cross compiler? > > It doesn't generate ARM code, if that's what you mean, but there is no > code involved in processing headers. But yes, it could act as a > cross-compiler, if run in the mode where it generates ASM (I'll be doing > that next week). > > But the intended mode of operation is that the compiler will generate > code in-memory then execute it. For that it would need to be ARM32 code > not x64. But any dependencies on gdi32.dll for example would cause > problems. > > In short, this is just a compiler test. > >> If not, then the ability to read some version >> of a "windows.h" header is totally and completely useless. > > There are several points of interest: > > (1) I was able to get an idea of how long my program took to perform the > job of compiler all those includes plus <windows.h>, on the slow RPi > Linux platform. > > (2) It was faster than gcc under Windows on a normal desktop PC, even > though it was running on the same Linux (not Windows) machine that is > apparently 300 times slower than your machine compiling those standard > headers. > > (3) I was able to trivially port the compiler I'd been using on Windows, > /and/ to trivially port the Windows-specific headers it was using. > If the compiler itself is written using portable C code, which should be fairly easy for a non-optimising compiler (it is things like pre-computing constants that are a challenge for cross-compiling), then "porting" a compiler from one host to another but keeping the target the same should just be a re-compile as long as there are no assumptions of the host and target being the same, and you have endian issues under control (ARM is usually little-endian, making this easy). > To do the equivalent using gcc from Windows and /its/ headers from > Windows, just to see how long it would take to run on this board > computer, would be a major undertaking. (Maybe you could do something > using 'wine', and port the entire gcc/tdm directory across, but I can > also see a dozen reasons why it wouldn't work.) "porting" headers means "copying". > > So apart from anything else, it illustrates the advantages of having > small, tidy and simple programs, and having small, tidy and compact > headers. OK, it is easier to copy 3 files than to copy 80 files. Happy? > >> It is perfectly possible to use Linux to cross-compile for Windows - >> most Linux distros will have a package for doing "mingw" >> cross-compilation, including "windows.h" files with all the bits needed. >> I don't have such a package installed at the moment, because I don't >> need to do such cross-compilation. >> >>> >>> This shows another advantage of keeping things simple. >> >> No, it shows another fabricated and irrelevant "advantage". > > See my point (3) above. What is true of unnecessarily large and > sprawling headers can also be true of anything else. > >> when I type >> "apt-get install mingw-w64", I could not care less whether that installs >> 3 header files or 300 header files. > > And look where that has got us. When I first used the Raspberry Pi, it's > Debian had apparently 54,000 files installed - but I still couldn't /do/ > anything! Everything needed an 'apt-get install' and loads of packages > needing to be downloaded or upgraded. When I install a new Windows system, I have no idea how many files it has. But it usually takes many hours of computer time - and that's a "pre-installed" system. And then the system has nothing but notepad and a browser whose only serious use is to download Firefox or Chrome. Everything to make the machine useful needs to be downloaded from dozens of different websites. When I install a desktop Linux system, it has a wide selection of software already in place. And there is a /huge/ selection that can be chosen and installed from a /single/ place. Yes, that is functionality that is worth a few files. > > Then you get stalled again and you need install something else. And yet > again. (On one such process, an apt-get install ran for 90 minutes. Then > it crashed. But by then I'd long forgotten whatever the hell it was I'd > been trying to do, and no longer cared.) You have an extraordinary ability to cause trouble for yourself - I don't know how you manage it. > >> Note that on Linux and with gcc, re-reading a header file that has a >> suitable inclusion guard is extremely fast. The data is all there in >> ram and the contents of the file are skipped with almost no work - this >> is a case that is highly optimised in gcc. > > Yes, skipping false #if/#ifdef/#elif/#else blocks can be fast. But is > still not completely trivial, as some tokenising is still involved. > You're looking for the next #elif/#else/#endif, but have to ignore those > that are inside comments, string literals, or are not at the start of a > line. You also have to keep track of nested #if/#ifdefs to ensure the > next #endif matches the one you're looking for. > > Given a choice, you wouldn't process 240K lines of this stuff (what is > skipped in gcc's windows.h). > > (Or maybe gcc has hit on optimisations for this, of which I can think of > several; I don't know.) It does have optimisations for that purpose, yes. > >> On Windows, it takes a good >> deal longer to read the file even if it is cached (but again, gcc will >> skip the contents quickly). > > That depends. In my tokeniser, a repeated header is already in the > program's memory; it doesn't need file functions to re-read it. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-01 11:59 +0100 |
| Message-ID | <pKLDA.487479$fZ.6744@fx41.am4> |
| In reply to | #107491 |
On 30/03/2017 15:23, David Brown wrote: > On 30/03/17 15:36, bartc wrote: [On speed of compiling] >> (Or maybe gcc has hit on optimisations for this, of which I can think of >> several; I don't know.) > > It does have optimisations for that purpose, yes. It seems to be then that, after all, you do appreciate the value of making certain things faster: * Optimisations for processing duplicate C headers * Build optimisations by only compiling where necessary * OS optimisations which can deal with efficiently with programs that make extensive use of files * Hardware optimisations in processors and in machine architecture which can make even compilers like gcc run as fast as possible * All sorts of new optimisations in the code generation of compilers like gcc, not only to make arbitrary code run faster, but to compile gcc itself to make it run as fast as it does now All this has required an enormous amount of effort by people who considered that what they already had /wasn't quite fast enough/. And presumably you've benefited from the results. You also seem to appreciate that an OS like Linux can be lean, lightweight (if not quite to my standards) and faster than one like Windows. But I guess that doesn't apply to compilers! I just mention all this because you do seem scorn all my efforts along those lines: DB: > Well, I presume you are having fun writing your compiler - because > otherwise I really cannot see the point of it. Although my project isn't just about speed. It's also about making things small, simple and effortless. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-01 14:41 +0100 |
| Message-ID | <y5ODA.492877$fZ.17004@fx41.am4> |
| In reply to | #107576 |
On 01/04/2017 11:59, bartc wrote: > On 30/03/2017 15:23, David Brown wrote: >> Well, I presume you are having fun writing your compiler - because >> otherwise I really cannot see the point of it. > > Although my project isn't just about speed. It's also about making > things small, simple and effortless. To illustrate that, this morning it just managed to compile and run Hello, World (not quite effortless yet as it has to work via https://pastebin.com/fCCCGHsd). Current size of my project is 0.2MB. Clang, by contrast, was 50MB yet was unable to compile the same program [it depends on other compilers to supply essential content and functionality]. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-03 11:08 +0200 |
| Message-ID | <obt39n$3jh$1@dont-email.me> |
| In reply to | #107576 |
On 01/04/17 12:59, bartc wrote: > On 30/03/2017 15:23, David Brown wrote: >> On 30/03/17 15:36, bartc wrote: > > [On speed of compiling] >>> (Or maybe gcc has hit on optimisations for this, of which I can think of >>> several; I don't know.) >> >> It does have optimisations for that purpose, yes. > > It seems to be then that, after all, you do appreciate the value of > making certain things faster: > At the risk of pointlessly repeating things I have said before, knowing full well that you will not take them in - yes, I certainly /do/ appreciate when things go faster. I like my compilation to go fast, and it is always better when builds are faster than slower. But I don't view speed of compilation as being the single important factor for a compiler. It is one of many factors, and it is far from the top. My position has always been that speed of compilation is /not/ the major issue when comparing compilers or considering tool quality. And for what I do, for the most part, C compilation with gcc is fast enough. It is simply not a problem for me. If it ran twice as fast, it would not make any difference to the way I work or what I do - nor would it make a difference if it took twice as long. If it took 10 times as long, it would be annoying in some of my projects. Of course, there are other types of compilation where the speed /is/ an issue. If you are rebuilding the Linux kernel or doing other large builds, things can never be fast enough. I have done enough builds of embedded Linux systems to be irritated by the time taken (especially for your old favourites, autotools and autoconf, rather than the compiler itself). But I would not consider swapping gcc for a toy compiler with a fraction of the features even there. And for C++ compilation, speed is again relevant - most of the focus of compilation speed is in the context of C++, not C. > * Optimisations for processing duplicate C headers Yes - it is a fine idea. It saves compiler effort, with no effort on the part of the programmer. Most compilers (including gcc) implement a "#pragma once" feature to make header inclusion faster - gcc (and probably other compilers) optimise standard C include guards so that you can get the same efficiency with standard C. > > * Build optimisations by only compiling where necessary > Of course. That is part of the reason why the speed of compilation itself is not as critical - it is only done when needed. My makefiles use a gcc feature that generates dependency files automatically, so that I am sure everything is compiled when necessary. > * OS optimisations which can deal with efficiently with programs that > make extensive use of files That's just good OS design. > > * Hardware optimisations in processors and in machine architecture which > can make even compilers like gcc run as fast as possible > I don't see what you mean here. Are you saying there is something wrong with picking a reasonably modern desktop PC for a development workstation? The "hardware optimisations" here are a solid amount of memory, multiple cpu cores, fast processing, etc. My main workstation is about 6 years old, I think, and was fast but not extreme at the time I got it. (My home machine is about a year or so old, and is a bit faster.) Do you think it would make more sense for me to compile natively on my target systems? If I have an embedded Linux system running at 800 MHz with 512 MB ram, why would I compile on that rather than a 2.6 GHz desktop with 12 GB ram? > * All sorts of new optimisations in the code generation of compilers > like gcc, not only to make arbitrary code run faster, but to compile gcc > itself to make it run as fast as it does now Are you now suggesting it is a bad idea for gcc binaries to be optimised? Or that it is somehow "cheating" if the compiler does a good job of compiling itself? > > All this has required an enormous amount of effort by people who > considered that what they already had /wasn't quite fast enough/. And > presumably you've benefited from the results. As always, you have been far too interested in making meaningless performance comparisons and complaining about things you don't understand, rather than listening to what anyone else says. gcc is so fast at compiling /my/ code that its speed is not an issue for /me/. Nowhere have I said its speed is not an issue for others, or that it would not be a good thing to be faster. What I have said is that /I/ don't care if it is faster - its speed is /good enough/ for /me/. When I choose a compiler for a project, I look at a number of factors. Speed of compilation is not one of them. Similarly, the size of a toolchain installation is almost totally irrelevant to me. Despite having many more toolchains installed than the average C developer (I keep each version I use, for each processor), I couldn't care less whether a toolchain takes 5 MB or 500 MB of disk space. I am fully aware that the reason gcc is fast enough for me is that other people see its speed as more relevant. But since I know a bit about how gcc is developed, and you don't, I know that it is /not/ the speed of C compilation that is the most important to the gcc developers - the speed of C++ compilation is far more relevant. (Of course, for many parts of gcc, a speed increase in one language benefits the other language too.) > > You also seem to appreciate that an OS like Linux can be lean, > lightweight (if not quite to my standards) and faster than one like > Windows. But I guess that doesn't apply to compilers! > I have nothing against a compiler being "lean" - but I have a great deal against judging a tool solely by how "lean" it is. I am interested in the efficiency of my development (that means features in the toolchain) and the efficiency of my run-time binaries (that means optimisations in the toolchain) - the efficiency of the tool that gets from A to B here is of little relevance. Similarly, when choosing an editor or IDE, I look for features that help me do my work more efficiently. As long as it works fast enough that it does not slow me down, I don't care in the least how efficient the IDE implementation is. It makes /zero/ difference to me that eclipse takes many 100 MB's of disk space, 1 GB of memory, and is written in an interpreted language - it is utterly irrelevant that it would be possible to write an IDE in 1 MB of space and 10 MB of ram. > I just mention all this because you do seem scorn all my efforts along > those lines: > > DB: >> Well, I presume you are having fun writing your compiler - because >> otherwise I really cannot see the point of it. > > Although my project isn't just about speed. It's also about making > things small, simple and effortless. > I scorn your obsession about speed of compilation as though it is the only factor of relevance to anybody or anything. And I scorn your obsession about the size and number of header files, compiler source files, and other files that few people ever look at. And I scorn your continuous insults on other people, their work, and their tools, as "unmaintainable bloat" - simply because /you/ don't understand what they have done or why they have done it.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-03 12:02 +0100 |
| Message-ID | <EYpEA.378079$8b6.367433@fx19.am4> |
| In reply to | #107665 |
On 03/04/2017 10:08, David Brown wrote: > On 01/04/17 12:59, bartc wrote: >> * Optimisations for processing duplicate C headers > > Yes - it is a fine idea. It saves compiler effort, with no effort on > the part of the programmer. Most compilers (including gcc) implement a > "#pragma once" feature to make header inclusion faster - gcc (and > probably other compilers) optimise standard C include guards so that you > can get the same efficiency with standard C. But how did it happen? I don't understand. Presumably someone (not you!) must have noticed that things were taking a bit longer than they would have liked? And decided to do something about it? While they were scorned by people with fast computers and small programs who thought it was all a waste of time? After all what's a few extra seconds! > I scorn your obsession about speed of compilation as though it is the > only factor of relevance to anybody or anything. And I scorn your > obsession about the size and number of header files, compiler source > files, and other files that few people ever look at. And I scorn your > continuous insults on other people, their work, and their tools, as > "unmaintainable bloat" But always having a go at Microsoft and Windows is fine? > - simply because /you/ don't understand what they > have done or why they have done it. Take the Win32 API. Let's say** it exports 20,000 defines, 5000 functions, 3000 typedefs and 1000 structs. About 30,000 declarations that need to be made known to any program that has '#include <windows.h>'. Is the best way of imparting this information really to present it as 200,000 text lines of sprawling declarations disseminated over 100 files in multiple directory levels? Which you have to locate, load, tokenise and parse over and over again. The program containing #include <windows.h> doesn't care. And in fact most such programs are only interested in a tiny fraction of the names declared in that header. It sounds to me to be a grossly inefficient way of going about things. You obviously don't care as you have a somewhat selfish attitude to these things: if building an app is /fast enough for you/ then it doesn't matter. But then you've presented some examples where things are slow even for you. Maybe, those sprawling headers can be processed by a one-off program that spits out a single file containing a linear list of all those declarations in compact form (after all, no one ever looks at these files, right?). Maybe, with such an important header as windows.h, exported entities can be written out as a C data table which can be incorporated into the compiler. Then, when windows.h is requested, it's instantly available. (I'm looking at such possibilities actually.) Maybe, if similar approaches are used elsewhere, if could help improve matters in situations where even you experience an annoying delay. (** I don't know the exact figures because big versions of windows.h are too complicated for me to parse. They contain too many compiler-specific features. However, for the version belonging to lccwin32 the figures (which will include imports from required standard headers) are 9846 macros, 2196 functions, 12 variables, 1808 typedefs, and 754 structs. Handy when a header is simple enough to do this stuff isn't it?) -------------------------------------------------- The speed and size of the tools I'm looking at will be such that it would be practical, every time you wanted to run the compiler, to compile it from scratch first, before running it to compile the source files you're interested it. Imagine compiling gcc from source every time you invoke 'gcc'. Would it still take only 36msec to compile a bunch of headers? This is in a different league. (This is exactly what I did a year ago with a compiler written in interpreted code. All 25 or so modules need to be byte-code compiled before it could run, but the process only took 30-40 msec. It adds up however it you have to invoke it 30 times! I don't do that any more because, although it was quite practical, the idea of it was crazy (I also used to compile my editor each time I used it!). So now it writes a consolidated binary file (like an exe). This is the difference between you and me: I have misgivings about a computer doing the same pointless work over and over, when it could be done once and for all, and you don't provided it's still fast enough. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-03 14:32 +0200 |
| Message-ID | <obtf76$c86$1@dont-email.me> |
| In reply to | #107666 |
On 03/04/17 13:02, bartc wrote: > On 03/04/2017 10:08, David Brown wrote: >> On 01/04/17 12:59, bartc wrote: > >>> * Optimisations for processing duplicate C headers >> >> Yes - it is a fine idea. It saves compiler effort, with no effort on >> the part of the programmer. Most compilers (including gcc) implement a >> "#pragma once" feature to make header inclusion faster - gcc (and >> probably other compilers) optimise standard C include guards so that you >> can get the same efficiency with standard C. > > But how did it happen? I don't understand. Presumably someone (not you!) > must have noticed that things were taking a bit longer than they would > have liked? And decided to do something about it? Your presumption may or may not be correct. It could just as easily have been someone who thought it might be nice if duplicate inclusions were handled faster - you have absolutely /no/ basis for assuming that someone thought the pre-processor was too slow. This is not a black-or-white issue - it is quite possible for someone to think it would be nice to be faster without anyone thinking the current state is too slow. And this feature was added a /long/ time ago (I haven't researched exactly when it appeared) - in a time when computers were a lot slower, and compilation took longer. The tasks of pre-processing C and tokenising it have not changed significantly since the days of K&R - it used to be a large part of the compilation time, while now it is rarely relevant (for C). It is the analysis, optimisation, and code generation stages that have changed massively over the years, and are now far more demanding of processor power. But at the time when this feature was added, pre-processing time was important. > > While they were scorned by people with fast computers and small programs > who thought it was all a waste of time? After all what's a few extra > seconds! > > >> I scorn your obsession about speed of compilation as though it is the >> only factor of relevance to anybody or anything. And I scorn your >> obsession about the size and number of header files, compiler source >> files, and other files that few people ever look at. And I scorn your >> continuous insults on other people, their work, and their tools, as >> "unmaintainable bloat" > > But always having a go at Microsoft and Windows is fine? You can scorn that my attitude there if you like. /Much/ of what I write about Windows and its use as a software development platform compared to Linux is based on verifiable fact or direct personal experience. Most of the rest is based on my personal opinion as a user of both platforms, often for the same tasks on very similar hardware. And some of it will be outdated information (I have Win7), lack of knowledge, and exaggeration due to personal likes and dislikes. There is a difference between "having a go at" and "being obsessive about". I think you will find it is rare that /I/ bring Linux and/or Windows into a discussion, except perhaps when noting the platform I am using for testing - while it is standard practice for you to bring up gcc, clang and sometimes MSVC as being bloated, inefficient, slow, hard to install, hard to use, incomprehensible, unmaintainable, or somehow tied to a conspiracy against you. As an example, you wrote this recently: > > To illustrate that, this morning it just managed to compile and run > Hello, World (not quite effortless yet as it has to work via > https://pastebin.com/fCCCGHsd). > > Current size of my project is 0.2MB. Clang, by contrast, was 50MB yet > was unable to compile the same program [it depends on other compilers > to supply essential content and functionality]. If you had simply written that your compiler has reached the point where it can compile "Hello, world!", then I would see that as an achievement - a serious step in the road towards a working compiler. But your second paragraph makes it clear that you see small size as being the important feature (in most circumstances, and for virtually all uses of a C compiler, it is not relevant). And your jab at clang is intended to show how bad other compilers are in comparison to yours - but in fact is parading your wilful ignorance, your misunderstandings about what a compiler actually is, your inability to read guidelines and information, and your total and complete unwillingness to learn anything from what people in this newsgroup tell you. It demonstrates either stupidity, or maliciousness. And I don't think you are stupid - I think you just get a kick out of trying to make other software look bad. If you think that is not a fair characterisation, then I am glad - but I have to tell you, this is the impression you give to me, at least. (It is perfectly reasonable to say that you think clang would be easier to work with on Windows if it were packaged along with a library and other tools. But you only need to say it once - and you need to say it to the folks who package clang for Windows.) > >> - simply because /you/ don't understand what they >> have done or why they have done it. > > Take the Win32 API. Let's say** it exports 20,000 defines, 5000 > functions, 3000 typedefs and 1000 structs. About 30,000 declarations > that need to be made known to any program that has '#include <windows.h>'. > > Is the best way of imparting this information really to present it as > 200,000 text lines of sprawling declarations disseminated over 100 files > in multiple directory levels? Which you have to locate, load, tokenise > and parse over and over again. That is the C way. Is it the /best/ way? No, there are more efficient ways to handle "modules" and import/export of symbols and information in a programming language. But it is the way C does it. Does it matter? No, not for C headers like this - at least not as long as there is good documentation for the APIs (and while I haven't looked much at the Windows API documentation, it seems there is plenty of it). In the C++ world, include file size and speed really does matter, because the files are a lot bigger and more complex than C headers. So the major compiler writes and the C++ committee are working on a better system, "modules". (clang made one experimental system, MS have significantly improved on it for MSVC. gcc is awaiting the results here, and have not implemented any kind of module support yet.) The world of computing has massive amounts of inefficiencies, in the name of flexibility and convenience - because computers are good at doing mindless tasks. Just look at the traffic and files used to show a little web page - there can be many times more characters in the headers, cookies, and other overhead than in the actual web page. And that page can be generated anew every access, from interpreted script code, even though the resulting page is the same. Processor time is cheap. > > The program containing #include <windows.h> doesn't care. And in fact > most such programs are only interested in a tiny fraction of the names > declared in that header. > > It sounds to me to be a grossly inefficient way of going about things. > What makes more sense, I think, is to have multiple separate headers that can be used more independently. Then you would not need to import the whole Windows API for every file the used /some/ of the API, but could use different bits in different places. I don't say that because I think it is a pain for the poor processor to have to parse so many lines again and again. I say that because I think it is a pain for the developer using an IDE, because features like auto-complete of function names will have thousands of API functions hiding the ones the programmer is actually interested in at the time. > You obviously don't care as you have a somewhat selfish attitude to > these things: if building an app is /fast enough for you/ then it > doesn't matter. But then you've presented some examples where things are > slow even for you. If building a program is fast enough for /me/, then it does not matter to /me/. I am quite happy to accept that other people find compilation speed more of an issue. However, I don't believe that the speed of C compilation is as much an issue as you seem to believe - not by a long way. And I don't believe you have a realistic view about what is relevant to the compilation speed of actual programs and real compilers. > > Maybe, those sprawling headers can be processed by a one-off program > that spits out a single file containing a linear list of all those > declarations in compact form (after all, no one ever looks at these > files, right?). If it were that simple, and if it made a significant difference to compilation speed, then compilers would do that already. A key problem is that the header system used by C is /too/ flexible. The interpretation of a header file can be different depending on previous headers, definitions, or even command-line options. All you could really do is concatenate files together - and since the files should already be in the OS's cache, that is not going to make much of a difference. If you generate pre-compiled header files for MSVC or gcc, you'll see they can be very large, partly as a result of this flexibility. > > Maybe, with such an important header as windows.h, exported entities can > be written out as a C data table which can be incorporated into the > compiler. Then, when windows.h is requested, it's instantly available. > (I'm looking at such possibilities actually.) A compiler implementation is free to do exactly that. It won't be strictly conforming to standards, since it is perfectly legal for a user to have their own "windows.h" file, but that does not mean it is not a potentially useful feature. > > Maybe, if similar approaches are used elsewhere, if could help improve > matters in situations where even you experience an annoying delay. No, it would not help me at all. That sort of thing helps if a compiler is tightly tied to a library and headers, and if there are only a few system headers that are always used. That does not apply in my work. > > (** I don't know the exact figures because big versions of windows.h are > too complicated for me to parse. They contain too many compiler-specific > features. However, for the version belonging to lccwin32 the figures > (which will include imports from required standard headers) are 9846 > macros, 2196 functions, 12 variables, 1808 typedefs, and 754 structs. > Handy when a header is simple enough to do this stuff isn't it?) > > -------------------------------------------------- > > The speed and size of the tools I'm looking at will be such that it > would be practical, every time you wanted to run the compiler, to > compile it from scratch first, before running it to compile the source > files you're interested it. > > Imagine compiling gcc from source every time you invoke 'gcc'. Would it > still take only 36msec to compile a bunch of headers? Imagine making a computer with lego-style connections so that every time you want to turn it on, you can re-build it. Tell me, what use would that be? What use is a compiler that needs to be compiled every time it is invoked? (Ignoring chicken-and-egg issues for the moment.) /Why/ would I possibly want to compile the compiler before every use? I is nice that it is /possible/ to compile the compiler, and occasionally it can be essential. But mostly I, like almost everyone else, get ready-made binaries for my compilers. > > This is in a different league. > > (This is exactly what I did a year ago with a compiler written in > interpreted code. All 25 or so modules need to be byte-code compiled > before it could run, but the process only took 30-40 msec. It adds up > however it you have to invoke it 30 times! > > I don't do that any more because, although it was quite practical, the > idea of it was crazy (I also used to compile my editor each time I used > it!). So now it writes a consolidated binary file (like an exe). > > This is the difference between you and me: I have misgivings about a > computer doing the same pointless work over and over, when it could be > done once and for all, and you don't provided it's still fast enough. > You want to compile the compiler before every use, but don't like pointless repetition? Something is wrong somewhere... My priorities are the developers' time, and the run-time of the target system (where efficiency means smaller or cheaper chips, longer battery life, etc.). The effort required by the computer in between is almost totally irrelevant - it only matters if it slows down the human developer.
[toc] | [prev] | [next] | [standalone]
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web