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 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-02 13:58 +0000 |
| Message-ID | <58e102c7.10267468@news.xs4all.nl> |
| In reply to | #107515 |
Ian Collins <ian-news@hotmail.com> wrote: > On 03/31/17 01:38 AM, David Brown wrote: > > > > So yes, gcc's design is optimised for the strengths of Linux. > > s/Linux/Unix/ Er, no. They're both products of the same set of people: the Stallmaniata. It's quite clear that GnuLinux and GnuC were designed to be symbiotic to one another, and parasitic towards anything else, in particular anything which reeks of Redmond. _C_ was designed concurrently with Unix. But, and David is not going to be willing to accept this, gcc _is not_ synonymous with C. It's one single implementation, and not IMAO a particularly elegant one, either. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-02 17:02 +0200 |
| Message-ID | <obr3ks$s15$1@dont-email.me> |
| In reply to | #107646 |
On 02/04/17 15:58, Richard Bos wrote: > Ian Collins <ian-news@hotmail.com> wrote: > >> On 03/31/17 01:38 AM, David Brown wrote: >>> >>> So yes, gcc's design is optimised for the strengths of Linux. >> >> s/Linux/Unix/ > > Er, no. Er, yes. gcc predates Linux - it is the compiler Linus used for the first kernel, and he first announced Linux after it was able to host gcc itself. And gcc places a lot of emphasis on working on a range of hosts - mostly Posix, but with a wide variety of features, and also Windows. It places even more emphasis on supporting a larger range of targets. > > They're both products of the same set of people: the Stallmaniata. Is that a term you made up yourself to sound like an insult to people you don't like, or people with a have a significantly different viewpoint from you? > It's quite clear that GnuLinux and GnuC were designed to be symbiotic to > one another, and parasitic towards anything else, in particular anything > which reeks of Redmond. > RMS started "GNU" long before Microsoft were relevant in the big scheme of the computer world. "GNU" stands for "GNU's Not Unix" - the project aimed to provide software that was technically similar or superior to traditional Unix software, but with a very different type of license. RMS was bothered by the commercialism and closed-source attitude that had developed in the Unix world, and wanted to go back to the freer and more open software world that had existed before (at least, in his eyes). I don't think I need to go into details about the differences in philosophy between Linus Torvalds / Linux and RMS / GNU. But they are different groups, with different aims and ideals, that happen to find each other's software a good practical match. However, gcc is used on a wide range of hosts and targets, not just Linux - and people use a range of C compilers on Linux. The only fixed point is that currently, gcc is the only compiler that can be used to compile the Linux kernel - but clang/llvm is getting close (as people modify both the kernel and clang to make this work). > _C_ was designed concurrently with Unix. But, and David is not going to > be willing to accept this, gcc _is not_ synonymous with C. It's one > single implementation, and not IMAO a particularly elegant one, either. > Why do you think I'd be unwilling to accept that? I have used a great many C compilers over the years, and still do. I /prefer/ gcc, given the choice - for many of my targets, it is the best choice technically, and it is usually the best choice economically (though I have used many other compilers with zero cost price, and several builds of gcc which have cost money).
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-03 17:50 +0000 |
| Message-ID | <58e28a77.11029046@news.xs4all.nl> |
| In reply to | #107648 |
David Brown <david.brown@hesbynett.no> wrote: > On 02/04/17 15:58, Richard Bos wrote: > > Ian Collins <ian-news@hotmail.com> wrote: > >> On 03/31/17 01:38 AM, David Brown wrote: > >>> > >>> So yes, gcc's design is optimised for the strengths of Linux. > >> > >> s/Linux/Unix/ > > > > Er, no. > > Er, yes. gcc predates Linux - it is the compiler Linus used for the > first kernel, and he first announced Linux after it was able to host gcc > itself. And gcc places a lot of emphasis on working on a range of hosts > - mostly Posix, but with a wide variety of features, and also Windows. > It places even more emphasis on supporting a larger range of targets. That's all dozens of years ago. _Today_, gcc and Linux are made in the first place for one another, and any other OS or implementation which wants to use either or the other has to join the back of the queue when it comes to compatibility. They can behave as the Desired System, or suffer the consequences. > I don't think I need to go into details about the differences in > philosophy between Linus Torvalds / Linux and RMS / GNU. But they are > different groups, with different aims and ideals, that happen to find > each other's software a good practical match. Myeah. Tell that to the people who insist it should be called "GNU/Linux". Now, who was that again...? Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-03 23:10 +0200 |
| Message-ID | <obudig$v0r$1@dont-email.me> |
| In reply to | #107682 |
On 03/04/17 19:50, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> On 02/04/17 15:58, Richard Bos wrote: >>> Ian Collins <ian-news@hotmail.com> wrote: >>>> On 03/31/17 01:38 AM, David Brown wrote: >>>>> >>>>> So yes, gcc's design is optimised for the strengths of Linux. >>>> >>>> s/Linux/Unix/ >>> >>> Er, no. >> >> Er, yes. gcc predates Linux - it is the compiler Linus used for the >> first kernel, and he first announced Linux after it was able to host gcc >> itself. And gcc places a lot of emphasis on working on a range of hosts >> - mostly Posix, but with a wide variety of features, and also Windows. >> It places even more emphasis on supporting a larger range of targets. > > That's all dozens of years ago. The design of gcc - the split into multiple binaries that communicate through temporary files or pipes, the reliance on external assembler, linker, and libraries, the multiple small include files, etc. - that part all pre-dates Linux. It is part of the original design of gcc, and it is still there. Those decisions were made because they were sensible for the main target at the time, Unix systems. The design has been kept for two reasons - one is that it is still a good design for the most common gcc hosts (Linux, BSD, and other *nix), and the other is that it is very difficult to change that sort of thing at a later date. > _Today_, gcc and Linux are made in the > first place for one another, and any other OS or implementation which > wants to use either or the other has to join the back of the queue when > it comes to compatibility. They can behave as the Desired System, or > suffer the consequences. Do you really think that MS adapted Windows to make it better for gcc? You don't suppose that gcc adapted to suit Windows better? In case the sarcasm was lost, gcc has been modified over the years to be a good deal easier to compile and run on Windows. A key example is that Windows does not support "fork()", which was used on gcc earlier (especially in the "collect2" program, whose function I forget - I think it was used in C++ compilation rather than C compilation). In the days of gcc 2.x, it was a serious challenge to get gcc to compile on Windows - you basically had to use cygwin with the full pack of autotools installed, the process was long and complicated, and the resulting binaries were very slow (mainly due to cygwin emulation layers). Been there, done that, glad I'm not doing it again. Modern gcc is far easier to compile for Windows, and can be done using the far more efficient mingw layer - because gcc has been adapted to make it easier to work on Windows. It is still more "at home" on Linux or any other *nix, but it /has/ been modified to be suitable with Windows as a host. So I think it is fair to say that gcc has a design that works best in *nix, and has been adapted to be workable (but not optimal) on Windows. I don't know of anything in gcc that makes Linux a better host for it than any other Unix or Posix system. The Linux kernel is certainly written to use the extensions of gcc. And gcc developers always test with compiling the kernel, and consider requests from the kernel developers with regard to new extensions. But they are far from being part of the same project or the same group - you need only look at the mailing lists of either projects to see significant animosity towards each other at times. Beyond the kernel, most Linux distros provide clang packages for users, and there are a number of other compilers available - though gcc is usually the default. > >> I don't think I need to go into details about the differences in >> philosophy between Linus Torvalds / Linux and RMS / GNU. But they are >> different groups, with different aims and ideals, that happen to find >> each other's software a good practical match. > > Myeah. > > Tell that to the people who insist it should be called "GNU/Linux". Those are not the people who make Linux. And the folks who like to talk about "GNU/Linux" are keen on making it clear that Linux is just the kernel - many of the key *nix utilities (including the standard compiler and library) are from GNU. Then there are lots of parts of the system that have nothing to do with the Linux kernel at all, /or/ the GNU project - like X, KDE, and most of the applications (and the GNU desktop Gnome is not part of Linux). These all work equally on BSD, or even other *nix systems. > > Now, who was that again...? > > Richard >
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-04-03 07:20 +1200 |
| Message-ID | <ekd17cF6dqtU1@mid.individual.net> |
| In reply to | #107646 |
On 04/ 3/17 01:58 AM, Richard Bos wrote: > Ian Collins <ian-news@hotmail.com> wrote: > >> On 03/31/17 01:38 AM, David Brown wrote: >>> >>> So yes, gcc's design is optimised for the strengths of Linux. >> >> s/Linux/Unix/ > > Er, no. Er, yes... As David pointed out, gcc predates Linux. https://groups.google.com/forum/#!msg/comp.lang.misc/Z9aYbsQJMDc/mA_CkiOi7TIJ -- Ian
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-04-02 19:39 +0000 |
| Subject | Optimized? (Was: Even more problems with lcc-win) |
| Message-ID | <obrk1m$nqu$1@news.xmission.com> |
| In reply to | #107651 |
In article <ekd17cF6dqtU1@mid.individual.net>, Ian Collins <ian-news@hotmail.com> wrote: >On 04/ 3/17 01:58 AM, Richard Bos wrote: >> Ian Collins <ian-news@hotmail.com> wrote: >> >>> On 03/31/17 01:38 AM, David Brown wrote: >>>> >>>> So yes, gcc's design is optimized for the strengths of Linux. >>> >>> s/Linux/Unix/ >> >> Er, no. > >Er, yes... As David pointed out, gcc predates Linux. > > >https://groups.google.com/forum/#!msg/comp.lang.misc/Z9aYbsQJMDc/mA_CkiOi7TIJ So? Let's assume that's right - that gcc predates Linux - that still doesn't mean that (current versions of) gcc aren't optimized for Linux. Note: Not that I know (or care) one way or the other about gcc and Linux, but I'm just pointing out the flaw in your "logic". P.S. I'm pretty sure that the truth of the assertion depends on what exactly you mean by "optimized". I can imagine several possible subtle shades of meaning one might attach to that word - which would in turn determine whether or not the assertion proves true. -- Those on the right constantly remind us that America is not a democracy; now they claim that Obama is a threat to democracy.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-04-02 15:59 -0400 |
| Message-ID | <3cc628c0-8e44-ed9a-7a58-a4972fe16be7@verizon.net> |
| In reply to | #107651 |
On 04/02/2017 03:20 PM, Ian Collins wrote: > On 04/ 3/17 01:58 AM, Richard Bos wrote: >> Ian Collins <ian-news@hotmail.com> wrote: >> >>> On 03/31/17 01:38 AM, David Brown wrote: >>>> >>>> So yes, gcc's design is optimised for the strengths of Linux. >>> >>> s/Linux/Unix/ >> >> Er, no. > > Er, yes... As David pointed out, gcc predates Linux. The initial release of Linux was 1991-09-17. At that time the current release of gcc was 1.40. <https://gcc.gnu.org/releases.html> lists 138 releases of gcc during the quarter century that has passed since that time. Are you arguing that a quarter century and 138 releases is not enough time to "optimize gcc for the strengths of linux"? If so, why?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-02 14:11 -0700 |
| Message-ID | <afd0154e-2a6f-435e-8d41-20eba9cd515a@googlegroups.com> |
| In reply to | #107654 |
On Sunday, April 2, 2017 at 2:59:47 PM UTC-5, James R. Kuyper wrote: > On 04/02/2017 03:20 PM, Ian Collins wrote: > > On 04/ 3/17 01:58 AM, Richard Bos wrote: > >> Ian Collins <ian-news@hotmail.com> wrote: > >> > >>> On 03/31/17 01:38 AM, David Brown wrote: > >>>> > >>>> So yes, gcc's design is optimised for the strengths of Linux. > >>> > >>> s/Linux/Unix/ > >> > >> Er, no. > > > > Er, yes... As David pointed out, gcc predates Linux. > > The initial release of Linux was 1991-09-17. At that time the current > release of gcc was 1.40. <https://gcc.gnu.org/releases.html> lists 138 > releases of gcc during the quarter century that has passed since that > time. Are you arguing that a quarter century and 138 releases is not > enough time to "optimize gcc for the strengths of linux"? If so, why? If the design of gcc had been optimized around the kinds of things that prevailing versions of Unix could handle efficiently, and Linux attempted to do those same things efficiently, code optimized for the former would naturally be optimized for the other. On the other hand, I'm curious whether there is *any* version of Unix that would be compatible with the dialect gcc processes when using -O2 or -O3 but not using any optimization-blocking flags. Linux is rather famously not compatible with that dialect, as its author has made clear his disdain for it. Would the authors of gcc regard all versions of Unix as "broken", or are there some that work with gcc's favored dialect?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-04-03 17:08 +1200 |
| Message-ID | <eke3lrFmadbU1@mid.individual.net> |
| In reply to | #107656 |
On 04/ 3/17 09:11 AM, supercat@casperkitty.com wrote: > On Sunday, April 2, 2017 at 2:59:47 PM UTC-5, James R. Kuyper wrote: >> On 04/02/2017 03:20 PM, Ian Collins wrote: >>> On 04/ 3/17 01:58 AM, Richard Bos wrote: >>>> Ian Collins <ian-news@hotmail.com> wrote: >>>> >>>>> On 03/31/17 01:38 AM, David Brown wrote: >>>>>> >>>>>> So yes, gcc's design is optimised for the strengths of Linux. >>>>> >>>>> s/Linux/Unix/ >>>> >>>> Er, no. >>> >>> Er, yes... As David pointed out, gcc predates Linux. >> >> The initial release of Linux was 1991-09-17. At that time the current >> release of gcc was 1.40. <https://gcc.gnu.org/releases.html> lists 138 >> releases of gcc during the quarter century that has passed since that >> time. Are you arguing that a quarter century and 138 releases is not >> enough time to "optimize gcc for the strengths of linux"? If so, why? > > If the design of gcc had been optimized around the kinds of things that > prevailing versions of Unix could handle efficiently, and Linux attempted > to do those same things efficiently, code optimized for the former would > naturally be optimized for the other. The was basically my point. What Unix does well, Linux usually does well and vice versa. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-03 13:42 +0000 |
| Message-ID | <njsEA.123519$QP1.71973@fx27.iad> |
| In reply to | #107646 |
raltbos@xs4all.nl (Richard Bos) writes: >Ian Collins <ian-news@hotmail.com> wrote: > >> On 03/31/17 01:38 AM, David Brown wrote: >> > >> > So yes, gcc's design is optimised for the strengths of Linux. >> >> s/Linux/Unix/ > >Er, no. > >They're both products of the same set of people: the Stallmaniata. >It's quite clear that GnuLinux and GnuC were designed to be symbiotic to >one another, and parasitic towards anything else, in particular anything >which reeks of Redmond. > >_C_ was designed concurrently with Unix. But, and David is not going to >be willing to accept this, gcc _is not_ synonymous with C. It's one >single implementation, and not IMAO a particularly elegant one, either. I bought my first Gnu GCC tape (9-track) in 1989 (cost for media & copying only). Linus was still in high school. s/Linux/Unix/ indeed.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 13:06 +0100 |
| Message-ID | <Qw6DA.176696$9O7.27796@fx22.am4> |
| In reply to | #107465 |
On 30/03/2017 11:35, David Brown wrote: > On 30/03/17 02:51, bartc wrote: >> The following sets of includes take 700ms to compile with gcc -O0 on >> Windows. >> Other compilers all take less time: 570ms, 220ms, while lccwin was >> around 100ms. But all are using different headers, all different sizes. >> (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.) > I don't have "windows.h" on my Linux machine (obviously). (See my other recent post. I managed to compile windows.h (not gcc's) on the RPi. Simplicity made that trivial.) > Compilation (with "-c", and no linking) took 4-7 milliseconds on this > machine (a slower PC than the other one I tested with). I think that set of includes is around 28Kloc on both systems (but Linux involves 80 files rather than 40). That means that your gcc is processing up to 7 million lines of code per second. And that the file system can open and close 20,000 files per second. My own experience of gcc (even allowing that there is no executable code involved here), makes that rather hard to believe. So I would regard your figures as suspicious. (I got figures of 1200msec on my RPi. Your 4ms figure suggests it is 300 times faster than this 700Mhz ARM. My own tests put the ARM's processing speed at 10-20 times slower than my PC.) When I include > a minimal main and generate an executable, it was 100 ms the first run, > 60-75 ms thereafter. > > Yes, at least part of this is the inefficiency of Windows for such > tasks. I know you don't like to hear that, but it is true. You can say > that this is because the design of gcc (with separate binaries and > processes) is better suited to *nix than Windows, but the result is that > compilation is typically faster in Linux than Windows. I ran my own program on the same gcc sets of headers of headers (tokenising only as incompatibilities make parsing impractical) it took around 100 msec for the exact same 170-odd files. So I don't think a slow file system is the problems. > What can we conclude from this quick test? We can see that Linux is > significantly faster than Windows As I said before, your machine is magic. At 7Mlps, it should be able to process a million lines of headers split across 1000 different files in about 140msec. -- 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:58 +0200 |
| Message-ID | <obiv8s$14h$1@dont-email.me> |
| In reply to | #107471 |
On 30/03/17 14:06, bartc wrote: > On 30/03/2017 11:35, David Brown wrote: >> On 30/03/17 02:51, bartc wrote: > >>> The following sets of includes take 700ms to compile with gcc -O0 on >>> Windows. > >>> Other compilers all take less time: 570ms, 220ms, while lccwin was >>> around 100ms. But all are using different headers, all different sizes. > >>> (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.) > >> I don't have "windows.h" on my Linux machine (obviously). > > (See my other recent post. I managed to compile windows.h (not gcc's) on > the RPi. Simplicity made that trivial.) > >> Compilation (with "-c", and no linking) took 4-7 milliseconds on this >> machine (a slower PC than the other one I tested with). > > I think that set of includes is around 28Kloc on both systems (but Linux > involves 80 files rather than 40). That means that your gcc is > processing up to 7 million lines of code per second. And that the file > system can open and close 20,000 files per second. Excluding windows.h, but including duplicates, I get 116 files (79 different files). Total lines are 23,364 including duplicates or 14,023 lines without duplicates. All the relevant files will be in the OS's file cache since they have all been read. Reading 20,000 files per second on Linux is not hard when they are all in ram. However, I see I have made a serious mistake in my testing here, for which I apologise - I have "ccache" enabled which caches the results of identical compilation. So the timing here is for the pre-processing (which still needs to be done) and then for calculating a hash of the pre-processed file, but not for the generation of the empty object file (since the results of that are cached by ccache). Since the key point here is the speed of the pre-processing of the #include files, however, it is still relevant to see that this is handled in 4-7 milliseconds. The same files are being read and pre-processed by the same "cpp" preprocessor as used normally by gcc. Running "gcc -c a.c" without ccache, it takes about 36 milliseconds on Linux - a little faster than on my Windows system despite the slower processor, but not as dramatic. > > My own experience of gcc (even allowing that there is no executable code > involved here), makes that rather hard to believe. > > So I would regard your figures as suspicious. > > (I got figures of 1200msec on my RPi. Your 4ms figure suggests it is 300 > times faster than this 700Mhz ARM. My own tests put the ARM's processing > speed at 10-20 times slower than my PC.) Figures from the web support the view that the Pi (at least the first version) is /very/ slow for compiling. It is not a relevant platform for comparison here. > > When I include >> a minimal main and generate an executable, it was 100 ms the first run, >> 60-75 ms thereafter. >> >> Yes, at least part of this is the inefficiency of Windows for such >> tasks. I know you don't like to hear that, but it is true. You can say >> that this is because the design of gcc (with separate binaries and >> processes) is better suited to *nix than Windows, but the result is that >> compilation is typically faster in Linux than Windows. > > I ran my own program on the same gcc sets of headers of headers > (tokenising only as incompatibilities make parsing impractical) it took > around 100 msec for the exact same 170-odd files. So I don't think a > slow file system is the problems. > >> What can we conclude from this quick test? We can see that Linux is >> significantly faster than Windows > > As I said before, your machine is magic. > > At 7Mlps, it should be able to process a million lines of headers split > across 1000 different files in about 140msec. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 14:50 +0100 |
| Message-ID | <M28DA.262047$987.233744@fx20.am4> |
| In reply to | #107483 |
On 30/03/2017 13:58, David Brown wrote: > On 30/03/17 14:06, bartc wrote: >> (I got figures of 1200msec on my RPi. Your 4ms figure suggests it is 300 >> times faster than this 700Mhz ARM. [OK, you said now your figures were spurious] My own tests put the ARM's processing >> speed at 10-20 times slower than my PC.) > > Figures from the web support the view that the Pi (at least the first > version) is /very/ slow for compiling. It is not a relevant platform > for comparison here. That logic seems a little flawed! If certain C compilers are intrinsically slow anyway, then that will show up on a Pi machine that is a magnitude slower than a desktop. People will then blame the hardware rather than the software. But it is a combination of compiler and machine that is being observed. I'm fairly confident now that I could get compile times of tens of thousands per second on the slow RPi (faster than I get on my desktop PC with gcc). Of course I would need to target actual ARM32 code to make that useful, which I will try later in the year. (Hopefully the platform won't yet be obsolete by then...) -- 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:27 +0200 |
| Message-ID | <obj4e5$jcs$1@dont-email.me> |
| In reply to | #107489 |
On 30/03/17 15:50, bartc wrote: > On 30/03/2017 13:58, David Brown wrote: >> On 30/03/17 14:06, bartc wrote: > >>> (I got figures of 1200msec on my RPi. Your 4ms figure suggests it is 300 >>> times faster than this 700Mhz ARM. > > [OK, you said now your figures were spurious] > > My own tests put the ARM's processing >>> speed at 10-20 times slower than my PC.) >> >> Figures from the web support the view that the Pi (at least the first >> version) is /very/ slow for compiling. It is not a relevant platform >> for comparison here. > > That logic seems a little flawed! > > If certain C compilers are intrinsically slow anyway, then that will > show up on a Pi machine that is a magnitude slower than a desktop. > People will then blame the hardware rather than the software. > > But it is a combination of compiler and machine that is being observed. The hardware is slow for serious modern compilers. That's all there is to it. And it is totally irrelevant to compare gcc on a Windows desktop with gcc on Linux on a Pi, and conclude that Linux is slow and/or Linux gcc is slow. > > I'm fairly confident now that I could get compile times of tens of > thousands per second on the slow RPi (faster than I get on my desktop PC > with gcc). Of course I would need to target actual ARM32 code to make > that useful, which I will try later in the year. (Hopefully the platform > won't yet be obsolete by then...) > The Pi is already obsolete - we are on to the Pi 3 at the moment, which is significantly faster for such tasks.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 16:57 +0100 |
| Message-ID | <7V9DA.543736$F83.24778@fx38.am4> |
| In reply to | #107492 |
On 30/03/2017 15:27, David Brown wrote: > On 30/03/17 15:50, bartc wrote: >> That logic seems a little flawed! >> >> If certain C compilers are intrinsically slow anyway, then that will >> show up on a Pi machine that is a magnitude slower than a desktop. >> People will then blame the hardware rather than the software. >> >> But it is a combination of compiler and machine that is being observed. > > The hardware is slow for serious modern compilers. That's all there is > to it. It's slow to run your favourite compiler. It's more than adequate for the sorts of tools I write. (I've had my interpreter running on it. That interpreter runs my own editor more responsively that the bundled native code editor.) > > And it is totally irrelevant to compare gcc on a Windows desktop with > gcc on Linux on a Pi, and conclude that Linux is slow and/or Linux gcc > is slow. I don't like Linux but I don't think it's slow in itself. Take the Seed7 language mentioned recently. I think it works by writing source code that is normally interpreted. But you can choose to compile it into equivalent C source, which is then turned into an executable a via a bundled C compiler. I think GHC (Haskell) works the same way; probably lots of products do. With such examples, it's not easy to stop what you're doing (on the Pi) transfer the intermediate code to a faster PC to do the compiling, then transfer it back. It's pointless; if you have a PC then just use the PC. But if someone /is/ using one of these toy computers, then why can't it do it all itself? You can't dismiss it because your preferred tools are so inefficient. > The Pi is already obsolete - we are on to the Pi 3 at the moment, which > is significantly faster for such tasks. There's also the Pi zero. But it seems to have been the case for a long time that people creating faster hardware are always one step behind those writing ever more inefficient software. -- bartc --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | mertesthomas@gmail.com |
|---|---|
| Date | 2017-03-30 14:31 -0700 |
| Message-ID | <5898a008-a590-4920-b02f-9bfba0749e7d@googlegroups.com> |
| In reply to | #107495 |
Am Donnerstag, 30. März 2017 17:57:00 UTC+2 schrieb Bart: > On 30/03/2017 15:27, David Brown wrote: > > On 30/03/17 15:50, bartc wrote: > > >> That logic seems a little flawed! > >> > >> If certain C compilers are intrinsically slow anyway, then that will > >> show up on a Pi machine that is a magnitude slower than a desktop. > >> People will then blame the hardware rather than the software. > >> > >> But it is a combination of compiler and machine that is being observed. > > > > The hardware is slow for serious modern compilers. That's all there is > > to it. > > It's slow to run your favourite compiler. It's more than adequate for > the sorts of tools I write. > > (I've had my interpreter running on it. That interpreter runs my own > editor more responsively that the bundled native code editor.) > > > > > And it is totally irrelevant to compare gcc on a Windows desktop with > > gcc on Linux on a Pi, and conclude that Linux is slow and/or Linux gcc > > is slow. > > I don't like Linux but I don't think it's slow in itself. > > Take the Seed7 language mentioned recently. I think it works by writing > source code that is normally interpreted. But you can choose to compile > it into equivalent C source, which is then turned into an executable a > via a bundled C compiler. Yes. Seed7 can be interpreted and there is also a compiler (written in Seed7), that compiles Seed7 to C. This C code is generated for a specific C compiler and the corresponding run-time library. When you compile the Seed7 interpreter yourself the same C compiler and its run-time library are used as target for the Seed7 compiler. Compiling the Seed7 interpreter is easy (there are makefiles for different operating systems and C compilers). Under Windows it is not necessary to compile Seed7. For Windows there is an Seed7 installer. This installer bundles a C compiler (MinGW gcc). The installer (the current version is seed7_05_20170328_win.exe) is here: https://sourceforge.net/projects/seed7/files/bin > I think GHC (Haskell) works the same way; probably lots of products do. This strategy has several advantages: - You get all optimizations done by the C compiler for free. - It is not necessary to generate machine code for different CPUs. - Porting to other systems (which have a C compiler) is easy. - The C run-time library and other C libraries are accessible. Regards, Thomas Mertes -- Seed7 Homepage: http://seed7.sourceforge.net Seed7 - The extensible programming language: User defined statements and operators, abstract data types, templates without special syntax, OO with interfaces and multiple dispatch, statically typed, interpreted or compiled, portable, runs under linux/unix/windows.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-28 15:54 -0500 |
| Message-ID | <95ildc5usd6su48i3pibth8ip4qos17sj9@4ax.com> |
| In reply to | #107299 |
On Tue, 28 Mar 2017 19:45:42 +0100, BartC <bc@freeuk.com> wrote: >On 28/03/2017 17:28, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >>> Well, if you start coding in slightly more adventurous waters ... > >> Yes, some of what you're trying to do is difficult. > >Thanks. According to David Brown, /nothing/ is ever difficult, nothing >is too complicated, and no tool is too slow! > >Here's another example of a minor problem I had to solve this morning, >although only tangentially connected to C. > >Usually a program invoked from the command line picks up all the >following parameters: > > > program A B C > >The three parameters are A B C (ignore the issue with Linux where >parameters involving * and ? can expand to any number). > >But the program I'm writing, call it X, takes /some/ of the parameters, >and creates another program Y which runs under X. Y thinks it's a >command line program and itself expects to read some command line >parameters. The issue is this, given: > > program A B C D E F > >which of those parameters belong X, and which should be left over to be >consumed by Y? (And in fact, Y can itself create a third program Z, >still running under the original process, which might need input too.) > >I looked at a few options, such as restricting the parameters for X, >bracketing them, but for the time being settled for an explicit >delimiter, to keep things flexible for all programs: > > program A B : D E F > >A,B are passed to X; D,E,F are available for Y. (But things like > need >to be shared, and ":" is not available as input to either program.) Certainly you're not the first to run into that difficulty. Gcc solves that by having a "-Xlinker" option, which causes it to pass the following token to the linker intact. MSVC does it a bit differently (and more like your ":" approach) by having a "/link" option, which causes the rest of the command line to be passed to the linker intact. OTOH, this is hardly the only gotcha area on command lines. How a program interprets multiple arguments often varies quite a bit. And that's not a problem specific to any one OS. Consider: pgm A ;processes A, produces A.out? or stdout? pgm A B ;A in, B out? or a and b in, and A.out, B.out or stdout? pgm A B C ;two or three inputs? output A.out, C.out, C or stdout? pgm A -x B C D ;what inputs does -x apply to? Parsing command lines is another area where *nix and Windows programs often have to take rather different approaches. Except for globbing, the two expand command lines to argv similarly, but Windows does provide easy access to the uninterpreted command line, which makes certain things possible that are clumsy in *nix (consider trying to implement ls where you didn't need to quote parameters if you wanted to list files of a given name in all subdirectories (sort of like "dir abc*.txt /s"). Globbing in *nix also adds another wrinkle to parameter assignment problem: pgm A -x B* C D ; did the user intend to apply -x to all (B*) and C and D, or just the first file in (B*), or just the files in (B*)?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-28 08:07 -0700 |
| Message-ID | <lntw6d5tjd.fsf@kst-u.example.com> |
| In reply to | #107254 |
bartc <bc@freeuk.com> writes:
[...]
> CLOCKS_PER_SECOND is another tricky one. I just assumed it was 1000 on
> Windows and 1000000 on Linux, but a recent test seemed to indicate it
> was 1000 on Linux too (despite bits/time.h suggesting it should be 1000000).
Do you mean CLOCKS_PER_SEC?
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | gordonb.uls6t@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-03-29 18:17 -0500 |
| Message-ID | <Id6dnUgowbsX3UHFnZ2dnUU7-dvNnZ2d@posted.internetamerica> |
| In reply to | #107216 |
>>> I was under the impression that functions and things exported from
>>> shared libraries could be accessed from any language using the right
>>> ABI, not just the original language (eg. C).
>>
>> Then you need the appropriate headers for that language.
>
> Yes, that's what I'm trying to create.
>
>> If the language doesn't come with the system, the language writer,
>> not the system writer, may be responsible for supplying header
>> files.
>
> What do you mean by the language writer? If you mean the implementor,
> then he will need the information necessary in order to be able to write
> the headers (or the equivalent in the language).
The language writer, if the language is new, is probably the language
designer AND the language implementor. If not, it's probably the
language implementor.
If you are writing a *C* compiler but using the existing library,
you need to supply headers like <stdio.h>. This might be done by
(a) using the system compiler headers (if the system compiler and/or
its headers are not installed by default, this requires installing
it), (b) copy the headers into your distribution (might draw copyright
lawsuits or encumber your compiler), (c) write your own and
reverse-engineer the system-dependent stuff in the header. You
have a choice of making one big <stdio.h> header or one for each
platform. Since you will be making different distributions for
different binaries of the compiler, I think using separate headers
would be best. At least keep the Windows stuff out of the Linux
headers and vice versa.
If you are implementing a language other than C, or something very
C-like: Just because the language implementor wants/needs something
doesn't mean that he gets it in a convenient form, or that he can
do it without putting bits of C in his source code, or even that
he gets it at all. The system compiler might also (a) be closed-source,
(b) use pre-compiled headers in a form you can't decode, and (c)
not provide a way of getting post-preprocessed code (which would
include the header files).
C can't be implemented without bits of assembly language. No,
I don't just mean kernel stuff like I/O. You're likely needed
to implement things like math rounding modes as well. It's
quite possible that your language can't be implemented without some
C glue. I do remember an implementation of FORTRAN where the calling
conventions for functions/subroutines were inconpatible, plus the
language name->linker symbol translation was incompatible, so and
*EVERY* C function (especially the math library) needed a wrapper.
Let's suppose you have a header file you need to interpret that has
a structure that is NOT opaque. Say, struct tm in <time.h>. You
need to figure out the names, types, and offsets of fields in struct
tm. You need this information for assembly language and Perl. You
can get *most* of the names and types by reading the standard, but
there are often extra fields (which take up space and will be written
by localtime(), so it's essential to get the overall size right.
One approach is write a program to parse the structure declaration
in <time.h>, have it produce a program which calls offsetof() and
sizeof() for each field in the structure, and create a Perl or
assembly-language header file that just defines symbols for each
field offset. I've actually run into this being done. It might
produce assembly-language directives like
struct_tm_offset_tm_year equ 20
and struct_tm_size equ 48
and the standard says tm_year is an int (which you know on your
platform is 32-bits.) which you'd use in assembly-language code to
get at the tm_year field. Types are a different problem. You
pretty much have to know the type (integer size and signedness)
beforehand. Some assembly-languages can carry a type with a symbol,
and maybe use that size instruction if it's not given explicitly,
but that doesn't help with knowing what size register you need to
load the value into.
Now, suppose you need to call localtime(). You give it a pointer
to a time_t and it fills in a struct tm for you. So how big is a
time_t? (I've seen it as 32 or 64 bits, even on the same hardware.)
This is one place where a little test program like:
---------------------
#include <time.h>
#include <stdio.h>
int main(int argc, char **argv) { printf("sizeof(time_t) = %zu\n", sizeof(time_t)); }
---------------------
would be useful. It might be a lot faster than sorting through chains
of typedefs in include files, especially if you already have this
written from the last platform you ported the compiler to.
Another problem: localtime() returns a pointer to a static structure.
So change the interface, and write a wrapper function. Have the
caller supply a place to put the information, and if you are
using threads, put a mutex around calls to localtime(). Perl
arranges to put the returned values in Perl variables.
If the struct is opaque, I encourage you NOT to export
fields of the struct or the size of it. This might get
annoying if the header file refers to the field in macros.
Perl provides I/O functions somewhat like the <stdio.h> functions,
but they use a Perl I/O handle, not a FILE *. Perl has predefined
I/O handles for stdin, stdout, and stderr, making them easy to get
at. The I/O handle is just a C wrapper around the stdio functions,
but it solves the problem of how to get access to stdout.
What else is in header files? Typedefs. These are hard to deal
with in assembly-language and Perl, but you can declare a variable
of that type and get its size and alignment using a C helper program.
Headers also tend to contain non-function-like macros containing
integer constants, used for things like passing to library calls
(e.g. SEEK_END). These you can turn into symbols. Headers may
contain function-like macros. Alternatives here are (a) ignore
them because the standard requires that there be an actual function
that does the same thing, (b) turn it into a function by wrapping
a function definition around it, or translate it into your new
language.
Function prototypes. These might not be needed in the new
language, or they'd need to be rewritten.
> I'm the implementor. I'm using a variety of sources including existing C
> headers in order to glean enough info to do the job, but solutions
> /requiring/ you to use stdio.h and /assuming/ you're going to use an
> existing C compiler aren't much good.
>
> I might, for example, want to be able to use C's file functions from
> assembly code.
Then you need to create assembly headers, if they are not provided.
These might be created *USING* <stdio.h> from the system and
its original compiler.
> fprintf(stdout, "hello");
>
> but to do it from assembly as I suggested above. Your only tools are an
> assembler and a linker that can manage the connection between your ASM
> code and a shared library of either msvcrt.dll or libc.so.6. How do you
> do it?
You don't have enough information. Furthermore, the implementation
might change on you. I think FreeBSD had one change that did alter
sizeof(FILE). Symbol versioning allowed old programs to continue
working and new ones to use the new code, but you couldn't mix old
and new objects in the same link. Symbol versioning pretty much
ensures that you get an error if you try.
If you can get away with something like:
-----------------------
#include <stdio.asm.inc>
.extern _stdout
_stdout equ _iob + struct_IO_FILE_size
-----------------------
then try it. (stdio.asm.inc is the stdio.h assembly-language header
file, and it defines struct_IO_FILE_size.) This requires being
able to define a relocatable symbol as an offset to an external
symbol, which is probably not well supported.
(It is assumed here that the assembler supports some type of include
file. It might use something different like ".include". I wouldn't
rule out using the C preprocessor on assembly-language files, or
perhaps you could use a different preprocessor like m4.) You got
that "_iob" part from reading <stdio.h> (or, if necessary, stringizing
the stdout macro and printing it).
> 'fprintf' is just an address, so it easy. What about 'stdout'? Where do
> you find the information that tells you where to get 'stdout'? (Windows
> and Linux manage this differently.)
>
>> Perhaps the easiest way to export something like stdout is to compile
>> a 3-line file like this as C:
>>
>> ---------------
>> #include <stdio.h>
>>
>> FILE *pointerToSTDOUT = stdout;
>> ---------------
>> and link it with the other-language code (assuming that pointer
>> format and variable names are compatible) which uses "extern
>> pointerToSTDOUT or whatever the equivalent is in that language.
>> You don't have to worry about whether _ is a legal character in
>> your language, nor the contents of <stdio.h>. Just treat it as an
>> opaque pointer that you pass to fprintf() or whatever.
>
> I'm writing a C compiler. I can't make it half-dependent on another C
> compiler for it to work!
It's already dependent on the C library from another compiler!
> How did the authors of that other compiler
> manage it - did they depend on yet another compiler, so that there is a
> chain of dozen compilers? (Like 5 buses following a sixth because only
> the one in front knows the way!)
The only thing you need from the old compiler is the old <stdio.h>,
or a new one that works the same in this regard. Your compiler
should be able to compile the 3-line file above just fine. If you
are writing a C compiler, what are you supplying as <stdio.h>? Most
user C programs are going to need *some* version of <stdio.h> that
matches the C library well enough to work.
Incidentally, I have been running into some problems with other
programs that process C getting tripped up by GCC syntax. One
I use a lot is "cproto", which creates a file of prototypes.
I have gradually been coming up with a list of command-line flags
which reduce the number of complaints, like
-D_Noreturn=""
which only affects the preprocessing used before the cproto
run, not preprocessing for compilation. Most of the GCC macros
can be defined as nothing. This doesn't even affect optimization,
since they are only removed for prototype generation, done
separately from compilation.
> (The only concession I can make, for people who want to compile from
> source, is to require an existing C compiler to bootstrap, then it can
> be set aside.)
>
>>> (I'm guessing that the dlopen() function on the Linux library creates
>>> new, private instances of the exported variables, and an internal
>>> initialisation routine sets them up.)
>>
>> Assume you have a private library you can require in addition to the
>> C library. I think there is a way for "extern FILE *stdout;" in
>> the main program to match up with "FILE *stdout;" in the private library
>> as one variable if you use RTLD_GLOBAL. It also works this way if
>> you use shared libraries without dlopen().
>>
>> Attempting to dlopen() the C library is a little bit pointless.
>> Guess where the dlopen() code is? You need to have it already
>> linked to call dlopen().
>
> The point of opening it is to get a handle to pass to dlsym(). But also,
> when I get into it, to ensure that I'm using a different invocation of
> the library from the program that is being executed.
I don't believe that you can dlopen() multiple copies of the same
library and get multiple instances of that library. The more common
use case is that you need several functions from the *SAME* library
(say, dbopen(), dbclose(), dbread(), and dbwrite())
and multiple calls to dlsym() for symbols in the same library should
refer to the same instance of that library. It does keep a reference
count so the one copy you get isn't prematurely deleted. Having
two different versions of the same library in the same program,
even if the only change was to the file name, is an invitation to
disaster (and usually segfaulting).
> (One use of this is when the primary executable is an interpreter of a
> language which can itself directly call functions in a library such as
> C. Any local state within its use of the library needs to be kept
> separate from that of the host.
That sounds like a call for a wrapper function. If a function has
state (such as strtok() or localtime()), arrange to store the state
and use the appropriate state on the next call.
> Another, which I'm doing now, is a program which converts C source to
> native code to be directly executed. It will need its own private fixups
> to an external C library, separate from its host. The host may also need
> to stay resident while different versions of the target program are run.)
That sounds like a use for fork().
>
> . Well, it is possible to dlopen() the
>> executable itself and read its symbols, so it might have some use.
>
> Is there a dl function to enumerate all the symbols rather than look for
> a specific one? (Sometimes you won't know which library a symbol might
> be in.)
On FreeBSD (Linux appears to work the same way), it looks like
dlinfo() provides pointers to the dynamic symbols in-memory for the
loaded libraries. You probably have to know a bit about ELF object
structure. I think there's enough info that you could print a list
of libraries, the symbols in them, and values for everything loaded.
If you pass dlsym() the handle RTLD_DEFAULT, it will search
a list of loaded libraries in a documented order. This sounds
like what you are trying to do. Or, at worst, you could call dlsym()
once for each library.
>>> (Did you yourself mention using this stuff from Perl, in another post? I
>>> guess Perl wasn't using stdio.h.)
>>
>> I mentioned that the C code from Perl used code that accessed the
>> fields of a FILE that it wasn't really supposed to. Yes, the Perl
>> C code was using <stdio.h>. (I was building Perl, not using it,
>> watching the Configure script test whether this worked. And in one
>> case, it failed with spectacular error messages but went on to build
>> a working Perl). However, Perl does have a way of converting C
>> header files to Perl header files. There's a tree of Perl *.ph
>> files, one for each C include file, hidden under the site_perl directory.
>> It even translates all the #if's!
>
> I wonder what it converts them to, unless .ph files are not very
> different from .h files.
Perl. Try reading one sometime (see below). It looks like all the
translations of #if are done at *RUN TIME*, although it's possible
that some optimization may be possible.
> (With my own such language, converting .h files is not easy, as there is
> no equivalent in the target language! It works completely differently.)
stdio.ph:
------------------
require '_h2ph_pre.ph';
no warnings qw(redefine misc);
unless(defined(&_STDIO_H_)) {
eval 'sub _STDIO_H_ () {1;}' unless defined(&_STDIO_H_);
require 'sys/cdefs.ph';
require 'sys/_null.ph';
require 'sys/_types.ph';
unless(defined(&_SIZE_T_DECLARED)) {
eval 'sub _SIZE_T_DECLARED () {1;}' unless defined(&_SIZE_T_DECLARED);
}
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 200809) {
unless(defined(&_OFF_T_DECLARED)) {
eval 'sub _OFF_T_DECLARED () {1;}' unless defined(&_OFF_T_DECLARED);
}
unless(defined(&_SSIZE_T_DECLARED)) {
eval 'sub _SSIZE_T_DECLARED () {1;}' unless defined(&_SSIZE_T_DECLARED);
}
}
unless(defined(&_OFF64_T_DECLARED)) {
eval 'sub _OFF64_T_DECLARED () {1;}' unless defined(&_OFF64_T_DECLARED);
}
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 200112|| (defined(&__XSI_VISIBLE) ? &__XSI_VISIBLE : undef)) {
unless(defined(&_VA_LIST_DECLARED)) {
eval 'sub _VA_LIST_DECLARED () {1;}' unless defined(&_VA_LIST_DECLARED);
}
}
eval 'sub _FSTDIO () {1;}' unless defined(&_FSTDIO);
unless(defined(&_STDFILE_DECLARED)) {
eval 'sub _STDFILE_DECLARED () {1;}' unless defined(&_STDFILE_DECLARED);
}
unless(defined(&_STDSTREAM_DECLARED)) {
eval 'sub _STDSTREAM_DECLARED () {1;}' unless defined(&_STDSTREAM_DECLARED);
}
eval 'sub __SLBF () {0x1;}' unless defined(&__SLBF);
eval 'sub __SNBF () {0x2;}' unless defined(&__SNBF);
eval 'sub __SRD () {0x4;}' unless defined(&__SRD);
eval 'sub __SWR () {0x8;}' unless defined(&__SWR);
eval 'sub __SRW () {0x10;}' unless defined(&__SRW);
eval 'sub __SEOF () {0x20;}' unless defined(&__SEOF);
eval 'sub __SERR () {0x40;}' unless defined(&__SERR);
eval 'sub __SMBF () {0x80;}' unless defined(&__SMBF);
eval 'sub __SAPP () {0x100;}' unless defined(&__SAPP);
eval 'sub __SSTR () {0x200;}' unless defined(&__SSTR);
eval 'sub __SOPT () {0x400;}' unless defined(&__SOPT);
eval 'sub __SNPT () {0x800;}' unless defined(&__SNPT);
eval 'sub __SOFF () {0x1000;}' unless defined(&__SOFF);
eval 'sub __SMOD () {0x2000;}' unless defined(&__SMOD);
eval 'sub __SALC () {0x4000;}' unless defined(&__SALC);
eval 'sub __SIGN () {0x8000;}' unless defined(&__SIGN);
eval 'sub __S2OAP () {0x1;}' unless defined(&__S2OAP);
eval 'sub _IOFBF () {0;}' unless defined(&_IOFBF);
eval 'sub _IOLBF () {1;}' unless defined(&_IOLBF);
eval 'sub _IONBF () {2;}' unless defined(&_IONBF);
eval 'sub BUFSIZ () {1024;}' unless defined(&BUFSIZ);
eval 'sub EOF () {(-1);}' unless defined(&EOF);
unless(defined(&FOPEN_MAX)) {
eval 'sub FOPEN_MAX () {20;}' unless defined(&FOPEN_MAX);
}
eval 'sub FILENAME_MAX () {1024;}' unless defined(&FILENAME_MAX);
if((defined(&__XSI_VISIBLE) ? &__XSI_VISIBLE : undef)) {
eval 'sub P_tmpdir () {"/tmp/";}' unless defined(&P_tmpdir);
}
eval 'sub L_tmpnam () {1024;}' unless defined(&L_tmpnam);
eval 'sub TMP_MAX () {308915776;}' unless defined(&TMP_MAX);
unless(defined(&SEEK_SET)) {
eval 'sub SEEK_SET () {0;}' unless defined(&SEEK_SET);
}
unless(defined(&SEEK_CUR)) {
eval 'sub SEEK_CUR () {1;}' unless defined(&SEEK_CUR);
}
unless(defined(&SEEK_END)) {
eval 'sub SEEK_END () {2;}' unless defined(&SEEK_END);
}
eval 'sub stdin () { &__stdinp;}' unless defined(&stdin);
eval 'sub stdout () { &__stdoutp;}' unless defined(&stdout);
eval 'sub stderr () { &__stderrp;}' unless defined(&stderr);
if(defined(&_XLOCALE_H_)) {
require 'xlocale/_stdio.ph';
}
if((defined(&__ISO_C_VISIBLE) ? &__ISO_C_VISIBLE : undef) >= 1999) {
}
if((defined(&__BSD_VISIBLE) ? &__BSD_VISIBLE : undef) || ((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) && (defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) <= 199506)) {
eval 'sub L_cuserid () {17;}' unless defined(&L_cuserid);
}
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef)) {
eval 'sub L_ctermid () {1024;}' unless defined(&L_ctermid);
}
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 199209) {
}
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 199506) {
}
if((defined(&__BSD_VISIBLE) ? &__BSD_VISIBLE : undef)) {
}
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 200112) {
}
if((defined(&__BSD_VISIBLE) ? &__BSD_VISIBLE : undef) || (defined(&__XSI_VISIBLE) ? &__XSI_VISIBLE : undef) > 0 && (defined(&__XSI_VISIBLE) ? &__XSI_VISIBLE : undef) < 600) {
}
if((defined(&__XSI_VISIBLE) ? &__XSI_VISIBLE : undef)) {
}
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 200809) {
unless(defined(&_WITH_GETLINE)) {
if(defined(&_BSD_SOURCE) || defined(&_GNU_SOURCE)) {
eval 'sub _WITH_GETLINE () {1;}' unless defined(&_WITH_GETLINE);
}
elsif(defined(&_POSIX_C_SOURCE)) {
if((defined(&_POSIX_C_SOURCE) ? &_POSIX_C_SOURCE : undef) >= 200809) {
eval 'sub _WITH_GETLINE () {1;}' unless defined(&_WITH_GETLINE);
}
}
}
if(defined(&_WITH_GETLINE)) {
}
unless(defined(&_WITH_DPRINTF)) {
if(defined(&_BSD_SOURCE) || defined(&_GNU_SOURCE)) {
eval 'sub _WITH_DPRINTF () {1;}' unless defined(&_WITH_DPRINTF);
}
elsif(defined(&_POSIX_C_SOURCE)) {
if((defined(&_POSIX_C_SOURCE) ? &_POSIX_C_SOURCE : undef) >= 200809) {
eval 'sub _WITH_DPRINTF () {1;}' unless defined(&_WITH_DPRINTF);
}
}
}
if(defined(&_WITH_DPRINTF)) {
}
}
if((defined(&__BSD_VISIBLE) ? &__BSD_VISIBLE : undef)) {
eval 'sub fropen {
my($cookie, $fn) = @_;
eval q( &funopen($cookie, $fn, 0, 0, 0));
}' unless defined(&fropen);
eval 'sub fwopen {
my($cookie, $fn) = @_;
eval q( &funopen($cookie, 0, $fn, 0, 0));
}' unless defined(&fwopen);
unless(defined(&_FTRUNCATE_DECLARED)) {
eval 'sub _FTRUNCATE_DECLARED () {1;}' unless defined(&_FTRUNCATE_DECLARED);
}
unless(defined(&_LSEEK_DECLARED)) {
eval 'sub _LSEEK_DECLARED () {1;}' unless defined(&_LSEEK_DECLARED);
}
unless(defined(&_MMAP_DECLARED)) {
eval 'sub _MMAP_DECLARED () {1;}' unless defined(&_MMAP_DECLARED);
}
unless(defined(&_TRUNCATE_DECLARED)) {
eval 'sub _TRUNCATE_DECLARED () {1;}' unless defined(&_TRUNCATE_DECLARED);
}
}
eval 'sub __sgetc {
my($p) = @_;
eval q((---> &_r < 0? &__srget : (*($p)-> &_p++)));
}' unless defined(&__sgetc);
if(defined(&__GNUC__) && defined(&__STDC__)) {
eval 'sub __sputc {
my($_c,$_p) = @_;
eval q({ &if (-- ($_p->{_w}) >= 0|| ( ($_p->{_w}) >= ($_p->{_lbfsize}) && $_c != ord(\'\\\\n\'))) (* ($_p->{_p})++ = $_c); &else ( &__swbuf($_c, $_p)); });
}' unless defined(&__sputc);
} else {
eval 'sub __sputc {
my($c, $p) = @_;
eval q((---> &_w < 0? -> &_w >= -> &_lbfsize ? (*-> &_p = ), *-> &_p != ord(\'\\\\n\' ? *->_p++ : __swbuf(\'\\\\n\'), $p) : &__swbuf(($c), $p) : (*($p)-> &_p = ($c), *($p)-> &_p++)));
}' unless defined(&__sputc);
}
unless(defined(&__cplusplus)) {
eval 'sub __sfeof {
my($p) = @_;
eval q(((($p)-> &_flags & &__SEOF) != 0));
}' unless defined(&__sfeof);
eval 'sub __sferror {
my($p) = @_;
eval q(((($p)-> &_flags & &__SERR) != 0));
}' unless defined(&__sferror);
eval 'sub __sclearerr {
my($p) = @_;
eval q((( &void)(($p)-> &_flags &= ~( &__SERR| &__SEOF))));
}' unless defined(&__sclearerr);
eval 'sub __sfileno {
my($p) = @_;
eval q((($p)-> &_file));
}' unless defined(&__sfileno);
eval 'sub feof {
my($p) = @_;
eval q((! &__isthreaded ? &__sfeof($p) : ( &feof)($p)));
}' unless defined(&feof);
eval 'sub ferror {
my($p) = @_;
eval q((! &__isthreaded ? &__sferror($p) : ( &ferror)($p)));
}' unless defined(&ferror);
eval 'sub clearerr {
my($p) = @_;
eval q((! &__isthreaded ? &__sclearerr($p) : ( &clearerr)($p)));
}' unless defined(&clearerr);
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef)) {
eval 'sub fileno {
my($p) = @_;
eval q((! &__isthreaded ? &__sfileno($p) : ( &fileno)($p)));
}' unless defined(&fileno);
}
eval 'sub getc {
my($fp) = @_;
eval q((! &__isthreaded ? &__sgetc($fp) : ( &getc)($fp)));
}' unless defined(&getc);
eval 'sub putc {
my($x, $fp) = @_;
eval q((! &__isthreaded ? &__sputc($x, $fp) : ( &putc)($x, $fp)));
}' unless defined(&putc);
eval 'sub getchar () {
eval q( &getc( &stdin));
}' unless defined(&getchar);
eval 'sub putchar {
my($x) = @_;
eval q( &putc($x, &stdout));
}' unless defined(&putchar);
if((defined(&__BSD_VISIBLE) ? &__BSD_VISIBLE : undef)) {
eval 'sub feof_unlocked {
my($p) = @_;
eval q( &__sfeof($p));
}' unless defined(&feof_unlocked);
eval 'sub ferror_unlocked {
my($p) = @_;
eval q( &__sferror($p));
}' unless defined(&ferror_unlocked);
eval 'sub clearerr_unlocked {
my($p) = @_;
eval q( &__sclearerr($p));
}' unless defined(&clearerr_unlocked);
eval 'sub fileno_unlocked {
my($p) = @_;
eval q( &__sfileno($p));
}' unless defined(&fileno_unlocked);
}
if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 199506) {
eval 'sub getc_unlocked {
my($fp) = @_;
eval q( &__sgetc($fp));
}' unless defined(&getc_unlocked);
eval 'sub putc_unlocked {
my($x, $fp) = @_;
eval q( &__sputc($x, $fp));
}' unless defined(&putc_unlocked);
eval 'sub getchar_unlocked () {
eval q( &getc_unlocked( &stdin));
}' unless defined(&getchar_unlocked);
eval 'sub putchar_unlocked {
my($x) = @_;
eval q( &putc_unlocked($x, &stdout));
}' unless defined(&putchar_unlocked);
}
}
}
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-30 19:20 +0100 |
| Message-ID | <W%bDA.729300$Pm3.319045@fx42.am4> |
| In reply to | #107438 |
On 30/03/2017 00:17, Gordon Burditt wrote:
> The language writer, if the language is new, is probably the language
> designer AND the language implementor. If not, it's probably the
> language implementor.
>
> If you are writing a *C* compiler but using the existing library,
> you need to supply headers like <stdio.h>. This might be done by
> (a) using the system compiler headers (if the system compiler and/or
> its headers are not installed by default, this requires installing
> it), (b) copy the headers into your distribution (might draw copyright
> lawsuits or encumber your compiler), (c) write your own and
> reverse-engineer the system-dependent stuff in the header
A lot of this stuff will be in the C Standard. Will it still need a
copyright notice even for things like this which are common knowledge:
extern int printf(char*, ...);
?
> If you are implementing a language other than C, or something very
> C-like: Just because the language implementor wants/needs something
> doesn't mean that he gets it in a convenient form, or that he can
> do it without putting bits of C in his source code, or even that
> he gets it at all. The system compiler might also (a) be closed-source,
> (b) use pre-compiled headers in a form you can't decode, and (c)
> not provide a way of getting post-preprocessed code (which would
> include the header files).
I expect the system I'm compiling for to document its interfaces. With
Windows, their docs are quite good, and stable.
(Before Windows, I tended to rely on hardware specs and data sheets.
Some hardware I built myself so that was no problem...)
This is assuming it isn't a closed system (I don't know if Apple is like
that; Android might as well be).
> C can't be implemented without bits of assembly language.
Well, if you're generating code, usually you will need that. Although it
should be possible to write a C interpreter without knowledge of the
underlying hardware and no actual machine instructions. (Something I
considered actually, but it would have been too slow relative to the
fast compiler.)
> You're likely needed
> to implement things like math rounding modes as well.
I'm sure C compilers in the 1970s and 80s all did their own thing.
But I'm not implementing Java where floating point results always have
to be identical whatever the hardware or version.
> It's
> quite possible that your language can't be implemented without some
> C glue.
That's unlikely. It should be possible to create an arbitrary language
without any dependency on a C compiler. Maybe to run some tests, but it
shouldn't be part of a distribution. (Supplying such an implementation
as source language X requiring a compiler/interpreter for X is a
different matter.)
> One approach is write a program to parse the structure declaration
> in <time.h>, have it produce a program which calls offsetof() and
> sizeof() for each field in the structure, and create a Perl or
> assembly-language header file that just defines symbols for each
> field offset. I've actually run into this being done.
I've done something like that to get the sizes used by various Win32 API
structs. Just to check the ones I have to build - in a different
language with its one padding/alignment rules - match up.
However I understand that on a given platform, all C compilers have to
follow the same rules for structs.
> You don't have enough information. Furthermore, the implementation
> might change on you. I think FreeBSD had one change that did alter
> sizeof(FILE).
Then, surely, every compiled binary program would fail? Assuming
sizeof(FILE) was a crucial part.
Symbol versioning allowed old programs to continue
> working and new ones to use the new code, but you couldn't mix old
> and new objects in the same link.
Oh, they had some sense then in overlapping versions...
>> I'm writing a C compiler. I can't make it half-dependent on another C
>> compiler for it to work!
>
> It's already dependent on the C library from another compiler!
On a binary library. We don't know its provenance; maybe it was written
in assembly, or in machine code, or some other language entirely.
Besides the libraries I've chosen already exist, so are effectively part
of the OS.
(I started using C libraries nearly 20 years before I used C. I just saw
them as a simpler-to-use alternative to the Win API.)
> The only thing you need from the old compiler is the old <stdio.h>,
> or a new one that works the same in this regard. Your compiler
> should be able to compile the 3-line file above just fine. If you
> are writing a C compiler, what are you supplying as <stdio.h>?
This is how it works at the minute:
* Start with an empty set of standard headers
* Try and compile some code
* If it complains about a missing standard function, then:
* Find which header it's supposed to go in
* Find the signature
* Add the header in as simple a form as possible
* Try compiling again (sometimes it needs a 'const' added)
* Repeat with the next missing bit
Sources of info include the C standard, online resources such as the
MSDN website, and existing headers, although the latter tend to have a
lot of implementation-specific crap.
>> The point of opening it is to get a handle to pass to dlsym(). But also,
>> when I get into it, to ensure that I'm using a different invocation of
>> the library from the program that is being executed.
>
> I don't believe that you can dlopen() multiple copies of the same
> library and get multiple instances of that library.
I'm calling dlopen() once. Surely it will give me a different instance
from the one used by the program that called dlopen()?
>> (One use of this is when the primary executable is an interpreter of a
>> language which can itself directly call functions in a library such as
>> C. Any local state within its use of the library needs to be kept
>> separate from that of the host.
>
> That sounds like a call for a wrapper function. If a function has
> state (such as strtok() or localtime()), arrange to store the state
> and use the appropriate state on the next call.
I would expect static data belonging to a shared library to have
separate copies for each instance. The question then is whether a dlopen
call belonging to process X will return a handle identical to that used
by X (assuming X is not using a statically linked version).
> Perl. Try reading one sometime (see below). It looks like all the
> translations of #if are done at *RUN TIME*, although it's possible
> that some optimization may be possible.
> stdio.ph:
> ------------------
>
> require '_h2ph_pre.ph';
>
> no warnings qw(redefine misc);
>
> unless(defined(&_STDIO_H_)) {
> eval 'sub _STDIO_H_ () {1;}' unless defined(&_STDIO_H_);
> require 'sys/cdefs.ph';
> require 'sys/_null.ph';
> require 'sys/_types.ph';
> unless(defined(&_SIZE_T_DECLARED)) {
> eval 'sub _SIZE_T_DECLARED () {1;}' unless defined(&_SIZE_T_DECLARED);
> }
> if((defined(&__POSIX_VISIBLE) ? &__POSIX_VISIBLE : undef) >= 200809) {
> unless(defined(&_OFF_T_DECLARED)) {
> eval 'sub _OFF_T_DECLARED () {1;}' unless defined(&_OFF_T_DECLARED);
<snip>
Interesting. So the people who created Perl didn't want to get as far
away from C as possible! They created an interpreter for a
preprocessor-like language, it looks like.
--
bartc
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
Page 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web