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 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-31 10:46 -0400 |
| Message-ID | <nq6qkg$nk4$1@jstuckle.eternal-september.org> |
| In reply to | #92982 |
On 8/31/2016 6:39 AM, David Brown wrote: > On 30/08/16 23:30, Jerry Stuckle wrote: >> On 8/30/2016 3:36 PM, David Brown wrote: >>> On 30/08/16 16:53, Jerry Stuckle wrote: >>>> On 8/30/2016 9:24 AM, David Brown wrote: >>>>> On 30/08/16 14:12, Jerry Stuckle wrote: >>>>>> On 8/30/2016 7:21 AM, David Brown wrote: > > <snip> > >>>>> But these mechanisms can quickly have much more overhead than a simple >>>>> "disable global interrupts, do the job, re-enable interrupt status". >>>>> For small job, such as atomically incrementing a counter, you could be >>>>> talking about hundreds of times larger overhead. >>>>> >>>> >>>> Not necessarily. Most systems have atomic operations for something like >>>> incrementing a counter. >>> >>> Most RISC processors do not have any sort of atomic operation for >>> incrementing a counter. Most CISC processors do (as long as the counter >>> is not too big). >>> >> >> But any one which has support for multiple threads has some kind of >> atomic operation. > > Yes, but in most cases (Alpha, PPC, MIPS, ARM - and probably many others > that I don't know) this is using a load-link or load-reserve and > conditional store mechanism. There is no atomic operation for counter > incrementing - they have no mechanism for a single read-modify-write > operation. Rather, you use the LL and SC instructions to make a > sequence of operations atomic. And since the final SC can fail, you > need a conditional loop. > Sure. And there's no atomic operation to clear a 10K buffer to zero, or to read input from a port, or millions of other things. Yet they can be done. What's so special about incrementing a counter? >> >>>> After all, similar operations are used to >>>> create mutexes. And even if not, mutexes locking and unlocking mutexes >>>> is a highly optimized operation in any OS I've seen - often as little as >>>> a half-dozen machine instructions or less, which can generally be >>>> implemented inline via a macro. >>> >>> A half-dozen instructions, often including a loop, is far more than a >>> single instruction. >>> >>> But again, there is a difference between bigger and smaller systems. >>> Small devices usually don't have operations optimised for mutexes, and >>> interrupt disabling is the normal way to do atomic operations. Bigger >>> devices usually have some way to get fast mutexes or other locks, >>> because you need a more sophisticated locking mechanism when dealing >>> with multiple cores. >>> >> >> If you are talking about small systems, then they only run the >> equivalent of kernel mode - no separation between kernel and user >> instructions. So it's quite easy to disable interrupts then re-enable >> them. Two instructions, typically. > > More than that if you want to support restoring interrupt status rather > than enabling interrupts, or if you want to handle multiple priority levels. > Disabling interrupts does not change their status. Neither does re-enabling interrupts. They just affect whether or not any maskable interrupt will be handled. For instance, in Intel chips, cli sets the interrupt flag to 0 in the FLAGS register, disabling all non-maskable interrupts. sti sets the flag to 1, re-enabling the interrupts. Priority levels come into play only when you are handling interrupts - a lower-level interrupt will have to wait for a higher-level interrupt to complete. >> >>>> >>>>> This is the way it is done on most small systems, and it often forms a >>>>> key part of higher-level synchronisation mechanisms. It can even be a >>>>> more efficient mechanism on processors with compare-and-swap or >>>>> load-store "reservation" instructions. >>>>> >>>> >>>> Yes, which is how mutexes are locked in such systems. It's pretty fast. >>>> >>>>>> >>>>>> And even then, it's not possible to disable all interrupts. Most >>>>>> processors have non-maskable interrupts, which cannot be disabled. >>>>>> These are important for things like a hardware interrupt. >>>>> >>>>> In most cases on small systems, you /can/ disable almost all interrupts. >>>>> Non-maskable interrupts are rarely used, except perhaps for extreme >>>>> situations (like power-fail interrupts). Bigger systems may be more >>>>> complicated, of course. >>>>> >>>> >>>> "Almost" is not "all". And they still have to be considered. Failure >>>> to do things like this is a common cause of design bugs. >>>> >>> >>> References? Samples? Examples? >>> >> >> Non-maskable interrupt can never be disabled. See documentation on >> Intel and other chips. > > No one said you could disable NMI's - the name "non-maskable" is a clue > here. What has been said is that NMI's are rarely used - you don't > disable them, you simply don't activate them. > They are heavily used in many systems, as I indicated before. And you would understand that if you actually worked on such systems. But it has become very obvious you haven't. >> >> And you have to know what the interrupt handler will do when it gets the >> interrupt. It may not just reboot the system, for instance. Back in >> the MS-DOS days, I had a debugger with a card that had a button on it. >> Pressing the button generated a NMI which normally would have rebooted >> the computer. But the code they put in brought up a system debugger >> instead. >> > > I am still waiting for references to justify why NMI's have to be > considered (rather than simply not used), and why failure to consider > them is a "common cause of design bugs". You might also like to explain > why they "are important for things like a hardware interrupt" when > hardware interrupts almost invariably use /maskable/ interrupts. > Because NMIs can come in at any time, and many systems use them for critical (non-error) situations, as I indicated above. > <snip> > >>>> >>>>>> >>>>>> No, it's a bad idea, and not required. If the hardware manufacturers >>>>>> thought it was a good idea, someone would have implemented it by now. >>>>>> The fact no one has indicates they see the potential problems much >>>>>> better than you do, and understand it's a problem that already has good >>>>>> solutions. >>>>>> >>>>> >>>>> I agree it is not a required feature - after all, we got on fine without >>>>> it. And there would be complications in implementing it in hardware, it >>>>> would not scale to multi-core systems, and it would be less useful and >>>>> more complicated with superscaler processors. But for smaller systems >>>>> and simpler microcontrollers, it would definitely be a useful feature. >>>>> Whether or not it would be cost-effective (no feature is free) is >>>>> another matter. >>>>> >>>> >>>> I just see too many downsides to this and no real upside - other than >>>> not wanting to ensure you've enabled interrupts after disabling them. >>>> >>>> But then I almost never disable interrupts, even in kernel code (and >>>> never in application code). It's just so rarely necessary. If you find >>>> you are doing so regularly, you need to be looking at why. >>>> >>> >>> You don't do the same sort of programming as me - just because an idea >>> does not seem useful to /you/, does not mean it is not useful to others. >>> >> >> I wouldn't say that. I have worked on some pretty small chips - ones >> that can't even be programmed in C - you have to use assembler. >> >> And I still don't see a reason for the idea, when there are already good >> ways to do it. >> >> And obviously the chip manufacturers agree, because *none* of them have >> implemented it. If someone thought it was a good idea, it would be part >> of their instruction set. > > As I have said, I don't know if it is worth the effort implementing such > a feature - it would be nice to have, but it is certainly not essential. > Chip designers make their decisions based on design costs (instruction > code space, and the effort needed to get it right), implementation costs > (die space, power usage, etc.), and potential usage. People making > wish-lists of features they would like have different criteria - "nice > to have" weighs very highly. > Obviously it is not. But chips internally run microcode. Implementing a new instruction generally does not take up additional die space, power, etc. - or if it does, very little. Rather, it's a matter of adding some microcode to the chip. Not simple, but a one-time cost. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-31 10:03 -0700 |
| Message-ID | <575ceb3e-c03f-4217-8a3a-b0a4014e029b@googlegroups.com> |
| In reply to | #92990 |
On Wednesday, August 31, 2016 at 9:46:54 AM UTC-5, Jerry Stuckle wrote: > Disabling interrupts does not change their status. Neither does > re-enabling interrupts. They just affect whether or not any maskable > interrupt will be handled. Perhaps I should have said "disabling interrupts during an operation in such a fashion that if interrupts had been disabled beforehand they will remain disabled, but if they were enabled beforehand they will be re-enabled afterward." On x86 that could be handled by doing a "pushf / cli" before the guarded region and "popf" afterward. I'm not sure whether those instructions are still as much of a bottleneck as they used to be in the 80286 and 80386 era, but having interrupts only be enabled on exit if they had been enabled on entry is much cleaner than saying that they will get unconditionally enabled regardless.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-31 22:52 -0400 |
| Message-ID | <nq854h$39c$1@jstuckle.eternal-september.org> |
| In reply to | #92997 |
On 8/31/2016 1:03 PM, supercat@casperkitty.com wrote: > On Wednesday, August 31, 2016 at 9:46:54 AM UTC-5, Jerry Stuckle wrote: >> Disabling interrupts does not change their status. Neither does >> re-enabling interrupts. They just affect whether or not any maskable >> interrupt will be handled. > > Perhaps I should have said "disabling interrupts during an operation in such > a fashion that if interrupts had been disabled beforehand they will remain > disabled, but if they were enabled beforehand they will be re-enabled > afterward." On x86 that could be handled by doing a "pushf / cli" before > the guarded region and "popf" afterward. I'm not sure whether those > instructions are still as much of a bottleneck as they used to be in the > 80286 and 80386 era, but having interrupts only be enabled on exit if they > had been enabled on entry is much cleaner than saying that they will get > unconditionally enabled regardless. > Actually, the correct instructions would be cli and sti. You would not want to do a popf and change other flags which may be important in the current execution. But they never were a "bottleneck in the 80286 and 80386 era". IF (and that's a BIG IF) you need to disable interrupts, you will be in kernel mode, and need to re-enable them ASAP. You don't just disable on entry and enable on exit. And you don't have a choice - you either disable/enable interrupts, or you don't. It applies to ALL maskable interrupts. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-01 07:41 -0700 |
| Message-ID | <371fd96c-eb18-44d1-a19f-ca0e25e4901f@googlegroups.com> |
| In reply to | #93037 |
On Wednesday, August 31, 2016 at 9:52:08 PM UTC-5, Jerry Stuckle wrote: > Actually, the correct instructions would be cli and sti. You would not > want to do a popf and change other flags which may be important in the > current execution. But they never were a "bottleneck in the 80286 and > 80386 era". If a function uses "sti" rather than doing a "pushf" before the "cli" and a "popf" (or other means of restoring the I flag) after running, then the function cannot be safely nested in any context where interrupts had been disabled.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-01 14:58 -0400 |
| Message-ID | <nq9toc$imi$1@jstuckle.eternal-september.org> |
| In reply to | #93054 |
On 9/1/2016 10:41 AM, supercat@casperkitty.com wrote: > On Wednesday, August 31, 2016 at 9:52:08 PM UTC-5, Jerry Stuckle wrote: >> Actually, the correct instructions would be cli and sti. You would not >> want to do a popf and change other flags which may be important in the >> current execution. But they never were a "bottleneck in the 80286 and >> 80386 era". > > If a function uses "sti" rather than doing a "pushf" before the "cli" and > a "popf" (or other means of restoring the I flag) after running, then the > function cannot be safely nested in any context where interrupts had been > disabled. > Wrong again. You're in a routine where you want to disable interrupts. pushf/popf does not affect anything other than the routine you are in - and in this case, it changes the results of the other flags in the register. You need to do pushf/popf when you are in an interrupt routine to ensure you don't change the registers for the interrupted thread. However, in the case you are describing, you do NOT want to do so. For instance: mov EAX,1 cli ; disable interrupts cmp EAX,FLAG_LOC ; set a flag based on the comparison sti jnz NOMATCH Using popf instead of sti would cause the code to fail. And things like this are very common. You're just showing you don't know how it actually works - you are just getting a bit of knowledge from google searches. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-31 02:27 -0700 |
| Message-ID | <3316781d-9291-42ea-9fe1-62630b53230a@googlegroups.com> |
| In reply to | #92959 |
On Tuesday, August 30, 2016 at 10:36:42 PM UTC+3, David Brown wrote: > > > A half-dozen instructions, often including a loop, is far more than a > single instruction. > > But again, there is a difference between bigger and smaller systems. > Small devices usually don't have operations optimised for mutexes, and > interrupt disabling is the normal way to do atomic operations. Bigger > devices usually have some way to get fast mutexes or other locks, > because you need a more sophisticated locking mechanism when dealing > with multiple cores. > Somehow, you were tricked into defending the wrong case. The idea of supercat (after serious polishing in details) is attractive for application mode programming on medium-size systems with clear separation between privileged and non-privileged code segments, but without SMP/SMT and without demand paging. The idea is not really attractive for billions of really small systems that run everything in context of maximal privilege, because on such systems simple enabling/disabling of interrupts is just fine. Unfortunately for supercat's proposal, he is late by 25-30 years. Nowadays those middle-ground systems are disappearing rather quickly.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-31 08:21 -0700 |
| Message-ID | <68ceaa51-7c55-4bc6-a472-f7456ebd0ee1@googlegroups.com> |
| In reply to | #92981 |
On Wednesday, August 31, 2016 at 4:27:50 AM UTC-5, already...@yahoo.com wrote: > On Tuesday, August 30, 2016 at 10:36:42 PM UTC+3, David Brown wrote: > > > > > > A half-dozen instructions, often including a loop, is far more than a > > single instruction. > > > > But again, there is a difference between bigger and smaller systems. > > Small devices usually don't have operations optimised for mutexes, and > > interrupt disabling is the normal way to do atomic operations. Bigger > > devices usually have some way to get fast mutexes or other locks, > > because you need a more sophisticated locking mechanism when dealing > > with multiple cores. > > > > Somehow, you were tricked into defending the wrong case. > The idea of supercat (after serious polishing in details) is attractive for application mode programming on medium-size systems with clear separation between privileged and non-privileged code segments, but without SMP/SMT and without demand paging. The idea is not really attractive for billions of really small systems that run everything in context of maximal privilege, because on such systems simple enabling/disabling of interrupts is just fine. > > Unfortunately for supercat's proposal, he is late by 25-30 years. Nowadays those middle-ground systems are disappearing rather quickly. I probably had the idea about 20 years ago, and it would have had more usefulness then vs. now. On the other hand, I believe there are still many cases where performance wins could be achieved by being able to order that all threads associated with certain tasks behave as though done on the same CPU. If there are enough different tasks to keep all cores busy, such a behavioral requirement should not cost much in performance, but would allow many expensive memory-synchronization operations to be avoided.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-31 09:05 -0700 |
| Message-ID | <74d248a2-a4ac-44b3-bb31-94fffc354036@googlegroups.com> |
| In reply to | #92991 |
On Wednesday, August 31, 2016 at 11:21:38 AM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, August 31, 2016 at 4:27:50 AM UTC-5, already...@yahoo.com wrote:
> > On Tuesday, August 30, 2016 at 10:36:42 PM UTC+3, David Brown wrote:
> > >
> > >
> > > A half-dozen instructions, often including a loop, is far more than a
> > > single instruction.
> > >
> > > But again, there is a difference between bigger and smaller systems.
> > > Small devices usually don't have operations optimised for mutexes, and
> > > interrupt disabling is the normal way to do atomic operations. Bigger
> > > devices usually have some way to get fast mutexes or other locks,
> > > because you need a more sophisticated locking mechanism when dealing
> > > with multiple cores.
> > >
> >
> > Somehow, you were tricked into defending the wrong case.
> > The idea of supercat (after serious polishing in details) is attractive for application mode programming on medium-size systems with clear separation between privileged and non-privileged code segments, but without SMP/SMT and without demand paging. The idea is not really attractive for billions of really small systems that run everything in context of maximal privilege, because on such systems simple enabling/disabling of interrupts is just fine.
> >
> > Unfortunately for supercat's proposal, he is late by 25-30 years. Nowadays those middle-ground systems are disappearing rather quickly.
>
> I probably had the idea about 20 years ago, and it would have had more
> usefulness then vs. now. On the other hand, I believe there are still many
> cases where performance wins could be achieved by being able to order that
> all threads associated with certain tasks behave as though done on the same
> CPU. If there are enough different tasks to keep all cores busy, such a
> behavioral requirement should not cost much in performance, but would allow
> many expensive memory-synchronization operations to be avoided.
What's needed is a fundamental protocol which allows every CPU in a multi-
CPU system to send an instruction stream to a designated "top level" or
"main" CPU (one so-designated in its design), such that the fringe CPUs
can issue the command and wait for the go-ahead signal back to indicate
the atomic thing was done. In this way, it is not just a locking mechanism,
but something which always guarantees atomicity as you can define checks
and tests in the number of machine instructions to run, thereby validating
that it's not already involved in something which would currently prevent
it.
I'll go ahead and add this to LibSF 386-x40. It's a good idea, and it
goes along with my "Love Threading" model of each thread being willing
to self-sacrifice its own workload to help out another thread that has
a request of its hardware resources:
https://groups.google.com/forum/#!topic/comp.arch/__PFd1_HBLA
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-31 09:15 -0700 |
| Message-ID | <86a4254a-8cf8-4baa-956e-72a86fe80318@googlegroups.com> |
| In reply to | #92993 |
On Wednesday, August 31, 2016 at 12:06:03 PM UTC-4, Rick C. Hodgin wrote:
> What's needed is a fundamental protocol which allows every CPU in a multi-
> CPU system to send an instruction stream to a designated "top level" or
> "main" CPU (one so-designated in its design), such that the fringe CPUs
> can issue the command and wait for the go-ahead signal back to indicate
> the atomic thing was done. In this way, it is not just a locking mechanism,
> but something which always guarantees atomicity as you can define checks
> and tests in the number of machine instructions to run, thereby validating
> that it's not already involved in something which would currently prevent
> it.
>
> I'll go ahead and add this to LibSF 386-x40. It's a good idea, and it
> goes along with my "Love Threading" model of each thread being willing
> to self-sacrifice its own workload to help out another thread that has
> a request of its hardware resources:
>
> https://groups.google.com/forum/#!topic/comp.arch/__PFd1_HBLA
To be clear, what I'm talking about is an internal protocol at the ISA
level that executes a block of code on the remote CPU when requested:
; Issue synchronize ASM instruction:
synchronize offset continue
; Assembly code goes here to run on remote CPU
; When the synchronizing CPU gets to the address of the
; continue: label below, it sends back the go-ahead signal
continue:
; The local CPU goes to this address and waits for the go-ahead
; signal to return from the synchronizing CPU.
In this way, a designated CPU within the system (CPU-0) could become
the synchronizing CPU designed for this purpose, able to do regular
work, but the one which always conducts the synchronizing workloads
in the case of multi-CPU synchronization. Special segment registers
will overlay FS and GS in these cases, allowing immediate access to
special synchronization blocks setup by the OS in two separate selectors
which are then updated globally, and quickly.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2016-09-02 22:22 +0200 |
| Message-ID | <6cnjsb9pf48p4bsmhpj98aeqpqamqqpltu@4ax.com> |
| In reply to | #92993 |
On Wed, 31 Aug 2016 09:05:28 -0700 (PDT), "Rick C. Hodgin" wrote: >What's needed is a fundamental protocol which allows every CPU in a multi- >CPU system to send an instruction stream to a designated "top level" or >"main" CPU (one so-designated in its design), such that the fringe CPUs >can issue the command and wait for the go-ahead signal back to indicate >the atomic thing was done. In this way, it is not just a locking mechanism, >but something which always guarantees atomicity as you can define checks >and tests in the number of machine instructions to run, thereby validating >that it's not already involved in something which would currently prevent >it. > >I'll go ahead and add this to LibSF 386-x40. It's a good idea, and it >goes along with my "Love Threading" model of each thread being willing >to self-sacrifice its own workload to help out another thread that has >a request of its hardware resources: i'm nobody i see instead many cpus that make their own run thread with nothing to do in 99% of time with the oter cpus in the 1% of time it is need they comunicate result to the other cpu... so in that 1% of time it is need comunicate to some other cpu it is like one want to factor a big number using ecm each cpu has the tread for try one separate set of curve for factor the number [separate calculation 99.9999% of the time] if some cpu find the solution says that to the cpu has call his tread...[comunication 0.0001% of time]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-28 08:41 +1200 |
| Message-ID | <e2ec8aFa03jU10@mid.individual.net> |
| In reply to | #92815 |
On 08/28/16 08:10 AM, supercat@casperkitty.com wrote:
>
> 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--;
> }
Why would you resort to such a scheme when there are standard (or
obvious target specific) tools for the job?
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-27 20:34 -0400 |
| Message-ID | <nptbio$trl$2@jstuckle.eternal-september.org> |
| In reply to | #92820 |
On 8/27/2016 4:41 PM, Ian Collins wrote:
> On 08/28/16 08:10 AM, supercat@casperkitty.com wrote:
>>
>> 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--;
>> }
>
> Why would you resort to such a scheme when there are standard (or
> obvious target specific) tools for the job?
>
Do you REALLY have to ask?
--
==================
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:41 -0700 |
| Message-ID | <894db1c6-77ed-4e91-ae16-0b9649ecded8@googlegroups.com> |
| In reply to | #92820 |
On Saturday, August 27, 2016 at 3:41:57 PM UTC-5, Ian Collins wrote:
> On 08/28/16 08:10 AM, supercat wrote:
> >
> > 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--;
> > }
>
> Why would you resort to such a scheme when there are standard (or
> obvious target specific) tools for the job?
What do you mean? Are you talking about the libraries supplied by chip
vendors? Even when such libraries are reasonably efficient and well-
designed, they may not be tailored to a project's exact needs [for
simplicity, my example omitted things an ISR might do on the fly, such as
bit stuffing, header generation, concatenation of data from multiple buffers,
etc.]. Further, using a chip vendor's library will often make it hard to
migrate code to another vendor's chip should the need arise.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-30 08:07 +1200 |
| Message-ID | <e2jj0aFa03jU11@mid.individual.net> |
| In reply to | #92877 |
On 08/30/16 04:41 AM, supercat@casperkitty.com wrote:
> On Saturday, August 27, 2016 at 3:41:57 PM UTC-5, Ian Collins wrote:
>> On 08/28/16 08:10 AM, supercat wrote:
>>>
>>> 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--;
>>> }
>>
>> Why would you resort to such a scheme when there are standard (or
>> obvious target specific) tools for the job?
>
> What do you mean?
Atomics and synchroniszation primitives.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 14:08 -0700 |
| Message-ID | <33405851-bacc-48af-badb-dfaca7f7c314@googlegroups.com> |
| In reply to | #92894 |
On Monday, August 29, 2016 at 3:07:49 PM UTC-5, Ian Collins wrote: > Atomics and synchroniszation primitives. And what kinds of primitives are available in a "bare-metal" freestanding C implementation? Many of the C implementations I use give the programmer explicit control over the reset vector and all interrupt vectors; from the compiler's point of view, an interrupt is a piece of code that might be executed at any time for reasons it knows nothing about. What kinds of primitives would you expect them to provide, and how would you suggest that I should go about using them?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-29 15:41 -0700 |
| Message-ID | <nq2dmj$rl8$1@dont-email.me> |
| In reply to | #92903 |
On 8/29/2016 2:08 PM, supercat@casperkitty.com wrote: > On Monday, August 29, 2016 at 3:07:49 PM UTC-5, Ian Collins wrote: >> Atomics and synchroniszation primitives. > > And what kinds of primitives are available in a "bare-metal" freestanding C > implementation? You have to check the docs out on that implementation. :^) > Many of the C implementations I use give the programmer > explicit control over the reset vector and all interrupt vectors; from the > compiler's point of view, an interrupt is a piece of code that might be > executed at any time for reasons it knows nothing about. What kinds of > primitives would you expect them to provide, and how would you suggest that > I should go about using them? You can always create a little set of primitives in assembly.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 16:30 -0700 |
| Message-ID | <c7d874b8-568e-47a6-a597-dc125d291f55@googlegroups.com> |
| In reply to | #92911 |
On Monday, August 29, 2016 at 5:41:32 PM UTC-5, Chris M. Thomasson wrote: > On 8/29/2016 2:08 PM, supercat wrote: > > Many of the C implementations I use give the programmer > > explicit control over the reset vector and all interrupt vectors; from the > > compiler's point of view, an interrupt is a piece of code that might be > > executed at any time for reasons it knows nothing about. What kinds of > > primitives would you expect them to provide, and how would you suggest that > > I should go about using them? > > You can always create a little set of primitives in assembly. I do have some sets of primitives I've created in assembly for things like compare-and-store, atomic-increment, and atomic mask-and-set (i.e. x^=(x & mask) ^ value;. I don't use such primitives for things like a simple assignment to a variable.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-29 17:14 -0700 |
| Message-ID | <nq2j5t$8do$2@dont-email.me> |
| In reply to | #92914 |
On 8/29/2016 4:30 PM, supercat@casperkitty.com wrote: > On Monday, August 29, 2016 at 5:41:32 PM UTC-5, Chris M. Thomasson wrote: >> On 8/29/2016 2:08 PM, supercat wrote: >>> Many of the C implementations I use give the programmer >>> explicit control over the reset vector and all interrupt vectors; from the >>> compiler's point of view, an interrupt is a piece of code that might be >>> executed at any time for reasons it knows nothing about. What kinds of >>> primitives would you expect them to provide, and how would you suggest that >>> I should go about using them? >> >> You can always create a little set of primitives in assembly. > > I do have some sets of primitives I've created in assembly for things like > compare-and-store, atomic-increment, and atomic mask-and-set (i.e. > x^=(x & mask) ^ value;. I don't use such primitives for things like a > simple assignment to a variable. what about atomic load and store?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-29 17:20 -0700 |
| Message-ID | <nq2jg5$9dh$1@dont-email.me> |
| In reply to | #92914 |
On 8/29/2016 4:30 PM, supercat@casperkitty.com wrote: > On Monday, August 29, 2016 at 5:41:32 PM UTC-5, Chris M. Thomasson wrote: >> On 8/29/2016 2:08 PM, supercat wrote: >>> Many of the C implementations I use give the programmer >>> explicit control over the reset vector and all interrupt vectors; from the >>> compiler's point of view, an interrupt is a piece of code that might be >>> executed at any time for reasons it knows nothing about. What kinds of >>> primitives would you expect them to provide, and how would you suggest that >>> I should go about using them? >> >> You can always create a little set of primitives in assembly. > > I do have some sets of primitives I've created in assembly for things like > compare-and-store, atomic-increment, and atomic mask-and-set (i.e. > x^=(x & mask) ^ value;. I don't use such primitives for things like a > simple assignment to a variable. > Perhaps this might be of interest to you: https://groups.google.com/forum/#!msg/comp.programming.threads/KepRbFWBJA4/pg83oJTzPUIJ ;^)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 23:37 -0700 |
| Message-ID | <eaf947bd-4199-4b01-8092-29b0215b0e51@googlegroups.com> |
| In reply to | #92917 |
On Monday, August 29, 2016 at 7:20:30 PM UTC-5, Chris M. Thomasson wrote: > Perhaps this might be of interest to you: > https://groups.google.com/forum/#!msg/comp.programming.threads/KepRbFWBJA4/pg83oJTzPUIJ Ad hoc solutions work fine if people recognize the value of recognizing precedent, and of establishing an orderly process for deprecating bad precedents *by providing a migration path to something that's essentially as good in all important respects*. That's what happened with e.g. <varargs.h> being replaced by <stdarg.h>, or old-style function declarations being replaced by prototype syntax. Unfortunately, since many key precedents that were responsible for C's popularity were never acknowledged, there was never any procedure for deprecating them nor for defining any replacement.
[toc] | [prev] | [next] | [standalone]
Page 13 of 18 — ← Prev page 1 … 11 12 [13] 14 15 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web