Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #92512 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2016-08-19 14:22 -0700 |
| Last post | 2016-08-22 05:11 -0700 |
| Articles | 20 on this page of 355 — 30 participants |
Back to article view | Back to comp.lang.c
Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:22 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 09:36 +1200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 22:48 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:56 -0700
Re: Default values in #define Chad <cdalten@gmail.com> - 2016-08-22 07:56 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 17:09 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:47 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:55 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 09:27 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 09:41 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 20:19 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 12:54 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:14 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:23 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 05:42 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:52 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 06:01 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:06 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:56 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:59 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-23 10:42 -0700
Re: Default values in #define matt@godbolt.org - 2016-08-23 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:57 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:31 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:06 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:15 -0700
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 13:26 +0100
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 22:07 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-06 06:22 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 00:50 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-07 06:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 01:44 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-08 06:58 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:16 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:47 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:49 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:52 -0800
Re: Default values in #define asetofsymbols@gmail.com - 2016-12-09 00:52 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:19 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-07 04:43 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 14:18 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 07:22 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 08:00 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 22:14 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 13:44 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:07 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-09 17:00 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 17:46 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:37 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-10 09:42 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 10:05 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:51 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 04:40 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 03:15 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-12 16:12 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-13 01:45 -0600
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 16:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 10:25 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 10:50 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 04:02 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 13:14 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:57 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 14:32 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:58 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:21 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 14:41 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:47 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 16:24 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 07:30 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:12 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 12:21 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 15:02 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 13:19 -0800
Petty and unprofessional (Was: Default values in #define) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-13 16:46 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 09:04 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 20:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:19 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-13 11:33 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:44 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-14 10:04 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:37 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:28 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:23 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:10 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:54 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:57 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 02:53 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 05:59 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:03 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:22 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 17:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 18:37 -0800
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:25 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 07:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:35 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 09:17 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 11:03 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 11:41 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 12:31 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 13:13 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-12 20:22 +0000
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 07:10 -0800
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:21 -0800
Re: Default values in #define jameskuyper@verizon.net - 2016-12-11 10:33 -0800
Re: Default values in #define Melzzzzz <mel@zzzzz.com> - 2016-12-11 16:22 +0100
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:16 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 13:54 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 14:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:11 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:49 -0700
Re: Default values in #define Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-21 05:50 -0600
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-21 13:10 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 12:56 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 21:11 +0100
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-22 15:47 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 11:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 20:07 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 14:30 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-24 06:25 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 10:34 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-24 08:50 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 15:37 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 11:58 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 01:27 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 22:28 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 23:38 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:44 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 07:29 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 07:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:26 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 11:11 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 12:03 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:31 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 09:28 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 22:51 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 16:35 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 01:44 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-30 10:06 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:41 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:24 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:32 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-30 22:30 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 09:17 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:46 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 10:29 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:12 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 12:30 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 11:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:56 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 08:17 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:18 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:34 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 00:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:19 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 11:38 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 10:03 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 10:31 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 12:50 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 21:30 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:37 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 08:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-06 07:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:54 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-02 08:40 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 10:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 15:16 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-25 08:28 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 00:54 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 01:00 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 11:17 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 04:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 13:45 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 06:09 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 17:11 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 09:31 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 12:48 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:50 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:01 +0200
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 10:57 -0700
Re: Default values in #define Ike Naar <ike@iceland.freeshell.org> - 2016-08-31 06:09 +0000
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 12:24 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:39 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:49 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:51 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:46 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-26 17:37 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 15:05 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 10:25 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 16:25 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 18:12 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 13:47 +1200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 19:32 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 22:54 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 21:11 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 18:25 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:11 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 06:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 10:16 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:17 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:26 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:10 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:35 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:28 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 15:38 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 13:27 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 16:42 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:16 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 17:24 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:21 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 08:12 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 15:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 10:53 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:34 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 14:44 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 12:48 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:19 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 11:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:33 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:51 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:46 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 16:26 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-03 17:31 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:03 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:36 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:30 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:39 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 03:57 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 15:34 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 07:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:46 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:03 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:52 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 07:41 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 14:58 -0400
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:27 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:05 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:15 -0700
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-09-02 22:22 +0200
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-28 08:41 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:34 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:41 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 08:07 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:08 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 15:41 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:30 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:14 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 23:37 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:19 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:26 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 04:40 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:56 +0200
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 15:43 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 19:34 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 00:51 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 20:36 +1200
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-08-31 00:39 -0500
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 21:40 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:22 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 11:36 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:26 -0800
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-27 06:34 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 12:48 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:12 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:10 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:18 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 10:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:49 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:13 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:48 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:14 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 08:59 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:43 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-29 22:58 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-30 07:14 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 00:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 00:26 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:10 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 10:47 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 03:32 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:38 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:44 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 14:00 +0200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 18:55 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:24 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 14:11 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 16:28 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 16:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-31 06:27 +0100
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 23:09 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 16:06 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:35 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:30 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:40 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:17 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:58 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 09:09 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:16 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:49 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:31 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:24 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:29 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 10:02 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:33 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 14:12 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 14:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:27 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 23:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 14:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:32 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:33 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:13 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:35 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 19:08 +0100
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-08-24 09:05 +0200
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-24 00:49 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-24 05:40 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-19 22:56 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 10:14 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 18:09 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 13:15 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 19:10 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 14:50 +1200
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 10:35 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-20 03:13 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 12:24 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-21 00:14 +1200
Re: Default values in #define gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-20 14:13 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:17 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 14:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:14 -0700
Re: Default values in #define Philipp Klaus Krause <pkk@spth.de> - 2016-08-21 12:51 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:11 -0700
Page 11 of 18 — ← Prev page 1 … 9 10 [11] 12 13 … 18 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 18:12 -0700 |
| Message-ID | <e1cb23ea-8fe0-4f1d-9182-2661cd3dac1a@googlegroups.com> |
| In reply to | #92767 |
On Friday, August 26, 2016 at 11:25:11 PM UTC+1, Ian Collins wrote: > On 08/27/16 10:05 AM, supercat@casperkitty.com wrote: > > On Friday, August 26, 2016 at 4:37:23 PM UTC-5, Richard Damon wrote: > >> volatile only requires that the compiler reads the variable exactly once > >> for every read mention and writes exactly once for every assignment in > >> the code. They also need to be ordered based on the promises of the > >> abstract machine. It does not guarantee atomic access. For that you need > >> to use things with atomic guarantees. > > > > It is often reasonable for an implementation to limit its guarantees to > > those the hardware would provide on a "normal" access. That does not > > imply that programmers should not be entitled to expect that *quality* > > implementations will provide guarantees at least as strong as those of > > the underlying hardware unless there is an obviously-compelling reason > > to do so. > > It would still be foolhardy to rely on such an assumption. > Word accesses are almost always inherently atomic, that's essentially what "word" means, in a computer context. You can't raise an interrupt mid instruction, only between instructions,at least normally. However if a variable is multi-word, then it seems you can have an interrupt between the read of the low word and the read of the high word, with potentially disastrous consequences, even more serious because that will likely be rare and, in the case of a counter, the algorithm will likely be robust to it except in the special case of low word wrapping and carrying. So volatile is essentially useless without other machinery around it in an interrupt-driven environment.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-27 13:47 +1200 |
| Message-ID | <e2c9okFa03jU7@mid.individual.net> |
| In reply to | #92775 |
On 08/27/16 01:12 PM, Malcolm McLean wrote: > On Friday, August 26, 2016 at 11:25:11 PM UTC+1, Ian Collins wrote: >> On 08/27/16 10:05 AM, supercat@casperkitty.com wrote: >>> On Friday, August 26, 2016 at 4:37:23 PM UTC-5, Richard Damon wrote: >>>> volatile only requires that the compiler reads the variable exactly once >>>> for every read mention and writes exactly once for every assignment in >>>> the code. They also need to be ordered based on the promises of the >>>> abstract machine. It does not guarantee atomic access. For that you need >>>> to use things with atomic guarantees. >>> >>> It is often reasonable for an implementation to limit its guarantees to >>> those the hardware would provide on a "normal" access. That does not >>> imply that programmers should not be entitled to expect that *quality* >>> implementations will provide guarantees at least as strong as those of >>> the underlying hardware unless there is an obviously-compelling reason >>> to do so. >> >> It would still be foolhardy to rely on such an assumption. >> > Word accesses are almost always inherently atomic, that's essentially > what "word" means, in a computer context. You can't raise an interrupt > mid instruction, only between instructions,at least normally. It may be possible to get an interrupt between the cycles of a misaligned access, or another thread updating the same variable. > However if a variable is multi-word, then it seems you can have > an interrupt between the read of the low word and the read of the high > word, with potentially disastrous consequences, even more serious > because that will likely be rare and, in the case of a counter, the > algorithm will likely be robust to it except in the special case of > low word wrapping and carrying. > So volatile is essentially useless without other machinery around it > in an interrupt-driven environment. Volatile is essentially useless for what it isn't intended to do! It does its intended job perfectly well. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 19:32 -0700 |
| Message-ID | <91a99d84-b481-4dae-949b-914cb5e8aab7@googlegroups.com> |
| In reply to | #92776 |
On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote: > > Volatile is essentially useless for what it isn't intended to do! It > does its intended job perfectly well. > volatile means that the object is subject to change at any time by an outside force. But that only makes sense if it is coherent. We can obviously change the price of beer. Due to the wicked and excessive taxes exacted by government, it might have to go up 10p. So it goes from 3.20 to 3.30. But there isn't an intermediate second between the barman rubbing out the 2 and writing the 3 when you can get a beer for 3.0. That's nonsense. Any rule that allows modification has to allow for temporary suspension during the period of modification itself.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 22:54 -0400 |
| Message-ID | <npqvct$suc$1@jstuckle.eternal-september.org> |
| In reply to | #92779 |
On 8/26/2016 10:32 PM, Malcolm McLean wrote: > On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote: >> >> Volatile is essentially useless for what it isn't intended to do! It >> does its intended job perfectly well. >> > volatile means that the object is subject to change at any time > by an outside force. But that only makes sense if it is coherent. > > We can obviously change the price of beer. Due to the wicked and > excessive taxes exacted by government, it might have to go up > 10p. So it goes from 3.20 to 3.30. But there isn't an intermediate > second between the barman rubbing out the 2 and writing the 3 > when you can get a beer for 3.0. That's nonsense. Any rule that > allows modification has to allow for temporary suspension during > the period of modification itself. > Sorry, in this case Ian is correct. Any user-mode operation which takes more than one assembler instruction can be interrupted between instructions, leaving the storage partially updated. That's why there are mutex (mutual exclusion) semaphores. But everyone has to agree to use them. And user-mode programs cannot temporarily suspend interrupts. That is a privileged operation. You may not like it - but that's the facts. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 21:11 -0700 |
| Message-ID | <60c8cdba-0914-430a-999d-5543e627025e@googlegroups.com> |
| In reply to | #92780 |
On Saturday, August 27, 2016 at 3:54:30 AM UTC+1, Jerry Stuckle wrote:
> On 8/26/2016 10:32 PM, Malcolm McLean wrote:
> > On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote:
> >>
> >> Volatile is essentially useless for what it isn't intended to do! It
> >> does its intended job perfectly well.
> >>
> > volatile means that the object is subject to change at any time
> > by an outside force. But that only makes sense if it is coherent.
> >
> > We can obviously change the price of beer. Due to the wicked and
> > excessive taxes exacted by government, it might have to go up
> > 10p. So it goes from 3.20 to 3.30. But there isn't an intermediate
> > second between the barman rubbing out the 2 and writing the 3
> > when you can get a beer for 3.0. That's nonsense. Any rule that
> > allows modification has to allow for temporary suspension during
> > the period of modification itself.
> >
>
> Sorry, in this case Ian is correct. Any user-mode operation which takes
> more than one assembler instruction can be interrupted between
> instructions, leaving the storage partially updated.
>
I'm not disputing that he is correct, just pointing out that it makes volatile essentially useless unless you rely on non-standard
mandated features.
>
> That's why there are mutex (mutual exclusion) semaphores. But everyone
> has to agree to use them.
>
> And user-mode programs cannot temporarily suspend interrupts. That is a
> privileged operation.
>
Not all the world is a PC. There are plenty of devices, some of which
qualify as general-purpose computers, where you have no user-mode,
and you provide your own interrupt service routines in C. Normally
it's necessary to disable interrupts to prevent the interrupt service
routine itself being interrupted.
>
> You may not like it - but that's the facts.
>
If
volatile long long counter; // counts number of times interrupt has
// been called
foo()
{
if(counter > prevcounter)
{
/* ISR has done something, handle it */
}
}
is not usable C then it's a pretty bad situation, yes. But as I
said, I don't do that sort of programming much in practice
nowadays. I used to in the past, but the fates have taken me
more into algorithm development.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-27 18:25 +1200 |
| Message-ID | <e2cq2eFa03jU9@mid.individual.net> |
| In reply to | #92783 |
On 08/27/16 04:11 PM, Malcolm McLean wrote:
> On Saturday, August 27, 2016 at 3:54:30 AM UTC+1, Jerry Stuckle wrote:
>>
>> Sorry, in this case Ian is correct. Any user-mode operation which takes
>> more than one assembler instruction can be interrupted between
>> instructions, leaving the storage partially updated.
>>
> I'm not disputing that he is correct, just pointing out that it makes
> volatile essentially useless unless you rely on non-standard
> mandated features.
Not really, a volatile (often a const volatile) could be some piece of
hardware. How you read it is target specific, not wanting the compiler
to optimise away any reads is not.
> If
> volatile long long counter; // counts number of times interrupt has
> // been called
>
> foo()
> {
> if(counter > prevcounter)
> {
> /* ISR has done something, handle it */
> }
> }
>
> is not usable C then it's a pretty bad situation, yes.
Not at all, it is a situation where you would use an atomic type. The
code base I'm currently working on makes heavy use of standard atomic
types.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-27 09:11 -0400 |
| Message-ID | <nps3ib$sbt$1@jstuckle.eternal-september.org> |
| In reply to | #92783 |
On 8/27/2016 12:11 AM, Malcolm McLean wrote:
> On Saturday, August 27, 2016 at 3:54:30 AM UTC+1, Jerry Stuckle wrote:
>> On 8/26/2016 10:32 PM, Malcolm McLean wrote:
>>> On Saturday, August 27, 2016 at 2:47:12 AM UTC+1, Ian Collins wrote:
>>>>
>>>> Volatile is essentially useless for what it isn't intended to do! It
>>>> does its intended job perfectly well.
>>>>
>>> volatile means that the object is subject to change at any time
>>> by an outside force. But that only makes sense if it is coherent.
>>>
>>> We can obviously change the price of beer. Due to the wicked and
>>> excessive taxes exacted by government, it might have to go up
>>> 10p. So it goes from 3.20 to 3.30. But there isn't an intermediate
>>> second between the barman rubbing out the 2 and writing the 3
>>> when you can get a beer for 3.0. That's nonsense. Any rule that
>>> allows modification has to allow for temporary suspension during
>>> the period of modification itself.
>>>
>>
>> Sorry, in this case Ian is correct. Any user-mode operation which takes
>> more than one assembler instruction can be interrupted between
>> instructions, leaving the storage partially updated.
>>
> I'm not disputing that he is correct, just pointing out that it makes volatile essentially useless unless you rely on non-standard
> mandated features.
>>
>> That's why there are mutex (mutual exclusion) semaphores. But everyone
>> has to agree to use them.
>>
>> And user-mode programs cannot temporarily suspend interrupts. That is a
>> privileged operation.
>>
> Not all the world is a PC. There are plenty of devices, some of which
> qualify as general-purpose computers, where you have no user-mode,
> and you provide your own interrupt service routines in C. Normally
> it's necessary to disable interrupts to prevent the interrupt service
> routine itself being interrupted.
No, but in every processor I know of which has kernel and user modes,
including mainframes, disabling interrupts is a privileged operation,
not available to user programs.
And interrupt routines execute in kernel mode, so they can enable or
disable other interrupts, as necessary.
>>
>> You may not like it - but that's the facts.
>>
> If
> volatile long long counter; // counts number of times interrupt has
> // been called
>
> foo()
> {
> if(counter > prevcounter)
> {
> /* ISR has done something, handle it */
> }
> }
>
> is not usable C then it's a pretty bad situation, yes. But as I
> said, I don't do that sort of programming much in practice
> nowadays. I used to in the past, but the fates have taken me
> more into algorithm development.
>
That is correct - for more than one reason. Yes, it requires multiple
assembler instructions to retrieve the counter. But even if it were an
int and could be handled in one instruction, there is no guarantee the
counter will not change between its retrieval and the comparison. That
is also multiple instructions.
I've seen similar before when people try to make a cheap mutex
semaphore, such as:
volatile bool locked = false;
foo() {
if (!locked) {
locked = true;
/* do something */
locked = false;
}
}
Between the test and the setting of locked, another thread could have
changed it. Another case of a very difficult bug to find.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-27 06:33 -0700 |
| Message-ID | <c12272a1-baba-4e7a-b2de-eb39bb03b6f4@googlegroups.com> |
| In reply to | #92797 |
On Saturday, August 27, 2016 at 2:11:48 PM UTC+1, Jerry Stuckle wrote: > On 8/27/2016 12:11 AM, Malcolm McLean wrote: > > No, but in every processor I know of which has kernel and user modes, > including mainframes, disabling interrupts is a privileged operation, > not available to user programs. > > And interrupt routines execute in kernel mode, so they can enable or > disable other interrupts, as necessary. > Yes, obviously if the environment is operating system plus untrusted programs - not necessarily in the "enemy hacker" sense, just programs that might be buggy, then disabling interrupts and not reenabling is a surefire way to take down the system. But not every device needs to be robust to that.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-27 10:16 -0400 |
| Message-ID | <nps7c3$8u4$1@jstuckle.eternal-september.org> |
| In reply to | #92799 |
On 8/27/2016 9:33 AM, Malcolm McLean wrote: > On Saturday, August 27, 2016 at 2:11:48 PM UTC+1, Jerry Stuckle wrote: >> On 8/27/2016 12:11 AM, Malcolm McLean wrote: >> >> No, but in every processor I know of which has kernel and user modes, >> including mainframes, disabling interrupts is a privileged operation, >> not available to user programs. >> >> And interrupt routines execute in kernel mode, so they can enable or >> disable other interrupts, as necessary. >> > Yes, obviously if the environment is operating system plus untrusted > programs - not necessarily in the "enemy hacker" sense, just programs > that might be buggy, then disabling interrupts and not reenabling > is a surefire way to take down the system. > But not every device needs to be robust to that. > No, there are a lot of embedded systems, DSPs, etc. which don't need to do that. But those also generally don't have an OS, and the application effectively is the OS. Nowadays, all multitasking processors have privileged and non-privileged instructions. And virtually all OS's limit applications to non-privileged instructions. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-27 13:17 -0700 |
| Message-ID | <b558bbef-78db-4a6f-bef0-a5586fe54627@googlegroups.com> |
| In reply to | #92801 |
On Saturday, August 27, 2016 at 9:16:43 AM UTC-5, Jerry Stuckle wrote: > Nowadays, all multitasking processors have privileged and non-privileged > instructions. And virtually all OS's limit applications to > non-privileged instructions. C isn't just used for "application"; many dialects are systems programming languages which can be used for writing things like operating systems and device drivers, which do operate in privileged modes. Further, many embedded systems don't force a distinction between applications and user-supplied extensions to the OS; code that doesn't need to operate in privileged mode may ask the OS to run it in non-privileged mode, but code that does need to run in privileged mode can request that.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-27 16:26 -0400 |
| Message-ID | <npst26$hjl$1@jstuckle.eternal-september.org> |
| In reply to | #92816 |
On 8/27/2016 4:17 PM, supercat@casperkitty.com wrote: > On Saturday, August 27, 2016 at 9:16:43 AM UTC-5, Jerry Stuckle wrote: >> Nowadays, all multitasking processors have privileged and non-privileged >> instructions. And virtually all OS's limit applications to >> non-privileged instructions. > > C isn't just used for "application"; many dialects are systems programming > languages which can be used for writing things like operating systems and > device drivers, which do operate in privileged modes. Further, many embedded > systems don't force a distinction between applications and user-supplied > extensions to the OS; code that doesn't need to operate in privileged mode > may ask the OS to run it in non-privileged mode, but code that does need to > run in privileged mode can request that. > Yes, but we've been talking applications here. Now you're trying to change the topic - as usual. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-27 13:10 -0700 |
| Message-ID | <2d96b3c5-8c6d-4aa5-a6f1-d6381a533e24@googlegroups.com> |
| In reply to | #92797 |
On Saturday, August 27, 2016 at 8:11:48 AM UTC-5, Jerry Stuckle wrote:
> No, but in every processor I know of which has kernel and user modes,
> including mainframes, disabling interrupts is a privileged operation,
> not available to user programs.
I've often wished processors would include an instruction which would
allow pending interrupts to execute and then disable interrupts for
e.g. the next 16 cycles (more for machines that take multiple cycles for
each instruction). Executing such an instruction while interrupts are
disabled from the previous one shouldn't trap, but should negate the
effects of the previous one (servicing pending interrupts) before
disabling interrupts again. Getting the semantics right in system with
virtual memory would be a bit tricky, making such an instruction safely
available within user mode would allow many kinds of operations to be
greatly simplified in single-core systems without virtual memory.
> I've seen similar before when people try to make a cheap mutex
> semaphore, such as:
>
> volatile bool locked = false;
>
> foo() {
> if (!locked) {
> locked = true;
> /* do something */
> locked = false;
> }
> }
>
> Between the test and the setting of locked, another thread could have
> changed it. Another case of a very difficult bug to find.
If there are two threads with similar code, that design is clearly broken.
Some similar designs, however, can be perfectly workable if a system has
memory barriers around compiler accesses, or if everything that is used
in the interrupt and mainline is "volatile" [note that memory barriers are
often less costly than requiring that everything be volatile].
For example:
volatile interrupt_item_count;
MAINLINE:
while(interrupt_item_count)
spin();
... store data into an array
... set pointer to start of array
interrupt_item_count = number_of_items;
INTERRUPT:
if (interrupt_item_count)
{
OUTPUT_DEVICE = *interrupt_data_ptr++;
interrupt_item_count--;
}
If a compiler can recognize a memory barrier between operations on
interrupt_item_count and operations on the array without the array having
to be volatile, it may be able to optimize out redundant writes to the array
if e.g. code zeroes out the whole thing and then populates parts of it.
If interrupts run to completion before returning to the calling context,
there won't be any problems with accessing the counter from both the main
line and interrupt, since the mainline can only write the counter if it is
zero, and the interrupt will only write it if it isn't.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-27 16:35 -0400 |
| Message-ID | <npsthn$ji7$1@jstuckle.eternal-september.org> |
| In reply to | #92815 |
On 8/27/2016 4:10 PM, supercat@casperkitty.com wrote:
> On Saturday, August 27, 2016 at 8:11:48 AM UTC-5, Jerry Stuckle wrote:
>> No, but in every processor I know of which has kernel and user modes,
>> including mainframes, disabling interrupts is a privileged operation,
>> not available to user programs.
>
> I've often wished processors would include an instruction which would
> allow pending interrupts to execute and then disable interrupts for
> e.g. the next 16 cycles (more for machines that take multiple cycles for
> each instruction). Executing such an instruction while interrupts are
> disabled from the previous one shouldn't trap, but should negate the
> effects of the previous one (servicing pending interrupts) before
> disabling interrupts again. Getting the semantics right in system with
> virtual memory would be a bit tricky, making such an instruction safely
> available within user mode would allow many kinds of operations to be
> greatly simplified in single-core systems without virtual memory.
>
To give an application such power could allow a misbehaving application
to effectively cripple a system. Terrible idea.
>> I've seen similar before when people try to make a cheap mutex
>> semaphore, such as:
>>
>> volatile bool locked = false;
>>
>> foo() {
>> if (!locked) {
>> locked = true;
>> /* do something */
>> locked = false;
>> }
>> }
>>
>> Between the test and the setting of locked, another thread could have
>> changed it. Another case of a very difficult bug to find.
>
> If there are two threads with similar code, that design is clearly broken.
> Some similar designs, however, can be perfectly workable if a system has
> memory barriers around compiler accesses, or if everything that is used
> in the interrupt and mainline is "volatile" [note that memory barriers are
> often less costly than requiring that everything be volatile].
>
> For example:
>
> volatile interrupt_item_count;
>
> MAINLINE:
> while(interrupt_item_count)
> spin();
> ... store data into an array
> ... set pointer to start of array
> interrupt_item_count = number_of_items;
>
> INTERRUPT:
> if (interrupt_item_count)
> {
> OUTPUT_DEVICE = *interrupt_data_ptr++;
> interrupt_item_count--;
> }
>
> If a compiler can recognize a memory barrier between operations on
> interrupt_item_count and operations on the array without the array having
> to be volatile, it may be able to optimize out redundant writes to the array
> if e.g. code zeroes out the whole thing and then populates parts of it.
> If interrupts run to completion before returning to the calling context,
> there won't be any problems with accessing the counter from both the main
> line and interrupt, since the mainline can only write the counter if it is
> zero, and the interrupt will only write it if it isn't.
>
And why should it recognize such a barrier? And even a statement such as
OUTPUT_DEVICE = *interrupt_data_ptr++;
can be interrupted, i.e. during the increment of interrupt_data_ptr.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 09:28 -0700 |
| Message-ID | <77615a84-4159-4c4e-ba76-0fe10fb70c77@googlegroups.com> |
| In reply to | #92819 |
On Saturday, August 27, 2016 at 3:35:11 PM UTC-5, Jerry Stuckle wrote: > On 8/27/2016 4:10 PM, supercat wrote: > > I've often wished processors would include an instruction which would > > allow pending interrupts to execute and then disable interrupts for > > e.g. the next 16 cycles (more for machines that take multiple cycles for > > each instruction). Executing such an instruction while interrupts are > > disabled from the previous one shouldn't trap, but should negate the > > effects of the previous one (servicing pending interrupts) before > > disabling interrupts again. Getting the semantics right in system with > > virtual memory would be a bit tricky, making such an instruction safely > > available within user mode would allow many kinds of operations to be > > greatly simplified in single-core systems without virtual memory. > > To give an application such power could allow a misbehaving application > to effectively cripple a system. Terrible idea. How could a rogue application use such a thing to cripple the system if the most it could do is delay interrupts by (e.g.) 16 cycles? I could see that one might want an option to exclude the top-priority interrupt from such a feature (with the caveat that the design of top-priority interrupts must be aware of the possibility of splitting operations that were expected to be atomic) but if each attempt to ask for 16 uninterruptible cycles were to allow any interrupts that had become pending during an earlier such request (and would have already executed but for that earlier request) to execute without further delay, the worst I could see would be a slight increase in interrupt latency.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-29 15:38 -0400 |
| Message-ID | <nq22v4$kig$1@jstuckle.eternal-september.org> |
| In reply to | #92875 |
On 8/29/2016 12:28 PM, supercat@casperkitty.com wrote: > On Saturday, August 27, 2016 at 3:35:11 PM UTC-5, Jerry Stuckle wrote: >> On 8/27/2016 4:10 PM, supercat wrote: >>> I've often wished processors would include an instruction which would >>> allow pending interrupts to execute and then disable interrupts for >>> e.g. the next 16 cycles (more for machines that take multiple cycles for >>> each instruction). Executing such an instruction while interrupts are >>> disabled from the previous one shouldn't trap, but should negate the >>> effects of the previous one (servicing pending interrupts) before >>> disabling interrupts again. Getting the semantics right in system with >>> virtual memory would be a bit tricky, making such an instruction safely >>> available within user mode would allow many kinds of operations to be >>> greatly simplified in single-core systems without virtual memory. >> >> To give an application such power could allow a misbehaving application >> to effectively cripple a system. Terrible idea. > > How could a rogue application use such a thing to cripple the system if > the most it could do is delay interrupts by (e.g.) 16 cycles? I could see > that one might want an option to exclude the top-priority interrupt from > such a feature (with the caveat that the design of top-priority interrupts > must be aware of the possibility of splitting operations that were expected > to be atomic) but if each attempt to ask for 16 uninterruptible cycles > were to allow any interrupts that had become pending during an earlier such > request (and would have already executed but for that earlier request) to > execute without further delay, the worst I could see would be a slight > increase in interrupt latency. > Simple. Reissue the instruction every 15 cycles. It doesn't actually have to DO anything else. Just disable the interrupts would be enough to crash the system. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 13:27 -0700 |
| Message-ID | <c9878961-cd91-440d-90ce-bdfa577276fa@googlegroups.com> |
| In reply to | #92892 |
On Monday, August 29, 2016 at 2:38:23 PM UTC-5, Jerry Stuckle wrote: > Simple. Reissue the instruction every 15 cycles. > > It doesn't actually have to DO anything else. Just disable the > interrupts would be enough to crash the system. You seem to have missed the part about processing pending interrupts before temporarily blocking them. If a loop issues the instruction (assume it takes one cycle), does 10 cycles of work, then issues the instruction again, and then does 15 more cycles of work, then within each 27-cycle loop there would be an opportunity to service interrupts after the first cycle and again after the eleventh, so no interrupt would be delayed more than 16 cycles. Since one should not expect to be able to run an arbitrary piece of code within a short 15-cycle window, there should be no concern about a context which uses the instruction being nested within another context that expects interrupts to be disabled continuously throughout it, since whoever is writing the outer code should be aware of what's within it (note that the construct would really only be useful from within assembly code, or with a compiler mode that is documented as generating code in a very straightforward and predictable fashion).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-29 16:42 -0400 |
| Message-ID | <nq26og$2ce$1@jstuckle.eternal-september.org> |
| In reply to | #92897 |
On 8/29/2016 4:27 PM, supercat@casperkitty.com wrote: > On Monday, August 29, 2016 at 2:38:23 PM UTC-5, Jerry Stuckle wrote: >> Simple. Reissue the instruction every 15 cycles. >> >> It doesn't actually have to DO anything else. Just disable the >> interrupts would be enough to crash the system. > > You seem to have missed the part about processing pending interrupts before > temporarily blocking them. If a loop issues the instruction (assume it > takes one cycle), does 10 cycles of work, then issues the instruction again, > and then does 15 more cycles of work, then within each 27-cycle loop there > would be an opportunity to service interrupts after the first cycle and > again after the eleventh, so no interrupt would be delayed more than 16 > cycles. > If the instruction disables interrupts for 16 cycles, and it is issued every 15 cycles, by your definition the interrupts will never be processed. Otherwise the system wouldn't fulfill your "disabled for 16 cycles" requirement. It's one or the other. Either it waits 16 cycles or it doesn't. You can't have it both ways. > Since one should not expect to be able to run an arbitrary piece of code > within a short 15-cycle window, there should be no concern about a > context which uses the instruction being nested within another context > that expects interrupts to be disabled continuously throughout it, since > whoever is writing the outer code should be aware of what's within it > (note that the construct would really only be useful from within assembly > code, or with a compiler mode that is documented as generating code in a > very straightforward and predictable fashion). > It doesn't need to run "an arbitrary piece of code". It just needs to keep reissuing the instruction. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 14:16 -0700 |
| Message-ID | <16739467-7da1-4575-bfd6-b0f9bce76fa7@googlegroups.com> |
| In reply to | #92899 |
On Monday, August 29, 2016 at 3:43:08 PM UTC-5, Jerry Stuckle wrote: > If the instruction disables interrupts for 16 cycles, and it is issued > every 15 cycles, by your definition the interrupts will never be > processed. Otherwise the system wouldn't fulfill your "disabled for 16 > cycles" requirement. Should I have been more explicit "disabled for 16 cycles, or sooner if another instruction enables interrupts"? I would have thought the latter was implied. > It's one or the other. Either it waits 16 cycles or it doesn't. You > can't have it both ways. Up to 16 cycles, or shorter if the code doesn't want/need the full 16. > > Since one should not expect to be able to run an arbitrary piece of code > > within a short 15-cycle window, there should be no concern about a > > context which uses the instruction being nested within another context > > that expects interrupts to be disabled continuously throughout it, since > > whoever is writing the outer code should be aware of what's within it > > (note that the construct would really only be useful from within assembly > > code, or with a compiler mode that is documented as generating code in a > > very straightforward and predictable fashion). > > > > It doesn't need to run "an arbitrary piece of code". It just needs to > keep reissuing the instruction. And each time it issues it, the instruction starts by processing any interrupts that have become pending since the last time the instruction was issued.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-29 17:24 -0400 |
| Message-ID | <nq296g$bj8$1@jstuckle.eternal-september.org> |
| In reply to | #92905 |
On 8/29/2016 5:16 PM, supercat@casperkitty.com wrote: > On Monday, August 29, 2016 at 3:43:08 PM UTC-5, Jerry Stuckle wrote: >> If the instruction disables interrupts for 16 cycles, and it is issued >> every 15 cycles, by your definition the interrupts will never be >> processed. Otherwise the system wouldn't fulfill your "disabled for 16 >> cycles" requirement. > > Should I have been more explicit "disabled for 16 cycles, or sooner if > another instruction enables interrupts"? I would have thought the latter > was implied. > Make up your mind. But once again you change the rules in the middle of the game. >> It's one or the other. Either it waits 16 cycles or it doesn't. You >> can't have it both ways. > > Up to 16 cycles, or shorter if the code doesn't want/need the full 16. > See above. >>> Since one should not expect to be able to run an arbitrary piece of code >>> within a short 15-cycle window, there should be no concern about a >>> context which uses the instruction being nested within another context >>> that expects interrupts to be disabled continuously throughout it, since >>> whoever is writing the outer code should be aware of what's within it >>> (note that the construct would really only be useful from within assembly >>> code, or with a compiler mode that is documented as generating code in a >>> very straightforward and predictable fashion). >>> >> >> It doesn't need to run "an arbitrary piece of code". It just needs to >> keep reissuing the instruction. > > And each time it issues it, the instruction starts by processing any > interrupts that have become pending since the last time the instruction > was issued. > And a solution to a problem which doesn't exist. That's what semaphores are for. And *no one except the kernel* should be able to disable interrupts, even for a short period of time. Even with your "rules" it can have a detrimental performance on the system. From your updates, it's obvious you've never done any kernel programming in the past. It is an entirely different approach than application programming. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-30 13:21 +0200 |
| Message-ID | <nq3q84$d3s$1@dont-email.me> |
| In reply to | #92907 |
On 29/08/16 23:24, Jerry Stuckle wrote: > On 8/29/2016 5:16 PM, supercat@casperkitty.com wrote: >> On Monday, August 29, 2016 at 3:43:08 PM UTC-5, Jerry Stuckle wrote: >>> If the instruction disables interrupts for 16 cycles, and it is issued >>> every 15 cycles, by your definition the interrupts will never be >>> processed. Otherwise the system wouldn't fulfill your "disabled for 16 >>> cycles" requirement. >> >> Should I have been more explicit "disabled for 16 cycles, or sooner if >> another instruction enables interrupts"? I would have thought the latter >> was implied. >> > > Make up your mind. But once again you change the rules in the middle of > the game. > >>> It's one or the other. Either it waits 16 cycles or it doesn't. You >>> can't have it both ways. >> >> Up to 16 cycles, or shorter if the code doesn't want/need the full 16. >> > > See above. > >>>> Since one should not expect to be able to run an arbitrary piece of code >>>> within a short 15-cycle window, there should be no concern about a >>>> context which uses the instruction being nested within another context >>>> that expects interrupts to be disabled continuously throughout it, since >>>> whoever is writing the outer code should be aware of what's within it >>>> (note that the construct would really only be useful from within assembly >>>> code, or with a compiler mode that is documented as generating code in a >>>> very straightforward and predictable fashion). >>>> >>> >>> It doesn't need to run "an arbitrary piece of code". It just needs to >>> keep reissuing the instruction. >> >> And each time it issues it, the instruction starts by processing any >> interrupts that have become pending since the last time the instruction >> was issued. >> > > And a solution to a problem which doesn't exist. That's what semaphores > are for. > > And *no one except the kernel* should be able to disable interrupts, > even for a short period of time. Even with your "rules" it can have a > detrimental performance on the system. > > From your updates, it's obvious you've never done any kernel programming > in the past. It is an entirely different approach than application > programming. > Actually, I think Supercat's idea here would have a great deal of practical use, though it is primarily for single core systems (or as an aid to making more general SMP locks and semaphores). I have also thought for years that it would be a very useful type of instruction, especially for embedded systems (though I think 16 cycle disable is longer than necessary). As usual, Jerry, you don't understand what is being suggested, and therefore insult people rather than attempting to think or to communicate like a normal person. But let me try to re-phrase the idea, and see if you understand it. It is often important to be able to perform a sequence of operations in an atomic fashion. There are a variety of methods for doing this, such as building primitives for locking from instructions such "compare-and-swap" and "store-with-reservation", carefully ordered memory accesses, or even special hardware to support semaphores. All of these have disadvantages - there can be significant overhead, and perhaps trial-and-retry loops, which means that something as simple as an atomic double-word read or write takes many times longer than the non-atomic version. In single processor systems, the easiest and most efficient way to handle this is often to disable interrupts temporarily, then restore them after the atomic operation. This is a cornerstone of embedded programming, and on bigger systems (with a distinction between user modes and privileged modes) it is often used in the kernel-side implementation of the OS's locking mechanisms. But manually enabling and disabling interrupts can be error-prone. It can be difficult to ensure that the interrupt disabled time is minimised (to avoid extra latency for interrupt routines), and user-mode code generally cannot disable interrupts because the relevant instructions are privileged. So the suggestion is for an instruction that will temporarily disable interrupts for a given number of clock cycles or instruction counts, after which they will automatically be restored to the previous state. The hardware would guarantee that pending interrupts are run before a new temporary interrupt disable instruction is run, thus ensuring that interrupts can't be blocked for more than the maximum specified time. This would make atomic accesses and lock primitives very simple and efficient, and eliminate much of the overhead needed when these are handled from user-mode (at least in the common case when there is no conflict). For single cpu embedded systems, it would be a great feature. There would be complications, of course, such as how it would interact with non-maskable interrupts or faults. But such issues can be solved. For multi-cpu systems, it would be harder - ideally, the feature could be combined with locking of a small address range. A little more thought would be needed in order to ensure that this would be fair, and one process could not make a denial-of-service attack on another process (at least, not in a worse way than it can today by grabbing locks).
[toc] | [prev] | [next] | [standalone]
Page 11 of 18 — ← Prev page 1 … 9 10 [11] 12 13 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web