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 23 of 34 — ← Prev page 1 … 21 22 [23] 24 25 … 34 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-17 13:43 +0100 |
| Message-ID | <uo8i1h$20dpf$1@dont-email.me> |
| In reply to | #380292 |
On 17/01/2024 02:04, Chris M. Thomasson wrote:
> On 1/16/2024 6:06 AM, David Brown wrote:
>> Well, you don't often write inline assembly - its rare to write it.
>> It's typically the kind of thing you write once for your particular
>> instruction, then stick it away in a header somewhere. You might use
>> it often, but you don't need to read or edit the code often.[...]
>
> As soon as you use inline assembler in a file, you sort of "need" to?
Nonsense.
How often do you use headers from the standard library, or third party
libraries, or other code? All the time, I'd assume. How often do you
read through these headers? Very rarely. How often do you edit them?
Never.
You do not need to read code of any kind, in order to use it.
Some kinds of code can be considered advanced, or ugly, or hard to
comprehend. inline assembly often falls into that category, as do
complicated macros, and some of the more cryptic corners of C++. That
code should be written by someone who knows what they are doing, tested
well, the interface described, and then the code is hidden away. Most
other people using the code never see it, and might not understand it
even if they did.
It is entirely reasonable to structure your headers like this:
// Return x + (y * z)
static inline int madd(int x, int y, int z);
...
// Implementation details
static inline int madd(int x, int y, int z) {
asm (...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-17 13:00 -0800 |
| Message-ID | <uo9f4m$26mk4$2@dont-email.me> |
| In reply to | #380329 |
On 1/17/2024 4:43 AM, David Brown wrote:
> On 17/01/2024 02:04, Chris M. Thomasson wrote:
>> On 1/16/2024 6:06 AM, David Brown wrote:
>
>>> Well, you don't often write inline assembly - its rare to write it.
>>> It's typically the kind of thing you write once for your particular
>>> instruction, then stick it away in a header somewhere. You might use
>>> it often, but you don't need to read or edit the code often.[...]
>>
>> As soon as you use inline assembler in a file, you sort of "need" to?
>
> Nonsense.
If I use inline asm in a file, I at least need to add in comments that
this is arch specific code. A macro for the arch also might be in order.
So, if the user compiles it on a different arch, well, the inline asm is
eluded. Why is that wrong? You never did that before?
>
> How often do you use headers from the standard library, or third party
> libraries, or other code? All the time, I'd assume. How often do you
> read through these headers? Very rarely. How often do you edit them?
> Never.
>
> You do not need to read code of any kind, in order to use it.
>
> Some kinds of code can be considered advanced, or ugly, or hard to
> comprehend. inline assembly often falls into that category, as do
> complicated macros, and some of the more cryptic corners of C++. That
> code should be written by someone who knows what they are doing, tested
> well, the interface described, and then the code is hidden away. Most
> other people using the code never see it, and might not understand it
> even if they did.
>
>
> It is entirely reasonable to structure your headers like this:
>
> // Return x + (y * z)
> static inline int madd(int x, int y, int z);
>
> ...
>
> // Implementation details
> static inline int madd(int x, int y, int z) {
> asm (...
>
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-18 13:00 +0100 |
| Message-ID | <uob3s3$2isoa$1@dont-email.me> |
| In reply to | #380370 |
On 17/01/2024 22:00, Chris M. Thomasson wrote: > On 1/17/2024 4:43 AM, David Brown wrote: >> On 17/01/2024 02:04, Chris M. Thomasson wrote: >>> On 1/16/2024 6:06 AM, David Brown wrote: >> >>>> Well, you don't often write inline assembly - its rare to write it. >>>> It's typically the kind of thing you write once for your particular >>>> instruction, then stick it away in a header somewhere. You might >>>> use it often, but you don't need to read or edit the code often.[...] >>> >>> As soon as you use inline assembler in a file, you sort of "need" to? >> >> Nonsense. > > If I use inline asm in a file, I at least need to add in comments that > this is arch specific code. A macro for the arch also might be in order. > So, if the user compiles it on a different arch, well, the inline asm is > eluded. Why is that wrong? You never did that before? > There's nothing at all wrong with that. My disagreement was with your suggestion that people using inline assembly (defined in a header written by someone else) need to be able to read and/or edit the code.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-18 13:28 -0800 |
| Message-ID | <uoc56s$2ogor$4@dont-email.me> |
| In reply to | #380407 |
On 1/18/2024 4:00 AM, David Brown wrote: > On 17/01/2024 22:00, Chris M. Thomasson wrote: >> On 1/17/2024 4:43 AM, David Brown wrote: >>> On 17/01/2024 02:04, Chris M. Thomasson wrote: >>>> On 1/16/2024 6:06 AM, David Brown wrote: >>> >>>>> Well, you don't often write inline assembly - its rare to write it. >>>>> It's typically the kind of thing you write once for your particular >>>>> instruction, then stick it away in a header somewhere. You might >>>>> use it often, but you don't need to read or edit the code often.[...] >>>> >>>> As soon as you use inline assembler in a file, you sort of "need" to? >>> >>> Nonsense. >> >> If I use inline asm in a file, I at least need to add in comments that >> this is arch specific code. A macro for the arch also might be in >> order. So, if the user compiles it on a different arch, well, the >> inline asm is eluded. Why is that wrong? You never did that before? >> > > There's nothing at all wrong with that. My disagreement was with your > suggestion that people using inline assembly (defined in a header > written by someone else) need to be able to read and/or edit the code. > Completely fair enough. Thanks, David! :^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-18 21:58 -0800 |
| Message-ID | <uod319$30j2c$6@dont-email.me> |
| In reply to | #380434 |
On 1/18/2024 1:28 PM, Chris M. Thomasson wrote: > On 1/18/2024 4:00 AM, David Brown wrote: >> On 17/01/2024 22:00, Chris M. Thomasson wrote: >>> On 1/17/2024 4:43 AM, David Brown wrote: >>>> On 17/01/2024 02:04, Chris M. Thomasson wrote: >>>>> On 1/16/2024 6:06 AM, David Brown wrote: >>>> >>>>>> Well, you don't often write inline assembly - its rare to write >>>>>> it. It's typically the kind of thing you write once for your >>>>>> particular instruction, then stick it away in a header somewhere. >>>>>> You might use it often, but you don't need to read or edit the >>>>>> code often.[...] >>>>> >>>>> As soon as you use inline assembler in a file, you sort of "need" to? >>>> >>>> Nonsense. >>> >>> If I use inline asm in a file, I at least need to add in comments >>> that this is arch specific code. A macro for the arch also might be >>> in order. So, if the user compiles it on a different arch, well, the >>> inline asm is eluded. Why is that wrong? You never did that before? >>> >> >> There's nothing at all wrong with that. My disagreement was with your >> suggestion that people using inline assembly (defined in a header >> written by someone else) need to be able to read and/or edit the code. >> > > Completely fair enough. Thanks, David! :^) Actually, iirc, my friend Joe Seigh had a nice inline impl of cmpxchg8b over on comp.programming.threads many moons ago...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-18 21:55 -0800 |
| Message-ID | <uod2s2$30j2c$5@dont-email.me> |
| In reply to | #380407 |
On 1/18/2024 4:00 AM, David Brown wrote: > On 17/01/2024 22:00, Chris M. Thomasson wrote: >> On 1/17/2024 4:43 AM, David Brown wrote: >>> On 17/01/2024 02:04, Chris M. Thomasson wrote: >>>> On 1/16/2024 6:06 AM, David Brown wrote: >>> >>>>> Well, you don't often write inline assembly - its rare to write it. >>>>> It's typically the kind of thing you write once for your particular >>>>> instruction, then stick it away in a header somewhere. You might >>>>> use it often, but you don't need to read or edit the code often.[...] >>>> >>>> As soon as you use inline assembler in a file, you sort of "need" to? >>> >>> Nonsense. >> >> If I use inline asm in a file, I at least need to add in comments that >> this is arch specific code. A macro for the arch also might be in >> order. So, if the user compiles it on a different arch, well, the >> inline asm is eluded. Why is that wrong? You never did that before? >> > > There's nothing at all wrong with that. My disagreement was with your > suggestion that people using inline assembly (defined in a header > written by someone else) need to be able to read and/or edit the code. > Did I necessarily imply that? If so, I apologize.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-18 22:02 -0800 |
| Message-ID | <uod39o$30j2c$7@dont-email.me> |
| In reply to | #380458 |
On 1/18/2024 9:55 PM, Chris M. Thomasson wrote: > On 1/18/2024 4:00 AM, David Brown wrote: >> On 17/01/2024 22:00, Chris M. Thomasson wrote: >>> On 1/17/2024 4:43 AM, David Brown wrote: >>>> On 17/01/2024 02:04, Chris M. Thomasson wrote: >>>>> On 1/16/2024 6:06 AM, David Brown wrote: >>>> >>>>>> Well, you don't often write inline assembly - its rare to write >>>>>> it. It's typically the kind of thing you write once for your >>>>>> particular instruction, then stick it away in a header somewhere. >>>>>> You might use it often, but you don't need to read or edit the >>>>>> code often.[...] >>>>> >>>>> As soon as you use inline assembler in a file, you sort of "need" to? >>>> >>>> Nonsense. >>> >>> If I use inline asm in a file, I at least need to add in comments >>> that this is arch specific code. A macro for the arch also might be >>> in order. So, if the user compiles it on a different arch, well, the >>> inline asm is eluded. Why is that wrong? You never did that before? >>> >> >> There's nothing at all wrong with that. My disagreement was with your >> suggestion that people using inline assembly (defined in a header >> written by someone else) need to be able to read and/or edit the code. >> > > Did I necessarily imply that? If so, I apologize. Wrt my sync code, alter it and you break it. Don't try to play games with it. If you do, I am not liable.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-16 15:55 +0000 |
| Message-ID | <2GxpN.207474$PuZ9.8349@fx11.iad> |
| In reply to | #380230 |
bart <bc@freeuk.com> writes: >On 16/01/2024 01:21, Kaz Kylheku wrote: >> On 2024-01-15, bart <bc@freeuk.com> wrote: > >[Inline assembly] > >> The instruction template is just a string literal to the >> compiler. It specifies text to be inserted into the assembly >> output. >> >> Some assembly languages require the whitespace; you need >> instructions to be on separate lines. >> >> GCC does not look inside this template other than to replace >> % codes like %0 (the first register). >> >> In my example, I put the newlines and tabs together on the right >> >> "imul %3, %2\n\t" >> "add %1, %2\n\t" >> "mov %1, %0\n\t" >> >> Thanks to these newlines and tabs, the textual output (generated .s >> file if we use gcc -S) has this in it: >> >> #APP >> # 24 "inline.c" 1 >> imul %edx, %esi >> add %esi, %edi >> mov %edi, %edi >> >> # 0 "" 2 >> #NO_APP >> movl 8(%rsp), %eax >> movl 16(%rsp), %edx >> > >This is still peculiar: why prioritise the appearance of the >intermediate code which I assume you're rarely going to look at? What leads you to the belief that anyone is 'prioritizing' the appearance of intermediate code?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-16 18:39 +0000 |
| Message-ID | <20240116100845.82@kylheku.com> |
| In reply to | #380230 |
On 2024-01-16, bart <bc@freeuk.com> wrote:
> On 16/01/2024 01:21, Kaz Kylheku wrote:
>> On 2024-01-15, bart <bc@freeuk.com> wrote:
>
> [Inline assembly]
>
>> The instruction template is just a string literal to the
>> compiler. It specifies text to be inserted into the assembly
>> output.
>>
>> Some assembly languages require the whitespace; you need
>> instructions to be on separate lines.
>>
>> GCC does not look inside this template other than to replace
>> % codes like %0 (the first register).
>>
>> In my example, I put the newlines and tabs together on the right
>>
>> "imul %3, %2\n\t"
>> "add %1, %2\n\t"
>> "mov %1, %0\n\t"
>>
>> Thanks to these newlines and tabs, the textual output (generated .s
>> file if we use gcc -S) has this in it:
>>
>> #APP
>> # 24 "inline.c" 1
>> imul %edx, %esi
>> add %esi, %edi
>> mov %edi, %edi
>>
>> # 0 "" 2
>> #NO_APP
>> movl 8(%rsp), %eax
>> movl 16(%rsp), %edx
>>
>
> This is still peculiar: why prioritise the appearance of the
> intermediate code which I assume you're rarely going to look at?
The the assembly language is whitespace sensitive. It requires
the newlines; and possibly also the leading indentation.
Chances are good you will look at the assembly output while
debugging.
> It's the version with strings and escape codes that you're going to be
> writing and maintaining, and that people will see in the C sources!
>
> This is akin to a language allowing embedded C but you have to write it
> like this:
>
> clang{"\tprintf(\"A=%%d\\n\", a);\n"};
>
> so that the generated version looks like:
>
> printf("A=%d\n", a);
Support for a multi-line string literal which allows literal
newlines to denote themselves would also work.
> Except you can't refer to 'a' directly, you have to write it as %0 and
> then have some extra mechanism to somehow map that to 'a'.
You *can* refer to registers directly in GCC inline assembly.
You just usually don't *want* to.
There has to be a good reason for that, like using a certain instruction
that only takes specific register as a source or destination operand.
(When you use a specific register in the template, you must inform the
compiler by including it in the list of "clobbers". Clobbers
are the last argument:
asm ("template" : outputs : inputs : clobbers)
if we clobber rax and rdx the clobbers might look like "rax", "rdx".
Then the compiler knows that if some variable is held in any of those
registers, it must be spilled to memory before that code can be executed
(or some other strategy must be taken, like not allocating those
registers).
>> You can understand why GCC went with this textual templating approach, since
>> the number of back-end assembly languages is astonishing. In some cases, I
>> think, GCC supports more than one assembler syntax for the same architecture.
>> Historically it has worked with assemblers that didn't come from GNU.
>
> gcc is a project 10s of 1000s of files. If a particular configuration
> targets one architecture out of 100, it can also support the ASM syntax
> for that architecture.
Not reasonably so. The parser of every front end would have to have
a special case for that assembly language.
The proposal does not pass a cost/benefit analysis, due to the
high cost and low benefit.
> You don't need to have the ASM syntax embedded within the C grammar. Not
> so specifically anyway; you allow a bunch of keyword and register tokens
> within asm{...}.
keywords and tokens are grammar.
A reasonable compromise would be to have some multi-line literal.
> Yes it's a bit harder, but if I can do it within a 0.3MB product, gcc
> can do it within 24MB.
That's quite literally fallacious. A big project worked on by many
people and widely used simply cannot do anything that a tiny one-person
project can do. Not at the process level, nor the code change level.
For that matter, in a one-person compiler that targets twelve
architectures, we wouldn't necessarily approach inline assembly the same
way as one which targets only x86.
>> It would not be practical for GNU C to have a bazillino assembly language
>> syntaxes in its grammar.
>>
>>> Just admit that my approach to inline assembler is better and give it up.
>>
>> Your approach to inline assembler has nicer looking syntax, but
>> semantically, it doesn't seem to be on same level as the GCC approach.
>>
>> GCC's inline assembly does nice things that are might not be possible in your
>> implementation. (Or pretty much anyone else's).
>>
>> Some of it has been sufficiently exemplified elsewhere in the thread.
>>
>> GCC can choose registers for your inline assembly block,
>
> The point of ASM is that /you/ call the shots.
Why don't you educate the GCC mailing list?
In the GNU C inline assembly (called "Extended Assembly") you do call
the shots. The instructions in your template are used verbatim: no
instructions are added, deleted or renamed. You just have to
coordinate with the compiler. If you don't inform the compiler about
what you are doing, things will go wrong. Optionally, you can request
that the compiler prepare operands for you and give you registers.
> It's not just more natural syntax, but better integration within the
No man-made syntax is natural.
> host language. More example, I can 'goto' to a label within an ASSEM
> block, and 'jmp' out of the ASSEM block to a HLL label, or to an label
> within a separate ASSEM block further on.
I don't know whether GCC inline assembly can do that or not. While
you probably can't refer to an ordinary C goto label, GCC does have
computed labels. Ther is a way to capture a label as a void * value
I think. If you can get that as an operand into an asm block, it may
be possible to jump to it.
It doesn't strike me as a great idea, honestly.
>> and will automatically
>> move between those registers and the operands they are connected to (if
>> necessary). The inline code seamlessly integrates with the code generated by
>> the compiler. You can write primitives that generate code as well as compiler
>> built-ins.
>
> OK. But it's not an 'assembler' as is generally understood.
Yes it is; it uses assembly language instructions, which are integrated
into assembly language output, fed into an assembler.
The fact that operands like %1 are replaced by registers just means
that it's a kind of macro assembly language.
> Mine is; it
> looks exactly line normal assembly, and it is written inline to the HLL.
Yes, and you do get points, from other programmers who have access to
the code, for it looking nice, and paying homage to Intel.
The machine running the end result and the users don't care so much.
The GNU "Extended Asm" as the documentation calls it has fantastic
functionality though, due to the way you can declare contracts between
the assembly fragment and the compiler.
How things look does become important when you are writing tens of
thousands of lines of code. Extended Asm isn't used for even hundreds of
lines of code. In a typical project that needs any inline assembly at
all, it's a very small amount of code.
A large block of assembly will more likely be written as a .S file,
not inline.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-17 00:11 +0000 |
| Message-ID | <uo75um$1lq3e$1@dont-email.me> |
| In reply to | #380260 |
On 16/01/2024 18:39, Kaz Kylheku wrote:
> On 2024-01-16, bart <bc@freeuk.com> wrote:
>> gcc is a project 10s of 1000s of files. If a particular configuration
>> targets one architecture out of 100, it can also support the ASM syntax
>> for that architecture.
>
> Not reasonably so. The parser of every front end would have to have
> a special case for that assembly language.
>
> The proposal does not pass a cost/benefit analysis, due to the
> high cost and low benefit.
>
>> You don't need to have the ASM syntax embedded within the C grammar. Not
>> so specifically anyway; you allow a bunch of keyword and register tokens
>> within asm{...}.
>
> keywords and tokens are grammar.
So how does the grammar of HTML work: does it also include the entire
grammar of JavaScript?
JS appears inside <script> ... </script> tags.
My assemble appears in a 'assem ... end block', or there's a one-liner
version which starts with 'asm'.
When my parser sees 'assem' or 'asm', it calls one of these functions:
if lx.subcode=0 then
p:=readassemline()
else
p:=readassemblock()
fi
They are in a 250-line module that deals with assembly. They return an
'assem' AST node.
Now, my assembly syntax is not Intel, just Intel style, and is flavoured
with elements of my HLL syntax (so uses 'u32' for example rather than
'dword').
There is a separate set of tables within the target-specific backend,
which contains all the supported x64 opcodes and registgers for example.
This part is needed anyway to generate x64 native code, whether assembly
source or binary.
When the global symbol table is initialised, the contents of those
opcode and register tables are added to it.
It's done in a way so that, if not in an ASM block, those can be used as
normal identifiers:
int mov, rax, push
mov := rax + push
If I wanted to refer to those from inline assembly, I have to escape them:
asm push [`push]
So, with a different architecture, I have a different backend and
different set opcode and register names.
The 250-line parsing module could possibly be made to deal with more
than one target, otherwise it's not a great imposition.
This stuff needn't be that hard. There just seems unwillingness to make
things easy and sensible.
Perhaps in a world full of C macros, makefile syntax and bash scripts,
the assembly syntax isn't considered too outre.
But, you say assembly isn't used much; have you considered that that
might be because it's such a pig to use?
> How things look does become important when you are writing tens of
> thousands of lines of code.
But not thousands, or even hundreds? Or dozens? Code can always benefit
from being readable and also not being painful to type.
Personally I think /any/ conventional assembly looks dreadful in even
small amounts, including mine. But gcc-style is a LOT worse.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-17 16:11 +0000 |
| Message-ID | <K_SpN.168166$vFZa.134000@fx13.iad> |
| In reply to | #380287 |
bart <bc@freeuk.com> writes:
>On 16/01/2024 18:39, Kaz Kylheku wrote:
>> On 2024-01-16, bart <bc@freeuk.com> wrote:
>
>>> gcc is a project 10s of 1000s of files. If a particular configuration
>>> targets one architecture out of 100, it can also support the ASM syntax
>>> for that architecture.
>>
>> Not reasonably so. The parser of every front end would have to have
>> a special case for that assembly language.
>>
>> The proposal does not pass a cost/benefit analysis, due to the
>> high cost and low benefit.
>>
>>> You don't need to have the ASM syntax embedded within the C grammar. Not
>>> so specifically anyway; you allow a bunch of keyword and register tokens
>>> within asm{...}.
>>
>> keywords and tokens are grammar.
>
>So how does the grammar of HTML work: does it also include the entire
>grammar of JavaScript?
>
>JS appears inside <script> ... </script> tags.
From the structured general markup language, or extensable markup
language (SGML/XML) perspective, anything between tags is completely
invisible. Semantics of any tag is Application dependent.
HTML (a non-proper subset of XML) applies semantics to
tags defined by HTML such as <script/>, <a/>, et alia.
An HTML interpreter interprets the tags and will pass the
data to the appropriate entity (in this case, a javascript
or ecmascript interpreter).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-18 21:42 -0800 |
| Message-ID | <uod24r$30j2c$3@dont-email.me> |
| In reply to | #380198 |
On 1/15/2024 10:55 AM, bart wrote: > On 15/01/2024 17:35, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: > >>> You're having a laugh, surely? >> >> No. I'm serious. [DWORD] is useless cruft. > > I don't use [DWORD], whatever that means. > > Meanwhile %% in front of every register name, f after a label, and "" > and \n and \t on every line is useful cruft! > >>> AT&T is bad enough even without the >>> travesty of it displayed here: >>> >>> "jmp 2f\n" >>> "3:\tmovsx %%bx, %%rbx\n\t" >> >> If you don't understand the standard C escapes, you really >> should go back to read the standard carefluly. > > I understand C escape codes. I am asking WHAT THE FUCK ARE THEY DOING IN > EVERY LINE OF AN ASSEMBLY PROGRAM? > > You're doing this on purpose aren't you? > > >> >>> >>> What's with the strings, newline and tab escapes? What's that 'f' for? >> >> RTFM for the architecture dependent assembler that the compiler >> driver will end up calling to build the output object file. > > So you don't actually know. > > Just admit that my approach to inline assembler is better and give it up. Next time I have to inline asm, I will play this music in my office, really loud! lol. https://youtu.be/PeYUTbU_iTw
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-18 21:44 -0800 |
| Message-ID | <uod27n$30j2c$4@dont-email.me> |
| In reply to | #380456 |
On 1/18/2024 9:42 PM, Chris M. Thomasson wrote: > On 1/15/2024 10:55 AM, bart wrote: >> On 15/01/2024 17:35, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: >> >>>> You're having a laugh, surely? >>> >>> No. I'm serious. [DWORD] is useless cruft. >> >> I don't use [DWORD], whatever that means. >> >> Meanwhile %% in front of every register name, f after a label, and "" >> and \n and \t on every line is useful cruft! >> >>>> AT&T is bad enough even without the >>>> travesty of it displayed here: >>>> >>>> "jmp 2f\n" >>>> "3:\tmovsx %%bx, %%rbx\n\t" >>> >>> If you don't understand the standard C escapes, you really >>> should go back to read the standard carefluly. >> >> I understand C escape codes. I am asking WHAT THE FUCK ARE THEY DOING >> IN EVERY LINE OF AN ASSEMBLY PROGRAM? >> >> You're doing this on purpose aren't you? >> >> >>> >>>> >>>> What's with the strings, newline and tab escapes? What's that 'f' for? >>> >>> RTFM for the architecture dependent assembler that the compiler >>> driver will end up calling to build the output object file. >> >> So you don't actually know. >> >> Just admit that my approach to inline assembler is better and give it up. > > Next time I have to inline asm, I will play this music in my office, > really loud! lol. https://youtu.be/PeYUTbU_iTw Start porting my asm to inline asm...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-15 12:28 -0800 |
| Message-ID | <uo44h7$12ct8$3@dont-email.me> |
| In reply to | #380180 |
On 1/15/2024 6:15 AM, bart wrote: [...] Iirc, Microsoft got rid of inline assembly for 64 bit targets a while back.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-15 16:39 +0100 |
| Message-ID | <uo3jk8$vou1$1@dont-email.me> |
| In reply to | #380167 |
On 15/01/2024 08:07, Kaz Kylheku wrote:
> On 2024-01-15, bart <bc@freeuk.com> wrote:
>> On 15/01/2024 00:34, Kaz Kylheku wrote:
>> I will now show it in my language but with that assignment replaced by
>> inline assembly:
>>
>> int a
>>
>> proc F=
>> int b:=2, c:=3
>> static int d=4
>>
>> assem
>> mov rax, [c] # (note my ints are 64 bits)
>> imul2 rax, [d]
>> add rax, [b]
>> mov [a], rax
>> end
>
> Problem is that the compiler's register allocator now has to be informed that
> the assembly language part is using rax and work around it.
That is not the only problem, but it is certainly a limitation.
>
>> end
>>
>> My question is: what would the C version look like with that line in gcc
>> inline assembly? (In both cases, 'a' should end up with the value 14.)
>
> Let's make it more interesting: what if b and c come from arguments,
> and the static int d actually has state that changes between
> invocations, so it can't be optimized away.
That makes sense.
> Let's return the
> result, a:
>
> int F(int b, int c)
> {
> static int d=4;
> int a;
>
> d++;
>
> asm("imul %3, %2\n\t"
> "add %2, %1\n\t"
> "mov %1, %0\n\t"
> : "=r" (a)
> : "r" (b), "r" (c), "r" (d));
>
> return a;
> }
>
> It's pretty arcane in that the material is both in string literals,
> and not. The assembly language template is textual; the compiler knows
> nothing about its interior.
>
> I specified one output operand, and three input operands, requesting
> that they be in registers. I don't specify the register identities.
Yes. You could also use "g", which allows registers, or memory
addresses, or immediate results, which could be appropriate for some
operands on some processors (like the x86). Re-arranging slightly
(unless that is considered "cheating"), so that the C code is "c *= d; c
+= b;", then only "c" needs to be in a register. And gcc can do the
move for you, so you don't need the third instruction. (On a processor
with three argument instructions, common for many RISC cpus, your "add"
would go directly to "a". But you'd also want to keep all operands as "r".)
> They are referenced by number: %0, %1, %2, %3 in the order they
> appear. (A way to use named references exists.)
Yes. I like to use it, if I have more than two operands. I often use
it even if I have just one or two operands.
> GNU inline assembly is ugly, but it's very well designed semantically;
> it hits the target.
>
I don't think gcc inline assembly is particularly pretty, or easy to use
- but I have not seen any alternatives that come close to the power and
/are/ pretty or easy to use. Inline assembly is something to be used
rarely, when you really need it - and rarely used things are allowed to
be difficult or ugly, and to require the user to look up reference
manuals. If a language or compiler's inline assembly is easy to use,
it's a sign that the tool is so weak that people will need to resort to
assembly on a regular basis.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-15 16:23 +0100 |
| Message-ID | <uo3ilc$vjmt$1@dont-email.me> |
| In reply to | #380160 |
On 15/01/2024 03:14, bart wrote:
> On 15/01/2024 00:34, Kaz Kylheku wrote:
>> On 2024-01-14, bart <bc@freeuk.com> wrote:
>>> On 12/01/2024 21:31, Kaz Kylheku wrote:
>>>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>>
>> GCC has great inline assembly.
>
>> You can reference C expressions, which
>> are evaluated to registers that the register allocator chooses, which
>> you can reference in your inline code in a symbolic way.
>
> GCC inline assembly looks absolutely diabolic.
You forgot the "IMHO" disclaimer. /You/ think it looks diabolic, and
you probably think that means everyone else thinks so too, and that
anyone who says they can use gcc inline assembler successfully is lying
or in denial.
I've used inline assembly with a fair number of compilers over the
years. There is no doubt that gcc's system can look scary. And there
is no doubt that there are simpler systems around.
However, I have never seen an inline assembly syntax that integrates
with an optimising compiler in an efficient way, and is not
approximately as complicated as gcc's.
Simpler inline assembly invariably places a lot more limits on the
integration. For example, it can require "assembly only" functions,
which cannot be inlined into other code. Or it forces specific uses of
registers, and perhaps forces local data to be put on the stack instead
of being in registers.
Several of the optimising compilers I have used have supported gcc's
syntax for inline assembly - including gcc, icc, clang and CodeWarrior
(which is a commercial compiler with no connection whatsoever with gcc
or open source - it just copies several of gcc's extensions because they
are a de-facto standard). The only compiler I used with an inline
assembly of comparable power and integration to gcc's, but a different
syntax, was Diab Data. It's syntax was nicer in some ways, less nice in
others, but I am confident that you would, if you were being honest,
find it equally diabolical.
(Note that gcc also supports what it calls "Basic assembly syntax". But
for most purposes, "Extended assembly syntax" is used because it is much
more powerful.)
> I take it you've never
> seen it done properly?
>
> Actually I spent 5-10 minutes looking for examples, to try and figure
> out if asm instructions could in fact directly refer to symbols in the HLL.
>
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.
> But most examples were one or two lines of weird syntax, following by
> some interfacing code. So I don't know.
>
Exactly. You don't know.
> 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. 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;
}
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
As you can see, I only need two manual assembly instructions - thinks
like moving data around are best handled in C, typically automatically
done by the compiler to fit the input and output operands. And the
compiler generates code that works with the optimiser.
With your simplistic inline assembly, you need to write everything
manually. And the compiler must assume to use rax and other scratch
registers, meaning it can't use them for local data that lives around
the assembly - even if your code does not use them. It has to put the
register data on the stack, and then your inline assembly has to move it
off the stack - a pointless waste of time compared to gcc that knows
about the data and the registers. Your assembly changes the value of
"a", but the compiler doesn't know that - so it is forced to make sure
all memory data is written out before the assembly, and re-read after
the assembly. What a painful waste of target efficiency!
Yes, your assembly syntax is simple and clear. No, it is not better for
real-world use-cases where inline assembly is relevant.
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. 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?
> 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.
> in dreadfil AT&T
> syntax.
"Dreadful" is, again, /your/ opinion - not shared by everyone. (I
personally don't care either way.) It only applies to x86, not any
other targets, and is easily changed by the "-masm=intel" flag.
> 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.
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).
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? 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.
>
> 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.
>
> * 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.
> (I might allow that at some point.) Most such functions
> however contain only ASM.
>
What a terrible limitation.
> 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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-15 17:30 +0000 |
| Message-ID | <YYdpN.177805$c3Ea.78753@fx10.iad> |
| In reply to | #380184 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-15 21:25 +0100 |
| Message-ID | <uo44ch$12fes$1@dont-email.me> |
| In reply to | #380194 |
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! The compiler was bought by Wind River, and I don't think it is very relevant now. I only ever got to play with the compiler for a short while, back in the late 1990's, for the m68k. Our company couldn't afford it at the time as it was /not/ cheap. But it had powerful optimisation for its day. I've never been much fond of Greenhills, though I have not had much use of it (some customers have).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-15 20:41 +0000 |
| Message-ID | <SLgpN.41334$5Hnd.11118@fx03.iad> |
| In reply to | #380205 |
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?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 15:08 +0100 |
| Message-ID | <uo62le$1finu$2@dont-email.me> |
| In reply to | #380209 |
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? :-)
[toc] | [prev] | [next] | [standalone]
Page 23 of 34 — ← Prev page 1 … 21 22 [23] 24 25 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web