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 22 of 34 — ← Prev page 1 … 20 21 [22] 23 24 … 34 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 14:24 +0100 |
| Message-ID | <uo6023$1f4l9$2@dont-email.me> |
| In reply to | #380206 |
On 15/01/2024 21:27, Chris M. Thomasson wrote: > On 1/15/2024 8:29 AM, David Brown wrote: >> On 15/01/2024 17:04, David Brown wrote: >>> On 15/01/2024 08:40, Kaz Kylheku wrote: >> >>>> A mul_add primitive might make sense if the processor had such a thing >>>> in one instruction. >>>> >>>> With GCC inline assembly, you want to only put the essentials into it: >>>> only do what is necessary and only bundle together what must be >>>> bundled. >>>> >>> >>> Yes. For inline assembly, simple is not really important, but small >>> is beautiful! Say exactly what you mean, no more and no less, and >>> let the compiler do what it does best. > [...] > > Wrt inline GCC assembly, remember __volatile__ and memory? ;^) > Yes, these are useful, and I use them - when appropriate.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-16 20:02 -0800 |
| Message-ID | <uo7jh0$1rb6c$2@dont-email.me> |
| In reply to | #380237 |
On 1/16/2024 5:24 AM, David Brown wrote: > On 15/01/2024 21:27, Chris M. Thomasson wrote: >> On 1/15/2024 8:29 AM, David Brown wrote: >>> On 15/01/2024 17:04, David Brown wrote: >>>> On 15/01/2024 08:40, Kaz Kylheku wrote: >>> >>>>> A mul_add primitive might make sense if the processor had such a thing >>>>> in one instruction. >>>>> >>>>> With GCC inline assembly, you want to only put the essentials into it: >>>>> only do what is necessary and only bundle together what must be >>>>> bundled. >>>>> >>>> >>>> Yes. For inline assembly, simple is not really important, but small >>>> is beautiful! Say exactly what you mean, no more and no less, and >>>> let the compiler do what it does best. >> [...] >> >> Wrt inline GCC assembly, remember __volatile__ and memory? ;^) >> > > Yes, these are useful, and I use them - when appropriate. > Exactly. I could get inline asm to work with my sync code, but since I disliked inline asm and MS dropped support for it for 64-bit targets around the time, I felt _much_ safer to implement my sync code in external assembly, trying to isolate them from the meat hooks of the compiler. Also, I would check the generated asm from any of my inline asm to make sure it was correct. This was a pain in the ass.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-16 11:54 +0000 |
| Message-ID | <uo5qp3$1dn2m$1@dont-email.me> |
| In reply to | #380190 |
On 15/01/2024 16:29, David Brown wrote:
> On 15/01/2024 17:04, David Brown wrote:
>> On 15/01/2024 08:40, Kaz Kylheku wrote:
>
>>> A mul_add primitive might make sense if the processor had such a thing
>>> in one instruction.
>>>
>>> With GCC inline assembly, you want to only put the essentials into it:
>>> only do what is necessary and only bundle together what must be
>>> bundled.
>>>
>>
>> Yes. For inline assembly, simple is not really important, but small
>> is beautiful! Say exactly what you mean, no more and no less, and let
>> the compiler do what it does best.
>>
>>
>> And move to C++20. Then you can write (for the mythical madd
>> instruction) :
>>
>> constexpr int mul_add(int x, int y, int z)
>> __attribute__((const))
>> {
>> if (std::is_constant_evaluated()) {
>> return x + y * z;
>> } else {
>> asm("madd %[x], %[y], %[z]"
>> : [x] "+r" (x) : [y] "g" (y), [z] "g" (z));
>> return x;
>> }
>> }
>>
>>
>> Now the compiler can evaluate at compile time if the parameters are
>> known, or using the super-efficient madd instruction at runtime if
>> necessary.
>>
>
> Apologies for replying to my own post, but of course this can be done in
> C with gcc extensions (and when we have inline assembly, we are already
> relying on gcc extensions):
>
> static inline int mul_add(int x, int y, int z)
> __attribute__((const))
> {
> if (__builtin_constant_p(x + y * z)) {
> return x + y * z;
> } else {
> asm("madd %[x], %[y], %[z]"
Which processor is this for again?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 14:42 +0100 |
| Message-ID | <uo6143$1f9o7$2@dont-email.me> |
| In reply to | #380232 |
On 16/01/2024 12:54, bart wrote:
> On 15/01/2024 16:29, David Brown wrote:
>> On 15/01/2024 17:04, David Brown wrote:
>>> On 15/01/2024 08:40, Kaz Kylheku wrote:
>>
>>>> A mul_add primitive might make sense if the processor had such a thing
>>>> in one instruction.
>>>>
>>>> With GCC inline assembly, you want to only put the essentials into it:
>>>> only do what is necessary and only bundle together what must be
>>>> bundled.
>>>>
>>>
>>> Yes. For inline assembly, simple is not really important, but small
>>> is beautiful! Say exactly what you mean, no more and no less, and
>>> let the compiler do what it does best.
>>>
>>>
>>> And move to C++20. Then you can write (for the mythical madd
>>> instruction) :
>>>
>>> constexpr int mul_add(int x, int y, int z)
>>> __attribute__((const))
>>> {
>>> if (std::is_constant_evaluated()) {
>>> return x + y * z;
>>> } else {
>>> asm("madd %[x], %[y], %[z]"
>>> : [x] "+r" (x) : [y] "g" (y), [z] "g" (z));
>>> return x;
>>> }
>>> }
>>>
>>>
>>> Now the compiler can evaluate at compile time if the parameters are
>>> known, or using the super-efficient madd instruction at runtime if
>>> necessary.
>>>
>>
>> Apologies for replying to my own post, but of course this can be done
>> in C with gcc extensions (and when we have inline assembly, we are
>> already relying on gcc extensions):
>>
>> static inline int mul_add(int x, int y, int z)
>> __attribute__((const))
>> {
>> if (__builtin_constant_p(x + y * z)) {
>> return x + y * z;
>> } else {
>> asm("madd %[x], %[y], %[z]"
>
> Which processor is this for again?
>
It's for a cpu with a "madd" instruction that implements "x = x + y * z"
in a single instruction - as Kaz pointed out, doing this in inline
assembly would make sense if it the cpu had such a dedicated
instruction. Inline assembly is typically used in such situations,
where the processor has a more efficient instruction sequence than the
compiler can generate.
But this mythical cpu uses Intel-style assembly syntax, for your
convenience :-)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-16 15:08 +0100 |
| Message-ID | <uo62ke$1fjel$1@dont-email.me> |
| In reply to | #380239 |
On 16.01.2024 14:42, David Brown wrote: > On 16/01/2024 12:54, bart wrote: >> >> Which processor is this for again? > > It's for a cpu with a "madd" instruction that implements "x = x + y * z" > in a single instruction - as Kaz pointed out, doing this in inline > assembly would make sense if it the cpu had such a dedicated > instruction. [...] I recall such a feature from a 35+ years old assembler project I did. It was on the TI TMS320C25 DSP, and the instruction was called 'MAC' (Multiply and ACcumulate). - Not sure it clarifies anything but just as an amendment if someone is interested in searching for keywords on such a function. Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 16:54 +0100 |
| Message-ID | <uo68rr$1ge1j$4@dont-email.me> |
| In reply to | #380241 |
On 16/01/2024 15:08, Janis Papanagnou wrote: > On 16.01.2024 14:42, David Brown wrote: >> On 16/01/2024 12:54, bart wrote: >>> >>> Which processor is this for again? >> >> It's for a cpu with a "madd" instruction that implements "x = x + y * z" >> in a single instruction - as Kaz pointed out, doing this in inline >> assembly would make sense if it the cpu had such a dedicated >> instruction. [...] > > I recall such a feature from a 35+ years old assembler project I did. > It was on the TI TMS320C25 DSP, and the instruction was called 'MAC' > (Multiply and ACcumulate). - Not sure it clarifies anything but just > as an amendment if someone is interested in searching for keywords > on such a function. > I was too blind to notice that this completely synthetic example expression actually is a useful function that is a single accelerated instruction on many architectures. (And I've just recently finished a project that uses MAC's in a filter.) Now I feel /really/ silly! Of course many architectures have multiply-accumulate instructions, in all sorts of variants, because they are key operations in many DSP algorithms and filters. They can be integer, floating point, saturated integer, scaled integer. In DSPs they are often very complex, such as having operands via pointer registers that scan through buffers (perhaps circular buffers), all in a single cycle. They are also sometimes known as "FMA" (fused multiply add). x86-64 has some SIMD/AVX512 MAC instructions, I believe.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-16 15:57 +0000 |
| Message-ID | <ZHxpN.207475$PuZ9.131537@fx11.iad> |
| In reply to | #380241 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 16.01.2024 14:42, David Brown wrote: >> On 16/01/2024 12:54, bart wrote: >>> >>> Which processor is this for again? >> >> It's for a cpu with a "madd" instruction that implements "x = x + y * z" >> in a single instruction - as Kaz pointed out, doing this in inline >> assembly would make sense if it the cpu had such a dedicated >> instruction. [...] > >I recall such a feature from a 35+ years old assembler project I did. >It was on the TI TMS320C25 DSP, and the instruction was called 'MAC' >(Multiply and ACcumulate). - Not sure it clarifies anything but just >as an amendment if someone is interested in searching for keywords >on such a function. Pretty much every modern architecture has multiply and accumulate instructions, even the ARM Cortex-M7 cores (MLA instruction).
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-17 06:25 +0100 |
| Subject | CPU's MAC instructions (was Re: Effect of CPP tags) |
| Message-ID | <uo7oce$1s7q3$1@dont-email.me> |
| In reply to | #380250 |
On 16.01.2024 16:57, Scott Lurndal wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 16.01.2024 14:42, David Brown wrote: >>> On 16/01/2024 12:54, bart wrote: >>>> >>>> Which processor is this for again? >>> >>> It's for a cpu with a "madd" instruction that implements "x = x + y * z" >>> in a single instruction - as Kaz pointed out, doing this in inline >>> assembly would make sense if it the cpu had such a dedicated >>> instruction. [...] >> >> I recall such a feature from a 35+ years old assembler project I did. >> It was on the TI TMS320C25 DSP, and the instruction was called 'MAC' >> (Multiply and ACcumulate). - Not sure it clarifies anything but just >> as an amendment if someone is interested in searching for keywords >> on such a function. > > Pretty much every modern architecture has multiply and accumulate > instructions, even the ARM Cortex-M7 cores (MLA instruction). Yeah, I inferred that already from David's response. At these days, though, I hadn't seen 'MAC' in the common standard CPUs. (And since that time I didn't do any assembler any more, so I don't know the contemporary architectures.) It's maybe noteworthy that despite such advanced CPU functions I didn't make use of them, despite I had functions like sum(x[i]*y[i]) to implement. The reason was that an algorithmic transformation, an optimization, made use of that 1-cycle MAC an inferior solution! Janis
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-16 18:52 +0000 |
| Message-ID | <20240116104616.380@kylheku.com> |
| In reply to | #380241 |
On 2024-01-16, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 16.01.2024 14:42, David Brown wrote:
>> On 16/01/2024 12:54, bart wrote:
>>>
>>> Which processor is this for again?
>>
>> It's for a cpu with a "madd" instruction that implements "x = x + y * z"
>> in a single instruction - as Kaz pointed out, doing this in inline
>> assembly would make sense if it the cpu had such a dedicated
>> instruction. [...]
>
> I recall such a feature from a 35+ years old assembler project I did.
> It was on the TI TMS320C25 DSP, and the instruction was called 'MAC'
> (Multiply and ACcumulate). - Not sure it clarifies anything but just
> as an amendment if someone is interested in searching for keywords
> on such a function.
It is obviously useful for evaluating polynomials via Horner's rule,
which involves multiplying the accumulator by a coefficient, and then
adding a term.
Ax^3 + Bx^2 + Cx + D -> x(Ax^2 + Bx + c) + D
-> x(x(Ax + B) + C) + D
O is output/accumuator:
O = A
O *= x; O += B; // multiply + add steps
O *= x; O += C;
O *= x: O += D;
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-15 14:15 +0000 |
| Message-ID | <uo3eli$uv97$1@dont-email.me> |
| In reply to | #380167 |
On 15/01/2024 07:07, Kaz Kylheku wrote:
> On 2024-01-15, bart <bc@freeuk.com> wrote:
>>> GCC has great inline assembly.
>> My question is: what would the C version look like with that line in gcc
>> inline assembly? (In both cases, 'a' should end up with the value 14.)
>
> Let's make it more interesting: what if b and c come from arguments,
> and the static int d actually has state that changes between
> invocations, so it can't be optimized away. Let's return the
> result, a:
>
> int F(int b, int c)
> {
> static int d=4;
> int a;
>
> d++;
>
> asm("imul %3, %2\n\t"
> "add %2, %1\n\t"
> "mov %1, %0\n\t"
> : "=r" (a)
> : "r" (b), "r" (c), "r" (d));
>
> return a;
> }
>
> It's pretty arcane in that the material is both in string literals,
> and not. The assembly language template is textual; the compiler knows
> nothing about its interior.
>
> I specified one output operand, and three input operands, requesting
> that they be in registers. I don't specify the register identities.
> They are referenced by number: %0, %1, %2, %3 in the order they
> appear. (A way to use named references exists.)
OK. I think you've just confirmed my worst fears about gcc inline assembly.
But you've also made it clear that this isn't really assembly at all. Is
it even for x64? I can't tell! The use of 'mov' rather than 'ldr' or
'str' suggests it is x86 or x64 rather than ARM. But are those 32-bit
mov's or 64-bit?
So it's some sort of hideous hybrid that gcc has come up with, that is
neither assembly nor C.
It figures that most examples I could find on-line were only a handful
of lines, often just one line, of actual instructions rather than
directives. My inline assembler doesn't have directives.
It would be far, far simpler to write assembly in its own file (and keep
well away from AT&T syntax), than to try and inline it. Which defeats
the purpose of it.
As for your revised example, I would write it like this (I'm using my
language, but no reason why that assem...end block can't be written the
same way within in C, using assem {...}, and without those ghastly strings):
func F(int b, c)int =
static int d=4
++d
assem
mov rax, [c]
imul2 rax, [d]
add rax, [b]
end
end
Exactly the same as before, except I don't need to explicitly write to
'a'. If a return value is expected in this context, then an assem block
is expected to set up that value in the right place.
Or I could even assign an assem block to variable:
a := assem mov rbx, [c]; imul2 rbx, [d]; add rbx, [b]; end
(I didn't know I could do this, but it seems to work.)
> 25: 0f af d1 imul %ecx,%edx
> 28: 01 d0 add %edx,%eax
> 2a: 89 c0 mov %eax,%eax
-----
> f: 0f af f0 imul %eax,%esi
> 12: 01 f7 add %esi,%edi
> 14: 89 f8 mov %edi,%eax
> The static variable is accessed relative to the instruction pointer.
> The offset is all zeros: that will be patched when this is linked.
That is a back-end detail; it's not usually specified in the instructions.
> Note that between the unoptimized and optimized code, the register
> identities changed entirely.
> GCC's inline assembly feature is largely agnostic of the assembler
> back end. It interfaces with register allocation and such, but is
> otherwise generic. This allows it to have exactly the same grammar,
> no matter the architecture target.
>
> The syntax isn't particularly nice, but it has power.
So it's some kind of HLA.
>> You need to tell me, because I will otherwise not have a clue. From what
>> I've seen of gcc inline asm:
>>
>> * Code has to be written within string literals, in dreadfil AT&T
>> syntax. And apparently even with embedded \n line breaks. (Good
>> grief - I think early 80s BASICs had more sophisticated facilities!)
>
> The code template, after the registers like %0 and %1 are substituted
> into it, is just shoved into the assembly language output verbatim.
That's how I crudely did it at one time (though still using real
syntax). But it doesn't work when the output is binary code and not
assembly text.
> The compiler doesn't analyze the interior.
>
> AT&T syntax is used if that's what the assembler requires.
>
> Not all GCC targets have assemblers in whose language the destination operand
> is on the right; it's that way for the x86 family though.
>>
>> * You mostly use offsets to get at local variables
>
> Nope; it's pretty much transparent.
So can specify the variables direcly? As in, for example:
asm inc u32 [d] # one-liner form of my syntax
>> I consider that when writing assembly, YOU are in charge not the
>> compiler.
>
> If you're writing *inline* assembly in compiled code, if you let
> the compiler be in charge of some things, it's a lot better.
Then you'd write in the HLL. Having inline ASM already takes care of 80%
of the pain of writing pure assembly. In gcc inline, it /adds/ pain!
But I stated my compiler does take care of some details like adding the
frame-pointer into the address mode. That's means you don't need to keep
track of whether a variable is local, static or global.
Below is an example of a function that mostly HLL with some inline ASM.
This one does the job of LIBFFI (another needlessly hard to build
library), for Win64 ABI.
-------------
export function os_calldllfunction(
ref proc fnaddr,
int retcode, nargs,
ref[]u64 args,
ref[]byte argcodes)u64 =
u64 a
r64 x
int nextra := 0, pushedbytes
!Stack is 16-byte aligned at this point
if nargs<4 then
nextra := 4-nargs !need at least 4 slots for shadow space
elsif nargs.odd then !need one more for a 16-byte-aligned stack
nextra := 1
fi
pushedbytes:=(nextra+nargs)*8
to nextra do
asm push 0
od
for i := nargs downto 1 do
a := args[i] !get generic 64-bit value to push
asm push u64 [a]
od
! Blindly load first 4 args to both int/float regs, whether used or not,
! and assuming calling a variadic function whether it is or not
assem
mov D10, [Dstack]
movq XMM0, [Dstack]
mov D11, [Dstack+8]
movq XMM1, [Dstack+8]
mov D12, [Dstack+16]
movq XMM2, [Dstack+16]
mov D13, [Dstack+24]
movq XMM3, [Dstack+24]
end
if retcode='I' then
a := (ref func:int64(fnaddr))^()
asm add Dstack,[pushedbytes]
return a
else
x := (ref func:r64(fnaddr))^()
asm add Dstack,[pushedbytes]
return u64@(x) !(type-punning cast)
fi
end
(Uses alternate register naming.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-15 14:35 +0000 |
| Message-ID | <6pbpN.200172$7sbb.118143@fx16.iad> |
| In reply to | #380180 |
bart <bc@freeuk.com> writes:
>On 15/01/2024 07:07, Kaz Kylheku wrote:
>> On 2024-01-15, bart <bc@freeuk.com> wrote:
>>
>> 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;
>> }
>But you've also made it clear that this isn't really assembly at all. Is
>it even for x64? I can't tell! The use of 'mov' rather than 'ldr' or
>'str' suggests it is x86 or x64 rather than ARM. But are those 32-bit
>mov's or 64-bit?
1) it's not an assembler, it's a way to "patch" the assembler code
generated by the compiler.
>
>So it's some sort of hideous hybrid that gcc has come up with, that is
>neither assembly nor C.
Your baseless opinion noted. Feel free to submit a patch to
the GCC team to implement your preferred syntax for inline assembler.
Do ensure that it works for all 100 of the GCC target architectures.
>It would be far, far simpler to write assembly in its own file (and keep
>well away from AT&T syntax),
No, it would not be.
And the AT&T syntax is _far_ superior to the intel syntax
with all the ugly syntactic sugar.
val = tp->mem_read(psource, len);
rax = get_reg_value(regs, REG_RAX, QUAD);
__asm__ __volatile__ (
"testl $1, %1\n\t" // 1 byte operand?
"jne 1f\n\t" // Yes, go to it
"testl $8, %1\n\t" // Was it eight bytes?
"jne 2f\n\t" // Yup. Done.
"testl $4, %1\n\t" // Was it 4 bytes?
"je 3f\n\t" // no, Try 2 bytes
"movsx %%ebx, %%rbx\n\t" // Sign extend 32-bits to 64
"cdqe\n\t" // Sign extend EAX to RAX
"jmp 2f\n" // Done here
"3:\tmovsx %%bx, %%rbx\n\t" // Sign extend 16-bits to 64
"movsx %%ax, %%rax\n\t" // Sign extend AX TO RAX
"jmp 2f\n" // Done here
"1:\tmovsx %%bl, %%rbx\n" // Sign extend BL to RBX
"movsx %%al, %%rax\n" // Sign extend AL to RAX
"2:\tsub %%rbx, %%rax\n" // Subtract from comparison value
"pushfq\n\t" // Save the flags from the sub
"popq %0\n\t"
:"=r"(flags_word)
:"r"(len), "b"(val), "a"(rax));
guest_rflags &= ~MATH_FLAGS;
guest_rflags |= (flags_word & MATH_FLAGS);
source += inc;
count--;
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-15 15:44 +0000 |
| Message-ID | <uo3jth$vqg9$1@dont-email.me> |
| In reply to | #380181 |
On 15/01/2024 14:35, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> But you've also made it clear that this isn't really assembly at all. Is
>> it even for x64? I can't tell! The use of 'mov' rather than 'ldr' or
>> 'str' suggests it is x86 or x64 rather than ARM. But are those 32-bit
>> mov's or 64-bit?
>
> 1) it's not an assembler, it's a way to "patch" the assembler code
> generated by the compiler.
>
>>
>> So it's some sort of hideous hybrid that gcc has come up with, that is
>> neither assembly nor C.
>
> Your baseless opinion noted. Feel free to submit a patch to
> the GCC team to implement your preferred syntax for inline assembler.
>
> Do ensure that it works for all 100 of the GCC target architectures.
Which all share the same instruction set? And all have an 'ebx' register:
"movsx %%ebx, %%rbx\n\t"
?
>
>> It would be far, far simpler to write assembly in its own file (and keep
>> well away from AT&T syntax),
>
> No, it would not be.
>
> And the AT&T syntax is _far_ superior to the intel syntax
> with all the ugly syntactic sugar.
>
> val = tp->mem_read(psource, len);
> rax = get_reg_value(regs, REG_RAX, QUAD);
>
> __asm__ __volatile__ (
> "testl $1, %1\n\t" // 1 byte operand?
> "jne 1f\n\t" // Yes, go to it
>
> "testl $8, %1\n\t" // Was it eight bytes?
> "jne 2f\n\t" // Yup. Done.
>
> "testl $4, %1\n\t" // Was it 4 bytes?
> "je 3f\n\t" // no, Try 2 bytes
> "movsx %%ebx, %%rbx\n\t" // Sign extend 32-bits to 64
> "cdqe\n\t" // Sign extend EAX to RAX
> "jmp 2f\n" // Done here
>
> "3:\tmovsx %%bx, %%rbx\n\t" // Sign extend 16-bits to 64
> "movsx %%ax, %%rax\n\t" // Sign extend AX TO RAX
> "jmp 2f\n" // Done here
>
> "1:\tmovsx %%bl, %%rbx\n" // Sign extend BL to RBX
> "movsx %%al, %%rax\n" // Sign extend AL to RAX
> "2:\tsub %%rbx, %%rax\n" // Subtract from comparison value
> "pushfq\n\t" // Save the flags from the sub
> "popq %0\n\t"
> :"=r"(flags_word)
> :"r"(len), "b"(val), "a"(rax));
You're having a laugh, surely? AT&T is bad enough even without the
travesty of it displayed here:
"jmp 2f\n"
"3:\tmovsx %%bx, %%rbx\n\t"
What's with the strings, newline and tab escapes? What's that 'f' for?
Instead of %rbx you now have to type %%rbx; better not leave out an % by
mistake. And you have to pay close attention here:
"testl $1, %1\n\t" // 1 byte operand?
so as not to mix up $1 and %1. It almost makes makefiles look readable!
I generally write:
"\tmovsx %%bx, %%rbx\n\t"
as:
movsx rbx, bx
I assume "2f" and "2:" are labels? I don't understand why you couldn't
have made it a /little/ more readable by writing:
"1:\tmovsx %%bl, %%rbx\n" // Sign extend BL to RBX
"movsx %%al, %%rax\n" // Sign extend AL to RAX
for example as:
"1: movsx %%bl, %%rbx" nl // ...
" movsx %%al, %%rax" nl // ...
BTW those comments are superfluous, unless you are acknowledging that
the syntax is so unreadable, that you have to write a version in English.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-15 17:35 +0000 |
| Message-ID | <B1epN.177806$c3Ea.53953@fx10.iad> |
| In reply to | #380187 |
bart <bc@freeuk.com> writes: >On 15/01/2024 14:35, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: > >>> But you've also made it clear that this isn't really assembly at all. Is >>> it even for x64? I can't tell! The use of 'mov' rather than 'ldr' or >>> 'str' suggests it is x86 or x64 rather than ARM. But are those 32-bit >>> mov's or 64-bit? >> >> 1) it's not an assembler, it's a way to "patch" the assembler code >> generated by the compiler. >> >>> >>> So it's some sort of hideous hybrid that gcc has come up with, that is >>> neither assembly nor C. >> >> Your baseless opinion noted. Feel free to submit a patch to >> the GCC team to implement your preferred syntax for inline assembler. >> >> Do ensure that it works for all 100 of the GCC target architectures. > >Which all share the same instruction set? No, of course not. The compiler syntax must be usable for all supported architectures. All the compiler does is pass it through to the assembler output after any parameter substitution. The compiler doesn't even look at the opcode. >You're having a laugh, surely? No. I'm serious. [DWORD] is useless 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. > >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.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-15 18:55 +0000 |
| Message-ID | <uo3v2u$11mbu$1@dont-email.me> |
| In reply to | #380195 |
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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-15 19:19 +0000 |
| Message-ID | <ZyfpN.121997$yEgf.104604@fx09.iad> |
| In reply to | #380198 |
bart <bc@freeuk.com> writes: >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? Even you included them in the example you posted (and elided from this reply). I include the C escape codes (they're not necessary for proper compilation) to make the intermediate assembler output more readable, in the unlikely event that one might need to look at it for some reason. Force of long-standing habit. You can certainly leave them out if you don't want them. They're not required. But you'd know that if you had bothered to read the documentation. >>> What's with the strings, newline and tab escapes? What's that 'f' for? Assemblers for fifty years have used numeric temporary labels. So that the target can be before or after the branch instruction, one may suffix the branch label with 'f' or 'b' on a branch-class instruction. The GNU gas assembler is hardly the first assembler to support such syntax. But, I suspect you already know this, and may even have been able to figure it out from context. But that wouldn't fit your trolling narrative.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-15 12:31 -0800 |
| Message-ID | <uo44m5$12ct8$4@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. inline assembler is not my cup of tea. If I work for a team that uses it, well I can use it as well... However, I might not have a big smile on my face when I am working on it. My boss says, hey man, if you don't smile right now you are fired. Well, I would smile for sure! ;^)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-16 01:21 +0000 |
| Message-ID | <20240115152928.267@kylheku.com> |
| In reply to | #380198 |
On 2024-01-15, bart <bc@freeuk.com> 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?
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
GCC's code is using eight spaces; mine is tabs. The indentation on
imul is spaces: that was generated by GCC. You don't have to
indent your first instruction.
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.
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, 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.
--
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-16 11:30 +0000 |
| Message-ID | <uo5pdi$1dgnv$1@dont-email.me> |
| In reply to | #380223 |
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?
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);
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 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.
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{...}.
Yes it's a bit harder, but if I can do it within a 0.3MB product, gcc
can do it within 24MB.
> 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.
It's not just more natural syntax, but better integration within the
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.
> 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. Mine is; it
looks exactly line normal assembly, and it is written inline to the HLL.
Although these days I keep such hybrid functions within their own modules.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-16 15:06 +0100 |
| Message-ID | <uo62gj$1finu$1@dont-email.me> |
| In reply to | #380230 |
On 16/01/2024 12:30, bart 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? It's often just habit. The tab character is entirely unnecessary, at least for gas (other assemblers may complain about instructions appearing at the start of the line). You do need some kind of separation between the assembly instructions - if you don't use "\n", then you could also use ";" (again, I know it works for gas). "\n\t" is a common habit, however, and has the benefit of looking nice if you examine the generated assembly - and if you are working with inline assembly, sometimes that is a very useful thing to check. > > 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! > 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. In reality, you don't even often write the inline assembly yourself - you include a manufacturer-supplied header full of "intrinsics" - small inline assembly functions wrapping useful assembly instructions. The whole thing would be nicer if C (or at least gcc) supported a multi-line string syntax akin to Python's """ ... """ syntax. But it doesn't. (Actually, such an extension could be very useful for lots of things.) >>> 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. No. The point of inline assembly is to do something that you can't do in C alone (even with compiler extensions). > > It's not just more natural syntax, but better integration within the > 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. > You can "goto" C labels in gcc inline assembly. I can't imagine much real-world use for it, but you can do it. (You use "asm goto" and pass the labels into the assembly expression.) I think you are viewing inline assembly as a verbatim list of instructions inserted blindly into the code generated by the compiler. I view it more like an expression that fits into the flow of the C code, and the flow of the generated code. It is working /with/ the compiler, not /against/ it. >> 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. Mine is; it > looks exactly line normal assembly, and it is written inline to the HLL. > Exactly. gcc inline assembly is inline assembly - it is not an assembler. (gcc also supports what it calls "basic assembly syntax" - you create a "naked" function and give a list of assembly instructions. This is typically used for things like specialised startup code in a microcontroller, or for task switching in an RTOS.) > Although these days I keep such hybrid functions within their own modules. > It's always good to keep things like this tidied away.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-16 17:04 -0800 |
| Message-ID | <uo793d$1lvso$2@dont-email.me> |
| In reply to | #380240 |
On 1/16/2024 6:06 AM, David Brown wrote: > On 16/01/2024 12:30, bart 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? > > It's often just habit. The tab character is entirely unnecessary, at > least for gas (other assemblers may complain about instructions > appearing at the start of the line). You do need some kind of > separation between the assembly instructions - if you don't use "\n", > then you could also use ";" (again, I know it works for gas). "\n\t" is > a common habit, however, and has the benefit of looking nice if you > examine the generated assembly - and if you are working with inline > assembly, sometimes that is a very useful thing to check. > >> >> 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! >> > > 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? Alter the name of the file, or add in sufficient comments that says this is arch specific! Damn it. ;^) Ahhh, bust out the macros. ct_foo.c becomes ct_foo_i686.c ? ;^D Been there done that...
[toc] | [prev] | [next] | [standalone]
Page 22 of 34 — ← Prev page 1 … 20 21 [22] 23 24 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web