Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #379646 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2023-12-26 16:59 +0100 |
| Last post | 2024-01-08 22:20 -0800 |
| Articles | 20 on this page of 671 — 31 participants |
Back to article view | Back to comp.lang.c
Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-26 16:59 +0100
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-26 17:45 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-26 22:50 +0000
Re: Effect of CPP tags Spiros Bousbouras <spibou@gmail.com> - 2023-12-27 17:11 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 14:45 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-28 17:34 +0100
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-28 14:11 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 13:13 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:47 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 15:12 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-20 14:29 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 04:46 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 10:56 -0500
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 12:11 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 17:55 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:57 -0500
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-24 07:42 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-31 12:43 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:41 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-02-01 09:19 +0100
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:11 -0700
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 23:56 -0700
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:12 -0700
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 17:38 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:33 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:42 +0000
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-28 18:04 -0500
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 16:11 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 16:04 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:51 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:22 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 15:52 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 17:27 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 11:01 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 22:18 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-31 14:40 +0100
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-12-31 12:43 -0500
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 12:57 +0100
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 18:32 -0800
usleep (Was: Effect of CPP tags) gazelle@shell.xmission.com (Kenny McCormack) - 2023-12-29 18:10 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-29 02:35 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-29 13:31 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-29 15:58 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 10:33 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 20:23 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-29 22:40 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 01:28 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-30 01:58 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 01:36 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 02:06 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:33 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 13:09 +0100
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-03 00:20 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 12:49 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 09:11 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 21:41 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-31 16:25 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 15:45 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:40 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 18:44 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 19:37 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 22:00 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 16:03 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 02:58 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 19:18 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-01 05:38 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 22:56 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 08:54 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 20:00 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 15:38 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 21:44 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 13:51 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 00:12 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:57 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 07:00 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:03 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:06 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 09:18 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 15:44 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 15:54 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 11:42 +0100
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:04 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 16:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 18:34 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 20:24 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 13:00 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 13:02 -0800
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-03 00:24 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 02:41 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-03 03:29 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 11:55 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-03 15:32 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 17:14 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 20:16 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-03 19:57 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 09:46 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-04 18:57 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 23:48 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 01:57 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 02:20 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 16:08 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 18:35 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-04 20:55 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 20:17 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 15:22 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-05 10:03 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 18:37 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 19:25 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 21:14 +0000
Re: Effect of CPP tags Jim Jackson <jj@franjam.org.uk> - 2024-01-04 22:07 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 22:48 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-04 23:14 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 23:48 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-04 23:25 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 01:53 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-05 04:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-05 15:05 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 07:58 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-05 17:34 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 18:42 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 08:39 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 19:15 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:21 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 10:06 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 16:29 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 18:44 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 19:33 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 20:06 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 14:50 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 01:09 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 17:55 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-07 01:00 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:56 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 10:02 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 22:19 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 22:43 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 02:04 +0000
Re: Effect of CPP tags Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-05 23:02 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 01:45 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 18:17 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 10:09 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 10:27 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 15:23 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 13:40 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 00:09 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:16 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 16:40 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:58 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-07 03:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-07 15:48 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 15:34 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 13:50 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 15:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 20:50 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 01:05 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 08:30 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 11:11 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 15:56 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 17:46 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 19:56 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 20:52 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 13:15 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 21:33 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-09 21:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 22:22 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 09:37 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 12:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 14:17 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 14:31 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 16:51 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 18:57 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:55 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 20:49 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 11:26 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:19 -0800
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-11 00:30 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 01:14 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:25 -0800
Re: Effect of CPP tags Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-11 17:56 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 18:31 +0000
Make (was: Re: Effect of CPP tags) vallor <vallor@cultnix.org> - 2024-01-15 21:01 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 02:29 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-10 17:46 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 14:51 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 17:58 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 19:16 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:30 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:27 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 14:22 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 17:37 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 23:27 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 16:05 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 00:40 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 16:49 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 02:04 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 19:17 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:26 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-10 11:22 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 01:54 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-10 02:57 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 05:28 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-10 06:28 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 09:50 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-09 23:40 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:10 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:10 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:11 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 11:55 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 11:42 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 14:59 -0800
Re: Effect of CPP tags vallor <vallor@cultnix.org> - 2024-01-11 14:58 +0000
A good place to discuss Makefiles? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-11 16:56 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 02:00 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 02:14 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:16 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 14:49 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 18:13 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 10:39 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 19:24 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 11:39 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:42 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 20:20 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 12:42 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 21:43 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 22:36 +0000
Re: Effect of CPP tags Paul <nospam@needed.invalid> - 2024-01-10 21:39 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 02:46 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 11:44 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 12:19 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 16:13 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-11 17:00 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 21:18 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-11 23:03 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 23:58 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 09:08 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 18:49 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 12:16 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 22:02 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 23:20 +0000
Re: Effect of CPP tags Anthony Cuozzo <anthony@cuozzo.us> - 2024-01-11 19:02 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 16:23 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 14:40 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 16:01 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 16:28 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:16 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 20:21 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 16:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 17:34 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 17:09 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:02 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 21:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 13:07 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 21:51 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 00:13 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 16:47 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 01:12 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 17:40 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-13 15:07 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-13 16:02 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:17 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 12:03 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-13 13:42 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 22:39 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-14 00:02 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 14:33 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-13 15:26 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 00:36 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-14 16:20 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:19 +0100
Makefile as an implementation instance of a transformation process (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-15 15:46 +0100
Re: Makefile as an implementation instance of a transformation process (was Re: Effect of CPP tags) Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-15 15:41 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:54 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 18:17 +0000
Re: Effect of CPP tags Anthony Cuozzo <anthony@cuozzo.us> - 2024-01-14 13:44 -0500
Re: Effect of CPP tags Jim Jackson <jj@franjam.org.uk> - 2024-01-14 19:16 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 19:57 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 13:14 -0800
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 09:51 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 11:39 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:57 +0100
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:40 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:41 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 18:41 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 19:12 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 19:32 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 20:12 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 23:28 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 00:04 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 18:23 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:22 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 21:16 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 15:24 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:45 +0100
Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 06:01 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 11:44 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 12:21 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 14:10 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 19:35 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:48 +0100
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:42 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 14:56 +0000
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:43 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:10 +0100
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-15 11:22 -0500
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:22 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 01:02 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 06:54 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 14:08 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 01:13 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 12:57 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 12:45 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-15 14:11 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 19:44 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 20:09 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 21:06 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 12:41 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:40 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:06 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 16:50 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:43 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 17:59 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:10 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 18:53 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 19:18 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 20:16 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:18 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:15 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 12:59 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 04:36 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:01 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:05 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:08 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:31 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 07:13 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 19:15 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 20:14 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:12 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:46 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:52 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:57 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 21:39 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:22 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 18:10 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 13:11 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-14 14:58 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 01:05 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 20:44 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 20:39 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-14 21:47 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 22:37 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 14:20 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:21 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 00:52 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 12:09 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:16 +0000
Re: Effect of CPP tags Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-12 23:04 +0000
Re: Effect of CPP tags Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-12 23:30 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-13 00:16 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 11:16 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 18:47 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 19:42 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 22:18 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 23:48 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-17 16:23 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 00:25 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 00:47 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 04:30 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 10:26 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 19:40 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 20:21 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 11:07 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 11:17 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 12:41 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 13:18 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 15:42 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 15:03 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 18:12 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 18:28 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 18:43 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 19:48 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-19 17:32 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 17:05 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 19:50 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 14:18 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 14:14 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 16:18 +0000
Re: Effect of CPP tags dave_thompson_2@comcast.net - 2024-02-26 04:17 -0500
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-02-26 15:56 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 15:16 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-18 21:47 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 23:46 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 23:29 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:23 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-21 00:40 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 12:42 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 21:31 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:04 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 12:18 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 00:34 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 02:14 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 07:07 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 23:36 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 07:40 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 17:04 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 17:29 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:27 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 23:24 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 18:18 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:38 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 16:55 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 17:08 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 02:21 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:34 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 18:35 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 03:03 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 19:59 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 13:28 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-17 12:55 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:24 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 20:02 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 11:54 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:42 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-16 15:08 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:54 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:57 +0000
CPU's MAC instructions (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 06:25 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 18:52 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 14:15 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 14:35 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 15:44 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:35 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 18:55 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 19:19 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:31 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 01:21 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 11:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 15:06 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 17:04 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 13:43 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-17 13:00 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-18 13:00 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:28 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:58 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:55 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 22:02 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:55 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 18:39 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 00:11 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:11 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:42 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:44 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:28 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 16:39 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 16:23 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 21:25 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 20:41 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 15:08 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 16:02 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 19:03 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 18:45 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 23:00 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 22:10 +0000
Re: Effect of CPP tags Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-16 22:18 +0000
NO vs. SE (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 07:11 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 14:17 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:33 +0000
Re: NO vs. SE (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 18:47 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 18:04 +0000
Re: NO vs. SE (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 19:15 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) om@iki.fi (Otto J. Makela) - 2024-01-18 17:22 +0200
Re: NO vs. SE (was Re: Effect of CPP tags) Phil Carmody <pc+usenet@asdf.org> - 2024-03-24 14:24 +0200
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 12:26 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:29 +0100
Interpreter Dispatch in C (was: Effect of CPP Tags) bart <bc@freeuk.com> - 2024-01-16 19:21 +0000
Re: Interpreter Dispatch in C David Brown <david.brown@hesbynett.no> - 2024-01-16 23:24 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 15:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 18:46 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 22:42 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 14:25 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 14:51 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 19:07 +0100
Optimization and inline assembly (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 07:07 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 18:58 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 19:01 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 09:52 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 09:41 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:20 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 13:24 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 13:45 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 14:55 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-11 12:27 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:04 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 16:24 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:36 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:43 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:36 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 20:05 -0500
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:54 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 01:32 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:45 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:33 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:48 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:49 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 22:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:23 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 19:23 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:46 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 08:21 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 19:20 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 20:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 13:12 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 21:37 +0000
Re: Effect of CPP tags Ike Naar <ike@sdf.org> - 2024-01-09 21:51 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 16:42 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 12:04 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 18:12 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 12:11 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 21:51 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 01:50 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:28 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-09 07:38 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-07 02:12 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:45 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:47 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 02:16 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 17:15 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 02:25 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 19:28 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 15:26 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 15:51 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 01:32 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 20:35 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 13:28 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:25 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 18:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 19:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 11:22 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 11:21 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 16:00 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 18:02 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:39 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 21:36 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:32 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 21:41 +0100
Re: Effect of CPP tags Ike Naar <ike@sdf.org> - 2024-01-08 08:53 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 09:59 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 12:53 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 14:11 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 15:28 +0100
Re: Effect of CPP tags Richard Damon <richard@damon-family.org> - 2024-01-06 09:56 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 15:57 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-06 23:58 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-06 23:45 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 00:21 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:26 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 02:14 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 12:14 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 19:29 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 22:41 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 23:27 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 15:43 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-07 03:32 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 11:37 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 14:41 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 22:54 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 16:06 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 15:54 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 16:23 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 09:55 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 12:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 15:29 +0100
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-06 05:33 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 17:41 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 21:32 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 15:13 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-03 13:42 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 12:46 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 12:37 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 12:51 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 18:21 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 10:43 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 17:39 -0500
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 12:33 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 10:36 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 21:59 +0100
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 16:38 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-02 20:23 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:35 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-02 20:54 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 20:28 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:45 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 23:08 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 18:16 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:05 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 21:45 +0000
Re: Effect of CPP tags Richard Damon <richard@damon-family.org> - 2023-12-29 11:58 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:44 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 10:54 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 20:19 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-12-30 06:51 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 16:16 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 23:21 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 19:14 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 01:34 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 02:18 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 23:46 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 15:26 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 17:26 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 19:23 +0000
Re: Effect of CPP tags Richard Damon <news.x.richarddamon@xoxy.net> - 2023-12-31 14:46 -0500
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-31 15:49 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 23:46 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 01:33 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 02:00 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 11:56 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-01 13:06 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 20:13 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-01 20:20 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 02:34 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:39 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:38 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 22:51 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 23:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 23:45 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 00:05 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 01:14 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 01:58 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 20:41 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 22:21 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 06:23 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 06:47 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 12:24 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:04 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 20:11 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 20:43 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 23:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 02:08 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 02:40 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 12:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 13:03 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 19:14 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-03 15:33 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-03 08:37 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:54 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 20:05 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-01 15:45 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 20:06 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 04:48 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:00 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:40 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:49 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 00:06 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 16:29 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 16:38 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:01 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:37 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-31 16:59 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 20:12 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 16:07 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 16:36 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 18:31 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 19:08 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 12:36 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-01 05:56 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:59 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:20 -0800
Page 21 of 34 — ← Prev page 1 … 19 20 [21] 22 23 … 34 Next page →
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-15 00:34 +0000 |
| Message-ID | <20240114115640.506@kylheku.com> |
| In reply to | #380136 |
On 2024-01-14, bart <bc@freeuk.com> wrote: > On 12/01/2024 21:31, Kaz Kylheku wrote: >> On 2024-01-12, bart <bc@freeuk.com> wrote: > >>> I mainly remember the times when they do hang. >> >> DOS/Windows stuff hangs also: >> >> C:\Users\kazk>findstr foo >> ... "hang" ... >> >> Even Microsoft clued in to the idea that a text filter shouldn't >> spew extraneous diagnostics by default. > > If you type 'findstr' with no arguments, it reports an error. Maybe > 'sort' was a better example to make your point. So does grep with no arguments? I don't see where that is going. > >>> But with 'as', it just sits there. I wonder what it's waiting for; for >>> me to type in ASM code live from the terminal? (If 'as' is designed for >>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember >>> it generating discrete, temporary .s files.) >> >> gcc -pipe works in pipe mode. >> >> The "as" command is intended for compiler use; not only is it not >> an interactive assembler, it doesn't even have particularly good >> diagnostics for batch use. You have to know what you're doing. > > You're sort of making excuses for it. I'm just stating what I have always believed the requirements to be. In Unixes and the GNU Project, there has not been a focus on assembly language as a primary development language, with a great developer experience. That's pretty much a fact. The amount of material written in .s or .S files is very small. > My 'aa' assembler was also > designed mainly for machine-generated code, so it has very few frills. > > The syntax however is decent enough that I can use it for my inline > assembler too. GCC has great inline assembly. You can reference C expressions, which are evaluated to registers that the register allocator chooses, which you can reference in your inline code in a symbolic way. You can also indicate that your code template has certain effects, so that the compiler is informed. I had a nice experience many years ago when I wrapped the MIPS "load-linked/store-conditional" primitives as separate inline code macros. When I used these macros to write a synchronization primitive, GCC optimized away an unnecessary instruction or two, due to the way they integrated together. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-15 02:14 +0000 |
| Message-ID | <uo24di$lo8r$1@dont-email.me> |
| In reply to | #380157 |
On 15/01/2024 00:34, Kaz Kylheku wrote:
> On 2024-01-14, bart <bc@freeuk.com> wrote:
>> On 12/01/2024 21:31, Kaz Kylheku wrote:
>>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>
>>>> I mainly remember the times when they do hang.
>>>
>>> DOS/Windows stuff hangs also:
>>>
>>> C:\Users\kazk>findstr foo
>>> ... "hang" ...
>>>
>>> Even Microsoft clued in to the idea that a text filter shouldn't
>>> spew extraneous diagnostics by default.
>>
>> If you type 'findstr' with no arguments, it reports an error. Maybe
>> 'sort' was a better example to make your point.
>
> So does grep with no arguments? I don't see where that is going.
This is about typing some command and it is apparently doing nothing, no
indication whether it's busy, has crashed, is stuck in a loop, or is
waiting for YOU to do something.
I didn't know grep was on Windows, but if I type 'grep' with no params,
it gives a usage message, so no complaints there.
> In Unixes and the GNU Project, there has not been a focus on assembly
> language as a primary development language, with a great developer
> experience.
>
> That's pretty much a fact.
That is extraordinary. Wasn't C first implemented in assembly? It's
always been a mainstay of computing as far as I can remember. Except no
one now write whole apps in assembly. (I've done quite a few in the past.)
Plenty though implement compilers that generate ASM source /in a file/
and they expect to feed that to an assembler. Most generate object files
from that.
>
> The amount of material written in .s or .S files is very small.
>
>> My 'aa' assembler was also
>> designed mainly for machine-generated code, so it has very few frills.
>>
>> The syntax however is decent enough that I can use it for my inline
>> assembler too.
>
> GCC has great inline assembly.
> You can reference C expressions, which
> are evaluated to registers that the register allocator chooses, which
> you can reference in your inline code in a symbolic way.
GCC inline assembly looks absolutely diabolic. I take it you've never
seen it done properly?
Actually I spent 5-10 minutes looking for examples, to try and figure
out if asm instructions could in fact directly refer to symbols in the HLL.
But most examples were one or two lines of weird syntax, following by
some interfacing code. So I don't know.
If /I/ had to write extensive programs in gcc inline assembly, then put
a gun to my head now!
Take this example in C:
int a;
void F(void) {
int b=2, c=3;
static int d=4;
a = b + c * d;
}
I will now show it in my language but with that assignment replaced by
inline assembly:
int a
proc F=
int b:=2, c:=3
static int d=4
assem
mov rax, [c] # (note my ints are 64 bits)
imul2 rax, [d]
add rax, [b]
mov [a], rax
end
end
My question is: what would the C version look like with that line in gcc
inline assembly? (In both cases, 'a' should end up with the value 14.)
You need to tell me, because I will otherwise not have a clue. From what
I've seen of gcc inline asm:
* Code has to be written within string literals, in dreadfil AT&T
syntax. And apparently even with embedded \n line breaks. (Good
grief - I think early 80s BASICs had more sophisticated facilities!)
* You mostly use offsets to get at local variables
* You apparently aren't allowed to use just any registers as you need
to negotiate with gcc so as not to interfere with /its/ use of
registers. So most examples I saw seemed to deal with this.
I consider that when writing assembly, YOU are in charge not the
compiler. As you can see from mine:
* It is written just as it would be in an actual ASM file
* You can refer to variables directly (the compiler will add what is
needed to access locals or statics)
If a function uses inline ASM, variables are kept in memory not
registers. (I might allow that at some point.) Most such functions
however contain only ASM.
That still lets ASM use the facilities of the HLL such as functions,
declarations, named constants, scopes etc.
I suppose you're going to suggest that gcc's facilities are superior...
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-15 07:07 +0000 |
| Message-ID | <20240114222417.720@kylheku.com> |
| In reply to | #380160 |
On 2024-01-15, bart <bc@freeuk.com> wrote:
> On 15/01/2024 00:34, Kaz Kylheku wrote:
>> In Unixes and the GNU Project, there has not been a focus on assembly
>> language as a primary development language, with a great developer
>> experience.
>>
>> That's pretty much a fact.
>
> That is extraordinary. Wasn't C first implemented in assembly? It's
No; C would have been implemented in NB (new B). It was B that was
implemented in assembly. That's just bootstrapping, though.
Thompson and Ritchie didn't have a nice assembler; IIRC, they started
out by assembling code using macros in the TECO editor.
Assembly language has never been emphasized in Unix, to my best
knowledge. It's there.
> always been a mainstay of computing as far as I can remember. Except no
> one now write whole apps in assembly. (I've done quite a few in the past.)
I did a bunch of assembly language programming, which was with
"nice" assemblers. At university, I made a linked list library with
numerous functions on a Sun 3 (68K) using Sun's "as". That was my
first encounter with Unix's idea of assembly. I got it done, but it
was pretty horrible, with next to no diagnostics when there was
something wrong. It was obvious that the tool assumes correct input,
coming from a compiler.
>>> My 'aa' assembler was also
>>> designed mainly for machine-generated code, so it has very few frills.
>>>
>>> The syntax however is decent enough that I can use it for my inline
>>> assembler too.
>>
>> GCC has great inline assembly.
>
>> You can reference C expressions, which
>> are evaluated to registers that the register allocator chooses, which
>> you can reference in your inline code in a symbolic way.
>
> GCC inline assembly looks absolutely diabolic. I take it you've never
> seen it done properly?
>
> Actually I spent 5-10 minutes looking for examples, to try and figure
> out if asm instructions could in fact directly refer to symbols in the HLL.
>
> But most examples were one or two lines of weird syntax, following by
> some interfacing code. So I don't know.
>
> If /I/ had to write extensive programs in gcc inline assembly, then put
> a gun to my head now!
>
> Take this example in C:
>
> int a;
>
> void F(void) {
> int b=2, c=3;
> static int d=4;
>
> a = b + c * d;
> }
>
> I will now show it in my language but with that assignment replaced by
> inline assembly:
>
> int a
>
> proc F=
> int b:=2, c:=3
> static int d=4
>
> assem
> mov rax, [c] # (note my ints are 64 bits)
> imul2 rax, [d]
> add rax, [b]
> mov [a], rax
> end
Problem is that the compiler's register allocator now has to be informed that
the assembly language part is using rax and work around it.
> end
>
> My question is: what would the C version look like with that line in gcc
> inline assembly? (In both cases, 'a' should end up with the value 14.)
Let's make it more interesting: what if b and c come from arguments,
and the static int d actually has state that changes between
invocations, so it can't be optimized away. Let's return the
result, a:
int F(int b, int c)
{
static int d=4;
int a;
d++;
asm("imul %3, %2\n\t"
"add %2, %1\n\t"
"mov %1, %0\n\t"
: "=r" (a)
: "r" (b), "r" (c), "r" (d));
return a;
}
It's pretty arcane in that the material is both in string literals,
and not. The assembly language template is textual; the compiler knows
nothing about its interior.
I specified one output operand, and three input operands, requesting
that they be in registers. I don't specify the register identities.
They are referenced by number: %0, %1, %2, %3 in the order they
appear. (A way to use named references exists.)
We don't have to code the data transfers between the registers
and the C operands they are connected to; that is done for us
by the compiler.
So, okay, unoptimized that looks like:
$ gcc -c inline.c
$ objdump -d inline.o
inline.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <F>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 89 7d ec mov %edi,-0x14(%rbp)
7: 89 75 e8 mov %esi,-0x18(%rbp)
a: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 10 <F+0x10>
10: 83 c0 01 add $0x1,%eax
13: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 19 <F+0x19>
19: 8b 0d 00 00 00 00 mov 0x0(%rip),%ecx # 1f <F+0x1f>
1f: 8b 45 ec mov -0x14(%rbp),%eax
22: 8b 55 e8 mov -0x18(%rbp),%edx
25: 0f af d1 imul %ecx,%edx
28: 01 d0 add %edx,%eax
2a: 89 c0 mov %eax,%eax
2c: 89 45 fc mov %eax,-0x4(%rbp)
2f: 8b 45 fc mov -0x4(%rbp),%eax
32: c9 leaveq
33: c3 retq
Optimized:
$ gcc -O2 -c inline.c
$ objdump -d inline.o
inline.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <F>:
0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 <F+0x6>
6: 83 c0 01 add $0x1,%eax
9: 89 05 00 00 00 00 mov %eax,0x0(%rip) # f <F+0xf>
f: 0f af f0 imul %eax,%esi
12: 01 f7 add %esi,%edi
14: 89 f8 mov %edi,%eax
16: c3 retq
The static variable is accessed relative to the instruction pointer.
The offset is all zeros: that will be patched when this is linked.
Note that between the unoptimized and optimized code, the register
identities changed entirely.
GCC's inline assembly feature is largely agnostic of the assembler
back end. It interfaces with register allocation and such, but is
otherwise generic. This allows it to have exactly the same grammar,
no matter the architecture target.
The syntax isn't particularly nice, but it has power.
> You need to tell me, because I will otherwise not have a clue. From what
> I've seen of gcc inline asm:
>
> * Code has to be written within string literals, in dreadfil AT&T
> syntax. And apparently even with embedded \n line breaks. (Good
> grief - I think early 80s BASICs had more sophisticated facilities!)
The code template, after the registers like %0 and %1 are substituted
into it, is just shoved into the assembly language output verbatim.
The compiler doesn't analyze the interior.
AT&T syntax is used if that's what the assembler requires.
Not all GCC targets have assemblers in whose language the destination operand
is on the right; it's that way for the x86 family though.
>
> * You mostly use offsets to get at local variables
Nope; it's pretty much transparent.
> * You apparently aren't allowed to use just any registers as you need
> to negotiate with gcc so as not to interfere with /its/ use of
> registers. So most examples I saw seemed to deal with this.
This is pretty awesome.
> I consider that when writing assembly, YOU are in charge not the
> compiler.
If you're writing *inline* assembly in compiled code, if you let
the compiler be in charge of some things, it's a lot better.
If specific registers are required, that can be arranged. Sometimes that
happens: some instruction sets have certain instructions that only work with
certain registers, as you know.
If you're not working with instructions like that, it's beneficial if
the compiler allocates them for you. That nicely integrates into the
register allocation.
> As you can see from mine:
>
> * It is written just as it would be in an actual ASM file
It is nice for editing and all, and you were cranking out hundreds
of lines of assembly, or even dozens, you'd want that.
But mainly the code exists to do a job, not to be admired.
> * You can refer to variables directly (the compiler will add what is
> needed to access locals or statics)
>
> If a function uses inline ASM, variables are kept in memory not
> registers. (I might allow that at some point.) Most such functions
> however contain only ASM.
As you can see, this is not a limitation in the GNU inline assembly.
The optimized code did away with memory references, except for the
static int d.
GNU inline assembly is ugly, but it's very well designed semantically;
it hits the target.
When you have to do something in assembly language, it is fluid;
you don't have to contend with an overly ridid instruction template that
interferes with surrounding optimization.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-14 23:36 -0800 |
| Message-ID | <uo2n9l$rh9q$1@dont-email.me> |
| In reply to | #380167 |
On 1/14/2024 11:07 PM, Kaz Kylheku wrote: > On 2024-01-15, bart <bc@freeuk.com> wrote: >> On 15/01/2024 00:34, Kaz Kylheku wrote: [...] > GNU inline assembly is ugly, but it's very well designed semantically; > it hits the target. I did not like it very much, made my eyes want to bleed. Iirc, Microsoft got rid of inline assembly for 64-bit targets, cannot remember when. > > When you have to do something in assembly language, it is fluid; > you don't have to contend with an overly ridid instruction template that > interferes with surrounding optimization.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-15 07:40 +0000 |
| Message-ID | <20240114231905.155@kylheku.com> |
| In reply to | #380167 |
On 2024-01-15, Kaz Kylheku <433-929-6894@kylheku.com> wrote:
> On 2024-01-15, bart <bc@freeuk.com> wrote:
>> On 15/01/2024 00:34, Kaz Kylheku wrote:
>>> In Unixes and the GNU Project, there has not been a focus on assembly
>>> language as a primary development language, with a great developer
>>> experience.
>>>
>>> That's pretty much a fact.
>>
>> That is extraordinary. Wasn't C first implemented in assembly? It's
>
> No; C would have been implemented in NB (new B). It was B that was
> implemented in assembly. That's just bootstrapping, though.
>
> Thompson and Ritchie didn't have a nice assembler; IIRC, they started
> out by assembling code using macros in the TECO editor.
>
> Assembly language has never been emphasized in Unix, to my best
> knowledge. It's there.
>
>> always been a mainstay of computing as far as I can remember. Except no
>> one now write whole apps in assembly. (I've done quite a few in the past.)
>
> I did a bunch of assembly language programming, which was with
> "nice" assemblers. At university, I made a linked list library with
> numerous functions on a Sun 3 (68K) using Sun's "as". That was my
> first encounter with Unix's idea of assembly. I got it done, but it
> was pretty horrible, with next to no diagnostics when there was
> something wrong. It was obvious that the tool assumes correct input,
> coming from a compiler.
>
>>>> My 'aa' assembler was also
>>>> designed mainly for machine-generated code, so it has very few frills.
>>>>
>>>> The syntax however is decent enough that I can use it for my inline
>>>> assembler too.
>>>
>>> GCC has great inline assembly.
>>
>>> You can reference C expressions, which
>>> are evaluated to registers that the register allocator chooses, which
>>> you can reference in your inline code in a symbolic way.
>>
>> GCC inline assembly looks absolutely diabolic. I take it you've never
>> seen it done properly?
>>
>> Actually I spent 5-10 minutes looking for examples, to try and figure
>> out if asm instructions could in fact directly refer to symbols in the HLL.
>>
>> But most examples were one or two lines of weird syntax, following by
>> some interfacing code. So I don't know.
>>
>> If /I/ had to write extensive programs in gcc inline assembly, then put
>> a gun to my head now!
>>
>> Take this example in C:
>>
>> int a;
>>
>> void F(void) {
>> int b=2, c=3;
>> static int d=4;
>>
>> a = b + c * d;
>> }
>>
>> I will now show it in my language but with that assignment replaced by
>> inline assembly:
>>
>> int a
>>
>> proc F=
>> int b:=2, c:=3
>> static int d=4
>>
>> assem
>> mov rax, [c] # (note my ints are 64 bits)
>> imul2 rax, [d]
>> add rax, [b]
>> mov [a], rax
>> end
>
> Problem is that the compiler's register allocator now has to be informed that
> the assembly language part is using rax and work around it.
>
>> end
>>
>> My question is: what would the C version look like with that line in gcc
>> inline assembly? (In both cases, 'a' should end up with the value 14.)
>
> Let's make it more interesting: what if b and c come from arguments,
> and the static int d actually has state that changes between
> invocations, so it can't be optimized away. Let's return the
> result, a:
>
> int F(int b, int c)
> {
> static int d=4;
> int a;
>
> d++;
>
> asm("imul %3, %2\n\t"
> "add %2, %1\n\t"
> "mov %1, %0\n\t"
> : "=r" (a)
> : "r" (b), "r" (c), "r" (d));
>
> return a;
> }
We can also turn this multiply and add into a stand-alone primitive
that we can put behind a macro:
#define mul_add(x, y, z) \
({ int _res; \
asm("imul %3, %2\n\t" \
"add %2, %1\n\t" \
"mov %1, %0\n\t" \
: "=r" (_res) \
: "r" (x), "r" (y), "r" (z)); \
_res; })
Which we then freely use like this:
int F(int b, int c)
{
static int d=4;
int a;
d++;
a = mul_add(b, c, d);
return a;
}
Complex example:
int G(int a, int b, int c, int d, int e, int f, int g, int h, int i)
{
return mul_add(mul_add(a, b, c),
mul_add(d, mul_add(e, f, g), h),
i);
}
gcc -O2 code:
0000000000000020 <G>:
20: 0f af f2 imul %edx,%esi
23: 01 f7 add %esi,%edi
25: 89 ff mov %edi,%edi
27: 8b 44 24 08 mov 0x8(%rsp),%eax
2b: 8b 54 24 10 mov 0x10(%rsp),%edx
2f: 44 0f af c8 imul %eax,%r9d
33: 45 01 c8 add %r9d,%r8d
36: 44 89 c0 mov %r8d,%eax
39: 0f af c2 imul %edx,%eax
3c: 01 c1 add %eax,%ecx
3e: 89 c9 mov %ecx,%ecx
40: 8b 44 24 18 mov 0x18(%rsp),%eax
44: 0f af c8 imul %eax,%ecx
47: 01 cf add %ecx,%edi
49: 89 f8 mov %edi,%eax
4b: c3 retq
GCC inline assembly is good if you have certain instructions that the compiler
doesn't use, and you'd like to use them as first class primitives (meaning that
they are not disadvantaged compared to primitives the compiler knows about).
We would likely obtain better code if if we unbundled the multiplication
and addition by writing separate mul and add primitives.
Because the code above has to follow the rigid template where imul
is immediately followed by the related add, after which there is
a mandatory mov.
We really want:
#define mul_add(x, y, z) add(x, mul(y, z))
where we separately write the add and mul as inline assembly fragments.
A mul_add primitive might make sense if the processor had such a thing
in one instruction.
With GCC inline assembly, you want to only put the essentials into it:
only do what is necessary and only bundle together what must be
bundled.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-15 17:04 +0100 |
| Message-ID | <uo3l28$1010j$1@dont-email.me> |
| In reply to | #380169 |
On 15/01/2024 08:40, Kaz Kylheku wrote:
> On 2024-01-15, Kaz Kylheku <433-929-6894@kylheku.com> wrote:
>> On 2024-01-15, bart <bc@freeuk.com> wrote:
>>> On 15/01/2024 00:34, Kaz Kylheku wrote:
>>>> In Unixes and the GNU Project, there has not been a focus on assembly
>>>> language as a primary development language, with a great developer
>>>> experience.
>>>>
>>>> That's pretty much a fact.
>>>
>>> That is extraordinary. Wasn't C first implemented in assembly? It's
>>
>> No; C would have been implemented in NB (new B). It was B that was
>> implemented in assembly. That's just bootstrapping, though.
>>
>> Thompson and Ritchie didn't have a nice assembler; IIRC, they started
>> out by assembling code using macros in the TECO editor.
>>
>> Assembly language has never been emphasized in Unix, to my best
>> knowledge. It's there.
>>
>>> always been a mainstay of computing as far as I can remember. Except no
>>> one now write whole apps in assembly. (I've done quite a few in the past.)
>>
>> I did a bunch of assembly language programming, which was with
>> "nice" assemblers. At university, I made a linked list library with
>> numerous functions on a Sun 3 (68K) using Sun's "as". That was my
>> first encounter with Unix's idea of assembly. I got it done, but it
>> was pretty horrible, with next to no diagnostics when there was
>> something wrong. It was obvious that the tool assumes correct input,
>> coming from a compiler.
>>
>>>>> My 'aa' assembler was also
>>>>> designed mainly for machine-generated code, so it has very few frills.
>>>>>
>>>>> The syntax however is decent enough that I can use it for my inline
>>>>> assembler too.
>>>>
>>>> GCC has great inline assembly.
>>>
>>>> You can reference C expressions, which
>>>> are evaluated to registers that the register allocator chooses, which
>>>> you can reference in your inline code in a symbolic way.
>>>
>>> GCC inline assembly looks absolutely diabolic. I take it you've never
>>> seen it done properly?
>>>
>>> Actually I spent 5-10 minutes looking for examples, to try and figure
>>> out if asm instructions could in fact directly refer to symbols in the HLL.
>>>
>>> But most examples were one or two lines of weird syntax, following by
>>> some interfacing code. So I don't know.
>>>
>>> If /I/ had to write extensive programs in gcc inline assembly, then put
>>> a gun to my head now!
>>>
>>> Take this example in C:
>>>
>>> int a;
>>>
>>> void F(void) {
>>> int b=2, c=3;
>>> static int d=4;
>>>
>>> a = b + c * d;
>>> }
>>>
>>> I will now show it in my language but with that assignment replaced by
>>> inline assembly:
>>>
>>> int a
>>>
>>> proc F=
>>> int b:=2, c:=3
>>> static int d=4
>>>
>>> assem
>>> mov rax, [c] # (note my ints are 64 bits)
>>> imul2 rax, [d]
>>> add rax, [b]
>>> mov [a], rax
>>> end
>>
>> Problem is that the compiler's register allocator now has to be informed that
>> the assembly language part is using rax and work around it.
>>
>>> end
>>>
>>> My question is: what would the C version look like with that line in gcc
>>> inline assembly? (In both cases, 'a' should end up with the value 14.)
>>
>> Let's make it more interesting: what if b and c come from arguments,
>> and the static int d actually has state that changes between
>> invocations, so it can't be optimized away. Let's return the
>> result, a:
>>
>> int F(int b, int c)
>> {
>> static int d=4;
>> int a;
>>
>> d++;
>>
>> asm("imul %3, %2\n\t"
>> "add %2, %1\n\t"
>> "mov %1, %0\n\t"
>> : "=r" (a)
>> : "r" (b), "r" (c), "r" (d));
>>
>> return a;
>> }
>
> We can also turn this multiply and add into a stand-alone primitive
> that we can put behind a macro:
>
> #define mul_add(x, y, z) \
> ({ int _res; \
> asm("imul %3, %2\n\t" \
> "add %2, %1\n\t" \
> "mov %1, %0\n\t" \
> : "=r" (_res) \
> : "r" (x), "r" (y), "r" (z)); \
> _res; })
static inline int mul_add(int x, int y, int z) {
asm("imul %[z], %[y]\n\t"
"add %[z], %[x]"
: [z] "+r" (z) : [y] "g" (y), [x] "g" (x));
return z;
}
>
> Which we then freely use like this:
>
> int F(int b, int c)
> {
> static int d=4;
> int a;
>
> d++;
>
> a = mul_add(b, c, d);
>
> return a;
> }
>
Yes.
>
> Complex example:
>
> int G(int a, int b, int c, int d, int e, int f, int g, int h, int i)
> {
> return mul_add(mul_add(a, b, c),
> mul_add(d, mul_add(e, f, g), h),
> i);
> }
>
> gcc -O2 code:
>
> 0000000000000020 <G>:
> 20: 0f af f2 imul %edx,%esi
> 23: 01 f7 add %esi,%edi
> 25: 89 ff mov %edi,%edi
> 27: 8b 44 24 08 mov 0x8(%rsp),%eax
> 2b: 8b 54 24 10 mov 0x10(%rsp),%edx
> 2f: 44 0f af c8 imul %eax,%r9d
> 33: 45 01 c8 add %r9d,%r8d
> 36: 44 89 c0 mov %r8d,%eax
> 39: 0f af c2 imul %edx,%eax
> 3c: 01 c1 add %eax,%ecx
> 3e: 89 c9 mov %ecx,%ecx
> 40: 8b 44 24 18 mov 0x18(%rsp),%eax
> 44: 0f af c8 imul %eax,%ecx
> 47: 01 cf add %ecx,%edi
> 49: 89 f8 mov %edi,%eax
> 4b: c3 retq
>
> GCC inline assembly is good if you have certain instructions that the compiler
> doesn't use, and you'd like to use them as first class primitives (meaning that
> they are not disadvantaged compared to primitives the compiler knows about).
>
> We would likely obtain better code if if we unbundled the multiplication
> and addition by writing separate mul and add primitives.
>
> Because the code above has to follow the rigid template where imul
> is immediately followed by the related add, after which there is
> a mandatory mov.
>
> We really want:
>
> #define mul_add(x, y, z) add(x, mul(y, z))
>
> where we separately write the add and mul as inline assembly fragments.
static inline int mul(int x, int y) {
asm("imul %[x], %[y]"
: [x] "+r" (x) : [y] "g" (y));
return x;
}
static inline int add(int x, int y) {
asm("add %[x], %[y]"
: [x] "+r" (x) : [y] "g" (y));
return x;
}
static inline int mul_add(int x, int y, int z) {
return add(x, mul(y, z));
}
Now compiling G gives (with Intel syntax - because some people cry
louder than others!) :
G:
mov eax, edi
imul r9d, DWORD PTR [rsp+8]
imul esi, edx
add r8d, r9d
add eax, esi
imul r8d, DWORD PTR [rsp+16]
add ecx, r8d
imul ecx, DWORD PTR [rsp+24]
add eax, ecx
ret
Notice how gcc can now re-arrange the adds and multiplies for greater
efficiency, and skip redundant moves and unnecessary register loads.
This is almost as optimal as if we define:
static inline int mul_add(int x, int y, int z) {
return x + y * z;
}
The only difference is that the for the inline assembly, the compiler
can't take advantage of what it knows about being able to ignore the
upper half of the 64-bit registers when doing this 32-bit arithmetic.
>
> A mul_add primitive might make sense if the processor had such a thing
> in one instruction.
>
> With GCC inline assembly, you want to only put the essentials into it:
> only do what is necessary and only bundle together what must be
> bundled.
>
Yes. For inline assembly, simple is not really important, but small is
beautiful! Say exactly what you mean, no more and no less, and let the
compiler do what it does best.
And move to C++20. Then you can write (for the mythical madd instruction) :
constexpr int mul_add(int x, int y, int z)
__attribute__((const))
{
if (std::is_constant_evaluated()) {
return x + y * z;
} else {
asm("madd %[x], %[y], %[z]"
: [x] "+r" (x) : [y] "g" (y), [z] "g" (z));
return x;
}
}
Now the compiler can evaluate at compile time if the parameters are
known, or using the super-efficient madd instruction at runtime if
necessary.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-15 17:29 +0100 |
| Message-ID | <uo3mhi$1073t$1@dont-email.me> |
| In reply to | #380188 |
On 15/01/2024 17:04, David Brown wrote:
> On 15/01/2024 08:40, Kaz Kylheku wrote:
>> A mul_add primitive might make sense if the processor had such a thing
>> in one instruction.
>>
>> With GCC inline assembly, you want to only put the essentials into it:
>> only do what is necessary and only bundle together what must be
>> bundled.
>>
>
> Yes. For inline assembly, simple is not really important, but small is
> beautiful! Say exactly what you mean, no more and no less, and let the
> compiler do what it does best.
>
>
> And move to C++20. Then you can write (for the mythical madd
> instruction) :
>
> constexpr int mul_add(int x, int y, int z)
> __attribute__((const))
> {
> if (std::is_constant_evaluated()) {
> return x + y * z;
> } else {
> asm("madd %[x], %[y], %[z]"
> : [x] "+r" (x) : [y] "g" (y), [z] "g" (z));
> return x;
> }
> }
>
>
> Now the compiler can evaluate at compile time if the parameters are
> known, or using the super-efficient madd instruction at runtime if
> necessary.
>
Apologies for replying to my own post, but of course this can be done in
C with gcc extensions (and when we have inline assembly, we are already
relying on gcc extensions):
static inline int mul_add(int x, int y, int z)
__attribute__((const))
{
if (__builtin_constant_p(x + y * z)) {
return x + y * z;
} else {
asm("madd %[x], %[y], %[z]"
: [x] "+r" (x) : [y] "g" (y), [z] "g" (z));
return x;
}
}
This is, in fact, even better than the C++20 version since it will
optimise to compile-time computation if the result can be calculated at
compile time, even if all the parameters are not "constant expressions".
This code will be optimised to "return 0;" :-)
int F4(int y, int z) {
return mul_add(y * z, -y, z);
}
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-15 12:27 -0800 |
| Message-ID | <uo44fg$12ct8$2@dont-email.me> |
| In reply to | #380190 |
On 1/15/2024 8:29 AM, David Brown wrote: > On 15/01/2024 17:04, David Brown wrote: >> On 15/01/2024 08:40, Kaz Kylheku wrote: > >>> A mul_add primitive might make sense if the processor had such a thing >>> in one instruction. >>> >>> With GCC inline assembly, you want to only put the essentials into it: >>> only do what is necessary and only bundle together what must be >>> bundled. >>> >> >> Yes. For inline assembly, simple is not really important, but small >> is beautiful! Say exactly what you mean, no more and no less, and let >> the compiler do what it does best. [...] Wrt inline GCC assembly, remember __volatile__ and memory? ;^)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-15 23:24 +0000 |
| Message-ID | <20240115152033.334@kylheku.com> |
| In reply to | #380206 |
On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 1/15/2024 8:29 AM, David Brown wrote: >> On 15/01/2024 17:04, David Brown wrote: >>> On 15/01/2024 08:40, Kaz Kylheku wrote: >> >>>> A mul_add primitive might make sense if the processor had such a thing >>>> in one instruction. >>>> >>>> With GCC inline assembly, you want to only put the essentials into it: >>>> only do what is necessary and only bundle together what must be >>>> bundled. >>>> >>> >>> Yes. For inline assembly, simple is not really important, but small >>> is beautiful! Say exactly what you mean, no more and no less, and let >>> the compiler do what it does best. > [...] > > Wrt inline GCC assembly, remember __volatile__ and memory? ;^) The volatile is only important if you're writing sync primitives, so the compiler won't move loads or stores to one side or the other of the inline assembly. If you're just doing some calculation, it's counterproductive to tell the compiler not to move the code. "memory" is only needed if your inline code clobbers memory. E.g. one of the operands is a pointer, and the code writes through it. That location isn't one of the output operands. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-15 18:18 -0800 |
| Message-ID | <uo4p1q$15bb0$1@dont-email.me> |
| In reply to | #380217 |
On 1/15/2024 3:24 PM, Kaz Kylheku wrote: > On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 1/15/2024 8:29 AM, David Brown wrote: >>> On 15/01/2024 17:04, David Brown wrote: >>>> On 15/01/2024 08:40, Kaz Kylheku wrote: >>> >>>>> A mul_add primitive might make sense if the processor had such a thing >>>>> in one instruction. >>>>> >>>>> With GCC inline assembly, you want to only put the essentials into it: >>>>> only do what is necessary and only bundle together what must be >>>>> bundled. >>>>> >>>> >>>> Yes. For inline assembly, simple is not really important, but small >>>> is beautiful! Say exactly what you mean, no more and no less, and let >>>> the compiler do what it does best. >> [...] >> >> Wrt inline GCC assembly, remember __volatile__ and memory? ;^) > > The volatile is only important if you're writing sync primitives, so the > compiler won't move loads or stores to one side or the other of the > inline assembly. If you're just doing some calculation, it's > counterproductive to tell the compiler not to move the code. > > "memory" is only needed if your inline code clobbers memory. E.g. > one of the operands is a pointer, and the code writes through it. > That location isn't one of the output operands. > I want my sync primitive code to be _un_abused by any "clever" optimizations. I want it is as it is. No rouge compiler thinking that link-time optimizations are all fun and joy, lets dance around the sync instructions... Step on them, ruin them, make them incorrect. Even GCC had a nasty error with an optimization wrt Pthread pthread_mutex_trylock(). Simply ruined is correctness wrt the standard. Some sarcastic comic relief: A setting for all compilers, -ct_stay_away_from_my_asm_pretty_please Would that make some programmers laugh out loud? lol. ;^)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 14:38 +0100 |
| Message-ID | <uo60su$1f9o7$1@dont-email.me> |
| In reply to | #380224 |
On 16/01/2024 03:18, Chris M. Thomasson wrote: > On 1/15/2024 3:24 PM, Kaz Kylheku wrote: >> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 1/15/2024 8:29 AM, David Brown wrote: >>>> On 15/01/2024 17:04, David Brown wrote: >>>>> On 15/01/2024 08:40, Kaz Kylheku wrote: >>>> >>>>>> A mul_add primitive might make sense if the processor had such a >>>>>> thing >>>>>> in one instruction. >>>>>> >>>>>> With GCC inline assembly, you want to only put the essentials into >>>>>> it: >>>>>> only do what is necessary and only bundle together what must be >>>>>> bundled. >>>>>> >>>>> >>>>> Yes. For inline assembly, simple is not really important, but small >>>>> is beautiful! Say exactly what you mean, no more and no less, and let >>>>> the compiler do what it does best. >>> [...] >>> >>> Wrt inline GCC assembly, remember __volatile__ and memory? ;^) >> >> The volatile is only important if you're writing sync primitives, so the >> compiler won't move loads or stores to one side or the other of the >> inline assembly. That is not what "volatile" means - either in normal C code, or for gcc inline assembly! >> If you're just doing some calculation, it's >> counterproductive to tell the compiler not to move the code. >> >> "memory" is only needed if your inline code clobbers memory. E.g. >> one of the operands is a pointer, and the code writes through it. >> That location isn't one of the output operands. >> > > I want my sync primitive code to be _un_abused by any "clever" > optimizations. I want it is as it is. What a strange idea! I want the compiler to be clever and optimise code. But I want to tell the compiler enough about my inline assembly so that it can optimise appropriately. For synchronisation inline assembly, a "memory" clobber is often required - but usually it is not enough on its own (you need memory barrier assembly instructions too). And for lots of other uses of inline assembly, you don't want memory clobbers as they can be costly - sometimes very wasteful. "volatile" on inline assembly tells the compiler that the code may use or cause side-effects other than just what it is told by the inputs, outputs and clobbers. It will enforce an ordering with respect to other volatile inline assembly, and other C volatile accesses - but it will not be ordered with respect to other calculations, non-volatile inline assembly, or non-volatile loads and stores. You might think that using "volatile" and a "memory" clobber stops any re-ordering of code in relation to your inline assembly, but you'd be wrong. And if you think that, then perhaps an external assembly file is the easiest way to get the guarantees you want. > No rouge compiler thinking that > link-time optimizations are all fun and joy, lets dance around the sync > instructions... Step on them, ruin them, make them incorrect. Even GCC > had a nasty error with an optimization wrt Pthread > pthread_mutex_trylock(). Simply ruined is correctness wrt the standard. > You've mentioned this many times - do you have a reference that gives the source of this function (at the time when there was an issue), and a description or report of what you think gcc did wrong? I am curious as to whether it was a bug in the code or a bug in gcc (gcc is certainly not bug-free).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-16 16:55 -0800 |
| Message-ID | <uo78ik$1lvso$1@dont-email.me> |
| In reply to | #380238 |
On 1/16/2024 5:38 AM, David Brown wrote: > On 16/01/2024 03:18, Chris M. Thomasson wrote: >> On 1/15/2024 3:24 PM, Kaz Kylheku wrote: >>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 1/15/2024 8:29 AM, David Brown wrote: >>>>> On 15/01/2024 17:04, David Brown wrote: >>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote: [...] >> No rouge compiler thinking that link-time optimizations are all fun >> and joy, lets dance around the sync instructions... Step on them, ruin >> them, make them incorrect. Even GCC had a nasty error with an >> optimization wrt Pthread pthread_mutex_trylock(). Simply ruined is >> correctness wrt the standard. >> > > You've mentioned this many times - do you have a reference that gives > the source of this function (at the time when there was an issue), and a > description or report of what you think gcc did wrong? I am curious as > to whether it was a bug in the code or a bug in gcc (gcc is certainly > not bug-free). It was a bug in GCC itself. It was posted over on comp.programming.threads. Just of the top of my head, it was from a smart guy by the name of David Schwartz... I probably butchered his last name wrt spelling! I just need to find it again. Argh. I created my own externally assembled sync primitives because, well, I wanted to try to make sure no compiler can mess around with them. One little mistake and is does not work at all.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-16 17:08 -0800 |
| Message-ID | <uo79at$1lvso$3@dont-email.me> |
| In reply to | #380238 |
On 1/16/2024 5:38 AM, David Brown wrote: > On 16/01/2024 03:18, Chris M. Thomasson wrote: >> On 1/15/2024 3:24 PM, Kaz Kylheku wrote: >>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 1/15/2024 8:29 AM, David Brown wrote: >>>>> On 15/01/2024 17:04, David Brown wrote: >>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote: [...] > You've mentioned this many times - do you have a reference that gives > the source of this function (at the time when there was an issue), and a > description or report of what you think gcc did wrong? I am curious as > to whether it was a bug in the code or a bug in gcc (gcc is certainly > not bug-free). > I think I found it David! https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-17 02:21 +0000 |
| Message-ID | <20240116172414.760@kylheku.com> |
| In reply to | #380293 |
On 2024-01-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 1/16/2024 5:38 AM, David Brown wrote: >> On 16/01/2024 03:18, Chris M. Thomasson wrote: >>> On 1/15/2024 3:24 PM, Kaz Kylheku wrote: >>>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> On 1/15/2024 8:29 AM, David Brown wrote: >>>>>> On 15/01/2024 17:04, David Brown wrote: >>>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote: > [...] >> You've mentioned this many times - do you have a reference that gives >> the source of this function (at the time when there was an issue), and a >> description or report of what you think gcc did wrong? I am curious as >> to whether it was a bug in the code or a bug in gcc (gcc is certainly >> not bug-free). >> > > I think I found it David! > > https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ David Schwartz has since been acquired by and merged with David Butenhoff, to form David Schwartzenhoff. The new motto is "bigger living through slightly less concurrency". -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-18 21:34 -0800 |
| Message-ID | <uod1lr$30j2c$2@dont-email.me> |
| In reply to | #380296 |
On 1/16/2024 6:21 PM, Kaz Kylheku wrote: > On 2024-01-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 1/16/2024 5:38 AM, David Brown wrote: >>> On 16/01/2024 03:18, Chris M. Thomasson wrote: >>>> On 1/15/2024 3:24 PM, Kaz Kylheku wrote: >>>>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>>> On 1/15/2024 8:29 AM, David Brown wrote: >>>>>>> On 15/01/2024 17:04, David Brown wrote: >>>>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote: >> [...] >>> You've mentioned this many times - do you have a reference that gives >>> the source of this function (at the time when there was an issue), and a >>> description or report of what you think gcc did wrong? I am curious as >>> to whether it was a bug in the code or a bug in gcc (gcc is certainly >>> not bug-free). >>> >> >> I think I found it David! >> >> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ > > David Schwartz has since been acquired by and merged with David > Butenhoff, to form David Schwartzenhoff. The new motto is "bigger living > through slightly less concurrency". > The tale of Multi_David! :^D
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-16 18:35 -0800 |
| Message-ID | <uo7ee5$1mtqj$1@dont-email.me> |
| In reply to | #380293 |
On 1/16/2024 5:08 PM, Chris M. Thomasson wrote: > On 1/16/2024 5:38 AM, David Brown wrote: >> On 16/01/2024 03:18, Chris M. Thomasson wrote: >>> On 1/15/2024 3:24 PM, Kaz Kylheku wrote: >>>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> >>>> wrote: >>>>> On 1/15/2024 8:29 AM, David Brown wrote: >>>>>> On 15/01/2024 17:04, David Brown wrote: >>>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote: > [...] >> You've mentioned this many times - do you have a reference that gives >> the source of this function (at the time when there was an issue), and >> a description or report of what you think gcc did wrong? I am curious >> as to whether it was a bug in the code or a bug in gcc (gcc is >> certainly not bug-free). >> > > I think I found it David! > > https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ > > > > Here is a nice quote from Dave Butenhof in that thread: ____________________________ Dave Butenhof's profile photo Dave Butenhof Nov 15, 2007, 3:12:14 PM to Chris Thomasson wrote: > "Zeljko Vrba" <zvrba....@ieee-sb1.cc.fer.hr> wrote in message > news:slrnfjnt6l...@ieee-sb1.cc.fer.hr... >> On 2007-11-14, Chris Thomasson <cri...@comcast.net> wrote: >>> >>> If GCC performs the optimization that David Schwartz pointer out, your >>> basically screwed. AFAICT, GCC is totally busted if it allows stores to >>> escape a critical-section. This is a race-condition waiting to >>> happen. I am >>> >> How is the compiler supposed to know where a CS begins and ends? should >> it have a knowledge of every imaginable official and unofficial API? > > I was under the impression that POSIX puts some restrictions on > compilers. Humm... I can't really remember where I heard that right now, > but I sure think I did. Humm... The point is that POSIX puts restrictions on the behavior of a conforming system. That includes library, kernel, and compiler. If the RESULT doesn't behave like POSIX, then it's not POSIX. A compiler that's part of a conforming POSIX system environment can't generate code that breaks synchronization. How it and the rest of the system accomplish that is unspecified. Often, it means simply not performing risky optimizations. But if they are enabled, then the system needs to be able to detect and avoid performing them in "dangerous" areas of code. (A complicated problem, but nothing's impossible.) ____________________________
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-17 03:03 +0000 |
| Message-ID | <20240116185341.795@kylheku.com> |
| In reply to | #380298 |
On 2024-01-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 1/16/2024 5:08 PM, Chris M. Thomasson wrote:
>> On 1/16/2024 5:38 AM, David Brown wrote:
>>> On 16/01/2024 03:18, Chris M. Thomasson wrote:
>>>> On 1/15/2024 3:24 PM, Kaz Kylheku wrote:
>>>>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
>>>>> wrote:
>>>>>> On 1/15/2024 8:29 AM, David Brown wrote:
>>>>>>> On 15/01/2024 17:04, David Brown wrote:
>>>>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote:
>> [...]
>>> You've mentioned this many times - do you have a reference that gives
>>> the source of this function (at the time when there was an issue), and
>>> a description or report of what you think gcc did wrong? I am curious
>>> as to whether it was a bug in the code or a bug in gcc (gcc is
>>> certainly not bug-free).
>>>
>>
>> I think I found it David!
>>
>> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>>
>>
>>
>>
>
> Here is a nice quote from Dave Butenhof in that thread:
> ____________________________
>
> Dave Butenhof's profile photo
> Dave Butenhof
> Nov 15, 2007, 3:12:14 PM
> to
> Chris Thomasson wrote:
> > "Zeljko Vrba" <zvrba....@ieee-sb1.cc.fer.hr> wrote in message
> > news:slrnfjnt6l...@ieee-sb1.cc.fer.hr...
> >> On 2007-11-14, Chris Thomasson <cri...@comcast.net> wrote:
> >>>
> >>> If GCC performs the optimization that David Schwartz pointer out, your
> >>> basically screwed. AFAICT, GCC is totally busted if it allows stores to
> >>> escape a critical-section. This is a race-condition waiting to
> >>> happen. I am
> >>>
> >> How is the compiler supposed to know where a CS begins and ends? should
> >> it have a knowledge of every imaginable official and unofficial API?
> >
> > I was under the impression that POSIX puts some restrictions on
> > compilers. Humm... I can't really remember where I heard that right now,
> > but I sure think I did. Humm...
> The point is that POSIX puts restrictions on the behavior of a
> conforming system. That includes library, kernel, and compiler. If the
> RESULT doesn't behave like POSIX, then it's not POSIX.
>
> A compiler that's part of a conforming POSIX system environment can't
> generate code that breaks synchronization. How it and the rest of the
> system accomplish that is unspecified.
>
> Often, it means simply not performing risky optimizations. But if they
> are enabled, then the system needs to be able to detect and avoid
> performing them in "dangerous" areas of code. (A complicated problem,
> but nothing's impossible.)
Basically, the optimization can only be performed when the value
which controls the selection statement can be shown not to have
been derived from the result of a pthread function, such that the value
indicates whether the caller owns or does not own a lock.
This is very difficult.
Even a value scanned from a stream can be such a value:
int result = pthred_mutex_trylock(...);
FILE *f = fopen("foo.txt", "w");
fprintf(f, "%d\n", result);
fclose(f);
system("mv foo.txt bar.txt");
int x;
FILE *g = fopen("bar.txt", "r");
fscanf(g, "%d", &f);
fclose(g);
if (x == 0) {
a++;
}
A better angle on it would be not to pursue the analysis of x at all,
but concentrate on a. If the variable a isn't something that can be
thread shared, then the optimization is okay.
If a is a local variable whose address has never been taken (or
else has never escaped from this scope), then it's should be
to convert this to:
int __inc = (x == 0);
a += __inc;
If a is something potentially shared, then no.
Programs that want good optimization should concentrate on using
automatic (not static) local variables as much as possible, in such a
way that it's clear that those variables don't escape into other scopes.
Those kinds of variables can be aggressively optimized, threads or not.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-16 19:59 -0800 |
| Message-ID | <uo7jap$1rb6c$1@dont-email.me> |
| In reply to | #380300 |
On 1/16/2024 7:03 PM, Kaz Kylheku wrote:
> On 2024-01-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 1/16/2024 5:08 PM, Chris M. Thomasson wrote:
>>> On 1/16/2024 5:38 AM, David Brown wrote:
>>>> On 16/01/2024 03:18, Chris M. Thomasson wrote:
>>>>> On 1/15/2024 3:24 PM, Kaz Kylheku wrote:
>>>>>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
>>>>>> wrote:
>>>>>>> On 1/15/2024 8:29 AM, David Brown wrote:
>>>>>>>> On 15/01/2024 17:04, David Brown wrote:
>>>>>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote:
>>> [...]
>>>> You've mentioned this many times - do you have a reference that gives
>>>> the source of this function (at the time when there was an issue), and
>>>> a description or report of what you think gcc did wrong? I am curious
>>>> as to whether it was a bug in the code or a bug in gcc (gcc is
>>>> certainly not bug-free).
>>>>
>>>
>>> I think I found it David!
>>>
>>> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>>>
>>>
>>>
>>>
>>
>> Here is a nice quote from Dave Butenhof in that thread:
>> ____________________________
>>
>> Dave Butenhof's profile photo
>> Dave Butenhof
>> Nov 15, 2007, 3:12:14 PM
>> to
>> Chris Thomasson wrote:
>>> "Zeljko Vrba" <zvrba....@ieee-sb1.cc.fer.hr> wrote in message
>>> news:slrnfjnt6l...@ieee-sb1.cc.fer.hr...
>>>> On 2007-11-14, Chris Thomasson <cri...@comcast.net> wrote:
>>>>>
>>>>> If GCC performs the optimization that David Schwartz pointer out, your
>>>>> basically screwed. AFAICT, GCC is totally busted if it allows stores to
>>>>> escape a critical-section. This is a race-condition waiting to
>>>>> happen. I am
>>>>>
>>>> How is the compiler supposed to know where a CS begins and ends? should
>>>> it have a knowledge of every imaginable official and unofficial API?
>>>
>>> I was under the impression that POSIX puts some restrictions on
>>> compilers. Humm... I can't really remember where I heard that right now,
>>> but I sure think I did. Humm...
>> The point is that POSIX puts restrictions on the behavior of a
>> conforming system. That includes library, kernel, and compiler. If the
>> RESULT doesn't behave like POSIX, then it's not POSIX.
>>
>> A compiler that's part of a conforming POSIX system environment can't
>> generate code that breaks synchronization. How it and the rest of the
>> system accomplish that is unspecified.
>>
>> Often, it means simply not performing risky optimizations. But if they
>> are enabled, then the system needs to be able to detect and avoid
>> performing them in "dangerous" areas of code. (A complicated problem,
>> but nothing's impossible.)
>
> Basically, the optimization can only be performed when the value
> which controls the selection statement can be shown not to have
> been derived from the result of a pthread function, such that the value
> indicates whether the caller owns or does not own a lock.
>
> This is very difficult.
>
> Even a value scanned from a stream can be such a value:
>
> int result = pthred_mutex_trylock(...);
>
> FILE *f = fopen("foo.txt", "w");
> fprintf(f, "%d\n", result);
> fclose(f);
> system("mv foo.txt bar.txt");
>
> int x;
> FILE *g = fopen("bar.txt", "r");
> fscanf(g, "%d", &f);
> fclose(g);
>
> if (x == 0) {
> a++;
> }
>
> A better angle on it would be not to pursue the analysis of x at all,
> but concentrate on a. If the variable a isn't something that can be
> thread shared, then the optimization is okay.
>
> If a is a local variable whose address has never been taken (or
> else has never escaped from this scope), then it's should be
> to convert this to:
>
> int __inc = (x == 0);
> a += __inc;
>
> If a is something potentially shared, then no.
>
> Programs that want good optimization should concentrate on using
> automatic (not static) local variables as much as possible, in such a
> way that it's clear that those variables don't escape into other scopes.
> Those kinds of variables can be aggressively optimized, threads or not.
>
>
Fwiw, I created my own externally assembled sync primitives to try to
get around a "rogue" compiler from altering anything within them. Link
time optimizations could get at my code... Turn them off? Well, this was
some years ago.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-17 13:28 +0100 |
| Message-ID | <uo8h5i$20910$1@dont-email.me> |
| In reply to | #380293 |
On 17/01/2024 02:08, Chris M. Thomasson wrote:
> On 1/16/2024 5:38 AM, David Brown wrote:
>> On 16/01/2024 03:18, Chris M. Thomasson wrote:
>>> On 1/15/2024 3:24 PM, Kaz Kylheku wrote:
>>>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
>>>> wrote:
>>>>> On 1/15/2024 8:29 AM, David Brown wrote:
>>>>>> On 15/01/2024 17:04, David Brown wrote:
>>>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote:
> [...]
>> You've mentioned this many times - do you have a reference that gives
>> the source of this function (at the time when there was an issue), and
>> a description or report of what you think gcc did wrong? I am curious
>> as to whether it was a bug in the code or a bug in gcc (gcc is
>> certainly not bug-free).
>>
>
> I think I found it David!
>
> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>
Looking at the start of that thread:
int trylock()
{
int res;
res = pthread_mutex_trylock(&mutex);
if (res == 0)
++acquires_count;
return res;
}
It is perfectly reasonable for a pre-C11 C compiler to change that to:
int trylock()
{
int res;
res = pthread_mutex_trylock(&mutex);
int x = acquires_count;
if (res == 0)
++x;
acquires_count = x;
return res;
}
That's the way C was defined, prior to C11 support for multithreading
environments. The compiler could assume that it alone had full control
over all data, unless it was defined as volatile. So to make this code
"correct" (according to the user's hopes) in pre-C11, "acquires_count"
must be volatile.
C11 disabled such optimisations, because they could introduce data races
that did not exist before. But C11 was not around at that time. So
having this optimisation was not a gcc bug - unless POSIX precluded such
optimisations and gcc was used in a POSIX-compatibility mode. (I don't
know the details of POSIX requirements.)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-17 12:55 -0800 |
| Message-ID | <uo9es6$26mk4$1@dont-email.me> |
| In reply to | #380328 |
On 1/17/2024 4:28 AM, David Brown wrote:
> On 17/01/2024 02:08, Chris M. Thomasson wrote:
>> On 1/16/2024 5:38 AM, David Brown wrote:
>>> On 16/01/2024 03:18, Chris M. Thomasson wrote:
>>>> On 1/15/2024 3:24 PM, Kaz Kylheku wrote:
>>>>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
>>>>> wrote:
>>>>>> On 1/15/2024 8:29 AM, David Brown wrote:
>>>>>>> On 15/01/2024 17:04, David Brown wrote:
>>>>>>>> On 15/01/2024 08:40, Kaz Kylheku wrote:
>> [...]
>>> You've mentioned this many times - do you have a reference that gives
>>> the source of this function (at the time when there was an issue),
>>> and a description or report of what you think gcc did wrong? I am
>>> curious as to whether it was a bug in the code or a bug in gcc (gcc
>>> is certainly not bug-free).
>>>
>>
>> I think I found it David!
>>
>> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>>
>
> Looking at the start of that thread:
>
> int trylock()
> {
> int res;
> res = pthread_mutex_trylock(&mutex);
> if (res == 0)
> ++acquires_count;
> return res;
> }
>
> It is perfectly reasonable for a pre-C11 C compiler to change that to:
>
> int trylock()
> {
> int res;
> res = pthread_mutex_trylock(&mutex);
> int x = acquires_count;
> if (res == 0)
> ++x;
> acquires_count = x;
> return res;
> }
>
> That's the way C was defined, prior to C11 support for multithreading
> environments. The compiler could assume that it alone had full control
> over all data, unless it was defined as volatile. So to make this code
> "correct" (according to the user's hopes) in pre-C11, "acquires_count"
> must be volatile.
>
> C11 disabled such optimisations, because they could introduce data races
> that did not exist before. But C11 was not around at that time. So
> having this optimisation was not a gcc bug - unless POSIX precluded such
> optimisations and gcc was used in a POSIX-compatibility mode. (I don't
> know the details of POSIX requirements.)
Iirc, I think that GCC was being used for POSIX where _POSIX_VERSION /
_POSIX2_C_VERSION was defined. The main point is that made it unusable
wrt pthread_mutex_trylock(). -pthread
This is one of the reasons why I was implementing my sync code in
externally assembled files, at the time.
[toc] | [prev] | [next] | [standalone]
Page 21 of 34 — ← Prev page 1 … 19 20 [21] 22 23 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web