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 24 of 34 — ← Prev page 1 … 22 23 [24] 25 26 … 34 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-16 16:02 +0000 |
| Message-ID | <xMxpN.207476$PuZ9.33416@fx11.iad> |
| In reply to | #380242 |
David Brown <david.brown@hesbynett.no> writes: >On 15/01/2024 21:41, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 15/01/2024 18:30, Scott Lurndal wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>>> On 15/01/2024 03:14, bart wrote: >>>> >>>> <snip> >>>> >>>>> The only compiler I used with an inline >>>>> assembly of comparable power and integration to gcc's, but a different >>>>> syntax, was Diab Data. >>>> >>>> Now there's a name I haven't heard in decades. What ever happened >>>> to them? We worked with them back in the early 90's using their >>>> 88100 compiler. It was impressive, particularly compared to the >>>> PCC port that Motorola provided. Greenhills was ok, but diab >>>> produced better code. gcc was still pretty primitive in those days. >>>> >>>> A good Norweigian company. >>> >>> A good /Swedish/ company, not Norwegian! >> >> Hm. I could have sworn the folks we dealt with were >> in Norway - perhaps a branch office? >> > >It would be a little surprising, but certainly possible. Sweden has had >been quite significant in the compiler world - IAR is a big name in >embedded toolchains, and they are Swedish. > >You are sure you are not just one of these ignorant parochial Merican's >who think Norway is the capital of Sweden? :-)] No, I'm 7/8th norwegian, with a bit of swiss. While I haven't visited (yet), I do have relatives there. Think Luren dal. Granted it's been three decades since were were using diab compilers (1993ish)...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 19:03 +0100 |
| Message-ID | <uo6gcp$1i5rh$1@dont-email.me> |
| In reply to | #380251 |
On 16/01/2024 17:02, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 15/01/2024 21:41, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 15/01/2024 18:30, Scott Lurndal wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>> On 15/01/2024 03:14, bart wrote: >>>>> >>>>> <snip> >>>>> >>>>>> The only compiler I used with an inline >>>>>> assembly of comparable power and integration to gcc's, but a different >>>>>> syntax, was Diab Data. >>>>> >>>>> Now there's a name I haven't heard in decades. What ever happened >>>>> to them? We worked with them back in the early 90's using their >>>>> 88100 compiler. It was impressive, particularly compared to the >>>>> PCC port that Motorola provided. Greenhills was ok, but diab >>>>> produced better code. gcc was still pretty primitive in those days. >>>>> >>>>> A good Norweigian company. >>>> >>>> A good /Swedish/ company, not Norwegian! >>> >>> Hm. I could have sworn the folks we dealt with were >>> in Norway - perhaps a branch office? >>> >> >> It would be a little surprising, but certainly possible. Sweden has had >> been quite significant in the compiler world - IAR is a big name in >> embedded toolchains, and they are Swedish. >> >> You are sure you are not just one of these ignorant parochial Merican's >> who think Norway is the capital of Sweden? :-)] > I hope you noticed the smiley :-) > No, I'm 7/8th norwegian, with a bit of swiss. While I haven't visited (yet), > I do have relatives there. Think Luren dal. > I would say you are of Norwegian decent, or have Norwegian family roots - it's not the same as being Norwegian. You need to at least visit the country! Alternatively, you need to eat a /lot/ of brunost to improve your credentials. I looked up "Lurendal" on Google maps. It's in Sweden :-) Maybe your parents told you they were Norwegian, because they know that Norwegians are superior to Swedes in every way... (There are a few place names in Norway with "Luren" in them, and of course spellings change over time between family names and place names.) > Granted it's been three decades since were were using diab compilers (1993ish)...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-16 18:45 +0000 |
| Message-ID | <N8ApN.207483$PuZ9.43104@fx11.iad> |
| In reply to | #380259 |
David Brown <david.brown@hesbynett.no> writes: >On 16/01/2024 17:02, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 15/01/2024 21:41, Scott Lurndal wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>>> On 15/01/2024 18:30, Scott Lurndal wrote: >>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>>> On 15/01/2024 03:14, bart wrote: >>>>>> >>>>>> <snip> >>>>>> >>>>>>> The only compiler I used with an inline >>>>>>> assembly of comparable power and integration to gcc's, but a different >>>>>>> syntax, was Diab Data. >>>>>> >>>>>> Now there's a name I haven't heard in decades. What ever happened >>>>>> to them? We worked with them back in the early 90's using their >>>>>> 88100 compiler. It was impressive, particularly compared to the >>>>>> PCC port that Motorola provided. Greenhills was ok, but diab >>>>>> produced better code. gcc was still pretty primitive in those days. >>>>>> >>>>>> A good Norweigian company. >>>>> >>>>> A good /Swedish/ company, not Norwegian! >>>> >>>> Hm. I could have sworn the folks we dealt with were >>>> in Norway - perhaps a branch office? >>>> >>> >>> It would be a little surprising, but certainly possible. Sweden has had >>> been quite significant in the compiler world - IAR is a big name in >>> embedded toolchains, and they are Swedish. >>> >>> You are sure you are not just one of these ignorant parochial Merican's >>> who think Norway is the capital of Sweden? :-)] >> > >I hope you noticed the smiley :-) > >> No, I'm 7/8th norwegian, with a bit of swiss. While I haven't visited (yet), >> I do have relatives there. Think Luren dal. >> > >I would say you are of Norwegian decent, or have Norwegian family roots >- it's not the same as being Norwegian. Point. > You need to at least visit the Country! My folks have been there a couple of times, and looked up distant relatives from both sides (the other side was from the Bergen area, IIRC). > Alternatively, you need to eat a /lot/ of brunost to improve >your credentials. Does lutefisk and lefse count? Had a small earthquake while typing this. Probably less than M3. > >I looked up "Lurendal" on Google maps. It's in Sweden :-) Blame my great great grandfather who changed his name from Olson to Johnson to Lurndal shortly after immigrating here, and shortly before serving in the Union army. > Maybe your >parents told you they were Norwegian, because they know that Norwegians >are superior to Swedes in every way... The area where they settled (western wisconsin) was Norwegian, with a fair bit of competition from Swedish and German immigrants. The small (Pop. 50) town near my grandfathers farm had two churches, both Lutheran, one for the German population and one for the Norwegians (the Swedes were in the next village over). > >(There are a few place names in Norway with "Luren" in them, and of >course spellings change over time between family names and place names.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 23:00 +0100 |
| Message-ID | <uo6uaj$1kkoc$1@dont-email.me> |
| In reply to | #380261 |
On 16/01/2024 19:45, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 16/01/2024 17:02, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 15/01/2024 21:41, Scott Lurndal wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>> On 15/01/2024 18:30, Scott Lurndal wrote: >>>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>>>> On 15/01/2024 03:14, bart wrote: >>>>>>> >>>>>>> <snip> >>>>>>> >>>>>>>> The only compiler I used with an inline >>>>>>>> assembly of comparable power and integration to gcc's, but a different >>>>>>>> syntax, was Diab Data. >>>>>>> >>>>>>> Now there's a name I haven't heard in decades. What ever happened >>>>>>> to them? We worked with them back in the early 90's using their >>>>>>> 88100 compiler. It was impressive, particularly compared to the >>>>>>> PCC port that Motorola provided. Greenhills was ok, but diab >>>>>>> produced better code. gcc was still pretty primitive in those days. >>>>>>> >>>>>>> A good Norweigian company. >>>>>> >>>>>> A good /Swedish/ company, not Norwegian! >>>>> >>>>> Hm. I could have sworn the folks we dealt with were >>>>> in Norway - perhaps a branch office? >>>>> >>>> >>>> It would be a little surprising, but certainly possible. Sweden has had >>>> been quite significant in the compiler world - IAR is a big name in >>>> embedded toolchains, and they are Swedish. >>>> >>>> You are sure you are not just one of these ignorant parochial Merican's >>>> who think Norway is the capital of Sweden? :-)] >>> >> >> I hope you noticed the smiley :-) >> >>> No, I'm 7/8th norwegian, with a bit of swiss. While I haven't visited (yet), >>> I do have relatives there. Think Luren dal. >>> >> >> I would say you are of Norwegian decent, or have Norwegian family roots >> - it's not the same as being Norwegian. > > Point. > >> You need to at least visit the Country! > > My folks have been there a couple of times, and looked > up distant relatives from both sides (the other side > was from the Bergen area, IIRC). Bergen's a nice city. It rains a lot, but otherwise it's a pleasant place. > >> Alternatively, you need to eat a /lot/ of brunost to improve >> your credentials. > > Does lutefisk and lefse count? Everyone likes lefser, but if you can claim to like lutefisk with a straight face, you must be Norwegian! (For those that don't know, "lutefisk" is made by drying cod completely, then soaking it in draincleaner, then washing it, then boiling it. It doesn't beat the Swedish canned fermented fish or Icelandic sharks buried for months in the sand, but it's definitely not something to be eaten lightly.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-16 22:10 +0000 |
| Message-ID | <19DpN.231126$xHn7.35184@fx14.iad> |
| In reply to | #380277 |
David Brown <david.brown@hesbynett.no> writes: >On 16/01/2024 19:45, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> Alternatively, you need to eat a /lot/ of brunost to improve >>> your credentials. >> >> Does lutefisk and lefse count? > >Everyone likes lefser, but if you can claim to like lutefisk with a >straight face, you must be Norwegian! Eat? Yes. Holiday tradition. Like? One can eat anything if it is drowned in enough butter. The feeling of that gelatinous mass sliding down the back of your throat is unforgettable. > >(For those that don't know, "lutefisk" is made by drying cod completely, >then soaking it in draincleaner, then washing it, then boiling it. It >doesn't beat the Swedish canned fermented fish or Icelandic sharks >buried for months in the sand, but it's definitely not something to be >eaten lightly.) > David is not exaggerating about the drain cleaner....
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-01-16 22:18 +0000 |
| Message-ID | <uo6vbf$1kkv7$1@dont-email.me> |
| In reply to | #380277 |
On 16/01/2024 22:00, David Brown wrote: > > (For those that don't know, "lutefisk" is made by drying cod completely, > then soaking it in draincleaner, then washing it, then boiling it. It > doesn't beat the Swedish canned fermented fish or Icelandic sharks > buried for months in the sand, but it's definitely not something to be > eaten lightly.) > Local: It's a delicacy Jeremy Clarkson: Haven't you people heard of chocolate?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-17 07:11 +0100 |
| Subject | NO vs. SE (was Re: Effect of CPP tags) |
| Message-ID | <uo7r3e$1skfj$1@dont-email.me> |
| In reply to | #380259 |
On 16.01.2024 19:03, David Brown wrote: > > [...], because they know that Norwegians are superior to Swedes in every way... I just wanted to reply on that but then I saw your email address... :-) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-17 14:17 +0100 |
| Subject | Re: NO vs. SE (was Re: Effect of CPP tags) |
| Message-ID | <uo8k11$20hg6$3@dont-email.me> |
| In reply to | #380313 |
On 17/01/2024 07:11, Janis Papanagnou wrote: > On 16.01.2024 19:03, David Brown wrote: >> >> [...], because they know that Norwegians are superior to Swedes in every way... > > I just wanted to reply on that but then I saw your email address... :-) > I'm Scottish by origin, but have lived in Norway for about 30 years. So I am a Norwegian by practice (and citizenship) rather than birth. (Norway and Sweden view each other as "brother" countries, with very close ties and cooperation, but also good-natured rivalry and occasional teasing.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-17 16:33 +0000 |
| Subject | Re: NO vs. SE (was Re: Effect of CPP tags) |
| Message-ID | <qjTpN.168168$vFZa.130478@fx13.iad> |
| In reply to | #380332 |
David Brown <david.brown@hesbynett.no> writes: >On 17/01/2024 07:11, Janis Papanagnou wrote: >> On 16.01.2024 19:03, David Brown wrote: >>> >>> [...], because they know that Norwegians are superior to Swedes in every way... >> >> I just wanted to reply on that but then I saw your email address... :-) >> > >I'm Scottish by origin, but have lived in Norway for about 30 years. So >I am a Norwegian by practice (and citizenship) rather than birth. > >(Norway and Sweden view each other as "brother" countries, with very >close ties and cooperation, but also good-natured rivalry and occasional >teasing.) And at various times in the past they've been one country (c.f. United Kingdoms).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-17 18:47 +0100 |
| Subject | Re: NO vs. SE (was Re: Effect of CPP tags) |
| Message-ID | <uo93s6$24p1g$2@dont-email.me> |
| In reply to | #380345 |
On 17/01/2024 17:33, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 17/01/2024 07:11, Janis Papanagnou wrote: >>> On 16.01.2024 19:03, David Brown wrote: >>>> >>>> [...], because they know that Norwegians are superior to Swedes in every way... >>> >>> I just wanted to reply on that but then I saw your email address... :-) >>> >> >> I'm Scottish by origin, but have lived in Norway for about 30 years. So >> I am a Norwegian by practice (and citizenship) rather than birth. >> >> (Norway and Sweden view each other as "brother" countries, with very >> close ties and cooperation, but also good-natured rivalry and occasional >> teasing.) > > And at various times in the past they've been one country (c.f. United Kingdoms). > Norway and Sweden have always been separate countries (since they became countries). They were in a union, with Norway dominated and ruled by Sweden, but they were still different countries. The Ununited Kingdom, on the other hand, is in some aspects one country, in other aspects four different countries (with a whole bunch of complicated bits), and in many aspects a complete mess. (I should stop there - this is no place to risk getting into politics.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-17 18:04 +0000 |
| Subject | Re: NO vs. SE (was Re: Effect of CPP tags) |
| Message-ID | <yEUpN.237106$xHn7.15611@fx14.iad> |
| In reply to | #380349 |
David Brown <david.brown@hesbynett.no> writes: >On 17/01/2024 17:33, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 17/01/2024 07:11, Janis Papanagnou wrote: >>>> On 16.01.2024 19:03, David Brown wrote: >>>>> >>>>> [...], because they know that Norwegians are superior to Swedes in every way... >>>> >>>> I just wanted to reply on that but then I saw your email address... :-) >>>> >>> >>> I'm Scottish by origin, but have lived in Norway for about 30 years. So >>> I am a Norwegian by practice (and citizenship) rather than birth. >>> >>> (Norway and Sweden view each other as "brother" countries, with very >>> close ties and cooperation, but also good-natured rivalry and occasional >>> teasing.) >> >> And at various times in the past they've been one country (c.f. United Kingdoms). >> > >Norway and Sweden have always been separate countries (since they became >countries). They were in a union, with Norway dominated and ruled by >Sweden, but they were still different countries. Note the plural kingdoms above. "United Kingdoms of Sweden and Norway, and known as the United Kingdoms"
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-17 19:15 +0100 |
| Subject | Re: NO vs. SE (was Re: Effect of CPP tags) |
| Message-ID | <uo95gn$256at$1@dont-email.me> |
| In reply to | #380332 |
On 17.01.2024 14:17, David Brown wrote: > On 17/01/2024 07:11, Janis Papanagnou wrote: >> On 16.01.2024 19:03, David Brown wrote: >>> >>> [...], because they know that Norwegians are superior to Swedes in >>> every way... >> >> I just wanted to reply on that but then I saw your email address... :-) > > I'm Scottish by origin, but have lived in Norway for about 30 years. So > I am a Norwegian by practice (and citizenship) rather than birth. By birth, or whatever; I think we are what we feel to be. :-) > > (Norway and Sweden view each other as "brother" countries, with very > close ties and cooperation, Yes, that's also how these countries are seen from other places. I've been a couple times in SE, and once in NO; I like these countries. Also with respect to computer languages; I was amazed by Simula, originating from the NCC in Oslo/NO, and I had a compiler that had been developed in Lund/SE, where I could even talk to one of the developers in the 1980's.) > but also good-natured rivalry and occasional teasing.) Within DE there's rivalry even between Bavaria and Prussia. ;-) (Not seriously but mainly also only some teasing. Historically, though, it had been a much more serious conflict.) Janis
[toc] | [prev] | [next] | [standalone]
| From | om@iki.fi (Otto J. Makela) |
|---|---|
| Date | 2024-01-18 17:22 +0200 |
| Subject | Re: NO vs. SE (was Re: Effect of CPP tags) |
| Message-ID | <87bk9i1xa6.fsf@tigger.extechop.net> |
| In reply to | #380313 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 16.01.2024 19:03, David Brown wrote: >> [...], because they know that Norwegians are superior to Swedes in >> every way... > > I just wanted to reply on that but then I saw your email address... :-) A Finn smirking from the sidelines. -- /* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2024-03-24 14:24 +0200 |
| Subject | Re: NO vs. SE (was Re: Effect of CPP tags) |
| Message-ID | <87wmprakcj.fsf@fatphil.org> |
| In reply to | #380414 |
om@iki.fi (Otto J. Makela) writes: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 16.01.2024 19:03, David Brown wrote: >>> [...], because they know that Norwegians are superior to Swedes in >>> every way... >> >> I just wanted to reply on that but then I saw your email address... :-) > > A Finn smirking from the sidelines. As if you have no rivalry with Swedes. What's the score? 5-1? Ooops, now it's 5-6. We have a great view here from Estonia. > /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ Send my regards to Vastarannan Kiiski. Phil -- We are no longer hunters and nomads. No longer awed and frightened, as we have gained some understanding of the world in which we live. As such, we can cast aside childish remnants from the dawn of our civilization. -- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-16 12:26 +0000 |
| Message-ID | <uo5skp$1e106$1@dont-email.me> |
| In reply to | #380184 |
On 15/01/2024 15:23, David Brown wrote:
> On 15/01/2024 03:14, bart wrote:
> You pass the relevant data into and out of the inline assembly. If you
> think you need access to other symbols in the assembly, you are (almost
> certainly) doing things wrong. You are trying to do the compiler's job
> behind its back, and that is not a good idea.
Not with gcc. You don't want to mess with that.
But /I/ use inline assembler when /I/ in in charge of the code.
>> If /I/ had to write extensive programs in gcc inline assembly, then
>> put a gun to my head now!
>
> If you are trying to write extensive programs in assembly, you are
> already getting it wrong.
I want to write HLL functions that may have a number of lines in
assembly, from one line up to a few dozen.
> Inline assembly is for things that cannot be
> expressed in high level languages, or the very rare occasions where you
> know a way to do something in assembly that is very much more efficient
> than the compiler can generate, and the code is speed critical, and
> there are no built-ins for the task, and no target intrinsics provided
> by the processor manufacturer.
>
>>
>> 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.)
>
> void F(void) {
> int b = 2:
> int c = 3;
> static int d = 4;
>
> asm ("imul2 %[c], %[d]\n\t"
> "add %[c], %[b]"
> : [c] "+g" (c) : [b] "g" (b), [d] "g" (d));
> a = c;
> }
Sorry, but you've turned it into gobbledygook. My example was for x64
which is a 1.5 address machine, here you've turned it into a 2-address
machine. Could I make it 3-address? What are the rules?
It is a different language.
> The generated result (from <https://godbolt.org>) is :
>
> F():
> mov eax, 3
> imul2 eax, 4
> add eax, 2
> mov DWORD PTR a[rip], eax
> ret
The initialisations I used were so I could test that it gave the correct
results. Without them, godbolt gives me this for the body of the function:
movl d.0(%rip), %edx
movl -8(%rbp), %eax
imul2 %eax, %edx
add %eax, -4(%rbp)
movl %eax, -8(%rbp)
movl -8(%rbp), %eax
movl %eax, a(%rip)
My version (which evaluates a=b+c*d; somehow your version modifies c)
gives me this (D0 == rax):
mov D0, [Dframe+test.f.c]
imul2 D0, [test.f.d]
add D0, [Dframe+test.f.b]
mov [test.a], D0
Unsurprisingly, this is exactly the ASM I typed (plus the necessary name
qualifiers). That is the entire point.
If I tweak your C version, make a,b,c,d all external statics, and apply
-O3, godbolt gives me this:
imul2 c(%rip), d(%rip)
add c(%rip), b(%rip)
movl c(%rip), %eax
movl %eax, a(%rip)
ret
This is slightly worrying: imul2 is not a valid instruction (it's
specific to my assembler). While add can't take two memory operands.
So it looks like it can only do so much checking. (Using gcc locally
gave valid assembly.)
So it all seems hit and miss.
I'll reply to the second half of your post later.
Let me just say that, in my interpreter, the extensive use of inline
assembly in one module, makes some programs run twice as fast, as a
gcc-O3-compiled C rendering.
It also lets me write trivial solutions to the LIBFFI problem.
It works.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 16:29 +0100 |
| Message-ID | <uo67c4$1ge1j$1@dont-email.me> |
| In reply to | #380233 |
On 16/01/2024 13:26, bart wrote:
> On 15/01/2024 15:23, David Brown wrote:
>> On 15/01/2024 03:14, bart wrote:
>
>> You pass the relevant data into and out of the inline assembly. If
>> you think you need access to other symbols in the assembly, you are
>> (almost certainly) doing things wrong. You are trying to do the
>> compiler's job behind its back, and that is not a good idea.
>
> Not with gcc. You don't want to mess with that.
No. But I prefer it that way - I am much happier with a compiler that
has a (fairly) precise way to express the interaction between inline
assembly and the rest of the compiler, than one that leaves you guessing
and hoping that your use of registers will not conflict with the compiler's.
>
> But /I/ use inline assembler when /I/ in in charge of the code.
>
>>> If /I/ had to write extensive programs in gcc inline assembly, then
>>> put a gun to my head now!
>>
>> If you are trying to write extensive programs in assembly, you are
>> already getting it wrong.
>
> I want to write HLL functions that may have a number of lines in
> assembly, from one line up to a few dozen.
I want to be /able/ to do that, but I very much don't want to /have/ to
do that. I certainly don't want to have to mess around with the donkey
work of moving data around and in and out of registers when the compiler
can do that for me! I use inline assembly when the compiler can't do
the job or use the particular instruction(s) by itself - and no more
than that.
>
>> Inline assembly is for things that cannot be expressed in high level
>> languages, or the very rare occasions where you know a way to do
>> something in assembly that is very much more efficient than the
>> compiler can generate, and the code is speed critical, and there are
>> no built-ins for the task, and no target intrinsics provided by the
>> processor manufacturer.
>>
>>>
>>> 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.)
>>
>> void F(void) {
>> int b = 2:
>> int c = 3;
>> static int d = 4;
>>
>> asm ("imul2 %[c], %[d]\n\t"
>> "add %[c], %[b]"
>> : [c] "+g" (c) : [b] "g" (b), [d] "g" (d));
>> a = c;
>> }
>
> Sorry, but you've turned it into gobbledygook. My example was for x64
> which is a 1.5 address machine, here you've turned it into a 2-address
> machine. Could I make it 3-address? What are the rules?
>
> It is a different language.
You are misunderstanding the gcc syntax here. Now that I see what you
mean, I realise I should probably have explained it earlier.
Basically, gcc inline assembly statements look like this :
asm(<asm template> : <outputs> : <inputs> : <clobbers>);
The <asm template> is a string (often written using C string
concatenation if it spans multiple lines). This is a /template/ - it
contains special characters and sequences that get filled in before it
is written out to the assembler. In particular, each input and output
operand is replaced.
The <inputs> and <outputs> are lists of input and output constraints for
data that is passed into and out of the assembly expression. A
constraint consists of an optional symbolic name inside square brackets,
an operand constraint string, and a C expression inside parentheses.
Inside the assembly template, you can refer to these operands by
positional number (%0 for the first, %1 for the next, etc.), or by the
symbolic name using the format %[name]. That is what the "%[c]", etc.,
means in the code I wrote. (The symbolic name does not have to bear any
connection to the variable name in C - indeed, the input and output
expressions do not have to refer to C variables. But /if/ they refer to
variables, then I often pick the same name.) Some people prefer to use
parameter numbers, others (like me) prefer names.
When the compiler is handling the inline assembly line, it first matches
the input and output operands to their constraints. A constraint "r"
means "any general-purpose register". "m" means "addressable memory",
"i" means "immediate value", and "g" means "general - any of r, m or i".
There are a great many other constraint codes available, most of which
are specific for specific targets.
So if the data that is to go into an input with constraint "r" is
already in a register - say "r8" - then any use of that operand in the
assembly template will be replaced by "r8" - or "%r8" or whatever format
is needed by the assembler. If the input data happens to be known at
compile-time (as is the case for your local variables here), then the
compiler will first pick a free register - say, "rbx" - and then
generate whatever code is needed to load that register with the known
number. That might be a "load" instruction, a "move" instruction, or a
bunch of instructions needed to access constant data from a store
relative to the current PC - whatever the target processor needs. If
the input expression is "foo() + 3 * xs[43]", it will evaluate that
expression and store the result in the free register.
If the constraint is "g", then it can be a lot more flexible - that's
suitable for x86 assembly, where many instructions can handle a memory
reference, an immediate, or a register. And if it is a memory
reference, the compiler will replace the operand in the assembly
template with whatever format suits the target - whether that be
"[rsi+4]", "16(si)", "*0x1234" or anything else suitable for the target.
Outputs are similarly matched with free registers, memory addresses, or
whatever suits the constraint (an "i" constraint is obviously not
helpful here). And after the assembly has been executed, this output
will then be assigned to the expression given in the output operand
list. For simple cases where the output operand is a local variable,
usually nothing will be needed because the compiler would match the
output operand to a register and use that for the local variable
afterwards. But the expression could be any lvalue, and need assignment
afterwards.
The "+g" (which would actually have been better as "+r") says that the
operand is an input as well as an output.
All in all, it means the compiler handles register allocation and moving
data into and out of registers - if needed.
The syntax can cover a lot more than this - modifiers for the operands
(very useful if you have, say, a 16-bit target and want to access the
high and low halves of a 32-bit operand), constraints of all sorts, flag
register changes, assembly templates that adjust automatically for Intel
and AT&T syntax, and so on. But that's too much for a Usenet post!
>
>
>> The generated result (from <https://godbolt.org>) is :
>>
>> F():
>> mov eax, 3
>> imul2 eax, 4
>> add eax, 2
>> mov DWORD PTR a[rip], eax
>> ret
>
> The initialisations I used were so I could test that it gave the correct
> results. Without them, godbolt gives me this for the body of the function:
>
>
> movl d.0(%rip), %edx
> movl -8(%rbp), %eax
> imul2 %eax, %edx
> add %eax, -4(%rbp)
> movl %eax, -8(%rbp)
> movl -8(%rbp), %eax
> movl %eax, a(%rip)
>
You need to initialise the values, or else the code has undefined or
unspecified behaviour - input operands are read, so they need to have
values from somewhere.
But there you see the power of gcc's inline assembly. I gave the
results with -O2, because it is unnatural to use gcc without
optimisation enabled. Your results are for -O0. And you can see that
gcc handles the movement in and out of registers as needed, and is happy
to replace the "%[b]" with reading memory directly from the stack.
>
> My version (which evaluates a=b+c*d; somehow your version modifies c)
> gives me this (D0 == rax):
>
> mov D0, [Dframe+test.f.c]
> imul2 D0, [test.f.d]
> add D0, [Dframe+test.f.b]
> mov [test.a], D0
>
"c" is a local variable - modifying it is fine. So my assembly matched:
c *= d;
c += b;
Then "a = c" was in C.
I could have created a new local variable "res", then had the assembly for :
res = c;
res *= d;
res += b;
a = res;
void F(void) {
int b=2, c=3;
static int d=4;
int res;
asm (
"mov %[res], %[c];\n\t"
"imul %[res], %[d];\n\t"
"add %[res], %[b];\n\t"
"mov %[a], %[res];\n\t"
: [res] "=&r" (res), [a] "=m" (a)
: [b] "g" (b), [c] "g" (c), [d] "g" (d));
}
That results in the same code when optimised, and a little extra at -O0
(since the compiler wants to keep the scratch variable "res" around).
(I am ending the assembly lines here with ";\n\t" - the extra semicolon
changes nothing in the behaviour, but makes it easy to see on godbolt
which lines are generated from the inline assembly.)
> Unsurprisingly, this is exactly the ASM I typed (plus the necessary name
> qualifiers). That is the entire point.
>
> If I tweak your C version, make a,b,c,d all external statics, and apply
> -O3, godbolt gives me this:
>
> imul2 c(%rip), d(%rip)
> add c(%rip), b(%rip)
> movl c(%rip), %eax
> movl %eax, a(%rip)
> ret
>
> This is slightly worrying: imul2 is not a valid instruction (it's
> specific to my assembler). While add can't take two memory operands.
>
Yes, that is correct. If the operands are all from memory, then at
least one constraint should be "r" rather than "g" to ensure that we
have at least one register operand. And we'd want a scratch variable,
rather than modifying "c". So you'd have something like this :
void F(void) {
extern int A, B, C, D;
int res = C;
asm ("imul %[res], %[d];\n\t"
"add %[res], %[b];\n\t"
: [res] "+r" (res)
: [b] "g" (B), [d] "g" (D));
A = res;
}
Again, only two lines of inline assembly, generating:
F:
mov eax, DWORD PTR C[rip]
imul eax, DWORD PTR D[rip];
add eax, DWORD PTR B[rip];
mov DWORD PTR A[rip], eax
ret
> So it looks like it can only do so much checking. (Using gcc locally
> gave valid assembly.)
>
gcc can't check the assembly at all.
> So it all seems hit and miss.
Assembly is not for the faint-hearted.
>
> I'll reply to the second half of your post later.
>
> Let me just say that, in my interpreter, the extensive use of inline
> assembly in one module, makes some programs run twice as fast, as a
> gcc-O3-compiled C rendering.
That can sometimes happen, for particular kinds of code. It is not
often that hand-written assembly will be so significantly faster than
gcc unless there are close matches for unusual instructions that the
compiler does not generate. But it can certainly happen.
Often the C code can be improved in various ways - perhaps using
extensions (such as gcc attributes). Getting the very best out of a
compiler for key performance-critical code is rarely just a matter of
writing "-O3" and hoping for the best.
If you can boil this down to a short and manageable piece of code, then
it might be fun to look at ways of improving the speed using either pure
standard C, or gcc extensions, and compare it to the hand-generated
assembly. I realise that making such as small sample that keeps the
effect is unlikely to be a trivial task. (And if you do this, put it in
a new thread :-) )
>
> It also lets me write trivial solutions to the LIBFFI problem.
>
> It works.
>
I'm sure your inline assembly /does/ work, for your needs. But it is
not "better" than gcc's inline assembly, and it would not do the job
that many others need from inline assembly.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-16 19:21 +0000 |
| Subject | Interpreter Dispatch in C (was: Effect of CPP Tags) |
| Message-ID | <uo6kvo$1j2ed$1@dont-email.me> |
| In reply to | #380245 |
On 16/01/2024 15:29, David Brown wrote:
> On 16/01/2024 13:26, bart wrote:
>> Let me just say that, in my interpreter, the extensive use of inline
>> assembly in one module, makes some programs run twice as fast, as a
>> gcc-O3-compiled C rendering.
>
> That can sometimes happen, for particular kinds of code. It is not
> often that hand-written assembly will be so significantly faster than
> gcc unless there are close matches for unusual instructions that the
> compiler does not generate. But it can certainly happen.
>
> Often the C code can be improved in various ways - perhaps using
> extensions (such as gcc attributes). Getting the very best out of a
> compiler for key performance-critical code is rarely just a matter of
> writing "-O3" and hoping for the best.
>
> If you can boil this down to a short and manageable piece of code, then
> it might be fun to look at ways of improving the speed using either pure
> standard C, or gcc extensions, and compare it to the hand-generated
> assembly. I realise that making such as small sample that keeps the
> effect is unlikely to be a trivial task. (And if you do this, put it in
> a new thread :-) )
I have done experiments that comprise under 100 lines of code and that
test a very small number of bytecodes, maybe just one.
But I don't believe you can extract useful conclusions that will scale.
gcc's agressive optimiser is likely to reduce such a simple program to
nothing, or it will be able to infer things are not possible when spread
over 20,000 lines of code over multiple modules, and where the test
bytecode is a runtime input, not set up in a data structure.
I've worked with four main kinds of bytecode dispatcher:
(1) Using a table of function pointers. The dispatcher is then a simple
3-line loop
(2) Using a large switch statement. Each case can be either inline code
or can call a function. gcc likes this one because it can inline
function calls
(3) Using computed-goto. In C, this would need gcc's extension to use
label pointers
(4) Using a threaded-code dispatcher, making extensive use of inline
assembly, which is an overlay over (1): when a bytecode can't be
fully handled here, it calls one of the handlers from (1).
These are progressively faster. I no longer use (2) or (3); there's no
point if I have (4).
The C version used (1), compared with (4) using my compiler and language.
I have in the past compared C versions of (2) and (3) with (4), and (4)
was still faster, although that was some time ago.
When I lookat at CPython sources a decade ago, they used method (3) when
compiled on Linux. On Windows however, they used method (2), since it
needs MSVC to build, which does not have the needed extension.
(My language also has label pointers, but it also has a built-in feature
for computed-goto: you only have to tweak one line to change a regular
switch-loop into one that uses computed-goto. That is, using multiple
loop-back points so that each can have its own branch prediction.
I don't use that in this product, only in a separate project.)
-------------
My (4) dispatcher uses thread-code functions that try and keep execution
within a tight, register-based environment:
* Essential globals are kept in registers
* There is no function entry/exit code: each handler jumps directly to
the next, without any loops
* ABI considerations are put aside (eg. all non-volatiles are saved once
at the beginning, and restored at the end)
* Most handlers use inline assembly
* When it is necessary to call a normal HLL handler, the environment
must be saved and restored.
This an example of a very simple handler that uses inline assembly:
threadedproc j_jump*=
assem
mov Dprog,[Dprog+kopnda]
*jumpnext
end
end
And this is one which uses the HLL handler:
threadedproc j_jumpptr*=
saveregs
k_jumpptr()
loadregs
jumpnext
end
saveregs/loadregs are macros. In both cases, 'jumpnext' is this macro
(it needs * to invoke it from assembly):
macro jumpnext = asm jmp [Dprog]
So, the overheads of executing 'goto L' in the interpreted language are
two machine instructions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 23:24 +0100 |
| Subject | Re: Interpreter Dispatch in C |
| Message-ID | <uo6vna$1krkt$1@dont-email.me> |
| In reply to | #380267 |
On 16/01/2024 20:21, bart wrote:
> On 16/01/2024 15:29, David Brown wrote:
>> On 16/01/2024 13:26, bart wrote:
>
>>> Let me just say that, in my interpreter, the extensive use of inline
>>> assembly in one module, makes some programs run twice as fast, as a
>>> gcc-O3-compiled C rendering.
>>
>> That can sometimes happen, for particular kinds of code. It is not
>> often that hand-written assembly will be so significantly faster than
>> gcc unless there are close matches for unusual instructions that the
>> compiler does not generate. But it can certainly happen.
>>
>> Often the C code can be improved in various ways - perhaps using
>> extensions (such as gcc attributes). Getting the very best out of a
>> compiler for key performance-critical code is rarely just a matter of
>> writing "-O3" and hoping for the best.
>>
>> If you can boil this down to a short and manageable piece of code,
>> then it might be fun to look at ways of improving the speed using
>> either pure standard C, or gcc extensions, and compare it to the
>> hand-generated assembly. I realise that making such as small sample
>> that keeps the effect is unlikely to be a trivial task. (And if you
>> do this, put it in a new thread :-) )
>
> I have done experiments that comprise under 100 lines of code and that
> test a very small number of bytecodes, maybe just one.
>
> But I don't believe you can extract useful conclusions that will scale.
>
That is sometimes the case.
> gcc's agressive optimiser is likely to reduce such a simple program to
> nothing, or it will be able to infer things are not possible when spread
> over 20,000 lines of code over multiple modules, and where the test
> bytecode is a runtime input, not set up in a data structure.
>
A trick here is to make your source data "volatile" - or make it depend
on a volatile (so that you are not affecting the access to the data
itself). And put the results into a volatile.
volatile int nothing = 0;
volatile int result;
void foo(void) {
int test_data = 1234;
double more_data = 3.14;
test_data += nothing;
// or
if (nothing) {
test_data = nothing;
more_data = nothing;
}
// Start timer
int x = run_tests(test_data, more_data);
// Stop timer
result = x;
}
It doesn't really matter how you use "nothing", just that the value of
the inputs could be affected by it.
(I can show you an alternative trick using target-independent inline
assembly, if you like.)
> I've worked with four main kinds of bytecode dispatcher:
>
> (1) Using a table of function pointers. The dispatcher is then a simple
> 3-line loop
>
OK.
> (2) Using a large switch statement. Each case can be either inline code
> or can call a function. gcc likes this one because it can inline
> function calls
>
I prefer switches to jump tables - I avoid function pointers where I
can, because they make it so much harder to analyse call trees.
> (3) Using computed-goto. In C, this would need gcc's extension to use
> label pointers
That is also sometimes used for such code. Again, I prefer the switch here.
>
> (4) Using a threaded-code dispatcher, making extensive use of inline
> assembly, which is an overlay over (1): when a bytecode can't be
> fully handled here, it calls one of the handlers from (1).
>
> These are progressively faster. I no longer use (2) or (3); there's no
> point if I have (4).
>
> The C version used (1), compared with (4) using my compiler and language.
>
It is perhaps a bit unfair to compare a slow algorithm in C with a fast
algorithm in a different language!
Much will depend on cache usage, branch prediction, and if you can
arrange for common cases to be checked first. And also remember that
"-O3" is not always faster than "-O2", and that sometimes there are
other flags that make a significant difference.
> I have in the past compared C versions of (2) and (3) with (4), and (4)
> was still faster, although that was some time ago.
Depending on your value of "some", that might make a difference - gcc
has improved over time.
>
> When I lookat at CPython sources a decade ago, they used method (3) when
> compiled on Linux. On Windows however, they used method (2), since it
> needs MSVC to build, which does not have the needed extension.
>
There's a lot of work been done on such bytecode interpreters. One of
the best-known experts, Anton Ertl, is the author of the GForth bytecode
interpreter. His code is all in gcc-extended C. (He gets really worked
up about some gcc optimisations "breaking" his "correct" code - we've
had a few disagreements of opinion on that topic. You'd like him :-) )
You may find some interesting papers on his webpage:
<http://www.complang.tuwien.ac.at/projects/interpreters.html>
He hangs out in comp.arch, and possibly other newsgroups.
> (My language also has label pointers, but it also has a built-in feature
> for computed-goto: you only have to tweak one line to change a regular
> switch-loop into one that uses computed-goto. That is, using multiple
> loop-back points so that each can have its own branch prediction.
>
> I don't use that in this product, only in a separate project.)
>
> -------------
>
> My (4) dispatcher uses thread-code functions that try and keep execution
> within a tight, register-based environment:
>
> * Essential globals are kept in registers
>
> * There is no function entry/exit code: each handler jumps directly to
> the next, without any loops
>
> * ABI considerations are put aside (eg. all non-volatiles are saved once
> at the beginning, and restored at the end)
>
> * Most handlers use inline assembly
>
> * When it is necessary to call a normal HLL handler, the environment
> must be saved and restored.
>
> This an example of a very simple handler that uses inline assembly:
>
> threadedproc j_jump*=
> assem
> mov Dprog,[Dprog+kopnda]
> *jumpnext
> end
> end
>
> And this is one which uses the HLL handler:
>
> threadedproc j_jumpptr*=
> saveregs
> k_jumpptr()
> loadregs
> jumpnext
> end
>
> saveregs/loadregs are macros. In both cases, 'jumpnext' is this macro
> (it needs * to invoke it from assembly):
>
> macro jumpnext = asm jmp [Dprog]
>
> So, the overheads of executing 'goto L' in the interpreted language are
> two machine instructions.
>
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-16 15:15 +0000 |
| Message-ID | <uo66i4$1g9n5$1@dont-email.me> |
| In reply to | #380184 |
On 15/01/2024 15:23, David Brown wrote:
> Let's look at an actual example from my own code, in an older project. I
> wanted an endian swap function on an ARM microcontroller, and for
> reasons that escape me for now, I did not want to use gcc's
> __builtin_bswap32, or an intrinsic from a header, or just plain C code
> (which modern gcc could optimise to a single "rev" instruction). The
> code was probably originally written for quite an old version of the
> compiler. So I wrote the function:
>
> static inline uint32_t swapEndian32(uint32_t x) {
> uint32_t y;
> asm ("rev %[y], %[x]" : [y] "=r" (y) : [x] "r" (x) : );
> return y;
> }
>
> This is, IMHO, quite clear once you know that gcc assembly consists of
> the assembly template, the outputs, then the inputs.
Well, you've explained it. But I'm none the wiser. Let's break it down
better:
rev %[y], %[x] # rev appears to be an ARM instruction:
# rev Rdest, Rsource
[y] "=r" (y) # Outputs?
[x] "r" (x) # Inputs?
You're telling gcc that somehow, the value of x needs to get into a
register (since rev doesn't work on memory, or immediates). And that the
new value of y needs to come from a register.
The compiler will decide which registers to use, and insert them into
that instruction. And it will ensure that x is loaded into its register,
if it is not already in one; and that y is loaded from its register, if
it is not already in the prefered one.
Since this is a return value, it will likely use R0 anyway.
But I'm inferring this from the way I know that 'rev' must work, and
from your comments. You seem to be expending a lot of effort however
into explaining it to gcc.
My function would be this on x64 (although I don't support bswap):
fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
This could have been shorter if 'bswap' had a separate dest register.
Here, knowing that x is always going to be rcx, I could have copied
straight from there, but would be bad form.
I think a useful enhancement to my scheme would be allow 'x' for example
to exist in static memory, stackframe, or in a register. The register
allocator for locals can be made to work with the assembly: it will only
choose registers that have not been used for anything else.
So, there are plenty of opportunities to make my scheme even better.
> And it generates
> the code optimally - when used in an expression, there will be no extra
> moves, or data put on the stack, or wasted registers. The compiler can
> move the code back and forth while optimising, eliminate calls when the
> result is used, and generally do its job just as well with this function
> as any other inline function or built in operator.
>
>>
>> You need to tell me, because I will otherwise not have a clue.
>
> It's clear that you haven't a clue. So how can you justify ranting and
> raving against something you don't understand?
I'm been familiar with x86 assembly for 40 years, so I should expect to
understand it! But the answer is simple: what gcc provides is little to
do with x86, and 90% of it seems made up.
>> From what I've seen of gcc inline asm:
>>
>> * Code has to be written within string literals,
>
> Yes, obviously. Assembly is not C, so writing assembly mixed in your C
> requires it to be in a format that is acceptable in C syntax (or at
> least close enough to C syntax to be a non-invasive extension). String
> literals are also quite amenable to generation by macros, for those that
> want to write something complicated.
So, how did I manage to get Intel-style assembly into my language? I
didn't need to use strings.
gcc should try harder!
>> in dreadfil AT&T
>> syntax.
>
> "Dreadful" is, again, /your/ opinion - not shared by everyone. (I
> personally don't care either way.)
This is the first hit for "at&t versus intel syntax":
https://imada.sdu.dk/u/kslarsen/dm546/Material/IntelnATT.htm
Its opinion is:
"The AT&T form for instructions involving complex operations is very
obscure compared to Intel syntax."
The second hit is from stackexchange and has the remark: "I personally
find "Intel syntax" much more readable, so that's why it surpises me."
The third hit is from stackoverflow, and starts: "To me, Intel syntax is
much easier to read."
The fourth hit offered no opinion (but chose to go with Intel).
The fifth is from Reddit and starts: "I'm curious whether more people
use Intel or AT&T syntax for x86_64 assembly language programming? I've
tried to use GNU GAS but found it a bit counterintuitive. On the other
hand, I used NASM, and it felt a lot better."
So, it's not just my opinion.
> It only applies to x86, not any
> other targets, and is easily changed by the "-masm=intel" flag
That's usually how I view gcc assembly output. But it still manages to
make it look terrible. Godbolt is much better as it filters out stuff
that is not relevant.
>> And apparently even with embedded \n line breaks. (Good
>> grief - I think early 80s BASICs had more sophisticated facilities!)
>
> That is an inevitability for string literals. And it doesn't matter
> much in practice, since most inline assembly (IME) consists of a single
> statement - gcc handles any moves that might be needed.
I'm sorry, but that is not writing 'assembly'.
> Remember, the compiler passes the assembly on to the assembler - this is
> /not/ a C compiler with a built-in assembler. And that's a good thing.
> Have you any idea how many assembly instructions there are for all the
> targets supported by gcc? And you'd need to update gcc every time there
> was a new instruction, rather than just updating the assembler (which is
> a lot simpler).
I wonder how many times people here have updated just 'as'? In any case,
there are a number of ways around it, but as you have pointed out, you
don't make serious use of assembly so it doesn't matter.
> Of course it would be /possible/ to extend gcc with a built-in
> assembler. But what would that give you? Lots of duplicate work to
> support C, C++, Fortran, Ada, and other languages?
On top of the duplicate work you already need to support C, C++, Fortran
and Ada?
Well, you can forget the last two. But a lower level language like C,
which is already known as a 'portable assembler', you'd think would have
better facilities.
I have a better idea: how about you take an existing, proper assembler,
and build a C compiler around it?
> The assembler
> already handles assembly - why make an HLL do it? It's a lot better to
> put the effort into reducing the number of times you actually need to
> write inline assembly, by improving the optimiser and builtin functions.
>
>>
>> * You mostly use offsets to get at local variables
>
> You never do that. You are imagining things. Or you are looking at
> some very odd inline assembly examples.
>
>>
>> * 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.
>
> Or, as sane people would say, you don't need to mess around trying to
> figure out what different registers are used for different purposes, or
> where your input data is, or where your output data should go - gcc will
> handle it all for you.
As I've said repeatedly, this not assembly. You have to ask exactly why
you need to use assembly. If it is in rare, special situations, then it
is not a big deal to think about how it will work with registers.
>>
>> 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
>
> Yes - and that's why it is so limited, and requires so much more
> assembly. I prefer to let the compiler do what the compiler is good at.
I do that when I write HLL code. But when I need ASM, it should be as
simple as possible:
a := asm rdtsc # low 32 bit of time stamp counter
println a
>>
>> * You can refer to variables directly (the compiler will add what is
>> needed to access locals or statics)
>
> I can refer to all the variables I want to - and coordinate with the
> compiler so that it knows what I am doing. Cooperation works far better
> than some arrogant pompous fool claiming they know better, and ruining
> the optimiser's work. Mind you, you wrote your compiler, so I suppose
> you /do/ know better than your compiler.
>
>>
>> If a function uses inline ASM, variables are kept in memory not
>> registers.
>
> What a terrible pessimation.
The need for assembly usually trumps whatever minor optimisation my
compiler might do.
>> (I might allow that at some point.) Most such functions however
>> contain only ASM.
>>
>
> What a terrible limitation.
I didn't mention a limitation. My remarks mean my functions can comprise
0% to 100% inline assembly, but quite often it will be 100%, by choice.
For example, routines to do 128-bit arithmetic.
>
>> 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...
>>
>
> There really isn't the slightest doubts there.
>
> I'll happily agree that your inline assembly is simpler. But in every
> other respect, it's not close to gcc's.
>
> But perhaps you don't care about efficient code generation (and to be
> fair, that is certainly not always important), and perhaps since your
> compiler doesn't do much optimising then there is little to be lost by
> failing to work along with the optimiser.
> And perhaps you have to write
> big sections of assembly because you can't write them in C and get fast
> results.
My last post mentioned an app where my inline assembly, even combined
with my non-optimised code for the rest, resulted in much faster
runtimes than achieved by transpiling to C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 18:46 +0100 |
| Message-ID | <uo6fe3$1i0eu$1@dont-email.me> |
| In reply to | #380243 |
On 16/01/2024 16:15, bart wrote:
> On 15/01/2024 15:23, David Brown wrote:
>
>> Let's look at an actual example from my own code, in an older project.
>> I wanted an endian swap function on an ARM microcontroller, and for
>> reasons that escape me for now, I did not want to use gcc's
>> __builtin_bswap32, or an intrinsic from a header, or just plain C code
>> (which modern gcc could optimise to a single "rev" instruction). The
>> code was probably originally written for quite an old version of the
>> compiler. So I wrote the function:
>>
>> static inline uint32_t swapEndian32(uint32_t x) {
>> uint32_t y;
>> asm ("rev %[y], %[x]" : [y] "=r" (y) : [x] "r" (x) : );
>> return y;
>> }
>>
>> This is, IMHO, quite clear once you know that gcc assembly consists of
>> the assembly template, the outputs, then the inputs.
>
> Well, you've explained it. But I'm none the wiser. Let's break it down
> better:
>
> rev %[y], %[x] # rev appears to be an ARM instruction:
Yes.
> # rev Rdest, Rsource
Yes.
> [y] "=r" (y) # Outputs?
Yes.
> [x] "r" (x) # Inputs?
Yes.
>
> You're telling gcc that somehow, the value of x needs to get into a
> register (since rev doesn't work on memory, or immediates). And that the
> new value of y needs to come from a register.
Yes.
>
> The compiler will decide which registers to use, and insert them into
> that instruction.
Yes.
> And it will ensure that x is loaded into its register,
> if it is not already in one; and that y is loaded from its register, if
> it is not already in the prefered one.
>
Yes.
All good here!
> Since this is a return value, it will likely use R0 anyway.
Well, that would be the case if "swapEndian32" were generated as a
stand-alone function. (Both x and y would use r0.) But as a small
static inline function, this would normally be inlined directly in
functions that use it :
#include <stdint.h>
uint32_t swapEndian32(uint32_t x) {
uint32_t y;
asm ("rev %[y], %[x]" : [y] "=r" (y) : [x] "r" (x) : );
return y;
}
void swap_lots(const uint32_t * restrict in, uint32_t * restrict out,
uint32_t n) {
while (n--) {
*out++ = swapEndian32(*in++);
*out++ = swapEndian32(*in++);
*out++ = swapEndian32(*in++);
*out++ = swapEndian32(*in++);
}
}
ARM GCC 13.2.0 with options "-O2 -Wall -Wextra -mcpu=cortex-m7" :
swapEndian32:
rev r0, r0
bx lr
swap_lots:
cbz r2, .L11
add ip, r2, #-1
adds r0, r0, #16
adds r1, r1, #16
push {r4, r5}
.L5:
add ip, ip, #-1
adds r1, r1, #16
cmp ip, #-1
ldrd r5, r4, [r0, #-16]
ldrd r2, r3, [r0, #-8]
rev r5, r5
rev r4, r4
rev r2, r2
rev r3, r3
add r0, r0, #16
strd r5, r4, [r1, #-32]
strd r2, r3, [r1, #-24]
bne .L5
pop {r4, r5}
bx lr
.L11:
bx lr
>
> But I'm inferring this from the way I know that 'rev' must work, and
> from your comments. You seem to be expending a lot of effort however
> into explaining it to gcc.
If you look at the "swap_lots" function above, you can see the
advantage. The compiler can use double-register loads and stores for
twice the memory efficiency (the Cortex-M7 has some 64-bit internal
buses), and it can schedule the instructions better (that core is
dual-issue and pipelined, but not OOO). This means the results are many
times faster than if everything were pushed sequentially through "rev
r0, r0".
>
> My function would be this on x64 (although I don't support bswap):
>
> fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
>
And how efficient would your "swap_lots" function be?
Here you can also see the massive advantage of gcc's use of string
assembly templates that it passes on to the assembler - you never get
the situation where the compiler doesn't support a particular assembly
instruction.
> This could have been shorter if 'bswap' had a separate dest register.
> Here, knowing that x is always going to be rcx, I could have copied
> straight from there, but would be bad form.
I agree that would be bad form, unless you know for sure that it would
always be in the one particular register. Again, gcc's syntax shines -
gcc will sort this out for you, generating any register moves that are
needed and skipping any that are unnecessary.
>
> I think a useful enhancement to my scheme would be allow 'x' for example
> to exist in static memory, stackframe, or in a register. The register
> allocator for locals can be made to work with the assembly: it will only
> choose registers that have not been used for anything else.
>
> So, there are plenty of opportunities to make my scheme even better.
>
Sure.
>
>
>> And it generates the code optimally - when used in an expression,
>> there will be no extra moves, or data put on the stack, or wasted
>> registers. The compiler can move the code back and forth while
>> optimising, eliminate calls when the result is used, and generally do
>> its job just as well with this function as any other inline function
>> or built in operator.
>>
>>>
>>> You need to tell me, because I will otherwise not have a clue.
>>
>> It's clear that you haven't a clue. So how can you justify ranting
>> and raving against something you don't understand?
>
> I'm been familiar with x86 assembly for 40 years, so I should expect to
> understand it! But the answer is simple: what gcc provides is little to
> do with x86, and 90% of it seems made up.
Oh, I know you understand x86 assembly. It's the gcc inline assembly
you didn't understand at all. (Now you understand a good deal about it.)
>
>
>>> From what I've seen of gcc inline asm:
>>>
>>> * Code has to be written within string literals,
>>
>> Yes, obviously. Assembly is not C, so writing assembly mixed in your
>> C requires it to be in a format that is acceptable in C syntax (or at
>> least close enough to C syntax to be a non-invasive extension).
>> String literals are also quite amenable to generation by macros, for
>> those that want to write something complicated.
>
> So, how did I manage to get Intel-style assembly into my language? I
> didn't need to use strings.
Your language is not C either.
>
> gcc should try harder!
No, it has a solution that works fine. It needs somewhat more
punctuation than optimal, but otherwise it's good enough for the purpose.
Of course it would always be possible to do better. But mixing in a
completely different kind of language in the middle of a high level
language is not helpful. You'd need to make huge changes to the parsers
just to handle the mix of line-oriented assembly and non-line-oriented
main code (in all the languages that gcc supports - in the main tree,
and all the extra ones run as separate projects). You'd need to deal
with the dozens of different mainline targets (and the other targets
that are separate projects). You'd need to keep updating this for every
little change to every processor target - duplicating work done already
by binutils and other assemblers. You'd then want to change clang, icc,
CodeWarrior, and other C compilers (and their C++ counterparts, and
their Rust, D, Pascal, and anything else that supports inline assembly)
- or you'd lose compatibility. Oh, and then you'd want to change all
the existing uses of inline gcc in user code.
It would be an enormous effort, merely to give a minor convenience
improvement to the tiny proportion of gcc users who ever write inline
assembly. (Many /use/ it, with pre-written code in headers, but they
don't /write/ it themselves.)
>
>
>>> in dreadfil AT&T
>>> syntax.
>>
>> "Dreadful" is, again, /your/ opinion - not shared by everyone. (I
>> personally don't care either way.)
>
> This is the first hit for "at&t versus intel syntax":
> https://imada.sdu.dk/u/kslarsen/dm546/Material/IntelnATT.htm
>
> Its opinion is:
>
> "The AT&T form for instructions involving complex operations is very
> obscure compared to Intel syntax."
Yes, /opinion/ is the key point.
That post also says "The advantage of AT&T syntax in this situation is
obvious".
I have no horse in this race - I don't care either way. People can have
whatever preferences and dislikes they want.
One thing we can be sure of is that numbers do not turn opinions into facts.
The reality is that AT&T syntax can be simpler and neater for some
things, while Intel syntax can be simpler and neater for others. I
don't think either of them are particularly good or clear. I don't
think AT&T's way of writing scaled indexing is good - I don't think
Intel's "DWORD PTR" stuff is at all nice or necessary. My opinion is
that they are equally bad in different ways, but I can live with either.
>
> So, it's not just my opinion.
I never suggested you were alone. But it is just opinion - not fact.
>
>> It only applies to x86, not any other targets, and is easily changed
>> by the "-masm=intel" flag
>
> That's usually how I view gcc assembly output. But it still manages to
> make it look terrible. Godbolt is much better as it filters out stuff
> that is not relevant.
>
gcc assembly output can be controlled in various ways (and you can get
an output listing from the assembler too, or use objdump on the
resulting binaries or object files). But of course the assembly
generated by gcc has lots of directives - it has to convey a great deal
of extra information downstream for things like debugging information.
>
>>> And apparently even with embedded \n line breaks. (Good
>>> grief - I think early 80s BASICs had more sophisticated facilities!)
>>
>> That is an inevitability for string literals. And it doesn't matter
>> much in practice, since most inline assembly (IME) consists of a
>> single statement - gcc handles any moves that might be needed.
>
> I'm sorry, but that is not writing 'assembly'.
It is writing inline assembly.
We are not talking about writing full programs in assembly here - we are
writing minimal pieces of assembly, integrated along with a high level
language. If one instruction is all that's needed, then that's all that
is needed.
>
>> Remember, the compiler passes the assembly on to the assembler - this
>> is /not/ a C compiler with a built-in assembler. And that's a good
>> thing. Have you any idea how many assembly instructions there are for
>> all the targets supported by gcc? And you'd need to update gcc every
>> time there was a new instruction, rather than just updating the
>> assembler (which is a lot simpler).
>
> I wonder how many times people here have updated just 'as'?
The toolchain developers will.
> In any case,
> there are a number of ways around it, but as you have pointed out, you
> don't make serious use of assembly so it doesn't matter.
For /serious/ use of assembly - writing large sections of assembly -
then it might be more convenient to write pure assembly files. But it's
certainly entirely possible to write large sections of gcc inline
assembly. But it is almost never a good idea to write assembly if you
can get the same results writing HLL code.
>
>> Of course it would be /possible/ to extend gcc with a built-in
>> assembler. But what would that give you? Lots of duplicate work to
>> support C, C++, Fortran, Ada, and other languages?
>
> On top of the duplicate work you already need to support C, C++, Fortran
> and Ada?
Yes, on top of that.
>
> Well, you can forget the last two.
Why? People use inline assembly in Fortran and Ada.
> But a lower level language like C,
> which is already known as a 'portable assembler', you'd think would have
> better facilities.
C is not, and never has been, a "portable assembler". The fact that
some people are badly mistaken about this does not make it a relevant
factor for what a C compiler should or should not support.
And gcc has vastly better inline assembly facilities than your language
and tools. /Vastly/ better. I thought I'd demonstrated that by now -
but perhaps it's just a question of the order that posts have been read
and written. I can't blame you for misconceptions you held and wrote
about before you read more about gcc's inline assembly (and before I
explained it more fully).
I don't claim, in any way, that gcc's inline assembly syntax is perfect
(quite aside from any opinions on AT&T vs Intel - after all, x86
assembly is not something I use or care about). But I /do/ claim it is
entirely useable, extremely powerful, and is used to great effect by
lots of people.
>
> I have a better idea: how about you take an existing, proper assembler,
> and build a C compiler around it?
And who would benefit?
Seriously - /why/ do you think it is important for gcc to have a neater
syntax for inline assembly? Would more people use it than do today -
and would that be a good thing? Would the people who use it today make
fewer mistakes? Would they be able to write it more efficiently, and
would that be a significant impact on their work?
Let's take an example from before:
void F(void) {
int b=2, c=3;
static int d=4;
asm ("imul %[c], %[d]\n\t"
"add %[c], %[b]\n\t"
: [c] "+r" (c) : [b] "g" (b), [d] "g" (d));
a = c;
}
Suppose gcc's inline assembly was changed to remove the need for
quotation marks and to put the input and output operands first, with a
fuller syntax. (I'm keeping the principle of these operands, and the
assembly template, as they are vital to functionality.) This would,
IMHO, be a step forward in looking nice:
void FF(void) {
int b=2, c=3;
static int d=4;
asm(
input g : op_b = b;
input g : op_d = d;
inout r : op_c = c;
{
imul op_c, op_d
add op_c, op_b
});
a = c;
}
What do we actually win here? The costs are significant efforts to
change the parsers, and incompatibility with other compilers and code.
What are the gains, who gains, and is it worth it? I just can't see it.
Now, if gcc were to get a multiline string feature like Python, /then/
we'd be getting somewhere. Adding that one feature would be really nice
in many places in C and C++ code, and would mean that - for free - you'd
get this step up:
void F(void) {
int b=2, c=3;
static int d=4;
asm ("""
imul %[c], %[d]
add %[c], %[b]
""" : [c] "+r" (c) : [b] "g" (b), [d] "g" (d));
a = c;
}
The strings are simpler, and there's no ugly line endings or \t codes.
>
>> The assembler already handles assembly - why make an HLL do it?
>> It's a lot better to put the effort into reducing the number of times
>> you actually need to write inline assembly, by improving the optimiser
>> and builtin functions.
>>
>>>
>>> * You mostly use offsets to get at local variables
>>
>> You never do that. You are imagining things. Or you are looking at
>> some very odd inline assembly examples.
>>
>>>
>>> * 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.
>>
>> Or, as sane people would say, you don't need to mess around trying to
>> figure out what different registers are used for different purposes,
>> or where your input data is, or where your output data should go - gcc
>> will handle it all for you.
>
> As I've said repeatedly, this not assembly. You have to ask exactly why
> you need to use assembly. If it is in rare, special situations, then it
> is not a big deal to think about how it will work with registers.
>
You only need assembly on rare occasions - as long as your HLL and
compiler are good enough. That is precisely why it is okay if inline
assembly is a bit cumbersome.
But I've no idea why you think something is only assembly if you have to
mess around with registers manually. It's a "no true Scotsman"
argument, with no content. Still, if you want to do that, gcc inline
assembly won't hinder you.
>>>
>>> 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
>>
>> Yes - and that's why it is so limited, and requires so much more
>> assembly. I prefer to let the compiler do what the compiler is good at.
>
> I do that when I write HLL code. But when I need ASM, it should be as
> simple as possible:
>
> a := asm rdtsc # low 32 bit of time stamp counter
> println a
>
What about a 64-bit version?
static inline uint64_t get_timestamp64(void) {
uint64_t lo, hi;
asm volatile ( "rdtsc" : "=a" (lo), "=d" (hi) );
return lo | (hi << 32);
}
static inline uint32_t get_timestamp32(void) {
uint32_t lo;
asm volatile ( "rdtsc" : "=a" (lo) :: "rdx" );
return lo;
}
It's not hugely difficult. And it doesn't have risks like causing
trouble if the compiler used the "d" register for something else.
Mind you, if I had to work with a compiler and HLL that didn't support
inlining, or macros, I suppose I might think a little differently. I
would not want to have to copy and paste any kind of inline assembly
every time I want to use it without the overhead of a function call.
Fortunately, I use a good compiler and good languages, so that is not a
concern for me.
>
>>>
>>> * You can refer to variables directly (the compiler will add what is
>>> needed to access locals or statics)
>>
>> I can refer to all the variables I want to - and coordinate with the
>> compiler so that it knows what I am doing. Cooperation works far
>> better than some arrogant pompous fool claiming they know better, and
>> ruining the optimiser's work. Mind you, you wrote your compiler, so I
>> suppose you /do/ know better than your compiler.
>>
>>>
>>> If a function uses inline ASM, variables are kept in memory not
>>> registers.
>>
>> What a terrible pessimation.
>
> The need for assembly usually trumps whatever minor optimisation my
> compiler might do.
>
Ah, there we differ. I use tools that do good optimisations. And
perhaps 70% of the use-cases of inline assembly will be lost if the tool
can't generate efficient code when there is inline assembly.
>
>>> (I might allow that at some point.) Most such functions however
>>> contain only ASM.
>>>
>>
>> What a terrible limitation.
>
> I didn't mention a limitation. My remarks mean my functions can comprise
> 0% to 100% inline assembly, but quite often it will be 100%, by choice.
> For example, routines to do 128-bit arithmetic.
Fair enough - I misunderstood. (For some C compilers I have used,
functions are /either/ C /or/ assembly - you can't mix them.)
>
>>
>>> 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...
>>>
>>
>> There really isn't the slightest doubts there.
>>
>> I'll happily agree that your inline assembly is simpler. But in every
>> other respect, it's not close to gcc's.
>>
>> But perhaps you don't care about efficient code generation (and to be
>> fair, that is certainly not always important), and perhaps since your
>> compiler doesn't do much optimising then there is little to be lost by
>> failing to work along with the optimiser.
>
>
>> And perhaps you have to write big sections of assembly because you
>> can't write them in C and get fast results.
>
> My last post mentioned an app where my inline assembly, even combined
> with my non-optimised code for the rest, resulted in much faster
> runtimes than achieved by transpiling to C.
Yes - and I agree that it can happen. But see my reply in to that other
post for a challenge, if you are interested. (No pressure.)
[toc] | [prev] | [next] | [standalone]
Page 24 of 34 — ← Prev page 1 … 22 23 [24] 25 26 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web