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 6 of 15 — ← Prev page 1 … 4 5 [6] 7 8 … 15 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-30 00:20 +0200 |
| Message-ID | <obhbph$ud2$1@dont-email.me> |
| In reply to | #107415 |
Le 29/03/2017 à 22:09, Scott Lurndal a écrit : > I believe there is still at least a one-clock penalty for the barrel shifter on > unaligned loads within the cache line. You think that at 2GHZ that is important? One cycle? Yes, we should try to write efficient programs but one cycle "penalty"? I mean at 2.2 GHZ it doesn't make it to 1 nanosecond: 0.45 ns. This is irrelevant in most programs. It is nine orders of magnitude smaller than a second, what is actually not a big lapse of time.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-29 15:38 -0700 |
| Message-ID | <072d0154-104f-419e-846a-8ab19c6712e3@googlegroups.com> |
| In reply to | #107430 |
On Wednesday, March 29, 2017 at 5:20:26 PM UTC-5, jacobnavia wrote: > Le 29/03/2017 à 22:09, Scott Lurndal a écrit : > > I believe there is still at least a one-clock penalty for the barrel shifter on > > unaligned loads within the cache line. > > You think that at 2GHZ that is important? One cycle? If code spends a lot of time shuffling things around the L0 cache, and its performance is sufficiently dominated by memory loads/stores that the CPU spends most of its time waiting for them to complete (processors can execute multiple instructions simultaneously, so that's not an unrealistic scenario) code which uses a lot of unaligned accesses when it could easily have used aligned accesses might take twice as long to execute as it should. That's a pretty big deal. On the other hand, if one doesn't know the alignment of an object, blindly performing an unaligned access and accepting the penalty may be faster than taking the time to examining an object's alignment and rearranging operations so as to avoid the penalty.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-30 13:19 +0000 |
| Message-ID | <MB7DA.177344$Bp6.5245@fx36.iad> |
| In reply to | #107430 |
jacobnavia <jacob@jacob.remcomp.fr> writes: >Le 29/03/2017 à 22:09, Scott Lurndal a écrit : >> I believe there is still at least a one-clock penalty for the barrel shifter on >> unaligned loads within the cache line. > >You think that at 2GHZ that is important? One cycle? > >Yes, we should try to write efficient programs but one cycle "penalty"? At _least_ one cycle, and considerably more on some processors, especially if they must trap and fixup. > >I mean at 2.2 GHZ it doesn't make it to 1 nanosecond: 0.45 ns. This is >irrelevant in most programs. It is nine orders of magnitude smaller than >a second, what is actually not a big lapse of time. You've clearly never designed a server processor.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-28 18:29 -0500 |
| Message-ID | <d6sldctmk51f65933intodjffjaqmkfin2@4ax.com> |
| In reply to | #107318 |
On Tue, 28 Mar 2017 20:47:36 +0100, BartC <bc@freeuk.com> wrote: >On 28/03/2017 20:29, David Brown wrote: >> On 28/03/17 20:45, BartC wrote: > >>> Thanks. According to David Brown, /nothing/ is ever difficult, nothing >>> is too complicated, and no tool is too slow! > >> And I certainly think a good proportion of the things you find >> extraordinarily difficult, complex or obtuse are not difficult at all. >> You have an extraordinary ability to wander into the fields, find little >> molehills, built them up into mountains of your imagination, > >Much of it is fact. Yesterday or the day before I posted some stats >about the size of windows.h on various compilers. You can choose to >compile on a 20Kloc version, or a 500Kloc one. My (open) question is what does the 20KLOC version omit that that the 500KLOC version does not. And again, there's only one definitive version, and that the one from MS. >Is it possible that one or two of them might be a teeny bit bloated? >According to you, never! There will also be some functionality they are >adding, some extra value, that is not present in the smaller version >(even if the small version still manages to compile the same program). > >Never mind that 75% of the lines in gcc/mingw's window.h (total 340K >lines in 160 files) are actually discarded, so are processed for nothing. Again, with further analysis, you can't tell if that's appropriate or not. As I mentioned, the normal MS windows.h has all sorts of provisions for only including subsets.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-29 01:36 +0200 |
| Message-ID | <obert5$e9f$1@dont-email.me> |
| In reply to | #107343 |
Le 29/03/2017 à 01:29, Robert Wessel a écrit :
> My (open) question is what does the 20KLOC version omit that that the
> 500KLOC version does not. And again, there's only one definitive
> version, and that the one from MS.
I omit unnecessary comments, spaces, etc. I omit plainly wrong ifdefs,
for instance if you eliminate all 32 bit stuff from windows.h a lot of
stuff and ifdefs go away. If you eliminate also all C++ stuff, you can
reduce the size of the headers by a LOT.
// This is used to switch the light
WINAPI STDCALL int TurnLightsOn(
__in __pure __whatever int howlong,
__out __mutable int * FAR result,
);
That can be reduced to
int TurnLightsOn(int,int);
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-29 22:36 +0200 |
| Message-ID | <obh5nr$81b$1@dont-email.me> |
| In reply to | #107345 |
On 29/03/17 01:36, jacobnavia wrote: > Le 29/03/2017 à 01:29, Robert Wessel a écrit : >> My (open) question is what does the 20KLOC version omit that that the >> 500KLOC version does not. And again, there's only one definitive >> version, and that the one from MS. > > I omit unnecessary comments, spaces, etc. Don't tell Bart - one of his key objections to big headers is that they are, in his opinion, unmaintainable. Removing comments and spaces won't help. > I omit plainly wrong ifdefs, > for instance if you eliminate all 32 bit stuff from windows.h a lot of > stuff and ifdefs go away. And so does support for 32-bit windows - it is hardly "plainly wrong". > If you eliminate also all C++ stuff, There are more than a few people that use C++ for development on Windows. They won't be using /your/ compiler, but it is certainly not "plainly wrong" or unnecessary in the standard version of windows.h It sounds more like you are pre-processing the windows.h file specifically for your compiler. That is not necessarily a bad idea, but it might be surprising to users if they want to actually look at the file, and are familiar with the original version. It could shave a few milliseconds off compile times - that would make Bart wet himself with joy, but not affect ordinary users. > you can > reduce the size of the headers by a LOT. > > // This is used to switch the light > > WINAPI STDCALL int TurnLightsOn( > __in __pure __whatever int howlong, > __out __mutable int * FAR result, > ); > > That can be reduced to > > int TurnLightsOn(int,int); > These extra bits are not "unnecessary" or "plainly wrong" - they are useful to more sophisticated compilers and tools, and/or deal with the historical silliness on 32-bit Windows of multiple calling conventions.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-29 23:50 +0200 |
| Message-ID | <obha0n$lst$1@dont-email.me> |
| In reply to | #107418 |
Le 29/03/2017 à 22:36, David Brown a écrit : > On 29/03/17 01:36, jacobnavia wrote: >> Le 29/03/2017 à 01:29, Robert Wessel a écrit : >>> My (open) question is what does the 20KLOC version omit that that the >>> 500KLOC version does not. And again, there's only one definitive >>> version, and that the one from MS. >> >> I omit unnecessary comments, spaces, etc. > > Don't tell Bart - one of his key objections to big headers is that they > are, in his opinion, unmaintainable. Removing comments and spaces won't > help. > lcc-win doesn't maintain any headers of windows since they are provided with the software development kit for windows. They are property of microsoft, like windows, the API, and all that stuff. >> I omit plainly wrong ifdefs, >> for instance if you eliminate all 32 bit stuff from windows.h a lot of >> stuff and ifdefs go away. > > And so does support for 32-bit windows - it is hardly "plainly wrong". > Allo? I am not Bart and I am just saying the same: all that bloated stuff can be trimmed to reason. I am the smallest. >> If you eliminate also all C++ stuff, > > There are more than a few people that use C++ for development on > Windows. They do not use lcc-win then. No c++ here. It is a C compiler. They won't be using /your/ compiler, but it is certainly not > "plainly wrong" or unnecessary in the standard version of windows.h > This headers are provided with lcc-win. They are adapted to lcc-win and not to any other compiler, compilers that need more bloated stuff, if you wish. I like small things, I find them beautifull, and my compiler has small parts, and it is a little c compiler. > It sounds more like you are pre-processing the windows.h file > specifically for your compiler. That is a fact, yes. I think each part must accomodate in the general philosophy, the design of lcc-win. > That is not necessarily a bad idea, but > it might be surprising to users if they want to actually look at the > file, and are familiar with the original version. Mmm, they are familiar with the bloated declarations, taking 4 lines of vertical space? I think they would find all the information more clearly in just one line, and anyway, the headers are not the information source but the microsoft documentation. Many windows programmers read the docs. And the docs are not in lcc-win but in microsoft that controls this interface. It could shave a few > milliseconds off compile times - that would make Bart wet himself with > joy, but not affect ordinary users. This is not done just for "shaving a few cycles" even if it does that too, of course. It is because eliminating bloat in space taken by the software it makes it easier to understand. You do not need to follow 32 bit stuff, that could confuse people. Anyway I agree that this does not affect ordinary users. > > >> you can >> reduce the size of the headers by a LOT. >> >> // This is used to switch the light >> >> WINAPI STDCALL int TurnLightsOn( >> __in __pure __whatever int howlong, >> __out __mutable int * FAR result, >> ); >> >> That can be reduced to >> >> int TurnLightsOn(int,int); >> > > These extra bits are not "unnecessary" or "plainly wrong" - they are > useful to more sophisticated compilers and tools, and/or deal with the > historical silliness on 32-bit Windows of multiple calling conventions. > Look, those extra bits are unnecessary in 64 bit windows, and if the annotations are followed by microsoft compilers they are not followed by lcc-win, so there is no sense in keeping that. And if more "sophisticated" tools than lcc-win need those headers, they could download the windows SDK, that microsoft published and not look into some compiler distributed headers... Those annotations aren't used in lcc-win, and each part is adapted to fit into the whole you see? A little c compiler.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-30 10:57 +1300 |
| Message-ID | <ek2otmFt3siU2@mid.individual.net> |
| In reply to | #107423 |
On 03/30/17 10:50 AM, jacobnavia wrote: >> > Look, those extra bits are unnecessary in 64 bit windows, and if the > annotations are followed by microsoft compilers they are not followed by > lcc-win, so there is no sense in keeping that. And if more > "sophisticated" tools than lcc-win need those headers, they could > download the windows SDK, that microsoft published and not look into > some compiler distributed headers... > > Those annotations aren't used in lcc-win, and each part is adapted to > fit into the whole you see? You are lucky, as an implementation provider you can remove all of the stuff not relevant to your implementation. It's a pity more don't! Cruft tends to accumulate and developers are seldom given the time to purge it. > A little c compiler. :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-03-29 15:10 -0700 |
| Message-ID | <c5aa8cd3-c88c-43fb-8009-55d90e24f2b6@googlegroups.com> |
| In reply to | #107423 |
On Wednesday, March 29, 2017 at 2:50:09 PM UTC-7, jacobnavia wrote: > Le 29/03/2017 à 22:36, David Brown a écrit : > > On 29/03/17 01:36, jacobnavia wrote: > >> Le 29/03/2017 à 01:29, Robert Wessel a écrit : > >>> My (open) question is what does the 20KLOC version omit that that the > >>> 500KLOC version does not. And again, there's only one definitive > >>> version, and that the one from MS. > >> > >> I omit unnecessary comments, spaces, etc. > > > > Don't tell Bart - one of his key objections to big headers is that they > > are, in his opinion, unmaintainable. Removing comments and spaces won't > > help. > > > > lcc-win doesn't maintain any headers of windows since they are provided > with the software development kit for windows. They are property of > microsoft, like windows, the API, and all that stuff. > > >> I omit plainly wrong ifdefs, > >> for instance if you eliminate all 32 bit stuff from windows.h a lot of > >> stuff and ifdefs go away. > > > > And so does support for 32-bit windows - it is hardly "plainly wrong". > > > > Allo? > > I am not Bart and I am just saying the same: all that bloated stuff can > be trimmed to reason. I am the smallest. > > >> If you eliminate also all C++ stuff, > > > > There are more than a few people that use C++ for development on > > Windows. > > They do not use lcc-win then. No c++ here. It is a C compiler. > > They won't be using /your/ compiler, but it is certainly not > > "plainly wrong" or unnecessary in the standard version of windows.h > > > > This headers are provided with lcc-win. They are adapted to lcc-win and > not to any other compiler, compilers that need more bloated stuff, if > you wish. > > I like small things, I find them beautifull, and my compiler has small > parts, and it is a little c compiler. > > > It sounds more like you are pre-processing the windows.h file > > specifically for your compiler. > > That is a fact, yes. I think each part must accomodate in the general > philosophy, the design of lcc-win. > > > That is not necessarily a bad idea, but > > it might be surprising to users if they want to actually look at the > > file, and are familiar with the original version. > > Mmm, they are familiar with the bloated declarations, taking 4 lines of > vertical space? > > I think they would find all the information more clearly in just one > line, and anyway, the headers are not the information source but the > microsoft documentation. > > Many windows programmers read the docs. And the docs are not in lcc-win > but in microsoft that controls this interface. > > It could shave a few > > milliseconds off compile times - that would make Bart wet himself with > > joy, but not affect ordinary users. > > This is not done just for "shaving a few cycles" even if it does that > too, of course. It is because eliminating bloat in space taken by the > software it makes it easier to understand. You do not need to follow 32 > bit stuff, that could confuse people. Anyway I agree that this does not > affect ordinary users. > > > > > >> you can > >> reduce the size of the headers by a LOT. > >> > >> // This is used to switch the light > >> > >> WINAPI STDCALL int TurnLightsOn( > >> __in __pure __whatever int howlong, > >> __out __mutable int * FAR result, > >> ); > >> > >> That can be reduced to > >> > >> int TurnLightsOn(int,int); > >> > > > > These extra bits are not "unnecessary" or "plainly wrong" - they are > > useful to more sophisticated compilers and tools, and/or deal with the > > historical silliness on 32-bit Windows of multiple calling conventions. > > > > Look, those extra bits are unnecessary in 64 bit windows, and if the > annotations are followed by microsoft compilers they are not followed by > lcc-win, so there is no sense in keeping that. And if more > "sophisticated" tools than lcc-win need those headers, they could > download the windows SDK, that microsoft published and not look into > some compiler distributed headers... > > Those annotations aren't used in lcc-win, and each part is adapted to > fit into the whole you see? > > A little c compiler. My compiler is strictly an intellectual exercise and I have no interest in efficiency or hardware. I do want to make it as simple as possible and to make it make post-compiler code that is as simple as possible. I started, a long time ago, with 1990 standard C and have stayed close to it ever since. But when I look at real life code (usually GTK+ based) I find it generally opaque so I end up trying to write tools to answer simple questions. The use of include files makes it hard to tell whether a function referenced in a unit in local or external. OK - that is easy enough to automate. Now the question becomes - which unit is each of the externals found in? I still haven't a decent tool to answer that question. I don't really to want to write an IDE but I may have to. Simpler headers would help a great deal.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-30 11:15 +1300 |
| Message-ID | <ek2q0iFt3siU3@mid.individual.net> |
| In reply to | #107428 |
On 03/30/17 11:10 AM, David Kleinecke wrote: > > My compiler is strictly an intellectual exercise and I have no > interest in efficiency or hardware. I do want to make it as simple > as possible and to make it make post-compiler code that is as simple > as possible. I started, a long time ago, with 1990 standard C and > have stayed close to it ever since. > > But when I look at real life code (usually GTK+ based) I find it > generally opaque so I end up trying to write tools to answer simple > questions. The use of include files makes it hard to tell whether a > function referenced in a unit in local or external. OK - that is > easy enough to automate. Now the question becomes - which unit is > each of the externals found in? I still haven't a decent tool to > answer that question. I don't really to want to write an IDE but I > may have to. Simpler headers would help a great deal. You don't have to write one to use one... Navigating foreign code is one of the most useful features of an IDE. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-03-30 09:22 -0700 |
| Message-ID | <80046ff5-5674-4b65-9847-bc07c27a6f82@googlegroups.com> |
| In reply to | #107429 |
On Wednesday, March 29, 2017 at 3:15:54 PM UTC-7, Ian Collins wrote: > On 03/30/17 11:10 AM, David Kleinecke wrote: > > > > My compiler is strictly an intellectual exercise and I have no > > interest in efficiency or hardware. I do want to make it as simple > > as possible and to make it make post-compiler code that is as simple > > as possible. I started, a long time ago, with 1990 standard C and > > have stayed close to it ever since. > > > > But when I look at real life code (usually GTK+ based) I find it > > generally opaque so I end up trying to write tools to answer simple > > questions. The use of include files makes it hard to tell whether a > > function referenced in a unit in local or external. OK - that is > > easy enough to automate. Now the question becomes - which unit is > > each of the externals found in? I still haven't a decent tool to > > answer that question. I don't really to want to write an IDE but I > > may have to. Simpler headers would help a great deal. > > You don't have to write one to use one... Navigating foreign code is > one of the most useful features of an IDE. True. Perhaps I just haven't found the right IDE. But I like to understand the tools I use so I want an open source IDE.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-03-30 18:50 +0200 |
| Message-ID | <20170330185005.2bc80bff91727ed2f928c337@gmail.com> |
| In reply to | #107496 |
On Thu, 30 Mar 2017 09:22:32 -0700 (PDT) David Kleinecke <dkleinecke@gmail.com> wrote: > But I like to understand the tools I use so I want an open > source IDE. You don't need technical drawings to understand how to drive a car. However if you'd like to study an IDE design, you may look at an open source project or write your own design with much or less success. From your (bad or good) experiences you will acquire new competences. Personally I find the use of any IDE is distracting and prevent the programmer from keeping his eyes on the code.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-03-31 09:31 -0700 |
| Message-ID | <34a9ec06-f457-41b7-8dae-06d9c1cb7936@googlegroups.com> |
| In reply to | #107497 |
On Thursday, March 30, 2017 at 9:52:34 AM UTC-7, GOTHIER Nathan wrote: > On Thu, 30 Mar 2017 09:22:32 -0700 (PDT) > David Kleinecke <dkleinecke@gmail.com> wrote: > > > But I like to understand the tools I use so I want an open > > source IDE. > > You don't need technical drawings to understand how to drive a car. > > However if you'd like to study an IDE design, you may look at an open source > project or write your own design with much or less success. From your (bad or > good) experiences you will acquire new competences. > > Personally I find the use of any IDE is distracting and prevent the programmer > from keeping his eyes on the code. I think IDE design is a potentially interesting question but it doesn't really seem to be a suitable topic for comp.lang.c.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-30 10:26 +0200 |
| Message-ID | <obifam$e0v$1@dont-email.me> |
| In reply to | #107423 |
On 29/03/17 23:50, jacobnavia wrote: > > This headers are provided with lcc-win. They are adapted to lcc-win and > not to any other compiler, compilers that need more bloated stuff, if > you wish. > It is absolutely fine to make headers for your compiler that fit your compiler and no others, and that fit with your design plans for your tool. That makes perfect sense. And the same goes for Bart for his tools - he can use whatever headers he wants. But that does /not/ mean that other sets of headers are "bloated", full of "unnecessary comments", "plainly wrong ifdefs", and the like. It just means /you/ don't need them for /your/ tools. Other people /do/ need them or find them useful - either people using those headers in different ways, or the people writing and maintaining the headers.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-30 13:23 +0000 |
| Message-ID | <6F7DA.177345$Bp6.7582@fx36.iad> |
| In reply to | #107423 |
jacobnavia <jacob@jacob.remcomp.fr> writes: >Le 29/03/2017 à 22:36, David Brown a écrit : >> These extra bits are not "unnecessary" or "plainly wrong" - they are >> useful to more sophisticated compilers and tools, and/or deal with the >> historical silliness on 32-bit Windows of multiple calling conventions. >> > >Look, those extra bits are unnecessary in 64 bit windows, Actually, since one may still build and execute 32-bit applications under 64-bit windows, I'd tend to disagree with that statement.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-03-30 12:01 -0500 |
| Message-ID | <c7eqdc1h016pfridif0huairasdbn6uedk@4ax.com> |
| In reply to | #107486 |
On Thu, 30 Mar 2017 13:23:14 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >jacobnavia <jacob@jacob.remcomp.fr> writes: >>Le 29/03/2017 à 22:36, David Brown a écrit : > >>> These extra bits are not "unnecessary" or "plainly wrong" - they are >>> useful to more sophisticated compilers and tools, and/or deal with the >>> historical silliness on 32-bit Windows of multiple calling conventions. >>> >> >>Look, those extra bits are unnecessary in 64 bit windows, > >Actually, since one may still build and execute 32-bit applications >under 64-bit windows, I'd tend to disagree with that statement. In fact most Windows applications are still 32 bit. For the most part they run just fine on Win64 machines, and then you don't have to support two versions. Some things do require 64-bit versions, notably some system stuff (device drivers), and if you offer some sort of API, you may need to have a 64-bit version. Obviously there are other advantages to being 64-bit (access to more address space being an obvious one), but they don't apply to all applications.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-02 13:51 +0000 |
| Message-ID | <58e1014a.9886437@news.xs4all.nl> |
| In reply to | #107486 |
scott@slp53.sl.home (Scott Lurndal) wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: > >Le 29/03/2017 à 22:36, David Brown a écrit : > > >> These extra bits are not "unnecessary" or "plainly wrong" - they are > >> useful to more sophisticated compilers and tools, and/or deal with the > >> historical silliness on 32-bit Windows of multiple calling conventions. > >> > > > >Look, those extra bits are unnecessary in 64 bit windows, > > Actually, since one may still build and execute 32-bit applications > under 64-bit windows, I'd tend to disagree with that statement. It may surprise jacob, who is an entirely self-made multi-billionaire, but some people still _use_ 32-bit versions of Windows. Because they have to, not because they're crazy or out to prove jacob wrong. Not everybody can afford to buy the latest model HP desktop every single year; in particular small businesses often have to make do with what they have and what works at an affordable fourth-hand price. Richard
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-04-02 23:04 +0200 |
| Message-ID | <obrors$873$1@dont-email.me> |
| In reply to | #107644 |
Le 02/04/2017 à 15:51, Richard Bos a écrit : > It may surprise jacob, who is an entirely self-made multi-billionaire, > but some people still _use_ 32-bit versions of Windows. Because they > have to, not because they're crazy or out to prove jacob wrong. Not > everybody can afford to buy the latest model HP desktop every single > year; in particular small businesses often have to make do with what > they have and what works at an affordable fourth-hand price. 1) Look Richard you do not like me. OK, it is your right, but we know that, is it necessary to say it in all your messages? 2) I am working in a processor that costs 30 US$. lcc-win starts working in that machine, and it could be the machine for everyone. 3) It is the amount of work involved in supporting all that code. I can't do that, so I specialize and take what is absolutely necessary. It is not to force people to buy new machines now, come on. 4) I am more than just a mere multibillionary. Much more. I do what I want, can you imagine that? Regards jacob
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-04-03 17:45 +0000 |
| Message-ID | <58e288b7.10581062@news.xs4all.nl> |
| In reply to | #107655 |
jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 02/04/2017 à 15:51, Richard Bos a écrit : > > It may surprise jacob, who is an entirely self-made multi-billionaire, > > but some people still _use_ 32-bit versions of Windows. Because they > > have to, not because they're crazy or out to prove jacob wrong. Not > > everybody can afford to buy the latest model HP desktop every single > > year; in particular small businesses often have to make do with what > > they have and what works at an affordable fourth-hand price. > > 1) Look Richard you do not like me. OK, it is your right, but we know > that, is it necessary to say it in all your messages? It's not you I don't like, it's your attitude towards people who have (_have_!) to use machines you consider beneath you. And if you think I mention you in all my messages, I really do think you need to get checked for paranoia. > 2) I am working in a processor that costs 30 US$. lcc-win starts working > in that machine, and it could be the machine for everyone. Ah-hah. I'm sure millions of mom-and-pop businesses all over the world, including the third world, would love to be able to buy that machine. Where can they do so? I'm sure I can't find it. > 3) It is the amount of work involved in supporting all that code. I > can't do that, so I specialize and take what is absolutely necessary. That is your choice, and it's a perfectly valid one. Pretending that it is the _only_ reasonable choice, and that supporting 32-bit computers is completely unnecessary these days, is _not_ valid. If you'd stuck to the former, and stopped doing the latter, I'd have no problem with your attitude. Richard
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-04-03 22:09 +0200 |
| Message-ID | <obua08$hsc$1@dont-email.me> |
| In reply to | #107681 |
Le 03/04/2017 à 19:45, Richard Bos a écrit : > Pretending that it is the _only_ reasonable choice, and that supporting > 32-bit computers is completely unnecessary these days, is _not_ valid. I have said nowhere that support of 32 bit applications should be dropped anywhere. I said that NOW with my current situation lcc-win simplifies the 64 bit headers offering only the 64 bit interface, and that is a good choice for lcc-win and maybe for other compilers if they want to cut into the baggage. A 32 bit compiler doesn't need any 64 bit interface and that could be cutted in the distribution of those 32 bit compilers too, without affecting compilation. This all is a consequence of you supposing that I consider 32 bits applications obsolete, what they are surely not. I was talking about specializing compilers to the environment they should be working and not make tools that are too general and too confusing to use. FAR, NEAR, etc, had their day in 16 bit applications. There is no point in using them in 64 bit applications. That is what I was saying, but you read that and deduce some completely different conclusions without any reference to what I wrote. There are people that can't afford a new computer. Yes, I know that. But that is a social problem that has nothing to do with how compilers can be built or tools and source code in general. Look at what you write: <quote> It may surprise jacob, who is an entirely self-made multi-billionaire, but some people still _use_ 32-bit versions of Windows. <end quote> then, <quote> Not everybody can afford to buy the latest model <end quote> Now jacob, the billionaire is trying to get rid of the poor folks that can't afford a new machine. All that because I say that 64 bit compilers could drop the 32 bit stuff in 64 bit compilers? 64 bit hardware was introduced by AMD around the year 2000, so it is HIGHLY certain that all 32 bit users are running 64 bit hardware unless their machine is 15 years old or older. True, windows xp is still running OK, and many people are forced to use that. So what? Are those people using 64 bit compilers? Surely not, in a 32 bit system. And 32 bit developers do not use 15+ year old machines as far as I can see. Yes, many people will start with "you haven't seen anything" or even Bart will start whinning that he uses a 20 year old machine. Richard Heathfield was using a compiler from the last century I remember (maybe he as updated since then) but here people are very fond of old stuff. As I get older, I see what happens, but try to keep current and not design programs around nostalgic feelings. "Those were the days, my friend..." etc. Software should not carry on old cruft forever.
[toc] | [prev] | [next] | [standalone]
Page 6 of 15 — ← Prev page 1 … 4 5 [6] 7 8 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web