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 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-28 20:47 +0100 |
| Message-ID | <obeef8$238$1@dont-email.me> |
| In reply to | #107315 |
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. 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. and then > stumble over them. And then you complain here as though it were somehow > the fault of people who use Linux and/or gcc, conspiring to make your > life difficult. Yes, filling up header files full of complete junk, which, for people like me who have to wade through the mess to find out how something works, or why it doesn't, is a real problem. > But there are plenty of other things in programming that /are/ hard. > That includes many things in cross-platform development - that's why for > serious work, most people use toolkits or libraries where another group > has done the work already. Yes, toolkits that only work on Linux! So much for cross-platform development.... -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-28 22:46 +0200 |
| Message-ID | <obeht0$enl$1@dont-email.me> |
| In reply to | #107318 |
On 28/03/17 21:47, BartC 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. > > Is it possible that one or two of them might be a teeny bit bloated? > According to you, never! Where did I say that? I don't think I have been involved in that sub-thread at all. But I would certainly agree with the people who have tried to explain that there are good reasons why there are lots of files, lots of code, and lots of conditionals in some header files. And I don't see it as a problem. I am assuming that the people who put these files together have done a reasonable job - and thus the files and lines are there for a reason. A certain percentage will be unnecessary, existing mainly for "historical reasons". But most will be useful in some way to some people. And since it really does not bother me in the slightest how many lines of code my compiler chews through in its includes, as long as it is /fast enough/, the situation does not concern me. > 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. > Pre-processors are really, /really/ good at discarding unused lines. It is not a high cost. But the ability to use the same header files across a range of systems with different options, or a range of different options on the same system, is very useful. > and then >> stumble over them. And then you complain here as though it were somehow >> the fault of people who use Linux and/or gcc, conspiring to make your >> life difficult. > > Yes, filling up header files full of complete junk, which, for people > like me who have to wade through the mess to find out how something > works, or why it doesn't, is a real problem. There are no people like you, Bart. And there are very few people who wade through these headers - and even fewer who then discard the work of others as "complete junk" simply because they don't understand them. > >> But there are plenty of other things in programming that /are/ hard. >> That includes many things in cross-platform development - that's why for >> serious work, most people use toolkits or libraries where another group >> has done the work already. > > Yes, toolkits that only work on Linux! So much for cross-platform > development.... > Google for "cross-platform development" or "cross-platform toolkit".
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-28 23:46 +0100 |
| Message-ID | <obeoun$6nh$1@dont-email.me> |
| In reply to | #107327 |
On 28/03/2017 21:46, David Brown wrote: > On 28/03/17 21:47, BartC wrote: >> 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. >> >> Is it possible that one or two of them might be a teeny bit bloated? > But I would certainly agree with the people who have tried to explain > that there are good reasons why there are lots of files, lots of code, > and lots of conditionals in some header files. And I don't see it as a > problem. I am assuming that the people who put these files together > have done a reasonable job - and thus the files and lines are there for > a reason. It's also possible these things are big simply because lots of different people work on them. When it also becomes harder to discard things to tidy the code up. A certain percentage will be unnecessary, existing mainly for > "historical reasons". But most will be useful in some way to some > people. And since it really does not bother me in the slightest how > many lines of code my compiler chews through in its includes, as long as > it is /fast enough/, the situation does not concern me. The trouble is, when it stops being 'fast enough', then it can be harder to speed things up if things have been allowed to grow to unmanageable size through complacency. (I've been testing my new, not quite finished C compiler on a Raspberry Pi, the slow one. The final code generation is not there, but will probably add 10% to these figures. It compiles itself (16Kloc) in 0.4 seconds; gcc -O0 takes 26 seconds [to compile my compiler, not itself! Otherwise I'd be here all night, assuming I could get to first base]. It compiles sqlite.c (170Kloc plus includes windows.h) in 3 seconds; gcc -O0 takes 140 seconds (1000 seconds for -O3). Figures are rough comparisons only as I'm not generating ARM code, but x64 intermediate. Also gcc compiles sqlite using Linux headers not windows.h. But it's clear my product will be a bit more nippy.) >> 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. >> > > Pre-processors are really, /really/ good at discarding unused lines. It > is not a high cost. Unused lines spread over 150 headers and 650 #includes. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-29 00:53 +0200 |
| Message-ID | <obepck$7q0$1@dont-email.me> |
| In reply to | #107336 |
Le 29/03/2017 à 00:46, BartC a écrit : > It compiles itself (16Kloc) in 0.4 seconds; lcc-win compiles itself in 1.2 seconds, and it is not just generating intermediate code, it is generating all .obj files AND an executable... 75 kloc, not 16. But at least your are generating something, the compiler from the preacher here is still 100% vaporware. Did you write the whole front end? I would say, that is not possible. You would have told us about it before... It is just too quick.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-29 02:00 +0100 |
| Message-ID | <KGDCA.532035$F83.171462@fx38.am4> |
| In reply to | #107337 |
On 28/03/2017 23:53, jacobnavia wrote: > Le 29/03/2017 à 00:46, BartC a écrit : >> It compiles itself (16Kloc) in 0.4 seconds; > > lcc-win compiles itself in 1.2 seconds, and it is not just generating > intermediate code, it is generating all .obj files AND an executable... > > 75 kloc, not 16. On what equipment? The 0.4 second figure is from running on a 700Mhz Raspberry Pi 32-bit (effectively a cross-compile test because I can't target ARM yet). On my main PC (Intel 3.2Ghz) it's currently around 23ms (700Klps) to compile itself (but with some provisos which I list below). My aim was to see if I manage 1Mlps for a C compiler (compile all modules of a project, link and run at the same time, all in memory; no object files). But it looks like I may have to settle for nearer 0.5Mlps (except for certain files such as SQLITE.c where I can currently hit nearly 1.4Mlps, with a final version probably still above 1Mlps (ie. it will compile in 1/6th of a second). But SQLITE.c is 40% comments... > Did you write the whole front end? Yes, of course. And speed was a consideration from the start. (Last year I was writing very fast byte-code compilers, hitting 1.5Mlps, so wanted to see what I could do with C.) ------------------- Speed testing notes: * Figures quoted are the differences between clock() called at the start of execution, and clock() called just before printing timing stats * That includes certain overheads (otherwise peak lps is higher) but excludes others (process loading for for example). It assumes file contains have been cached (as they usually will be if you've just been working on them). * Compilation is processing on-disk source to in-memory code. Current in-memory code is a thin wrapper around x64 but it needs final conversion to native. This is a linear process and should not slow it down too much. * Not included are the fixups that will be necessary to run code in-memory. * Currently it compiles one module only, so all test inputs are a single C file including a C version of the compiler source (which is not written in C). Experience with my byte-code compiler suggests this gives a 10% advantage compared with compiling separate modules. * The best performance involves converting my compiler source to C, then compiling with gcc -O3. This is the one thing that grates. However, my own code (not using anyone's C compiler) is only 20% slower. And I can work on that 20%. (Tiny C also relies on gcc -O3 AFAIK.) What the hell, it's still going to be pretty fast! If it's ten times slower, it will still compile itself in 1/4 of a second. -- 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-29 05:05 -0700 |
| Message-ID | <7155b616-10d8-489c-a156-9f370573e8ec@googlegroups.com> |
| In reply to | #107337 |
Am Mittwoch, 29. März 2017 00:54:06 UTC+2 schrieb jacobnavia: > Le 29/03/2017 à 00:46, BartC a écrit : > > It compiles itself (16Kloc) in 0.4 seconds; > > lcc-win compiles itself in 1.2 seconds, and it is not just generating > intermediate code, it is generating all .obj files AND an executable... > > 75 kloc, not 16. > > But at least your are generating something, the compiler from the > preacher here is still 100% vaporware. Who is the preacher? 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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-29 10:57 -0400 |
| Message-ID | <8c17b560-278e-da25-b49f-aae2551dca3c@verizon.net> |
| In reply to | #107374 |
On 03/29/2017 08:05 AM, mertesthomas@gmail.com wrote: > Am Mittwoch, 29. März 2017 00:54:06 UTC+2 schrieb jacobnavia: ... >> But at least your are generating something, the compiler from the >> preacher here is still 100% vaporware. I'll give you a hint. One of his recent posts to this newsgroup was titled "The Lord calls out to you for repentance, salvation".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-29 17:06 +0200 |
| Message-ID | <obgibe$tq9$2@dont-email.me> |
| In reply to | #107391 |
On 29/03/17 16:57, James R. Kuyper wrote: > On 03/29/2017 08:05 AM, mertesthomas@gmail.com wrote: >> Am Mittwoch, 29. März 2017 00:54:06 UTC+2 schrieb jacobnavia: > ... >>> But at least your are generating something, the compiler from the >>> preacher here is still 100% vaporware. > > > I'll give you a hint. One of his recent posts to this newsgroup was > titled "The Lord calls out to you for repentance, salvation". And if that's not a good enough hint, look at your killfile settings!
[toc] | [prev] | [next] | [standalone]
| From | mertesthomas@gmail.com |
|---|---|
| Date | 2017-03-29 08:39 -0700 |
| Message-ID | <d99bc271-3318-4d92-af58-3eb0c679cf10@googlegroups.com> |
| In reply to | #107391 |
Am Mittwoch, 29. März 2017 16:58:01 UTC+2 schrieb James R. Kuyper: > On 03/29/2017 08:05 AM, mertesthomas wrote: > > Am Mittwoch, 29. März 2017 00:54:06 UTC+2 schrieb jacobnavia: > ... > >> But at least your are generating something, the compiler from the > >> preacher here is still 100% vaporware. > > > I'll give you a hint. One of his recent posts to this newsgroup was > titled "The Lord calls out to you for repentance, salvation". Thank you for this information. Btw. the salvation comes from using the right programming language. :-) [enter flame-war here] 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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-03-30 18:29 +0100 |
| Message-ID | <87vaqqlllt.fsf@gmail.com> |
| In reply to | #107396 |
mertesthomas@gmail.com writes: > Am Mittwoch, 29. März 2017 16:58:01 UTC+2 schrieb James R. Kuyper: >> On 03/29/2017 08:05 AM, mertesthomas wrote: >> > Am Mittwoch, 29. März 2017 00:54:06 UTC+2 schrieb jacobnavia: >> ... >> >> But at least your are generating something, the compiler from the >> >> preacher here is still 100% vaporware. >> >> >> I'll give you a hint. One of his recent posts to this newsgroup was >> titled "The Lord calls out to you for repentance, salvation". > > Thank you for this information. > Btw. the salvation comes from using the right programming language. :-) > [enter flame-war here] A Programming Language is merely medium through which the One True Editor occasionally may express its omnipotence. M-x all-hail-emacs
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-28 23:44 -0700 |
| Message-ID | <5f831b89-bc1a-4e63-a244-085b8497cef0@googlegroups.com> |
| In reply to | #107336 |
On Tuesday, March 28, 2017 at 5:46:47 PM UTC-5, Bart wrote:
> Figures are rough comparisons only as I'm not generating ARM code, but
> x64 intermediate. Also gcc compiles sqlite using Linux headers not
> windows.h. But it's clear my product will be a bit more nippy.)
How would its output compare with x86-64 gcc7 with -O3 when tasked with
generating the following to be called from outside code?
void shift8(unsigned char *p, unsigned char x)
{
for (int i=0; i<7; i++)
p[i] = p[i+1];
p[7] = x;
}
GCC generates
shift8(unsigned char*, unsigned char):
push rbx
mov ebx, esi
lea rsi, [rdi+1]
mov edx, 7
call memmove
mov BYTE PTR [rax+7], bl
pop rbx
ret
so I think you might do pretty well against it. If your compiler can allow
aliasing in situations where gcc -O3 wouldn't be inclined to do so, and the
above code were written to exploit that, e.g.
void shift8(unsigned char *p, unsigned char x)
{
*(unsigned int*)(p ) = *(unsigned int*)(p+1);
*(unsigned int*)(p+3) = *(unsigned int*)(p+4);
p[7] = x;
}
I wouldn't be surprised if you beat gcc -O3, since any memmove function
would need to do at least one comparison to select an algorithm (copy
upward or downward) and likely more than that (maybe processors can
optimize rep movsb to be as efficient as variations that copy larger
chunks, but at least historically a memcpy/memmove would have to manually
select the most efficient size of operand).
I wouldn't fault a compiler whose generated code sometimes increased the
fixed cost associated with a loop in exchange for reducing the per-iteration
costs even in cases where it would make smaller loops *slightly* more
expensive. Using memmove for a seven-byte copy operation, however, seems
to be setting the bar a bit low.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-29 12:33 +0100 |
| Message-ID | <4YMCA.401802$0k4.291341@fx37.am4> |
| In reply to | #107363 |
On 29/03/2017 07:44, supercat@casperkitty.com wrote:
> On Tuesday, March 28, 2017 at 5:46:47 PM UTC-5, Bart wrote:
>> Figures are rough comparisons only as I'm not generating ARM code, but
>> x64 intermediate. Also gcc compiles sqlite using Linux headers not
>> windows.h. But it's clear my product will be a bit more nippy.)
>
> How would its output compare with x86-64 gcc7 with -O3 when tasked with
> generating the following to be called from outside code?
My compiler will be 'nippy' with regard to compilation speed, not speed
of generated code, which will be rather pedestrian.
> void shift8(unsigned char *p, unsigned char x)
> {
> for (int i=0; i<7; i++)
> p[i] = p[i+1];
> p[7] = x;
> }
>
>
> GCC generates
>
> shift8(unsigned char*, unsigned char):
> push rbx
> mov ebx, esi
> lea rsi, [rdi+1]
> mov edx, 7
> call memmove
> mov BYTE PTR [rax+7], bl
> pop rbx
> ret
>
> so I think you might do pretty well against it.
I doubt it. I don't have an optimiser. But gcc -O0 generates 30
executable instructions for your function, and my code is 19
instructions (here shown as intermediate code but should map closely to
x64: https://pastebin.com/qsR2eH3F)
I've tested the output of an older compiler (likely to be as bad as this
one) and it performed poorly on a benchmark based around this function
(calling it 100 million times).
gcc -O3 was exceptional, but this is exactly what it excels it: making
fast work of small, tight functions like this. In fact, the difference
between -O3 and -O0 was 10:1. And actually, I needed to use 'volatile'
to stop the runtime being 0 seconds.
In more general apps however, which is what my compiler is aimed at, the
differences between my code and even gcc -O3 will be much narrower.
(And on the RPi, in the time it takes gcc to compile a program once, I
could squeeze in half a dozen edit-compile-run cycles. When the program
is finished and I want the maximum speed, /then/ maybe I could pass it
through gcc -O3!)
> If your compiler can allow
> aliasing
It's not aware of aliasing at all.
> Using memmove for a seven-byte copy operation, however, seems
> to be setting the bar a bit low.
Despite the memmove, it managed 0.23 seconds (on my test) compared with
2.25 seconds with -O0. Other compilers were around the 0.8 mark (all
optimised). My old one (with non-C equivalent code) about 1.3. Tiny C
somewhere above 3 seconds.
--
bartc
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-29 08:54 -0700 |
| Message-ID | <86081e8a-e976-4e54-8104-f0a3c71f37f3@googlegroups.com> |
| In reply to | #107368 |
On Wednesday, March 29, 2017 at 6:33:27 AM UTC-5, Bart wrote:
> gcc -O3 was exceptional, but this is exactly what it excels it: making
> fast work of small, tight functions like this. In fact, the difference
> between -O3 and -O0 was 10:1. And actually, I needed to use 'volatile'
> to stop the runtime being 0 seconds.
I'm not sure in what sense replacing a 7-byte loop with a call to memmove
is "excelling".
> In more general apps however, which is what my compiler is aimed at, the
> differences between my code and even gcc -O3 will be much narrower.
> > If your compiler can allow
> > aliasing
>
> It's not aware of aliasing at all.
By that do you mean it allows programmers to exploit aliasing however they
see fit, since it will reload everything all the time?
> > Using memmove for a seven-byte copy operation, however, seems
> > to be setting the bar a bit low.
>
> Despite the memmove, it managed 0.23 seconds (on my test) compared with
> 2.25 seconds with -O0. Other compilers were around the 0.8 mark (all
> optimised). My old one (with non-C equivalent code) about 1.3. Tiny C
> somewhere above 3 seconds.
Did you ensure gcc actually called the above routine, rather than inlining
it? If gcc inlines the code, it may decide not to do the stupid memmove.
How does your compiler's generated code compare if you use either:
void shift8(unsigned char *p, unsigned char x)
{
*(unsigned int*)(p ) = *(unsigned int*)(p+1);
*(unsigned int*)(p+3) = *(unsigned int*)(p+4);
p[7] = x;
}
or
void shift8(unsigned char *p, unsigned char x)
{
*(unsigned long long*)p >> 8;
p[7] = x;
}
Such things would be unsafe in gcc, since the documentation of gcc
doesn't actually promise clearly and unequivocally that -fno-strict-alias
will make it behave as though N1570 6.5.7, and the authors of gcc have
stated that they regard as "broken" any code that relies upon anything
less than a clear and unequivocal behavioral definition. I'm curious,
however, how performance would be in a compiler that could promise to
support them with machine-level semantics. Even a simplistic compiler
should be able to come up with something like:
push rbp
mov rbp,rsp
mov rbx,[rbp+16]
shr [qword rbx],8
mov rbx,[rbp+16]
add rbx,7
movzx rax,[byte bp+24]
mov [rbx],al
pop rbp
ret
A little longer than gcc's code which calls memmove, but I suspect it would
still be faster. Further, it wouldn't take much extra work for a compiler
to improve that to:
mov rbx,[rsp+16]
shr [qword rbx],8
movzx rax,[byte bp+24]
mov [rbx+7],al
ret
which should significantly outperform the memmove call.
What purpose is there for gcc making a memmove call for any fixed size less
than 33 bytes? Values from 5-7 bytes can at worst be done by loading two
32-bit registers with overlapping ranges and then storing them. Values from
9-15 bytes can be done by loading two 64-bit registers and storing them.
Values up to 32 bytes can be done by, at worst, loading up to four possibly-
overlapping 64-bit registers and storing them. If all loads are done before
any stores, there would be no need to worry about overlapping ranges. I'm
not sure what the break-even point would be for using memmove but I would be
very surprised if any version of memmove had a break-even point below 33
bytes on a CPU with hardware for efficient 8-byte unaligned loads.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-03-29 17:38 +0100 |
| Message-ID | <jqRCA.707709$Pm3.553290@fx42.am4> |
| In reply to | #107401 |
On 29/03/2017 16:54, supercat@casperkitty.com wrote:
> On Wednesday, March 29, 2017 at 6:33:27 AM UTC-5, Bart wrote:
>> gcc -O3 was exceptional, but this is exactly what it excels it: making
>> fast work of small, tight functions like this. In fact, the difference
>> between -O3 and -O0 was 10:1. And actually, I needed to use 'volatile'
>> to stop the runtime being 0 seconds.
>
> I'm not sure in what sense replacing a 7-byte loop with a call to memmove
> is "excelling".
>> It's not aware of aliasing at all.
>
> By that do you mean it allows programmers to exploit aliasing however they
> see fit, since it will reload everything all the time?
I really don't know how to answer that. Code I generate tends to do
exactly what the programmer tells it. Any optimisation it might do is
very conservative.
>>> Using memmove for a seven-byte copy operation, however, seems
>>> to be setting the bar a bit low.
>>
>> Despite the memmove, it managed 0.23 seconds (on my test) compared with
>> 2.25 seconds with -O0. Other compilers were around the 0.8 mark (all
>> optimised). My old one (with non-C equivalent code) about 1.3. Tiny C
>> somewhere above 3 seconds.
>
> Did you ensure gcc actually called the above routine, rather than inlining
> it? If gcc inlines the code, it may decide not to do the stupid memmove.
I've looked at it again within the context of the test, and I can't find
a trace of memmove. It seems to be inline code of some sort. There is a
still a loop, but I can't make head or tail of it.
So I'm not sure if it's doing the work that was set, or whether it's
taking some short cut.
(This is why I gave up testing against gcc -O2/-O3 years ago when
looking at micro-benchmarks.)
>
> How does your compiler's generated code compare if you use either:
>
> void shift8(unsigned char *p, unsigned char x)
> {
> *(unsigned int*)(p ) = *(unsigned int*)(p+1);
> *(unsigned int*)(p+3) = *(unsigned int*)(p+4);
> p[7] = x;
> }
I went straight to inline ASM, where it was easy to be faster than the
other compilers, but not as fast as gcc -O3.
So I think my test set up is flawed because gcc is better able to take
advantage. If I remove the main() routine containing the driver code,
and remove 'static' from shift8(), then then memmove is back.
/Now/ if I test it (calling shift8 from another module), then gcc -O3 is
a little bit slower than the other compilers (but still somewhat faster
than mine).
> Even a simplistic compiler
I'll leave that to you then..
> should be able to come up with something like:
>
> push rbp
> mov rbp,rsp
> mov rbx,[rbp+16]
> shr [qword rbx],8
> mov rbx,[rbp+16]
> add rbx,7
> movzx rax,[byte bp+24]
> mov [rbx],al
> pop rbp
> ret
Yes, this is why with bottlenecks, I just resort to ASM. Then you can
get by with a compiler that can't even do this reduction.
--
bartc
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-29 16:42 +0000 |
| Message-ID | <NtRCA.96799$7b1.42748@fx30.iad> |
| In reply to | #107401 |
supercat@casperkitty.com writes:
> I'm
>not sure what the break-even point would be for using memmove but I would be
>very surprised if any version of memmove had a break-even point below 33
>bytes on a CPU with hardware for efficient 8-byte unaligned loads.
What CPU has efficient 8-byte unaligned loads? Support for unaligned
operations (e.g. intel, ARM64), doesn't make them efficient.
The library version of memmove is highly optimized to deal with
unaligned start points and to use the most efficient load/stores
to handle the data movement (in some cases, using non-temporal
instructions to avoid cache pollution) and arranging instructions
to avoid register dependency stalls.
e.g.:
/**
* Fast Memory Copy.
*
* First, move any bytes prior to the first cache-line boundary as
* bytes. Then move an integral number of cache-lines, prefetching
* the next cache line to be used.
*
* Note: For best results, the caller should ensure that the source
* and destination buffers are at least 8-byte aligned.
*
* @param %RDI = The destination DVMM virtual address
* @param %RSI = The source DVMM virtual address
* @param %RDX = The number of bytes to copy
* @returns The destination DVMM virtual address
*/
ENTRY(memcpy)
ENTRY(memmove)
pushq %rbp # Push frame pointer on stack
movq %rsp, %rbp # Set new frame pointer
movq %rdi, %r8 # Save for return value
movq %rdx, %rcx # Copy to count register
andq $0x3f, %rcx # Up to first cache line
je 2f # Already aligned
subq %rcx, %rdx # Remove from count
1:
rep movsb
2:
movq %rdx, %rcx # Remaining Bytes to copy
shrq $6, %rcx # RCX - Number of cache lines
je 4f # Nothing left to copy
3:
prefetchnta 64(%rsi) # Prefetch one line ahead (shared)
prefetchw 64(%rdi) # Prefetch one line ahead (modified)
decq %rcx # Sets Flags for jnz below
movq (%rsi), %r9 # Copy cache line
movq 8(%rsi), %r10
movq 16(%rsi), %r11
movq 24(%rsi), %rax
movq %r9, (%rdi)
movq %r10, 8(%rdi)
movq %r11, 16(%rdi)
movq %rax, 24(%rdi)
movq 32(%rsi), %r9
movq 40(%rsi), %r10
movq 48(%rsi), %r11
movq 56(%rsi), %rax
movq %r9, 32(%rdi)
movq %r10, 40(%rdi)
movq %r11, 48(%rdi)
movq %rax, 56(%rdi)
leaq 64(%rdi), %rdi
leaq 64(%rsi), %rsi
jnz 3b
4:
movq %r8, %rax
leaveq
ret
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-29 10:28 -0700 |
| Message-ID | <01768d8f-39bd-4c55-b494-55b4c64df3ad@googlegroups.com> |
| In reply to | #107406 |
On Wednesday, March 29, 2017 at 11:42:27 AM UTC-5, Scott Lurndal wrote: > What CPU has efficient 8-byte unaligned loads? Support for unaligned > operations (e.g. intel, ARM64), doesn't make them efficient. From what i understand, modern x86 processors have no penalty for unaligned loads that fit within a cache line, and those which cross a cache-line boundary are treated as two memory operations. On some hardware platforms, unaligned stores need to be decomposed into pieces that each have a power-of-two size, so a 32-bit store may be split into one 16-bit pieces and two 8-bit pieces, and a 64-bit store may be split into one 32-bit, one 16-bit, and two 8-bit pieces. It's possible that reads might need similar treatment if a platform isn't willing to read outside the exact specified area; I'll generously allow that they might. A 32-byte move would thus require, worst-case, 16 reads and 16 writes. Using unaligned 64-bit ops would be more efficient, even worst-case, than using 32+32 individual byte operations. The only way code could win by optimizing for alignment would be if it could handling the middle 3 8-bit chunks as aligned units rather than having each get processed as up to four chunks. That could eliminate 9 redundant reads and 9 redundant writes in the odd-byte case, or 6+6 in the odd-halfword case, or 3+3 in the odd-word case. Would those savings be sufficient to justify the fixed cost of manually checking for alignment.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-29 20:09 +0000 |
| Message-ID | <4wUCA.96820$7b1.52990@fx30.iad> |
| In reply to | #107409 |
supercat@casperkitty.com writes: >On Wednesday, March 29, 2017 at 11:42:27 AM UTC-5, Scott Lurndal wrote: >> What CPU has efficient 8-byte unaligned loads? Support for unaligned >> operations (e.g. intel, ARM64), doesn't make them efficient. > >From what i understand, modern x86 processors have no penalty for unaligned >loads that fit within a cache line, and those which cross a cache-line >boundary are treated as two memory operations. I believe there is still at least a one-clock penalty for the barrel shifter on unaligned loads within the cache line.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-29 13:29 -0700 |
| Message-ID | <26d7320d-06b9-470f-bc44-952cb716125d@googlegroups.com> |
| In reply to | #107415 |
On Wednesday, March 29, 2017 at 3:09:43 PM UTC-5, Scott Lurndal wrote: > I believe there is still at least a one-clock penalty for the barrel shifter on > unaligned loads within the cache line. I know some chips had a penalty, and I would expect that some chips don't. In any case, unless unaligned loads are handled via trap handler, a move of 8 bytes at any alignment will almost certainly be handled at least as efficiently using a "load double-word" and "store double-word" instruction as by any combination of smaller instructions, even if the alignment is known. A 16-byte move at odd-word alignment may benefit from using two aligned word loads and a double-world load rather than two misaligned loads, and likewise for stores, but that pre-supposes that the alignment is known. If the alignment isn't known, the cost of figuring out what it is would exceed any savings unless the thing being moved is large.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-30 13:18 +0000 |
| Message-ID | <NA7DA.177343$Bp6.123761@fx36.iad> |
| In reply to | #107417 |
supercat@casperkitty.com writes: >On Wednesday, March 29, 2017 at 3:09:43 PM UTC-5, Scott Lurndal wrote: >> I believe there is still at least a one-clock penalty for the barrel shifter on >> unaligned loads within the cache line. > >I know some chips had a penalty, and I would expect that some chips don't. In my experience, the hardware cost to support zero-cost unaligned loads/stores is prohibitive. In any case, portable code should not assume unaligned loads are even possible.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-30 08:22 -0700 |
| Message-ID | <8b05cd8c-c380-4575-be07-0997205a20c2@googlegroups.com> |
| In reply to | #107484 |
On Thursday, March 30, 2017 at 8:18:44 AM UTC-5, Scott Lurndal wrote: > In my experience, the hardware cost to support zero-cost unaligned > loads/stores is prohibitive. In any case, portable code should not > assume unaligned loads are even possible. There is a time penalty, but if code has to operate on arbitrarily-placed objects, that penalty will on many processors be consistently less than the cost of manually splitting operations into smaller aligned pieces. On such processors, the only time code to manually handle alignment issues would come out ahead would be if multiple adjacent objects are going to have the same alignment. In general, if an implementation is known to have some useful features that others don't, exploiting such features will allow code to be written more simply or efficiently than would be possible otherwise, at the expense of making it unusable on other implementations. I don't see alignment issues as being special in that regard.
[toc] | [prev] | [next] | [standalone]
Page 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web