Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #108327 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2017-04-22 09:06 +0100 |
| Last post | 2017-04-26 08:53 +0200 |
| Articles | 20 on this page of 245 — 25 participants |
Back to article view | Back to comp.lang.c
gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 09:06 +0100
Re: gcc failure (optimised/non-optimised) Andrew Cooper <amc96@cam.ac.uk> - 2017-04-22 09:49 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:52 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:37 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:07 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 08:33 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-28 22:32 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-28 14:53 -0700
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-29 07:00 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:19 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-29 11:30 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-22 16:12 +0200
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:16 +0100
Re: gcc failure (optimised/non-optimised) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-23 05:41 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-23 14:14 -0700
Re: gcc failure (optimised/non-optimised) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-24 04:04 -0500
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:22 +0100
Re: gcc failure (optimised/non-optimised) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-24 12:05 -0400
Re: gcc rules OK (optimised/non-optimised) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-24 17:06 -0400
Re: gcc rules OK (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 15:06 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:31 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 09:29 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 10:47 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 11:36 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:50 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 15:35 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:36 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 08:37 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:07 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-25 11:57 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:34 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 11:25 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:57 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:38 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-28 22:38 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-22 08:35 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 17:16 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 18:55 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-22 21:04 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-22 21:51 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:56 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 16:49 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-30 16:02 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 11:51 -0500
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 21:42 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-30 17:35 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 11:57 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-30 18:44 +0100
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 11:34 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 12:03 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:30 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-30 21:18 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:33 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 16:27 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-01 10:16 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:34 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:43 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-03 12:54 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 17:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-03 18:05 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 20:37 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 10:22 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 11:01 +0100
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 12:18 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 11:55 +0100
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 15:14 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-04 09:34 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 10:09 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:25 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-04 11:28 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 11:53 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 13:07 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 14:19 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 16:44 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:09 -0700
Re: gcc failure (optimised/non-optimised) Ian Collins <ian-news@hotmail.com> - 2017-05-05 08:17 +1200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 22:26 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:38 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 22:49 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 19:58 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:32 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-05 12:53 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:51 -0700
Re: gcc failure (optimised/non-optimised) Ian Collins <ian-news@hotmail.com> - 2017-05-05 08:58 +1200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:45 -0700
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-05 06:41 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-05 10:40 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-06 13:21 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-06 11:26 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-06 22:52 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-07 19:01 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-07 19:48 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 11:17 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 06:36 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 16:21 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 09:16 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 21:20 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 13:07 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 22:46 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 14:38 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:16 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 15:09 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 15:14 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 15:43 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 16:56 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 16:57 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 17:27 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 17:41 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:16 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-09 12:11 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 09:58 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 09:40 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-10 12:05 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:55 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:26 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-09 13:56 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 14:19 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-10 14:22 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 09:26 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:36 -0500
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 01:12 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 21:15 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 10:41 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-11 15:32 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 01:54 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-12 07:45 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 23:52 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 12:57 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-10 21:56 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 10:45 +0200
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-11 14:43 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-12 10:55 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-12 07:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-12 09:02 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-14 13:14 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 16:04 -0500
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:33 -0500
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:51 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:14 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:07 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-09 18:30 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:44 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:42 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-05 14:10 +0000
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 17:12 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 15:08 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:24 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:29 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 18:07 +0000
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 20:15 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 15:47 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 01:22 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 18:57 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 09:30 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:25 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 10:33 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 10:10 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 12:49 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-05 18:31 -0700
Re: gcc failure (optimised/non-optimised) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-05 22:18 -0600
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-07 23:58 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:33 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:04 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:51 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-08 19:01 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:39 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-10 06:42 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:53 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-05 00:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:54 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:27 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 02:10 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 22:56 -0500
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:00 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 15:15 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:06 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-05 00:43 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 21:52 +0200
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-01 23:16 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-02 09:19 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:28 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 13:12 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:23 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 10:08 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:32 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 13:59 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:47 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-30 21:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 11:24 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 12:45 -0700
Re: gcc failure (optimised/non-optimised) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-04-23 23:11 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:46 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:23 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 15:38 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 17:31 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-24 17:15 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:36 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:06 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 14:03 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:25 -0700
Re: gcc failure (optimised/non-optimised) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-27 05:51 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:08 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-01 10:48 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 11:39 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-05-01 13:54 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:55 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:18 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:03 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:13 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 19:47 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 18:51 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 14:06 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 21:05 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 16:06 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 14:19 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 08:41 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 10:07 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:44 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 09:03 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 09:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:41 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:51 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 08:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:13 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:11 +0000
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 14:04 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:57 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:38 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:43 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 18:22 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 17:48 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:24 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-27 03:03 -0700
Re: gcc failure (optimised/non-optimised) James Kuyper <jameskuyper@verizon.net> - 2017-04-27 10:12 -0400
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:48 +0000
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 10:14 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:32 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:47 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-26 08:53 +0200
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-05 10:32 +0200 |
| Message-ID | <oehd57$m69$1@dont-email.me> |
| In reply to | #109291 |
On 05/05/17 04:58, David Kleinecke wrote:
> On Thursday, May 4, 2017 at 1:49:29 PM UTC-7, David Brown wrote:
>> On 04/05/17 22:38, David Kleinecke wrote:
>>> On Thursday, May 4, 2017 at 1:27:05 PM UTC-7, David Brown wrote:
>>>> On 04/05/17 22:09, David Kleinecke wrote:
>>>>> On Thursday, May 4, 2017 at 7:45:11 AM UTC-7, David Brown wrote:
>>>>>> On 04/05/17 15:19, bartc wrote:
>>>>>>> On 04/05/2017 12:07, David Brown wrote:
>>>>>>>
>>>>>> Oh, I can understand it for /some/ for loops. Sometimes it is clearer
>>>>>> (usually for some personal subjective value of "clearer") to use "while"
>>>>>> loops, even though someone else might have written it as a "for" loop.
>>>>>> If someone had written "for (; cond ;) ...", I would be much happier
>>>>>> seeing it as "while (cond) ...". But if I correctly interpreted David
>>>>>> K's posts, he would also change:
>>>>>>
>>>>>> for (int i = 0; i < 10; i++) ...
>>>>>>
>>>>>> into:
>>>>>>
>>>>>> Int i = 0;
>>>>>> while (i < 10) {
>>>>>> ...
>>>>>> i++;
>>>>>> }
>>>>>>
>>>>>> which seems a big step backwards to me.
>>>>>
>>>>> A lot depends on what goes on in the {...}. If i is never
>>>>> used (happens) then
>>>>> i = 10;
>>>>> while (i--) { ...}
>>>>> works. If i is used only once then that occurrence can be
>>>>> give the ++. Otherwise it is often OK to increment the last
>>>>> time i occurs in the {...}. A separate i++ is rarely needed.
>>>>>
>>>>>
>>>>
>>>> There are lots of ways a for loop like the one above can be re-written
>>>> using while. The point is, why? It will almost certainly not result in
>>>> clearer code (Ian gave some reasons for that). It will almost certainly
>>>> not result in more efficient object code.
>>>
>>> Well then it doesn't matter which way one goes. If one
>>> objects to "for" constructs on esthetic grounds - like I
>>> do - "while" is available. And vice versa.
>>>
>>> There is a school of thought that there should always be
>>> only one way to do things. I don't belong.
>>>
>>
>> Apparently you /are/ of the school of thought that there should only be
>> one way of doing things. Most C programmers aim to use "for" loops when
>> that is clearer, and "while" loops when they are clearer. There are
>> good reasons why the language has multiple ways of writing loops.
>>
>> What you seem to want to do, however, is restrict the language to a
>> subset - specifically excluding "for" loops. And you are willing to
>> make a mess of existing code, rendering it almost unintelligible to
>> other programmers, simply because you don't like C's "for" syntax (or
>> its standard types).
>
> You still misunderstand what I am doing. I am looking for
> simplicity and elegance. I am not "seriously" coding. I usually
> don't even bother to compile. I look at what I have produced and
> ask - is this easier to understand?
Why not just change your editor to use a prettier font? That is about
as useful.
"Simplicity and elegance" sound great, but are hard to achieve. One way
to ensure that you cannot possibly get there is by re-writing code with
artificial restrictions on key language features that exist to make code
flow clearer. Another way to ensure failure is to arbitrarily create
your own terms for normal language features.
>
> But I observe that "easier to understand" is a very elusive
> concept. I have spent enough time doing forensic programming -
> by which I mean documenting what existing undocumented programs
> actually do - to appreciate simplicity and elegance.
>
I agree that "easier to understand" is a difficult concept, and is often
used very subjectively. Unless you are coding for a very specific
audience, you need to find a balance between "easier for /me/ to
understand" and "easier for the average C programmer to understand".
Changing all "for" loops into "while" loops, or inventing your own names
for standard types, is firmly in the "me" side here.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-05 12:53 -0700 |
| Message-ID | <c5db84b3-90d5-4c23-b029-139cee403d59@googlegroups.com> |
| In reply to | #109304 |
On Friday, May 5, 2017 at 1:32:52 AM UTC-7, David Brown wrote:
> On 05/05/17 04:58, David Kleinecke wrote:
> > On Thursday, May 4, 2017 at 1:49:29 PM UTC-7, David Brown wrote:
> >> On 04/05/17 22:38, David Kleinecke wrote:
> >>> On Thursday, May 4, 2017 at 1:27:05 PM UTC-7, David Brown wrote:
> >>>> On 04/05/17 22:09, David Kleinecke wrote:
> >>>>> On Thursday, May 4, 2017 at 7:45:11 AM UTC-7, David Brown wrote:
> >>>>>> On 04/05/17 15:19, bartc wrote:
> >>>>>>> On 04/05/2017 12:07, David Brown wrote:
> >>>>>>>
> >>>>>> Oh, I can understand it for /some/ for loops. Sometimes it is clearer
> >>>>>> (usually for some personal subjective value of "clearer") to use "while"
> >>>>>> loops, even though someone else might have written it as a "for" loop.
> >>>>>> If someone had written "for (; cond ;) ...", I would be much happier
> >>>>>> seeing it as "while (cond) ...". But if I correctly interpreted David
> >>>>>> K's posts, he would also change:
> >>>>>>
> >>>>>> for (int i = 0; i < 10; i++) ...
> >>>>>>
> >>>>>> into:
> >>>>>>
> >>>>>> Int i = 0;
> >>>>>> while (i < 10) {
> >>>>>> ...
> >>>>>> i++;
> >>>>>> }
> >>>>>>
> >>>>>> which seems a big step backwards to me.
> >>>>>
> >>>>> A lot depends on what goes on in the {...}. If i is never
> >>>>> used (happens) then
> >>>>> i = 10;
> >>>>> while (i--) { ...}
> >>>>> works. If i is used only once then that occurrence can be
> >>>>> give the ++. Otherwise it is often OK to increment the last
> >>>>> time i occurs in the {...}. A separate i++ is rarely needed.
> >>>>>
> >>>>>
> >>>>
> >>>> There are lots of ways a for loop like the one above can be re-written
> >>>> using while. The point is, why? It will almost certainly not result in
> >>>> clearer code (Ian gave some reasons for that). It will almost certainly
> >>>> not result in more efficient object code.
> >>>
> >>> Well then it doesn't matter which way one goes. If one
> >>> objects to "for" constructs on esthetic grounds - like I
> >>> do - "while" is available. And vice versa.
> >>>
> >>> There is a school of thought that there should always be
> >>> only one way to do things. I don't belong.
> >>>
> >>
> >> Apparently you /are/ of the school of thought that there should only be
> >> one way of doing things. Most C programmers aim to use "for" loops when
> >> that is clearer, and "while" loops when they are clearer. There are
> >> good reasons why the language has multiple ways of writing loops.
> >>
> >> What you seem to want to do, however, is restrict the language to a
> >> subset - specifically excluding "for" loops. And you are willing to
> >> make a mess of existing code, rendering it almost unintelligible to
> >> other programmers, simply because you don't like C's "for" syntax (or
> >> its standard types).
> >
> > You still misunderstand what I am doing. I am looking for
> > simplicity and elegance. I am not "seriously" coding. I usually
> > don't even bother to compile. I look at what I have produced and
> > ask - is this easier to understand?
>
> Why not just change your editor to use a prettier font? That is about
> as useful.
>
> "Simplicity and elegance" sound great, but are hard to achieve. One way
> to ensure that you cannot possibly get there is by re-writing code with
> artificial restrictions on key language features that exist to make code
> flow clearer. Another way to ensure failure is to arbitrarily create
> your own terms for normal language features.
>
> >
> > But I observe that "easier to understand" is a very elusive
> > concept. I have spent enough time doing forensic programming -
> > by which I mean documenting what existing undocumented programs
> > actually do - to appreciate simplicity and elegance.
> >
>
> I agree that "easier to understand" is a difficult concept, and is often
> used very subjectively. Unless you are coding for a very specific
> audience, you need to find a balance between "easier for /me/ to
> understand" and "easier for the average C programmer to understand".
> Changing all "for" loops into "while" loops, or inventing your own names
> for standard types, is firmly in the "me" side here.
I am not aiming at the average C programmer. What I have seen
of average C code suggests the average C programmer is running
on auto-pilot most of the time. I am trying imagine the coding
principals in the fairly distant future - say 2117.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-04 13:51 -0700 |
| Message-ID | <af4a5046-a306-4248-9720-2a3c630407f8@googlegroups.com> |
| In reply to | #109265 |
On Thursday, May 4, 2017 at 3:27:05 PM UTC-5, David Brown wrote:
> There are lots of ways a for loop like the one above can be re-written
> using while. The point is, why? It will almost certainly not result in
> clearer code (Ian gave some reasons for that). It will almost certainly
> not result in more efficient object code.
I've seen plenty of compilers where a count-toward-zero loop will generate
more efficient object code. Some people may consider that horrible, but I
believe the quality of a compiler intended for low-level programming on a
platform should be evaluated based upon the efficiency of code *it can be
coaxed into generating by someone familiar with the platform*. Compilers
intended for other purposes should be judged by other criteria.
If `size` is a global variable that won't change during a loop, a compiler
given
for (unsigned i=0; i<size; i++)
{
.. doSomething
}
won't be able to optimize away the comparison unless it can *prove* that
size won't change within the loop. While one could write code that uses
an automatic variable to hold a copy of the size and another to hold the
current count, I would regard:
unsigned n=size;
if (n) do
{
...someAction...
} while(--n);
to be nicer than declaring an extra variable and hoping the optimizer gets
rid of it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-05 08:58 +1200 |
| Message-ID | <en1iv8Fnb5bU4@mid.individual.net> |
| In reply to | #109270 |
On 05/ 5/17 08:51 AM, supercat@casperkitty.com wrote: > On Thursday, May 4, 2017 at 3:27:05 PM UTC-5, David Brown wrote: >> There are lots of ways a for loop like the one above can be re-written >> using while. The point is, why? It will almost certainly not result in >> clearer code (Ian gave some reasons for that). It will almost certainly >> not result in more efficient object code. > > I've seen plenty of compilers where a count-toward-zero loop will generate > more efficient object code. When? in the 80s? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-04 14:45 -0700 |
| Message-ID | <661a92b8-5aad-4b52-b9c4-484556cf4ac7@googlegroups.com> |
| In reply to | #109271 |
On Thursday, May 4, 2017 at 3:58:30 PM UTC-5, Ian Collins wrote: > When? in the 80s? In the world of small embedded controllers, such things are still common. When designing a system, it's often important to be able to test the performance of software mockups on proposed hardware designs to see if they will be able to achieve adequate performance before committing time to getting production software working on hardware that may need to be abandoned. Having a compiler apply a massive speedup to mockup/benchmarking code that won't actually be available in production will be decidedly unhelpful. Again, different implementations are intended for different purposes. I don't object to compilers that apply certain loop optimizations when it makes sense for them to do so, but I tend to be of the opinion that if one doesn't want a low-level compiler to include something in the machine code, one shouldn't write it in the source.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-05-05 06:41 +0100 |
| Message-ID | <87shkjq2qs.fsf@gmail.com> |
| In reply to | #109275 |
supercat@casperkitty.com writes: > On Thursday, May 4, 2017 at 3:58:30 PM UTC-5, Ian Collins wrote: >> When? in the 80s? > > In the world of small embedded controllers, such things are still common. Name three.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-05 10:40 -0700 |
| Message-ID | <966b8240-6c88-4a9a-83aa-004646558fca@googlegroups.com> |
| In reply to | #109293 |
On Friday, May 5, 2017 at 12:41:55 AM UTC-5, gwowen wrote:
> supercat writes:
>
> > On Thursday, May 4, 2017 at 3:58:30 PM UTC-5, Ian Collins wrote:
> >> When? in the 80s?
> >
> > In the world of small embedded controllers, such things are still common.
>
> Name three.
The Keil 8051 compilers I've used were like that; ditto the HiTech PIC
compilers. I don't remember exactly when each was last updated, but well
past the 1980s. It's been awhile since I've used updated versions, but
the vendors generally focused newer versions more on handling newer CPUs
and features thereof than on changing the way code handles existing
processors.
For that matter, Keil's compiler for the ARM generates literal code for
"for" loops, **but managed to generate more efficient code than the versions
of gcc bundled with Atmel Studio when I fed one of my projects into both,
even when I enabled aggressive optimizations on gcc**. I was a bit surprised,
actually, that feeding:
volatile int zzq5;
void testzzq(void)
{
int i;
for (i=0; i<100; i++)
zzq5 = 5;
}
void testzzq2(void)
{
int i=100;
do { zzq5 = 5; } while(--i);
}
with optimization level set to 2 yielded better code for the second than
the first, but setting optimization to level 3 improved the first code
to the literal equivalent of:
void testzzq(void)
{
int i;
for (i=0; i<100; i+=2)
{
zzq5 = 5;
zzq5 = 5;
}
}
which was cool, but degraded the efficiency of the latter to that of the
un-improved first loop. Weird.
I hadn't noticed that bizarre behavior in the -O3 before; it seems to suggest
that perhaps -O2 might be a better choice. In any case, in any case, the
Keil ARM compiler is a third example of a compiler which, which could yield
optimal code using a manually-written countdown loop (note that the best code
among all scenarios tested would be with a manually-unrolled countdown loop).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-06 13:21 +0200 |
| Message-ID | <oekbdg$g98$1@dont-email.me> |
| In reply to | #109353 |
On 05/05/17 19:40, supercat@casperkitty.com wrote:
> On Friday, May 5, 2017 at 12:41:55 AM UTC-5, gwowen wrote:
>> supercat writes:
>>
>>> On Thursday, May 4, 2017 at 3:58:30 PM UTC-5, Ian Collins wrote:
>>>> When? in the 80s?
>>>
>>> In the world of small embedded controllers, such things are still common.
>>
>> Name three.
>
> The Keil 8051 compilers I've used were like that; ditto the HiTech PIC
> compilers. I don't remember exactly when each was last updated, but well
> past the 1980s. It's been awhile since I've used updated versions, but
> the vendors generally focused newer versions more on handling newer CPUs
> and features thereof than on changing the way code handles existing
> processors.
>
Keil's 8051 compiler /is/ from the 80's, and you are correct that they
have done little to improve optimisation, code quality, or standards
conformance for many, many years. These days, Keil is owned by the
company that has most incentive in making the 8051 core look bad - ARM.
And unfortunately, Keil is still considered the "standard" 8051 compiler
- despite its bugs, non-standard behaviour, and poor quality
optimisation compared to alternatives like IAR and SDCC (which /will/
convert an upward counting for-loop into a downward counting while-loop
in some cases). And unfortunately for the embedded world, some
manufacturers still make chips with 8051 cores.
So you get this one - if you have to program for an 8051
microcontroller, you have to write your code in "Keil 8051 C" rather
than normal C.
> For that matter, Keil's compiler for the ARM generates literal code for
> "for" loops, **but managed to generate more efficient code than the versions
> of gcc bundled with Atmel Studio when I fed one of my projects into both,
> even when I enabled aggressive optimizations on gcc**. I was a bit surprised,
> actually, that feeding:
>
> volatile int zzq5;
> void testzzq(void)
> {
> int i;
> for (i=0; i<100; i++)
> zzq5 = 5;
> }
>
> void testzzq2(void)
> {
> int i=100;
> do { zzq5 = 5; } while(--i);
> }
>
I just did a quick test with gcc on godbolt, with "-O2 -Wall -Wextra -x
c -mthumb -mcpu=cortex-m3". The two loops above give identical code in
gcc 4.5, 4.6, and 5.4 (the versions on godbolt). I don't know what
version Atmel are distributing, but it does not sound like one of the
modern popular ARM gcc builds. So you don't get that one.
> with optimization level set to 2 yielded better code for the second than
> the first, but setting optimization to level 3 improved the first code
> to the literal equivalent of:
>
> void testzzq(void)
> {
> int i;
> for (i=0; i<100; i+=2)
> {
> zzq5 = 5;
> zzq5 = 5;
> }
> }
>
> which was cool, but degraded the efficiency of the latter to that of the
> un-improved first loop. Weird.
>
> I hadn't noticed that bizarre behavior in the -O3 before; it seems to suggest
> that perhaps -O2 might be a better choice.
-O3 optimisation is always a bit risky. Sometimes things get slower
rather than faster, and sometimes code grows big enough that cache
sizes, bus bandwidths, etc., mean code that looks faster, actually runs
slower in practice.
> In any case, in any case, the
> Keil ARM compiler is a third example of a compiler which, which could yield
> optimal code using a manually-written countdown loop (note that the best code
> among all scenarios tested would be with a manually-unrolled countdown loop).
>
Keil's ARM compiler is used by some people, but gcc (especially from the
GNU ARM Embedded group) is vastly more popular. And ARM are in the
process of replacing the Keil compiler with clang/llvm.
For my scoring, you have a solid case for Keil 8051 but not for the ARM
compilers.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-06 11:26 -0700 |
| Message-ID | <a06d0ebe-c2dd-4d0d-bae9-8d4fdc05b29a@googlegroups.com> |
| In reply to | #109394 |
On Saturday, May 6, 2017 at 6:21:31 AM UTC-5, David Brown wrote:
> And unfortunately for the embedded world, some
> manufacturers still make chips with 8051 cores.
As of a few years ago, they still *introduce* such chips (e.g. Nordic Semi's
first integrated-radio controller was 8051 based). I must confess I'm a bit
puzzled as to why; with all the grad student projects that have been written
in the last few decades, I would think that there should be some open-source
core that would be just as functional, and to which it should be possible to
retarget a compiler.
Incidentally, when I switched to Keil (rebranded as Archimedes 5) it was a
major improvement over Archimedes 4 for that platform.
> So you get this one - if you have to program for an 8051
> microcontroller, you have to write your code in "Keil 8051 C" rather
> than normal C.
Even if one were using a different brand of compiler, I would think it would
still be necessary to write "8051 C". I'm not sure how any compiler vendor
could make a language that was semantically better than Keil without
sacrificing performance, and from what I've seen the Keil could yield
efficient output if one write the soure code correctly.
> I just did a quick test with gcc on godbolt, with "-O2 -Wall -Wextra -x
> c -mthumb -mcpu=cortex-m3". The two loops above give identical code in
> gcc 4.5, 4.6, and 5.4 (the versions on godbolt). I don't know what
> version Atmel are distributing, but it does not sound like one of the
> modern popular ARM gcc builds. So you don't get that one.
I don't doubt that gcc made such optimizations, but in the code I tested
any savings it achieved through such optimizations were outweighed by other
places where it generated less efficient code than the Keil. I understand
that different application fields benefit from different kinds of
optimizations; for the code I was testing, however, the savings from the
kinds of optimizations gcc likes to perform were insufficient to make up
for the places where Keil did a better job in straightforward code generation.
BTW, I find it curious that no compilers I've seen for the ARM have a storage
class up to 1K or 4K (depending upon the chip) of heavily-used globals which
would be required to fit within direct displacement range of the start of the
area containing them. For a lot of embeddded programs, the vast majority of
accesses are made to variables that could fit in such an area (it's not all
that uncommon for ARM programs to have less than 1K of globals *total*), and
using such an area would reduce the number of address-load instructions.
> -O3 optimisation is always a bit risky. Sometimes things get slower
> rather than faster, and sometimes code grows big enough that cache
> sizes, bus bandwidths, etc., mean code that looks faster, actually runs
> slower in practice.
Keil is a different compiler from gcc. Still, the same point does seem to
apply to both. What's bizarre is that both gcc and Keil will apply some
"optimizations" which will always make the code worse. GCC on x86, for
example, will sometimes replace a "for" loop that copies exactly 7 bytes
with a call to "memmove". I find it hard to imagine that an implementation
of memmove which was capable of handling arbitrary-size copies would be
able to do a seven-byte copy faster than something like:
mov ebx,0xFFFFFFF9
lp:
movzx eax,byte [esi+ebx+8]
add ebx,1
mov [esi+ebx+6]
jnz lp
which should be a fairly easy way to transform the loop.
> Keil's ARM compiler is used by some people, but gcc (especially from the
> GNU ARM Embedded group) is vastly more popular. And ARM are in the
> process of replacing the Keil compiler with clang/llvm.
I wonder if they'll add to clang an option to uphold a reasonable
interpretation of the Standard without having to disable type-based
aliasing altogether, since there are many situatons where it can be usefully
applied without causing any trouble. Perhaps it may be possible to come
up with a strained interpretation of the Standard that stretch the Standard
that would allow clang's behavior, but from what I can tell it can't even be
relied upon to recognize aliasing between union members having common initial
sequences even when all accesses to the members are done on lvalues of one
of the following forms:
[unionLValue]
[unionLValue].[member]
[unionLValue].[lastAccessedMember].[field]
and the last form is only used after a union has been written by storing a
value of union or union-member type to the same union member employed by
the third type.
Oh well, in initial testing clang at least seems--unlike gcc--to uphold
volatile semantics which are suitable for embedded-systems programming.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-06 22:52 +0200 |
| Message-ID | <oelcst$vhl$1@dont-email.me> |
| In reply to | #109400 |
On 06/05/17 20:26, supercat@casperkitty.com wrote: > On Saturday, May 6, 2017 at 6:21:31 AM UTC-5, David Brown wrote: >> And unfortunately for the embedded world, some >> manufacturers still make chips with 8051 cores. > > As of a few years ago, they still *introduce* such chips (e.g. Nordic Semi's > first integrated-radio controller was 8051 based). I must confess I'm a bit > puzzled as to why; with all the grad student projects that have been written > in the last few decades, I would think that there should be some open-source > core that would be just as functional, and to which it should be possible to > retarget a compiler. > Serious SoC manufacturers would not consider an open-source core unless it came with massive levels of support. It costs millions to make a chip - you don't just copy-and-paste a grad student project into one! When a company like Nordic Semi needs a cpu core, they license one from a solid company with a reputation for tried and tested cores, and where they know there are good tools already available - again, from companies that can provide proper support. Other factors are licensing costs, core area, requirements for die setup (not all cores will fit on the die stackup used for radio chips), power, etc. And of course, familiarity amongst the chips designers. There are quite a number of suppliers of 8051 cores for SoCs, so it is not actually very surprising that they are a popular choice amongst manufacturers. It may seem obvious that ARM or perhaps MIPS would be better choices - but often these chips don't need particularly powerful processors, and ARM and MIPS cores will usually impose requirements on the die setup and process sizes that don't suit every SoC design. Of course, developers hate having to use 8051, and companies like Nordic Semi saw designers pick competitors' chips with ARM (or msp430) cores, they too moved to ARM for their cores. > Incidentally, when I switched to Keil (rebranded as Archimedes 5) it was a > major improvement over Archimedes 4 for that platform. > >> So you get this one - if you have to program for an 8051 >> microcontroller, you have to write your code in "Keil 8051 C" rather >> than normal C. > > Even if one were using a different brand of compiler, I would think it would > still be necessary to write "8051 C". I'm not sure how any compiler vendor > could make a language that was semantically better than Keil without > sacrificing performance, and from what I've seen the Keil could yield > efficient output if one write the soure code correctly. Yes, "Keil 8051 C", "SDCC 8051 C", "IAR 8051 C", etc., are all subtly different almost-C languages, and for each compiler you have a different (but with a fair overlap) set of recommendations for how to write your C code in order to generate efficient object code. It simply is not a C friendly core. > >> I just did a quick test with gcc on godbolt, with "-O2 -Wall -Wextra -x >> c -mthumb -mcpu=cortex-m3". The two loops above give identical code in >> gcc 4.5, 4.6, and 5.4 (the versions on godbolt). I don't know what >> version Atmel are distributing, but it does not sound like one of the >> modern popular ARM gcc builds. So you don't get that one. > > I don't doubt that gcc made such optimizations, but in the code I tested > any savings it achieved through such optimizations were outweighed by other > places where it generated less efficient code than the Keil. I understand > that different application fields benefit from different kinds of > optimizations; for the code I was testing, however, the savings from the > kinds of optimizations gcc likes to perform were insufficient to make up > for the places where Keil did a better job in straightforward code generation. > > BTW, I find it curious that no compilers I've seen for the ARM have a storage > class up to 1K or 4K (depending upon the chip) of heavily-used globals which > would be required to fit within direct displacement range of the start of the > area containing them. For a lot of embeddded programs, the vast majority of > accesses are made to variables that could fit in such an area (it's not all > that uncommon for ARM programs to have less than 1K of globals *total*), and > using such an area would reduce the number of address-load instructions. You are thinking of something akin to the "small data section" that is used by common ABIs on PowerPC (and, I think, MIPS)? I have often wondered about that myself. The PPC has 31 registers, compared to the ARM's 13 (excluding essentials like stack pointer, link register, and program counter). The PPC can afford a small data section anchor (actually, it has two - one for read-write data, one for read-only data) without too much cost. gcc has the "-fsection-anchors" option that can give a similar effect for data local to the translation unit, at least in some circumstances. But I too think a fair amount could be gained if the compiler took advantage of the limited range of ram to use anchor+offset modes more often. > >> -O3 optimisation is always a bit risky. Sometimes things get slower >> rather than faster, and sometimes code grows big enough that cache >> sizes, bus bandwidths, etc., mean code that looks faster, actually runs >> slower in practice. > > Keil is a different compiler from gcc. Still, the same point does seem to > apply to both. What's bizarre is that both gcc and Keil will apply some > "optimizations" which will always make the code worse. GCC on x86, for > example, will sometimes replace a "for" loop that copies exactly 7 bytes > with a call to "memmove". I find it hard to imagine that an implementation > of memmove which was capable of handling arbitrary-size copies would be > able to do a seven-byte copy faster than something like: > > mov ebx,0xFFFFFFF9 > lp: > movzx eax,byte [esi+ebx+8] > add ebx,1 > mov [esi+ebx+6] > jnz lp > > which should be a fairly easy way to transform the loop. The gcc folks like to track that sort of thing and fix it when someone notices it (how often do people copy 7 bytes? How often do those people examine the generated assembly code? It's easy to miss cases like that). Check if it still applies to the latest versions, and if not then file a "missed optimisation" bug report. > >> Keil's ARM compiler is used by some people, but gcc (especially from the >> GNU ARM Embedded group) is vastly more popular. And ARM are in the >> process of replacing the Keil compiler with clang/llvm. > > I wonder if they'll add to clang an option to uphold a reasonable > interpretation of the Standard without having to disable type-based > aliasing altogether, since there are many situatons where it can be usefully > applied without causing any trouble. Perhaps it may be possible to come > up with a strained interpretation of the Standard that stretch the Standard > that would allow clang's behavior, but from what I can tell it can't even be > relied upon to recognize aliasing between union members having common initial > sequences even when all accesses to the members are done on lvalues of one > of the following forms: > > [unionLValue] > [unionLValue].[member] > [unionLValue].[lastAccessedMember].[field] > > and the last form is only used after a union has been written by storing a > value of union or union-member type to the same union member employed by > the third type. > > Oh well, in initial testing clang at least seems--unlike gcc--to uphold > volatile semantics which are suitable for embedded-systems programming. > Where does gcc fail here?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-07 19:01 -0700 |
| Message-ID | <cc338b5e-4fc5-47e0-ba87-86800bc12e80@googlegroups.com> |
| In reply to | #109409 |
On Saturday, May 6, 2017 at 3:52:58 PM UTC-5, David Brown wrote:
> On 06/05/17 20:26, supercat wrote:
> > Oh well, in initial testing clang at least seems--unlike gcc--to uphold
> > volatile semantics which are suitable for embedded-systems programming.
> >
>
> Where does gcc fail here?
While multi-core or out-of-order execution CPUs with weak memory models will
of course require use of features beyond "volatile", on many systems volatile
will be sufficient if volatile accesses are processed in order relative to
all accesses to objects whose address has been exposed to the outside world--
essentially treating a volatile access as a call to an external subroutine
whose innards the compiler knows nothing about.
Under such semantics, given:
extern int a[4];
extern volatile int b;
for (int i=0; i<4; i++)
a[i] = 0;
a[1]+=3;
a[1]+=2;
b=1;
a[2]+=3;
b=2;
a compiler would be allowed to consolidate the operations before "b=1" so
they simply write {0,5,0,0} into a[0..3], but a[2] would need to be written
with 0 before the b=1, and then written with 2 between the b=1 and b=2.
The Standard leaves regards such matters as Implementation-Defined, and
would allow a compiler to perform a[2]=3 before the write of b=1, but
requiring that a programmer declare a[] as volatile in order to achieve
such semantics would yield-sub optimal code. In systems with interrupts
or DMA, the ability to have such features act upon data in "ordinary"
storage is useful. Under gcc's execution model, however, it's necessary
to first copy any data to dedicated volatile-qualified storage.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-08 11:09 +0200 |
| Message-ID | <oepce6$p79$1@dont-email.me> |
| In reply to | #109451 |
On 08/05/17 04:01, supercat@casperkitty.com wrote:
> On Saturday, May 6, 2017 at 3:52:58 PM UTC-5, David Brown wrote:
>> On 06/05/17 20:26, supercat wrote:
>>> Oh well, in initial testing clang at least seems--unlike gcc--to uphold
>>> volatile semantics which are suitable for embedded-systems programming.
>>>
>>
>> Where does gcc fail here?
>
> While multi-core or out-of-order execution CPUs with weak memory models will
> of course require use of features beyond "volatile",
That is a limitation of C's "volatile", not gcc's implementation of
volatile. It is part of the reason for C11's atomic accesses and thread
libraries. "Volatile" simply is not strong enough for such systems -
you need memory barriers, locks, flushes, etc.
> on many systems volatile
> will be sufficient if volatile accesses are processed in order relative to
> all accesses to objects whose address has been exposed to the outside world--
> essentially treating a volatile access as a call to an external subroutine
> whose innards the compiler knows nothing about.
Volatile accesses are only ordered with respect to other volatile
accesses (and even then only from within the view of the current
executing thread). Volatile accesses are not ordered with respect to
other data accesses, which have /no/ outwardly visible order in
themselves (calls to external code form sequence points for such accesses).
This is a very common misunderstanding about "volatile". And yes, /if/
it were true, then some things would be simpler - there would be no need
of memory barriers, fences, etc., at least on single cpu systems. You
would still need more for multiple cpu systems - specific processor
instructions are usually needed to ensure the data moves off core.
>
> Under such semantics, given:
>
> extern int a[4];
> extern volatile int b;
>
> for (int i=0; i<4; i++)
> a[i] = 0;
> a[1]+=3;
> a[1]+=2;
> b=1;
> a[2]+=3;
> b=2;
>
> a compiler would be allowed to consolidate the operations before "b=1" so
> they simply write {0,5,0,0} into a[0..3], but a[2] would need to be written
> with 0 before the b=1, and then written with 2 between the b=1 and b=2.
>
That would be true, with such semantics for "volatile". But C does not
define volatile semantics like that. A particular compiler
implementation is, of course, free to make volatile accesses act as
memory barriers - but it is certainly not required.
> The Standard leaves regards such matters as Implementation-Defined, and
> would allow a compiler to perform a[2]=3 before the write of b=1, but
> requiring that a programmer declare a[] as volatile in order to achieve
> such semantics would yield-sub optimal code.
The standard leaves details of what volatile accesses actually /do/ up
to the compiler - it only insists that they are observable behaviour and
should match the abstract machine in value and order.
If the programmer wants to be sure that the externally visible order
here is "a[2] = 0; b = 1; a[2] = 3; b = 2;", then making "a" volatile is
one way to do it. There are other methods - inserting function calls in
the code, using C11 "atomic_thread_fence(memory_order_seq_cst);" before
"b = 1;", or using a range of implementation-defined methods.
For implementation-defined methods, most tools provide a memory barrier
of some sort - either as part of the compiler implementation, or as part
of an operating system API (the best choice if you are using an OS).
For gcc, the simplest one is
asm volatile ("" ::: "memory");
(Note that this is /not/ sufficient for multi-cpu systems - it is only
for the current cpu.)
Also, most implementations will accept casting a pointer to a
non-volatile into a pointer to a volatile, and accessing through that
pointer, to work as a volatile access. Thus Linux defines:
#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
And you can write:
ACCESS_ONCE(a[2]) = 0;
b = 1;
ACCESS_ONCE(a[2]) = 3;
b = 2;
I don't know of any compiler where such volatile-casted accesses would
not be treated as normal volatile accesses in the expected way - but I
am not convinced the standards /require/ it to work. (The "typeof"
operator is a gcc'ism, but the principle is clear.)
And again note that none of this is safe for multiple cpus.
> In systems with interrupts
> or DMA, the ability to have such features act upon data in "ordinary"
> storage is useful. Under gcc's execution model, however, it's necessary
> to first copy any data to dedicated volatile-qualified storage.
>
That is not "gcc's execution model" - it is /C's/ execution model.
gcc's model is perfectly correct in following the standards, and is
absolutely fine for embedded and systems programming. You do have to
understand what you are doing, of course, and I have certainly seen code
where the author appears to have the same mistaken believes that you are
suggesting here.
Note also that code that uses "volatile" at all is almost certainly very
specific to the target and/or the compiler, and thus it is perfectly
reasonable to use implementation-specific (either compiler-specific, or
OS specific) methods to enforce the ordering you want with the
efficiency you want.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-07 19:48 -0700 |
| Message-ID | <12ffc80c-0471-43f5-9376-5732bae2ed37@googlegroups.com> |
| In reply to | #109409 |
On Saturday, May 6, 2017 at 3:52:58 PM UTC-5, David Brown wrote:
> Where does gcc fail here?
More real-world example:
extern void * volatile rx_buff;
extern volatile unsigned short rx_count;
void read_data(void *dat, unsigned short n)
{
rx_buff = dat;
rx_count = n;
while(rx_count);
}
int some_value;
int test(void)
{
if (some_value)
read_data(&some_value, sizeof some_value);
return some_value;
}
Unfortunately, testing this example with clang shows that it shares gcc's
less-than-helpful volatile semantics.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-08 11:17 +0200 |
| Message-ID | <oepct1$qkr$1@dont-email.me> |
| In reply to | #109454 |
On 08/05/17 04:48, supercat@casperkitty.com wrote:
> On Saturday, May 6, 2017 at 3:52:58 PM UTC-5, David Brown wrote:
>> Where does gcc fail here?
>
> More real-world example:
>
> extern void * volatile rx_buff;
> extern volatile unsigned short rx_count;
>
> void read_data(void *dat, unsigned short n)
> {
> rx_buff = dat;
> rx_count = n;
> while(rx_count);
> }
>
> int some_value;
> int test(void)
> {
> if (some_value)
> read_data(&some_value, sizeof some_value);
> return some_value;
> }
I can't figure out where you might see this code going wrong - I don't
see any reorderings of non-volatile accesses around volatile accesses
that would illustrate your problem.
>
> Unfortunately, testing this example with clang shows that it shares gcc's
> less-than-helpful volatile semantics.
>
You mean, of course, gcc's /correct/ volatile semantics - but your
less-than-helpful misunderstanding about C's idea of "volatile" ?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 06:36 -0700 |
| Message-ID | <bb59791b-4d14-4bec-9620-bf0baa46a1ee@googlegroups.com> |
| In reply to | #109477 |
On Monday, May 8, 2017 at 4:17:33 AM UTC-5, David Brown wrote: > On 08/05/17 04:48, supercat wrote: > I can't figure out where you might see this code going wrong - I don't > see any reorderings of non-volatile accesses around volatile accesses > that would illustrate your problem. Both clang and gcc cache the first value read from some_value and return that, rather than reloading it. > You mean, of course, gcc's /correct/ volatile semantics - but your > less-than-helpful misunderstanding about C's idea of "volatile" ? Since the semantics of volatile access are Implementation-Defined, gcc's semantics are allowable by the Standard, but that does not imply that they are suitable for systems programming without the use of compiler-specific directives. Any implementation which can invoke outside code must be able to achieve the semantics associated with a call to outside code the compiler knows nothing about, and it should be simple for such implementations to achieve such semantics without the cost of an actual function call. The only reason I can see for the Standard not to define an intrinsic for such a purpose would be that every implementation either provided such an ability naturally with its 'volatile' semantics, or else targeted platforms and purposes where sch semantics wouldn't be useful. Otherwise it should have been simple to include such a thing in the semantics and simple for compilers to implement it (if nothing else, define an intrinsic as a call to __SECRETLY_DO_NOTHING(), but tweak the code generator so as to omit the actual call).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-08 16:21 +0200 |
| Message-ID | <oepum7$nsq$1@dont-email.me> |
| In reply to | #109495 |
On 08/05/17 15:36, supercat@casperkitty.com wrote: > On Monday, May 8, 2017 at 4:17:33 AM UTC-5, David Brown wrote: >> On 08/05/17 04:48, supercat wrote: >> I can't figure out where you might see this code going wrong - I don't >> see any reorderings of non-volatile accesses around volatile accesses >> that would illustrate your problem. > > Both clang and gcc cache the first value read from some_value and return > that, rather than reloading it. "some_value" is not volatile, and the compiler can see it is never changed. Why should it reload it? Is the compiler to guess what you meant to write? I suppose /I/ should have been able to guess what you meant, but I often find it hard with your examples. > >> You mean, of course, gcc's /correct/ volatile semantics - but your >> less-than-helpful misunderstanding about C's idea of "volatile" ? > > Since the semantics of volatile access are Implementation-Defined, gcc's > semantics are allowable by the Standard, but that does not imply that they > are suitable for systems programming without the use of compiler-specific > directives. They are perfectly fine for systems programming and embedded programming. Let's be clear on this - /vast/ numbers of programmers, and /vast/ numbers of systems, use gcc daily for embedded programming and for systems programming. There is /no/ problem writing good, clear, efficient and correct code that uses gcc and deals with interaction with hardware registers, DMA, interrupts, multiple processors, etc. I can accept that /you/ seem to find this more difficult than it would have been if gcc had considered every volatile access to be a memory barrier (though you would be mistaken if you thought it would work in multi-cpu systems). I can accept that some programmers get this wrong, and misunderstand how this works. I can accept that some programmers would be happier if /every/ memory access worked as though it were "volatile" - that every read or write were directly translated, in order. But the fact that /you/ have trouble here, and that some other programmers have even more trouble, does /not/ mean that gcc has "unhelpful" volatile semantics, or that changing them would be an improvement. It merely means that embedded programming can be hard, as is low-level systems programming, especially on multi-cpu systems. That is nothing new. > > Any implementation which can invoke outside code must be able to achieve > the semantics associated with a call to outside code the compiler knows > nothing about, and it should be simple for such implementations to achieve > such semantics without the cost of an actual function call. The only > reason I can see for the Standard not to define an intrinsic for such a > purpose would be that every implementation either provided such an ability > naturally with its 'volatile' semantics, or else targeted platforms and > purposes where sch semantics wouldn't be useful. Otherwise it should have > been simple to include such a thing in the semantics and simple for > compilers to implement it (if nothing else, define an intrinsic as a call > to __SECRETLY_DO_NOTHING(), but tweak the code generator so as to omit the > actual call). > Alternatively, the Standards authors thought that only people who understood C, and their target platforms and particular implementations, should be writing code for such purposes. And they probably thought that this sort of thing is likely to be highly implementation dependent, which is a /good/ thing in this case - it lets implementations deal with it in whatever way is best for them without imposing rules and limitations that might be very unsuitable for other implementations. Please understand that just because /you/ can't think of a reason why something is /not/ the case, does not mean that it /is/ the case.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 09:16 -0700 |
| Message-ID | <b5c7a57a-b04f-499f-bf83-7fbf2f3b4254@googlegroups.com> |
| In reply to | #109497 |
On Monday, May 8, 2017 at 9:21:09 AM UTC-5, David Brown wrote:
> "some_value" is not volatile, and the compiler can see it is never
> changed. Why should it reload it? Is the compiler to guess what you
> meant to write? I suppose /I/ should have been able to guess what you
> meant, but I often find it hard with your examples.
On many systems, data is read or written by giving some outside process the
address if the data and performing a write to a volatile location to trigger
that process. It is not unusual for the act of writing to a volatile location
to affect other aspects of system state.
In the days before "volatile", such code would simply work but compilers
had to do all memory accesses in order. Making code compatible with
compilers that reordered non-qualified accesses relative to each other but
maintained order with respect to "volatile" accesses was simple and
practical since the same locations were used to trigger every I/O operation
regardless of what objects might be affected by them. All one had to do
to achieve compatibility with such compilers was add "volatile" qualifiers
to the objects that would *trigger* the actions.
If one wants to trigger an I/O operation that can cause some data to be
stored to an arbitrary address, which should be more efficient:
1. Read the data directly to the place it's needed, and have an access
to a volatile object separate any such process from any other access
to the object in question.
2. Use a dedicated volatile-qualified buffer, perform the I/O on that
buffer, and then manually copy the data to the destination (note that
memcpy isn't usable with volatile-qualified storage).
3. Require that any object upon which I/O will be performed be volatile-
qualified, which would in turn require that all code that makes use
of such objects use volatile-qualified pointers for the purpose.
4. Use compiler-specific directives which may not exist on the compiler
one is using because it provides the necessary semantics without
them, to tell the compiler to block optimizations across the volatile
access.
I'd regard both #2 and #3 as rather horrible, and #4 would have been
impossible when a lot of existing code was written. A compiler that can't
offer the appropriate semantics from "volatile" will be incompatible with
code written for compilers that neither had nor needed directives to block
"optimizations" across volatile accesses, and would thus be unsuitable for
use with a a substantial corpus of existing code.
> Let's be clear on this - /vast/ numbers of programmers, and /vast/
> numbers of systems, use gcc daily for embedded programming and for
> systems programming. There is /no/ problem writing good, clear,
> efficient and correct code that uses gcc and deals with interaction with
> hardware registers, DMA, interrupts, multiple processors, etc.
Compiler writers used to regard as desirable an ability to use code
written for other compilers. In many applications the usefulness of
caching exposed objects in registers across volatile accesses will be
rather limited, and in cases where such optimizations would be needed
to achieve performance, a programmer could let the compiler know that
an object won't be modified via outside means via:
int *restrict pFoo = &foo;
x=*pFoo; // Use it here
volatileThing = 23;
y=*pFoo; // Can use cached value because of "restrict" qualifier
Consequently, the trade-off between treating "volatile" as ordering
volatile accesses relative to everything, rather than merely to other
volatile-qualified accesses, is a trade-off between compatibility with
code written for compilers that neither had nor needed special directives
to force ordering upon non-qualified accesses, versus some slight
opportunities for optimization that could have been achieved in other ways
if they were really needed.
> I can accept that /you/ seem to find this more difficult than it would
> have been if gcc had considered every volatile access to be a memory
> barrier (though you would be mistaken if you thought it would work in
> multi-cpu systems).
I am fully aware that there are some hardware platforms where loads and
stores may be cached or reordered at the hardware level. On many systems,
however, a programmer will know of all such hardware issues that exist (if
any). The question is whether compilers should require the use of compiler-
specific directives to prevent them from creating problems of their own.
> I can accept that some programmers get this wrong, and misunderstand how
> this works. I can accept that some programmers would be happier if
> /every/ memory access worked as though it were "volatile" - that every
> read or write were directly translated, in order.
N1570 notes that some implementations document such behavior (5.1.2.3
pa. 9 Example 1). I am suggesting that such behavior would be compatible
with the widest range of code, but that one could achieve almost as good
compatibility by treating volatile accesses as globally ordered relative
to all accesses, but treating non-qualified accesses as unordered relative
to each other (but ordered relative to volatile accesses).
> But the fact that /you/ have trouble here, and that some other
> programmers have even more trouble, does /not/ mean that gcc has
> "unhelpful" volatile semantics, or that changing them would be an
> improvement. It merely means that embedded programming can be hard, as
> is low-level systems programming, especially on multi-cpu systems. That
> is nothing new.
On systems where hardware performs memory re-ordering, a low-level
compiler should not be expected to relieve a programmer of responsibility
for dealing with such hardware-related issues. That does not mean that
a programmer should need to use compiler-specific directives when dealing
with a simple CPU which performs all memory and I/O operations in execution
order.
> > Any implementation which can invoke outside code must be able to achieve
> > the semantics associated with a call to outside code the compiler knows
> > nothing about, and it should be simple for such implementations to achieve
> > such semantics without the cost of an actual function call. The only
> > reason I can see for the Standard not to define an intrinsic for such a
> > purpose would be that every implementation either provided such an ability
> > naturally with its 'volatile' semantics, or else targeted platforms and
> > purposes where sch semantics wouldn't be useful. Otherwise it should have
> > been simple to include such a thing in the semantics and simple for
> > compilers to implement it (if nothing else, define an intrinsic as a call
> > to __SECRETLY_DO_NOTHING(), but tweak the code generator so as to omit the
> > actual call).
>
> Alternatively, the Standards authors thought that only people who
> understood C, and their target platforms and particular implementations,
> should be writing code for such purposes. And they probably thought
> that this sort of thing is likely to be highly implementation dependent,
> which is a /good/ thing in this case - it lets implementations deal with
> it in whatever way is best for them without imposing rules and
> limitations that might be very unsuitable for other implementations.
On many platforms, code targeting a generic compiler that uses the semantics
described in N1570 5.1.2.3 pa.9 Example One, could perform a wide range of
low-level I/O without need for compiler-specific directives. One of the
biggest advantages of C over assembly was that C code written for a generic
low-level compiler on a particular platform would be compatible with any
compiler that tried to be compatible with such code.
> Please understand that just because /you/ can't think of a reason why
> something is /not/ the case, does not mean that it /is/ the case.
Do you consider it plausible that the authors of the Standard intended that
implementations interpret the Standard so as to require the use of more
compiler-specific directives than would have been necessary previously?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-08 21:20 +0200 |
| Message-ID | <oeqg73$rf8$1@dont-email.me> |
| In reply to | #109509 |
On 08/05/17 18:16, supercat@casperkitty.com wrote: > On Monday, May 8, 2017 at 9:21:09 AM UTC-5, David Brown wrote: >> "some_value" is not volatile, and the compiler can see it is never >> changed. Why should it reload it? Is the compiler to guess what you >> meant to write? I suppose /I/ should have been able to guess what you >> meant, but I often find it hard with your examples. > > On many systems, data is read or written by giving some outside process the > address if the data and performing a write to a volatile location to trigger > that process. It is not unusual for the act of writing to a volatile location > to affect other aspects of system state. Yes, it is unusual. The code is wrong - it is incorrect C. Maybe you are used to writing such code, but /I/ certainly am not. When you have something like a communications buffer that you want to fill, then write to another volatile "trigger" to send the data out (or to read in new data), the most common technique is simply to declare that buffer as volatile. This may be marginally pessimistic, but only marginally so - usually your code reads or writes the data once, and it makes little difference if those accesses are volatile or not. More sophisticated programmers might leave the buffers non-volatile and use memory barriers to enforce ordering - in complex situations on more modern devices, such as cpus with cache and an external DMA, you may need extra flushes or other cpu instructions to enforce the order correctly. What you don't do is use plain accesses and /hope/ that the compiler will do what you want. > > In the days before "volatile", such code would simply work but compilers > had to do all memory accesses in order. I don't know when "volatile" came into use, but it is in the C89 standard. Previous to that, you would be relying on implementation-dependent behaviour for /all/ accesses and ordering. But that's okay, as C was designed to allow that. And anyway, what does this have to do with gcc /today/ ? Sometimes I imagine you sitting on the porch on your rocking chair, telling tall tales to your grandchildren about the days of your youth, when compilers were /real/ compilers and programmers were /real/ programmers. >> Let's be clear on this - /vast/ numbers of programmers, and /vast/ >> numbers of systems, use gcc daily for embedded programming and for >> systems programming. There is /no/ problem writing good, clear, >> efficient and correct code that uses gcc and deals with interaction with >> hardware registers, DMA, interrupts, multiple processors, etc. > <snip fantasy problems> > >> I can accept that /you/ seem to find this more difficult than it would >> have been if gcc had considered every volatile access to be a memory >> barrier (though you would be mistaken if you thought it would work in >> multi-cpu systems). > > I am fully aware that there are some hardware platforms where loads and > stores may be cached or reordered at the hardware level. On many systems, > however, a programmer will know of all such hardware issues that exist (if > any). The question is whether compilers should require the use of compiler- > specific directives to prevent them from creating problems of their own. And if the programmer knows all this stuff, then he should /certainly/ be aware of implementation-dependent behaviour of the compiler - and use it to get the effects needed! Compilers do /not/ create problems here. Imagining what you think compilers used to do, or what you think compilers do do, or what you think the standards authors should have written, or what you think they thought they were writing when they wrote something else, or what you think they meant to write - /that/ is what is causing your problems. I know how C works here. I know what the standards say. I know how my tools work, and what extensions I need to use to get specific behaviour for particular targets. I know how my various targets work. Consequently, I don't have a problem here, and can write efficient and correct code. I would recommend you also spend more time learning such things, and less time complaining about them, imagining problems, inventing ideas about how compilers working "in the good old days" and how that differs from what those evil buggers at gcc write specifically to give /you/ a hard time. <snip> > >> Please understand that just because /you/ can't think of a reason why >> something is /not/ the case, does not mean that it /is/ the case. > > Do you consider it plausible that the authors of the Standard intended that > implementations interpret the Standard so as to require the use of more > compiler-specific directives than would have been necessary previously? > Yes.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 13:07 -0700 |
| Message-ID | <23b594ae-2310-4bde-bf19-b56ddad92115@googlegroups.com> |
| In reply to | #109532 |
On Monday, May 8, 2017 at 2:20:23 PM UTC-5, David Brown wrote: > Yes, it is unusual. The code is wrong - it is incorrect C. Maybe you > are used to writing such code, but /I/ certainly am not. So how would you write code that needs to efficiently read and write data of arbitrary type on a 32-bit CPU? Would you use memcpy to copy the data to a non-qualified uint32_t[] [hopefully using 32-bit operations] so that you could then copy it from there to a uint32_t volatile[], or would you use a loop to memcpy groups of four bytes to a uint32_t that could be written to a uint32_t volatile[], or what? > When you have something like a communications buffer that you want to > fill, then write to another volatile "trigger" to send the data out (or > to read in new data), the most common technique is simply to declare > that buffer as volatile. This may be marginally pessimistic, but only > marginally so - usually your code reads or writes the data once, and it > makes little difference if those accesses are volatile or not. More > sophisticated programmers might leave the buffers non-volatile and use > memory barriers to enforce ordering - in complex situations on more > modern devices, such as cpus with cache and an external DMA, you may > need extra flushes or other cpu instructions to enforce the order correctly. What's pessimistic is *needing* to use a specially-allocated communications buffer in cases where the storage which holds the data won't be needed by the main-line until after the outside process has finished using it. Many communications APIs feature asynchronous "beginRead" and "beginWrite" operations which can be used with "ordinary" storage, provided that code doesn't try to do anything with the storage in question until after the asynchronous operations have completed. > What you don't do is use plain accesses and /hope/ that the compiler > will do what you want. Some compilers, including any that use the 5.1.2.3p.9 semantics, will work as indicated even though they lack any kind of memory-barrier directives since they don't need them. > > In the days before "volatile", such code would simply work but compilers > > had to do all memory accesses in order. > > I don't know when "volatile" came into use, but it is in the C89 > standard. Previous to that, you would be relying on > implementation-dependent behaviour for /all/ accesses and ordering. But > that's okay, as C was designed to allow that. Before the late 1980s, many compilers simply performed all reads and writes in the order given. The "volatile" keyword was added to make it possible for compilers to perform optimizations without making the language unsuitable for systems-programming use. If it *wasn't* intended to eliminate the need for compiler-specific directives on the kinds of platforms that existed in the late 1980s (which, incidentally, are very much like low-end platforms today) why bother with it at all? > And anyway, what does this have to do with gcc /today/ ? Sometimes I > imagine you sitting on the porch on your rocking chair, telling tall > tales to your grandchildren about the days of your youth, when compilers > were /real/ compilers and programmers were /real/ programmers. I would suggest that a compiler which can't perform some task as cleanly and straightforwardly as a 5.1.2.3p9 compiler shouldn't be regarded as particularly suitable for that task. > And if the programmer knows all this stuff, then he should /certainly/ > be aware of implementation-dependent behaviour of the compiler - and use > it to get the effects needed! Is there any reason that code which needs to do something that any compiler which is remotely suitable for systems programming must be capable of doing (flushing all register-cached variables and creating a barrier to load/store re-ordering) in order to handle external function calls, should need to use compiler-specific directives for that purpose? If there existed a directive which said "do everything that would be necessary before calling an opaque external function, but feel free to omit the call itself", then it would make sense to deprecate any code which fails to use such a directive in cases where its semantics would be required. No such directive exists, however. > > Do you consider it plausible that the authors of the Standard intended that > > implementations interpret the Standard so as to require the use of more > > compiler-specific directives than would have been necessary previously? > > Yes. Interesting. I would have thought such an outcome would have been contrary to the whole purpose of trying to write a standard in the first place.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-08 22:46 +0200 |
| Message-ID | <oeql9k$ee3$1@dont-email.me> |
| In reply to | #109536 |
On 08/05/17 22:07, supercat@casperkitty.com wrote: > On Monday, May 8, 2017 at 2:20:23 PM UTC-5, David Brown wrote: >> Yes, it is unusual. The code is wrong - it is incorrect C. Maybe you >> are used to writing such code, but /I/ certainly am not. > > So how would you write code that needs to efficiently read and write data > of arbitrary type on a 32-bit CPU? I don't read and write data of arbitrary types - I /know/ what types I use. > Would you use memcpy to copy the data > to a non-qualified uint32_t[] [hopefully using 32-bit operations] so that > you could then copy it from there to a uint32_t volatile[], or would you > use a loop to memcpy groups of four bytes to a uint32_t that could be written > to a uint32_t volatile[], or what? There is no answer to a question like that (except perhaps "what"), since it will depend on the circumstances. Maybe I will use transfers that I know are valid on the compiler in question even if they are not guaranteed by the standards. Maybe I will use memcpy. Maybe I will use unions. Maybe memcpy, but with extensions (like gcc attributes) to ensure the compiler knows the alignments of the pointers involved, and can generate more efficient transfers. In most cases, I won't /care/ - because the reason I am passing such data around is because it will be transferred by a UART running at 19200 baud, and it does not matter if the buffer is available a microsecond earlier or later. What matters is that the code is clear and correct. > >> When you have something like a communications buffer that you want to >> fill, then write to another volatile "trigger" to send the data out (or >> to read in new data), the most common technique is simply to declare >> that buffer as volatile. This may be marginally pessimistic, but only >> marginally so - usually your code reads or writes the data once, and it >> makes little difference if those accesses are volatile or not. More >> sophisticated programmers might leave the buffers non-volatile and use >> memory barriers to enforce ordering - in complex situations on more >> modern devices, such as cpus with cache and an external DMA, you may >> need extra flushes or other cpu instructions to enforce the order correctly. > > What's pessimistic is *needing* to use a specially-allocated communications > buffer in cases where the storage which holds the data won't be needed by > the main-line until after the outside process has finished using it. Many > communications APIs feature asynchronous "beginRead" and "beginWrite" > operations which can be used with "ordinary" storage, provided that code > doesn't try to do anything with the storage in question until after the > asynchronous operations have completed. > >> What you don't do is use plain accesses and /hope/ that the compiler >> will do what you want. > > Some compilers, including any that use the 5.1.2.3p.9 semantics, will work What part of the word "example" is causing you problems here? And on the one hand you are obsessing about irrelevant run-time efficiency, while simultaneously extolling the benefits of compilers that will be extremely slow and inefficient. > as indicated even though they lack any kind of memory-barrier directives > since they don't need them. Your original point was about "multi-core or out-of-order execution CPUs with weak memory models" - you /do/ need memory barrier directives (which until C11 were outside the scope of C) regardless of the compiler. > >>> In the days before "volatile", such code would simply work but compilers >>> had to do all memory accesses in order. >> >> I don't know when "volatile" came into use, but it is in the C89 >> standard. Previous to that, you would be relying on >> implementation-dependent behaviour for /all/ accesses and ordering. But >> that's okay, as C was designed to allow that. > > Before the late 1980s, many compilers simply performed all reads and writes > in the order given. In the dark ages, compilers did not have many optimisations. We know that. > The "volatile" keyword was added to make it possible > for compilers to perform optimizations without making the language unsuitable > for systems-programming use. If it *wasn't* intended to eliminate the need > for compiler-specific directives on the kinds of platforms that existed in > the late 1980s (which, incidentally, are very much like low-end platforms > today) why bother with it at all? Again, you equate "I can't think why this is not the case" with "clearly it /is/ the case". I wish you would stop doing that - you cannot use your ignorance or lack of imagination as "proof" that your ideas are correct. I was not involved in the decision making process of the C standards committee in the late 1980's. I don't know what they were thinking. All I can see is what the standards say. And from what they say, "volatile" is a useful tool for controlling the order of specific accesses in a C program - but it does not control non-volatile accesses. If you want to control the ordering of accesses, you either make them all explicitly volatile, or you use implementation-specific methods. So I would guess "volatile" was added as a helpful common tool, not a replacement for implementation details. > >> And anyway, what does this have to do with gcc /today/ ? Sometimes I >> imagine you sitting on the porch on your rocking chair, telling tall >> tales to your grandchildren about the days of your youth, when compilers >> were /real/ compilers and programmers were /real/ programmers. > > I would suggest that a compiler which can't perform some task as cleanly > and straightforwardly as a 5.1.2.3p9 compiler shouldn't be regarded as > particularly suitable for that task. Perhaps it is not suitable as a compiler for /you/. Let other people use tools that work for /them/. In the meantime, I recommend you keep your gcc settings on "-fno-strict-alias -fwrapv" and avoid optimisation (certainly nothing above -O1), just in case the scary compiler does something different from a tool from 40 years ago. > >> And if the programmer knows all this stuff, then he should /certainly/ >> be aware of implementation-dependent behaviour of the compiler - and use >> it to get the effects needed! > > Is there any reason that code which needs to do something that any compiler > which is remotely suitable for systems programming must be capable of doing > (flushing all register-cached variables and creating a barrier to load/store > re-ordering) in order to handle external function calls, should need to use > compiler-specific directives for that purpose? Yes. (The reasons are too obvious to bother explaining.) > > If there existed a directive which said "do everything that would be > necessary before calling an opaque external function, but feel free to > omit the call itself", then it would make sense to deprecate any code > which fails to use such a directive in cases where its semantics would be > required. No such directive exists, however. That makes no sense. > >>> Do you consider it plausible that the authors of the Standard intended that >>> implementations interpret the Standard so as to require the use of more >>> compiler-specific directives than would have been necessary previously? >> >> Yes. > > Interesting. I would have thought such an outcome would have been contrary > to the whole purpose of trying to write a standard in the first place. > You asked if I considered it plausible. I said yes. You are very fond of sophistry, but it is not really a helpful technique in such a discussion.
[toc] | [prev] | [next] | [standalone]
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web