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 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-10 17:36 -0500 |
| Message-ID | <0a57hctiqbibggl78sc7pmapb0t350snrf@4ax.com> |
| In reply to | #109685 |
On Wed, 10 May 2017 09:26:46 -0700 (PDT), supercat@casperkitty.com wrote: >On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >> There are no M0+ implementations with unprivileged modes. There are >> some M3/M4 devices that have them, but I think you would look long and >> hard to find a single example of a program for them that does not run in >> privileged mode all the time. > >The ARM information page describes the effects of Unprivileged mode on >implementations that care to implement it. It does not specify whether >any actually do so. > >Even if one reaches out to the Cortex-M3 which adds LL/CS ability, I'm >not sure how that can effectively be leveraged to implement an atomic 64- >bit type in contexts that don't support a spinlock. Do you know of any >lock-free algorithms to implement 64-bit atomic operations using 32-bit >LL/CS without relying upon any shared global state, heap storage, or other >things that might be unavailable to a freestanding implementation? Why is that a requirement? If an OS exists that prevents you from implementing spinlocks, then it should provide the atomics directly, or at least provide a proper mutex. >> And if you /have/ such a distinction, then you necessarily have an OS of >> some sort that runs in privileged mode and will provide such services as >> locks or atomic accesses. Thus your implementation is: >> >> perform system call for the appropriate operation >> >> The implementation in the OS is: >> >> preserve current interrupt status >> disable interrupts >> perform operation >> restore previous interrupt status >> >> Problem solved. > >The programmer may know about the underlying OS, but that doesn't mean that >the compiler would. Would the Standard allow for an implementation to >report that it supports atomics if, when code tries to perform an operation >on a 64-bit atomic type, it calls a function with an implementation-defined >name that user code would then be required to supply, which would in turn >have to perform the operation without help from the compiler? A lot of free- >standing implementations handle things like stdio.h in such a fashion, but >that's allowable because the Standard doesn't require them to supply such >functionality in the first place. Is an implementation allowed to say that >it supports atomics.h functionality but then punt all the implementation >back to the programmer?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-11 01:12 +0200 |
| Message-ID | <of06hu$c05$1@dont-email.me> |
| In reply to | #109685 |
On 10/05/17 18:26, supercat@casperkitty.com wrote:
> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote:
>> There are no M0+ implementations with unprivileged modes. There are
>> some M3/M4 devices that have them, but I think you would look long and
>> hard to find a single example of a program for them that does not run in
>> privileged mode all the time.
>
> The ARM information page describes the effects of Unprivileged mode on
> implementations that care to implement it. It does not specify whether
> any actually do so.
As far as I know, real-world implementations of M0+ don't use
unpriviledged (thread) modes.
>
> Even if one reaches out to the Cortex-M3 which adds LL/CS ability, I'm
> not sure how that can effectively be leveraged to implement an atomic 64-
> bit type in contexts that don't support a spinlock. Do you know of any
> lock-free algorithms to implement 64-bit atomic operations using 32-bit
> LL/CS without relying upon any shared global state, heap storage, or other
> things that might be unavailable to a freestanding implementation?
For bare metal single cpu systems, you can use this:
uint64_t readAtomic64(volatile uint64_t *p) {
uint64_t a = *p;
while (true) {
uint64_t b = *p;
if (a == b) return a;
a = b;
}
}
void writeAtomic64(volatile uint64_t *p, uint64_t x) {
do {
*p = x;
} while (*p != x);
}
That works because a function will either run to completion, or be
interrupted. If it is interrupted, that interrupt will either run to
completion, or be interrupted. And so on. You don't have
multi-threading, and cannot have arbitrary interleaving between threads
of execution. So while the two instructions that read the halves of the
uin64_t can be interrupted by an operation that writes a new value to
the variable, the write will be completed before continuing. It is
therefore enough in most real-world cases to check for two adjacent
identical reads. (There is a possibility of a number of interrupts
during the reads of "a" and "b" causing an incorrect value to be
returned - but that would require an extremely contrived and unrealistic
system.)
Often, simply disabling interrupts and re-enabling them around atomic
reads and writes is easier and more efficient. That is especially true
if you are doing something more complicated than a read or a write.
Using LDREX and STREX, we can be more correct, even for multi-tasking
and for multiple cores. The code here is untested, however.
Just for reference, LDREX and STREX are in effect functions like these,
where the functions are executed atomically:
volatile uint32_t* reservation;
uint32_t __LDREXW(uint32_t *addr) {
uint32_t x = *addr;
reservation = addr;
}
uint32_t __STREXW(uint32_t value, uint32_t *addr) {
if (reservation == addr) {
*addr = value;
reservation = 0;
return 0;
} else {
reservation = 0;
return 1;
}
}
So we can do:
typedef union { uint64_t x; uint32_t ws[2]; } mixer_t;
uint64_t readAtomic64(volatile uint64_t *p) {
volatile mixer_t * q = (volatile mixer_t *) p;
mixer_t m;
do {
m.ws[0] = __LDREXW(&q->ws[0]);
m.ws[1] = q->ws[1];
} while (__STREXW(m.ws[0], &q->ws[0]));
return m.x;
}
void writeAtomic64(volatile uint64_t *p, uint64_t x) {
volatile mixer_t * q = (volatile mixer_t *) p;
mixer_t m;
m.x = x;
do {
(void) __LDREXW(&q->ws[0]);
q->ws[1] = m.ws[1];
} while (__STREXW(m.ws[0], &q->ws[0]));
}
>
>> And if you /have/ such a distinction, then you necessarily have an OS of
>> some sort that runs in privileged mode and will provide such services as
>> locks or atomic accesses. Thus your implementation is:
>>
>> perform system call for the appropriate operation
>>
>> The implementation in the OS is:
>>
>> preserve current interrupt status
>> disable interrupts
>> perform operation
>> restore previous interrupt status
>>
>> Problem solved.
>
> The programmer may know about the underlying OS, but that doesn't mean that
> the compiler would.
You have that backwards. The OS implementer needs to understand the
compiler for a freestanding C implementation.
> Would the Standard allow for an implementation to
> report that it supports atomics if, when code tries to perform an operation
> on a 64-bit atomic type, it calls a function with an implementation-defined
> name that user code would then be required to supply, which would in turn
> have to perform the operation without help from the compiler?
Possibly. That would be a flexible idea.
I don't know whether or not the implementation would report that it
supports atomics - I can't imagine a use of asking it except perhaps to
give a user-friendly error message if they are needed by the code but
not supported by the compiler.
> A lot of free-
> standing implementations handle things like stdio.h in such a fashion, but
> that's allowable because the Standard doesn't require them to supply such
> functionality in the first place. Is an implementation allowed to say that
> it supports atomics.h functionality but then punt all the implementation
> back to the programmer?
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-10 21:15 -0700 |
| Message-ID | <c2e33e5c-422b-450e-92dc-5f7853fc0045@googlegroups.com> |
| In reply to | #109722 |
On Wednesday, May 10, 2017 at 6:12:13 PM UTC-5, David Brown wrote:> For bare metal single cpu systems, you can use this:
>
> uint64_t readAtomic64(volatile uint64_t *p) {
> uint64_t a = *p;
> while (true) {
> uint64_t b = *p;
> if (a == b) return a;
> a = b;
> }
> }
>
> void writeAtomic64(volatile uint64_t *p, uint64_t x) {
> do {
> *p = x;
> } while (*p != x);
> }
>
> That works because a function will either run to completion, or be
> interrupted. If it is interrupted, that interrupt will either run to
> completion, or be interrupted. And so on. You don't have
> multi-threading, and cannot have arbitrary interleaving between threads
> of execution. So while the two instructions that read the halves of the
> uin64_t can be interrupted by an operation that writes a new value to
> the variable, the write will be completed before continuing. It is
> therefore enough in most real-world cases to check for two adjacent
> identical reads. (There is a possibility of a number of interrupts
> during the reads of "a" and "b" causing an incorrect value to be
> returned - but that would require an extremely contrived and unrealistic
> system.)
How are you expecting that the above will work? If the main line is writing
the variable when an interrupt occurs that tries to read the variable, the
interrupt will see a half-updated value, and I don't see how the while()
loop in the write routine is supposed to fix that. I think it may be possible
to have each atomic uint64 accompanied by a pointer to a structure describing
a 64-bit compare-exchange request which would include the match and replacement
values along with a status indicator. If an interrupt occurs while the CX is
being processed, the interrupt handler could use the descriptor to complete it
before performing its own operation, but that would seem tricky. I'm not
sure if it would be amenable to other threading scenarios.
> Often, simply disabling interrupts and re-enabling them around atomic
> reads and writes is easier and more efficient. That is especially true
> if you are doing something more complicated than a read or a write.
I'm pretty sure that the Cortex M3 is used with operating systems that make
use of Unprivileged mode even if the Cortex M0 isn't, so disabling interrupts,
while nice, isn't always an option.
> Using LDREX and STREX, we can be more correct, even for multi-tasking
> and for multiple cores. The code here is untested, however.
> typedef union { uint64_t x; uint32_t ws[2]; } mixer_t;
> uint64_t readAtomic64(volatile uint64_t *p) {
> volatile mixer_t * q = (volatile mixer_t *) p;
> mixer_t m;
> do {
> m.ws[0] = __LDREXW(&q->ws[0]);
> m.ws[1] = q->ws[1];
> } while (__STREXW(m.ws[0], &q->ws[0]));
> return m.x;
> }
Since the above code would violate aliasing if p held the address of an
object whose declared type is uint64_t, an atomic uint64_t would have to
be a struct or union type rather. I'll assume you're using uint64_t
for simplicity, or with the intention that the code will only work on
compilers that offer some useful exceptions to the aliasing rules.
> void writeAtomic64(volatile uint64_t *p, uint64_t x) {
> volatile mixer_t * q = (volatile mixer_t *) p;
> mixer_t m;
> m.x = x;
>
> do {
> (void) __LDREXW(&q->ws[0]);
> q->ws[1] = m.ws[1];
> } while (__STREXW(m.ws[0], &q->ws[0]));
> }
Here again, if an interrupt happens after the mainline has half-updated the
value and the interrupt tries to read it, how is the interrupt supposed to
either find out what the new lower half will be or what the old upper half
was?
> You have that backwards. The OS implementer needs to understand the
> compiler for a freestanding C implementation.
Someone who is implementing an OS using a particular compiler would need to
understand the compiler. A compiler that is generating code that needs to
use features of an OS developed using another compiler, however, would have
to understand that OS.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-11 10:41 +0200 |
| Message-ID | <of17ti$q02$1@dont-email.me> |
| In reply to | #109730 |
On 11/05/17 06:15, supercat@casperkitty.com wrote:
> On Wednesday, May 10, 2017 at 6:12:13 PM UTC-5, David Brown wrote:> For bare metal single cpu systems, you can use this:
>>
>> uint64_t readAtomic64(volatile uint64_t *p) {
>> uint64_t a = *p;
>> while (true) {
>> uint64_t b = *p;
>> if (a == b) return a;
>> a = b;
>> }
>> }
>>
>> void writeAtomic64(volatile uint64_t *p, uint64_t x) {
>> do {
>> *p = x;
>> } while (*p != x);
>> }
>>
>
>> That works because a function will either run to completion, or be
>> interrupted. If it is interrupted, that interrupt will either run to
>> completion, or be interrupted. And so on. You don't have
>> multi-threading, and cannot have arbitrary interleaving between threads
>> of execution. So while the two instructions that read the halves of the
>> uin64_t can be interrupted by an operation that writes a new value to
>> the variable, the write will be completed before continuing. It is
>> therefore enough in most real-world cases to check for two adjacent
>> identical reads. (There is a possibility of a number of interrupts
>> during the reads of "a" and "b" causing an incorrect value to be
>> returned - but that would require an extremely contrived and unrealistic
>> system.)
>
> How are you expecting that the above will work? If the main line is writing
> the variable when an interrupt occurs that tries to read the variable, the
> interrupt will see a half-updated value, and I don't see how the while()
> loop in the write routine is supposed to fix that.
Sorry, that routine was added to the post /far/ too late at night, and
was much too simplistic. It will not work if you are writing, and an
interrupt function then wants to read the value.
There are many other ways to do this, depending on tradeoffs between
memory usage, interrupt disable time, different assumptions about usage,
etc.
> I think it may be possible
> to have each atomic uint64 accompanied by a pointer to a structure describing
> a 64-bit compare-exchange request which would include the match and replacement
> values along with a status indicator. If an interrupt occurs while the CX is
> being processed, the interrupt handler could use the descriptor to complete it
> before performing its own operation, but that would seem tricky. I'm not
> sure if it would be amenable to other threading scenarios.
You would need extra states somewhere - basically, you need something
that is small enough to be written atomically (such as a sig_atomic_t)
that you use for synchronisation and locking. You may need two of them
- I haven't thought through the details yet.
>
>> Often, simply disabling interrupts and re-enabling them around atomic
>> reads and writes is easier and more efficient. That is especially true
>> if you are doing something more complicated than a read or a write.
>
> I'm pretty sure that the Cortex M3 is used with operating systems that make
> use of Unprivileged mode even if the Cortex M0 isn't, so disabling interrupts,
> while nice, isn't always an option.
I would be surprised if that was commonly the case - most OS's for small
systems are linked as libraries and you don't have a privilege
separation. However, the details are irrelevant to the programmer - if
you use an OS, you use OS-provided features for mutex's or passing data
in message queues between threads. It does not matter to the user if
this is done by disabling interrupts in a local function, by a system
call (software interrupt), or any other mechanism. That is one of the
reasons for using an OS in the first place!
>
>> Using LDREX and STREX, we can be more correct, even for multi-tasking
>> and for multiple cores. The code here is untested, however.
>
>> typedef union { uint64_t x; uint32_t ws[2]; } mixer_t;
>> uint64_t readAtomic64(volatile uint64_t *p) {
>> volatile mixer_t * q = (volatile mixer_t *) p;
>> mixer_t m;
>> do {
>> m.ws[0] = __LDREXW(&q->ws[0]);
>> m.ws[1] = q->ws[1];
>> } while (__STREXW(m.ws[0], &q->ws[0]));
>> return m.x;
>> }
>
> Since the above code would violate aliasing if p held the address of an
> object whose declared type is uint64_t, an atomic uint64_t would have to
> be a struct or union type rather. I'll assume you're using uint64_t
> for simplicity, or with the intention that the code will only work on
> compilers that offer some useful exceptions to the aliasing rules.
It is fine to access the uint64_t via a pointer to a union that has
uint64_t as one of its members.
However, we are already solidly in the target dependent code world. We
are still portable between compilers for the ARM Cortex-M devices.
>
>> void writeAtomic64(volatile uint64_t *p, uint64_t x) {
>> volatile mixer_t * q = (volatile mixer_t *) p;
>> mixer_t m;
>> m.x = x;
>>
>> do {
>> (void) __LDREXW(&q->ws[0]);
>> q->ws[1] = m.ws[1];
>> } while (__STREXW(m.ws[0], &q->ws[0]));
>> }
>
> Here again, if an interrupt happens after the mainline has half-updated the
> value and the interrupt tries to read it, how is the interrupt supposed to
> either find out what the new lower half will be or what the old upper half
> was?
>
And again, this was written too quickly, too late at night. The
ldrexw/strexw need to be used to implement a lock independent of the
actual data, in order to cope with arbitrary orderings of reads and writes.
>> You have that backwards. The OS implementer needs to understand the
>> compiler for a freestanding C implementation.
>
> Someone who is implementing an OS using a particular compiler would need to
> understand the compiler. A compiler that is generating code that needs to
> use features of an OS developed using another compiler, however, would have
> to understand that OS.
>
That would be more of a hosted implementation, rather than a
free-standing implementation - a hosted implementation needs to know a
bit about the target OS.
But if a freestanding compiler implements atomics and relies on a target
OS to do so, then yes, there needs to be some sort of cooperation
between them such as an agreement on the function names used for these
things.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-11 15:32 -0700 |
| Message-ID | <6a71d86f-6dae-4390-a457-953184970712@googlegroups.com> |
| In reply to | #109736 |
On Thursday, May 11, 2017 at 3:41:36 AM UTC-5, David Brown wrote:
> It is fine to access the uint64_t via a pointer to a union that has
> uint64_t as one of its members.
Is there anything in the Standard that would require a compiler to
recognize use of a pointer-to-union for purposes of accessing a member
thereof that would not likewise require a compiler to recognize structure
members likewise?
I think there *should* be a means of specifying a type which behaves like
a union, with a proviso that a pointer of any constituent type may be
converted into a pointer-to-unionish-thing type, regardless of alignment,
and may be used to alias things of all the types in the union, provided
that it's only used to "directly" access members for which the pointer's
alignment is suitable. I don't think the Standard requires that compilers
treat unions like that, however, nor does it provide any way to compel
compilers to recognize anything similar.
> However, we are already solidly in the target dependent code world. We
> are still portable between compilers for the ARM Cortex-M devices.
> And again, this was written too quickly, too late at night. The
> ldrexw/strexw need to be used to implement a lock independent of the
> actual data, in order to cope with arbitrary orderings of reads and writes.
How does can lock handle situations where one piece of code accessing an
object might be an interrupt that is blocking the other? The only way I
think things could be made to work would be with an algorithm that would
put the operation into a state where either piece of code--or both--would
be allowed to complete it and let the original piece of code that had
requested it know whether it worked.
> > Someone who is implementing an OS using a particular compiler would need to
> > understand the compiler. A compiler that is generating code that needs to
> > use features of an OS developed using another compiler, however, would have
> > to understand that OS.
> >
>
> That would be more of a hosted implementation, rather than a
> free-standing implementation - a hosted implementation needs to know a
> bit about the target OS.
Some implementations make it possible to produce what I would call
"freestanding code"--basically a binary "blob" which can be read into memory
and executed (in the simplest versions of the concept, any static variables
would be placed immediately following the code as part of the blob). The
code within the blob would not need to know or care how it came to be stored
in memory, nor would it need to know or care about any underlying OS unless
it happens to call functions therefor.
If I write code for something like:
static unsigned intabs(int x) { return x<0 ? -(unsigned)x : x; }
unsigned approxdist(int x, int y)
{
unsigned ux = intabs(x);
unsigned uy = intabs(y);
return (ux > uy) ? ux + (uy >> 1) : uy + (ux >> 1);
}
a suitably-configured freestanding implementation could generate a blob
which could be invoked from within any OS that can place the code into
executable storage.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-12 01:54 -0500 |
| Message-ID | <itmahc56kp4lap7k5e680cnmfe9vet46or@4ax.com> |
| In reply to | #109790 |
On Thu, 11 May 2017 15:32:05 -0700 (PDT), supercat@casperkitty.com
wrote:
>On Thursday, May 11, 2017 at 3:41:36 AM UTC-5, David Brown wrote:
>> It is fine to access the uint64_t via a pointer to a union that has
>> uint64_t as one of its members.
>
>Is there anything in the Standard that would require a compiler to
>recognize use of a pointer-to-union for purposes of accessing a member
>thereof that would not likewise require a compiler to recognize structure
>members likewise?
>
>I think there *should* be a means of specifying a type which behaves like
>a union, with a proviso that a pointer of any constituent type may be
>converted into a pointer-to-unionish-thing type, regardless of alignment,
>and may be used to alias things of all the types in the union, provided
>that it's only used to "directly" access members for which the pointer's
>alignment is suitable. I don't think the Standard requires that compilers
>treat unions like that, however, nor does it provide any way to compel
>compilers to recognize anything similar.
>
>> However, we are already solidly in the target dependent code world. We
>> are still portable between compilers for the ARM Cortex-M devices.
>
>> And again, this was written too quickly, too late at night. The
>> ldrexw/strexw need to be used to implement a lock independent of the
>> actual data, in order to cope with arbitrary orderings of reads and writes.
>
>How does can lock handle situations where one piece of code accessing an
>object might be an interrupt that is blocking the other? The only way I
>think things could be made to work would be with an algorithm that would
>put the operation into a state where either piece of code--or both--would
>be allowed to complete it and let the original piece of code that had
>requested it know whether it worked.
>
>> > Someone who is implementing an OS using a particular compiler would need to
>> > understand the compiler. A compiler that is generating code that needs to
>> > use features of an OS developed using another compiler, however, would have
>> > to understand that OS.
>> >
>>
>> That would be more of a hosted implementation, rather than a
>> free-standing implementation - a hosted implementation needs to know a
>> bit about the target OS.
>
>Some implementations make it possible to produce what I would call
>"freestanding code"--basically a binary "blob" which can be read into memory
>and executed (in the simplest versions of the concept, any static variables
>would be placed immediately following the code as part of the blob).
Not even relocations?
>The
>code within the blob would not need to know or care how it came to be stored
>in memory, nor would it need to know or care about any underlying OS unless
>it happens to call functions therefor.
>
>If I write code for something like:
>
> static unsigned intabs(int x) { return x<0 ? -(unsigned)x : x; }
> unsigned approxdist(int x, int y)
> {
> unsigned ux = intabs(x);
> unsigned uy = intabs(y);
> return (ux > uy) ? ux + (uy >> 1) : uy + (ux >> 1);
> }
>
>a suitably-configured freestanding implementation could generate a blob
>which could be invoked from within any OS that can place the code into
>executable storage.
That really doesn't sound very useful. On almost all OS's it would be
just as easy, if not easier, to create the equivilent of a shared
library and load that. And such purely computational subroutines are
going to be pretty rare.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-12 07:45 -0700 |
| Message-ID | <f312319b-8fc0-40b1-b7b8-a843dd42608a@googlegroups.com> |
| In reply to | #109801 |
On Friday, May 12, 2017 at 1:54:35 AM UTC-5, robert...@yahoo.com wrote: > That really doesn't sound very useful. On almost all OS's it would be > just as easy, if not easier, to create the equivilent of a shared > library and load that. And such purely computational subroutines are > going to be pretty rare. A number of companies supply device drivers as "blobs". While some require the use of a particular embedded OS, others are designed to be usable from any OS that can be configured to leave a certain range of addresses free or else pass a pointer to usable storage, and which can call certain entry points at certain required times. While such purposes may be somewhat specialized, I would suggest that it's useful to have a compiler that can be set to "just work" in a wide variety of purposes without having to be individually tailored for each. Some platforms may make it easier or harder to implement a compiler in such a fashion, but on implementations where that concept is workable, I think a "general-purpose" compiler should try to support it.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-12 23:52 -0500 |
| Message-ID | <qk3dhc9qdarvfn0bksjfsq4i5l9g77sann@4ax.com> |
| In reply to | #109836 |
On Fri, 12 May 2017 07:45:14 -0700 (PDT), supercat@casperkitty.com wrote: >On Friday, May 12, 2017 at 1:54:35 AM UTC-5, robert...@yahoo.com wrote: >> That really doesn't sound very useful. On almost all OS's it would be >> just as easy, if not easier, to create the equivilent of a shared >> library and load that. And such purely computational subroutines are >> going to be pretty rare. > >A number of companies supply device drivers as "blobs". While some require >the use of a particular embedded OS, others are designed to be usable from >any OS that can be configured to leave a certain range of addresses free or >else pass a pointer to usable storage, and which can call certain entry >points at certain required times. While such purposes may be somewhat >specialized, I would suggest that it's useful to have a compiler that can >be set to "just work" in a wide variety of purposes without having to be >individually tailored for each. Some platforms may make it easier or harder >to implement a compiler in such a fashion, but on implementations where that >concept is workable, I think a "general-purpose" compiler should try to >support it. Most such uses are to preclude revealing source code, and there's always a loader of some sort to load the blob. This is common for *nix graphics card drivers. But none of those blobs are really independent, and the loader and the OS it attaches the blob to are really the OS as far as the blob is concerned. And compiler for that environment will have to support it, but that sort of thing will often involve a custom CRT.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-14 12:57 -0700 |
| Message-ID | <kfnr2zrqkie.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109790 |
supercat@casperkitty.com writes:
> On Thursday, May 11, 2017 at 3:41:36 AM UTC-5, David Brown wrote:
>> It is fine to access the uint64_t via a pointer to a union that has
>> uint64_t as one of its members.
>
> Is there anything in the Standard that would require a compiler to
> recognize use of a pointer-to-union for purposes of accessing a member
> thereof that would not likewise require a compiler to recognize structure
> members likewise? [...]
That sentence should be taken out and shot.
As to the orginal statement, assuming I understand what is meant, it
is wrong. Accessing an object via a union type intermediary, eg,
union foo *it = ...;
do_something( it->some_member );
is undefined behavior unless 'it' points to an actual union
object (of the appropriate type). If it simply points at a
scalar object, even one that is suitably aligned and has a member
matching the scalar object's type, an attempted access like that
shown above is undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-10 21:56 -0700 |
| Message-ID | <of0qof$kj2$1@dont-email.me> |
| In reply to | #109685 |
On 5/10/2017 9:26 AM, supercat@casperkitty.com wrote: > On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >> There are no M0+ implementations with unprivileged modes. There are >> some M3/M4 devices that have them, but I think you would look long and >> hard to find a single example of a program for them that does not run in >> privileged mode all the time. > > The ARM information page describes the effects of Unprivileged mode on > implementations that care to implement it. It does not specify whether > any actually do so. > > Even if one reaches out to the Cortex-M3 which adds LL/CS ability, I'm > not sure how that can effectively be leveraged to implement an atomic 64- > bit type in contexts that don't support a spinlock. Do you know of any > lock-free algorithms to implement 64-bit atomic operations using 32-bit > LL/CS without relying upon any shared global state, heap storage, or other > things that might be unavailable to a freestanding implementation? Fwiw, check this out: https://groups.google.com/d/topic/comp.lang.asm.x86/FScbTaQEYLc/discussion [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-11 10:45 +0200 |
| Message-ID | <of184t$s3n$1@dont-email.me> |
| In reply to | #109732 |
On 11/05/17 06:56, Chris M. Thomasson wrote: > On 5/10/2017 9:26 AM, supercat@casperkitty.com wrote: >> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >>> There are no M0+ implementations with unprivileged modes. There are >>> some M3/M4 devices that have them, but I think you would look long and >>> hard to find a single example of a program for them that does not run in >>> privileged mode all the time. >> >> The ARM information page describes the effects of Unprivileged mode on >> implementations that care to implement it. It does not specify whether >> any actually do so. >> >> Even if one reaches out to the Cortex-M3 which adds LL/CS ability, I'm >> not sure how that can effectively be leveraged to implement an atomic 64- >> bit type in contexts that don't support a spinlock. Do you know of any >> lock-free algorithms to implement 64-bit atomic operations using 32-bit >> LL/CS without relying upon any shared global state, heap storage, or >> other >> things that might be unavailable to a freestanding implementation? > > Fwiw, check this out: > > https://groups.google.com/d/topic/comp.lang.asm.x86/FScbTaQEYLc/discussion > I have seen that before (atomic 63 bit counter on 32-bit x86). I haven't studied it in enough detail, but the principle is nice. My gut feeling is that you might need 2 bits of overlap, not just one, but I'd need to think about it. It is a fine example of how specific cases can be handled more efficiently than general ones. It is a lot more efficient to read that counter, and to increment it, than to use a general 64-bit atomic read and a 64-bit atomic read-modify-write.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-11 14:43 -0700 |
| Message-ID | <of2lnk$gl8$1@dont-email.me> |
| In reply to | #109737 |
On 5/11/2017 1:45 AM, David Brown wrote: > On 11/05/17 06:56, Chris M. Thomasson wrote: >> On 5/10/2017 9:26 AM, supercat@casperkitty.com wrote: >>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >>>> There are no M0+ implementations with unprivileged modes. There are >>>> some M3/M4 devices that have them, but I think you would look long and >>>> hard to find a single example of a program for them that does not run in >>>> privileged mode all the time. >>> >>> The ARM information page describes the effects of Unprivileged mode on >>> implementations that care to implement it. It does not specify whether >>> any actually do so. >>> >>> Even if one reaches out to the Cortex-M3 which adds LL/CS ability, I'm >>> not sure how that can effectively be leveraged to implement an atomic 64- >>> bit type in contexts that don't support a spinlock. Do you know of any >>> lock-free algorithms to implement 64-bit atomic operations using 32-bit >>> LL/CS without relying upon any shared global state, heap storage, or >>> other >>> things that might be unavailable to a freestanding implementation? >> >> Fwiw, check this out: >> >> https://groups.google.com/d/topic/comp.lang.asm.x86/FScbTaQEYLc/discussion >> > > I have seen that before (atomic 63 bit counter on 32-bit x86). I > haven't studied it in enough detail, but the principle is nice. My gut > feeling is that you might need 2 bits of overlap, not just one, but I'd > need to think about it. > > It is a fine example of how specific cases can be handled more > efficiently than general ones. It is a lot more efficient to read that > counter, and to increment it, than to use a general 64-bit atomic read > and a 64-bit atomic read-modify-write. Agreed. However, I think a single point of overlap is enough to trigger things wrt correctness. Also, fwiw, check this out: https://groups.google.com/d/topic/comp.lang.asm.x86/LIIXOo01Jd0/discussion ;^)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-12 10:55 +0200 |
| Message-ID | <of3t3a$jdh$1@dont-email.me> |
| In reply to | #109785 |
On 11/05/17 23:43, Chris M. Thomasson wrote: > On 5/11/2017 1:45 AM, David Brown wrote: >> On 11/05/17 06:56, Chris M. Thomasson wrote: >>> On 5/10/2017 9:26 AM, supercat@casperkitty.com wrote: >>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >>>>> There are no M0+ implementations with unprivileged modes. There are >>>>> some M3/M4 devices that have them, but I think you would look long and >>>>> hard to find a single example of a program for them that does not >>>>> run in >>>>> privileged mode all the time. >>>> >>>> The ARM information page describes the effects of Unprivileged mode on >>>> implementations that care to implement it. It does not specify whether >>>> any actually do so. >>>> >>>> Even if one reaches out to the Cortex-M3 which adds LL/CS ability, I'm >>>> not sure how that can effectively be leveraged to implement an >>>> atomic 64- >>>> bit type in contexts that don't support a spinlock. Do you know of any >>>> lock-free algorithms to implement 64-bit atomic operations using 32-bit >>>> LL/CS without relying upon any shared global state, heap storage, or >>>> other >>>> things that might be unavailable to a freestanding implementation? >>> >>> Fwiw, check this out: >>> >>> https://groups.google.com/d/topic/comp.lang.asm.x86/FScbTaQEYLc/discussion >>> >>> >> >> I have seen that before (atomic 63 bit counter on 32-bit x86). I >> haven't studied it in enough detail, but the principle is nice. My gut >> feeling is that you might need 2 bits of overlap, not just one, but I'd >> need to think about it. >> >> It is a fine example of how specific cases can be handled more >> efficiently than general ones. It is a lot more efficient to read that >> counter, and to increment it, than to use a general 64-bit atomic read >> and a 64-bit atomic read-modify-write. > > Agreed. However, I think a single point of overlap is enough to trigger > things wrt correctness. Also, fwiw, check this out: > > https://groups.google.com/d/topic/comp.lang.asm.x86/LIIXOo01Jd0/discussion > > ;^) > I have noted the links for homework reading and further thought.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-12 07:30 -0700 |
| Message-ID | <e7b402d6-8645-45c8-84df-b561eebcef5e@googlegroups.com> |
| In reply to | #109813 |
On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: > On 11/05/17 23:43, Chris M. Thomasson wrote: > > On 5/11/2017 1:45 AM, David Brown wrote: > >> On 11/05/17 06:56, Chris M. Thomasson wrote: > >>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: > >>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: > >>>>> There are no M0+ implementations with unprivileged modes. There are > >>>>> some M3/M4 devices that have them, but I think you would look long and > >>>>> hard to find a single example of a program for them that does not > >>>>> run in > >>>>> privileged mode all the time. > >>>> > >>>> The ARM information page describes the effects of Unprivileged mode on > >>>> implementations that care to implement it. It does not specify whether > >>>> any actually do so. > >>>> > >>>> Even if one reaches out to the Cortex-M3 which adds LL/CS ability, I'm > >>>> not sure how that can effectively be leveraged to implement an > >>>> atomic 64- > >>>> bit type in contexts that don't support a spinlock. Do you know of any > >>>> lock-free algorithms to implement 64-bit atomic operations using 32-bit > >>>> LL/CS without relying upon any shared global state, heap storage, or > >>>> other > >>>> things that might be unavailable to a freestanding implementation? > >>> > >>> Fwiw, check this out: > >>> > >>> https://groups.google.com/d/topic/comp.lang.asm.x86/FScbTaQEYLc/discussion > >>> > >>> > >> > >> I have seen that before (atomic 63 bit counter on 32-bit x86). I > >> haven't studied it in enough detail, but the principle is nice. My gut > >> feeling is that you might need 2 bits of overlap, not just one, but I'd > >> need to think about it. > >> > >> It is a fine example of how specific cases can be handled more > >> efficiently than general ones. It is a lot more efficient to read that > >> counter, and to increment it, than to use a general 64-bit atomic read > >> and a 64-bit atomic read-modify-write. > > > > Agreed. However, I think a single point of overlap is enough to trigger > > things wrt correctness. Also, fwiw, check this out: > > > > https://groups.google.com/d/topic/comp.lang.asm.x86/LIIXOo01Jd0/discussion > > > > ;^) > > > > I have noted the links for homework reading and further thought. This whole thread is really depressing. It's bad enough that "spin locks" seem to be in the process of becoming a standard part of the language. Completely wrong, and would not be necessary if Intel would simply quit pretending their trash processors were anything but big toys. Real processors provide the basis of proper monitor entry and process thread release. But Intel has to have the "advantage" in speed, to push their competitors out of the market, so they build their processors for speed instead of for manageability. And we get spinlocks, whose very name indicates what's wrong with them, instead of proper primitives for managing threads of execution. -- Joel Rees Delusions of reinventing the industry all by myself: http://defining-computers.blogspot.com/
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-12 09:02 -0700 |
| Message-ID | <3ce689a4-aae6-4f0f-9c26-fa5ad186f01f@googlegroups.com> |
| In reply to | #109835 |
On Friday, May 12, 2017 at 9:30:26 AM UTC-5, joel...@gmail.com wrote: > And we get spinlocks, whose very name indicates what's wrong with > them, instead of proper primitives for managing threads of > execution. There is nothing wrong with spinlocks when used properly (code which acquires a spinlock never holds it for longer than would be required to perform a short sequence of wait-free operations). For most spinlocks the most common scenario will be that the core that wants to acquire it will be the last one to have used it, in which case there's no need for any inter-processor communication. In most contention scenarios, the time before the lock becomes free would be far less than the time required to perform any kind of task switch. Optimizing for those cases is generally more important than optimizing for the rare cases where many cores try to hit the same spinlock at the same time, or where a core that acquires a spinlock gets blocked by an interrupt (when spinlocks are used properly, the OS should ensure that they get cleaned up before the core is given to some other thread).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-14 13:14 -0700 |
| Message-ID | <ofadk9$9tt$1@dont-email.me> |
| In reply to | #109835 |
On 5/12/2017 7:30 AM, joel.rees@gmail.com wrote: > On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: >> On 11/05/17 23:43, Chris M. Thomasson wrote: >>> On 5/11/2017 1:45 AM, David Brown wrote: >>>> On 11/05/17 06:56, Chris M. Thomasson wrote: >>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: >>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: [...] > And we get spinlocks, whose very name indicates what's wrong with > them, instead of proper primitives for managing threads of > execution. Why do you think we need spinlocks on Intel processors? We can code a diverse array of non-blocking algorithms on Intel cpus.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-14 16:04 -0500 |
| Message-ID | <udhhhc910cbfqjhbh8migkdverspv3crc4@4ax.com> |
| In reply to | #109974 |
On Sun, 14 May 2017 13:14:11 -0700, "Chris M. Thomasson" <invalid@invalid.invalid> wrote: >On 5/12/2017 7:30 AM, joel.rees@gmail.com wrote: >> On Friday, May 12, 2017 at 5:55:20 PM UTC+9, David Brown wrote: >>> On 11/05/17 23:43, Chris M. Thomasson wrote: >>>> On 5/11/2017 1:45 AM, David Brown wrote: >>>>> On 11/05/17 06:56, Chris M. Thomasson wrote: >>>>>> On 5/10/2017 9:26 AM, supercat@somewhere wrote: >>>>>>> On Wednesday, May 10, 2017 at 7:22:45 AM UTC-5, David Brown wrote: >[...] > > > And we get spinlocks, whose very name indicates what's wrong with > > them, instead of proper primitives for managing threads of > > execution. > >Why do you think we need spinlocks on Intel processors? We can code a >diverse array of non-blocking algorithms on Intel cpus. The only reason I brought up spinlocks is that they're a sufficient primitive to allow the building of all the atomic functions in C. That many processors provide better ways to implement many of those atomics is nice, but not really pertinent to the original point.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-10 17:33 -0500 |
| Message-ID | <jo47hc1aggo4ir7953c3rjqvtikrnq9nqk@4ax.com> |
| In reply to | #109633 |
On Tue, 9 May 2017 14:19:25 -0700 (PDT), supercat@casperkitty.com wrote: >On Tuesday, May 9, 2017 at 1:56:37 PM UTC-5, robert...@yahoo.com wrote: >> What exactly would be problematic on a M0? On any single processor >> system pretty much all of those can be implemented as: >> >> disable interrupts >> perform operation >> enable interrupts > >A freestanding implementation should avoid presumptions about the context >in which code will be run. Hard to avoid as soon as you start implementing anything that might interact with the OS (or anything OS-like on a small system). >Any code which tries to disable interrupts on >the M0+ will only work if run in Privileged mode, and would thus be unusable >from within user tasks under an OS that runs such tasks in Unprivileged >mode. While I don't know to what extent controllers based on the M0+ have >hardware designs that would make the Privileged/Unprivileged distinction >useful, the ARM Cortex-M0+ does recognize it and it would seem presumptuous >for a freestanding implementation to impose requirements on the execution >context. If you're going to want to implement stdatomic, you'll have to interact with the OS on almost all systems. >It might be reasonable for a Cortex-M0 implementation to require the use >of a configuration option to specify whether it should generate code that >is suitable for use in Unprivileged mode, and support atomics.h only when >it isn't going so, but that would still leave the problem of how to tell a >compiler not to perform its own reordering of operations across a boundary >when generating code suitable for use in Unprivileged mode. > >> On a multiprocessor M0 (should such a thing exist), you can do that by >> also acquiring and releasing a spin lock (or a proper mutex). and you >> can do a spin lock with Dekker's algorithm even if the processor >> provides no atomic update at all (if you have at least test-and-set, >> implementing a spin lock is trivial). And while Dekker's is limited >> to only two processors, there are more complex algorithms which are >> not (Peterson's, for example). > >Spinlocks break in the scenario where atomics would most often be needed >on cores like the M0--for variables which are accessed by an interrupt and >the mainline. Spinlocks need to be used *with* the interrupt disable. The sequence is along the lines of: spin: cli tas flag jset doit sti jmp spin doit: ...perform atomic op... mov flag,0 sti The spinlock is only required in the multi-processor case. On a single processor, the interrupt disable is sufficient. If there's an OS that's preventing access to the interrupt disable flag, it should probably be providing either a proper mutex, or the atomic functions itself. > If there were a guarantee that all accesses would be done in >a single mainline or in nested interrupts, it would be possible to precede >each atomic update with an initially-null pointer that would (if non-null) >identify a data structure identifying what would have to happen to finish >an operation that was in progress. I don't know any way to make such a >thing work if nested contexts aren't guaranteed to finish before returning >control, however.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-09 13:51 +0000 |
| Message-ID | <pPjQA.28099$9o7.7307@fx12.iad> |
| In reply to | #109552 |
supercat@casperkitty.com writes: >On Monday, May 8, 2017 at 4:16:34 PM UTC-5, Scott Lurndal wrote: >> supercat writes: >> >On Monday, May 8, 2017 at 2:20:23 PM UTC-5, David Brown wrote: >> >> >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. >> >> An accurate characterization _at the time_. Today, with weak memory models, >> high core counts, out-of-order processor pipelines and the need for speed, >> volatile is insufficent. > >Someone writing low-level code for a hardware platform should be responsible >for doing whatever the hardware requires to ensure memory ordering. In some >cases that may mean ensuring that all code that uses certain objects gets run >on the same core [rather easy to do on single-core systems]. Even that doesn't work with an out-of-order core, where the processor itself can hoist a load ahead of a store unless special barrier instructions are emitted by the compiler and/or programmer to prevent such reordering.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-09 09:14 -0700 |
| Message-ID | <b37d3d4f-72dc-4c3b-a9f8-c28ff24171d4@googlegroups.com> |
| In reply to | #109586 |
On Tuesday, May 9, 2017 at 8:51:31 AM UTC-5, Scott Lurndal wrote: > Even that doesn't work with an out-of-order core, where the processor itself > can hoist a load ahead of a store unless special barrier instructions are > emitted by the compiler and/or programmer to prevent such reordering. Naturally. Someone writing low-level code needs to know the target hardware. My point is that if a platform makes it possible to achieve required ordering through a certain sequence of loads and stores (e.g. by including at least one dummy I/O read before any I/O operation that would trigger a DMA write, and after any I/O operation that would trigger a DMA read, or by programming the bus management unit to disable certain kinds of overlapping) an implementation which is is designed to be compatible with low-level code on that platform shouldn't require compiler-specific gymnastics to prevent compiler reordering from messing things up. I'm curious how often reordering non-volatile operations across volatile ones really improves performance. Given a choice between compatibility with code that doesn't use compiler-specific directives or an occasional slight performance boost, I would think it would be better to favor compatibility by default.
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web