Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #108284 > unrolled thread
| Started by | Robert Finch <robfi680@gmail.com> |
|---|---|
| First post | 2024-09-06 22:27 -0400 |
| Last post | 2025-11-13 07:24 +0000 |
| Articles | 20 on this page of 908 — 33 participants |
Back to article view | Back to comp.arch
Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-06 22:27 -0400
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-07 14:41 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-07 23:22 -0400
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-08 18:06 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-09 23:59 -0400
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2024-09-10 02:00 -0500
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-10 10:58 -0400
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2024-09-10 16:07 -0500
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-11 09:54 -0400
Re: Tonights Tradeoff Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-09-11 08:48 -0700
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-11 21:32 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-11 23:37 -0400
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-12 16:46 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-12 15:28 -0400
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-12 20:46 +0000
Re: Tonights Tradeoff EricP <ThatWouldBeTelling@thevillage.com> - 2024-09-13 11:08 -0400
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-13 17:09 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2024-09-11 18:44 -0500
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-11 21:30 +0000
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-11 21:28 +0000
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2024-09-12 05:37 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2024-09-12 03:21 -0500
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-12 06:21 -0400
Re: Tonights Tradeoff mitchalsup@aol.com (MitchAlsup1) - 2024-09-11 21:27 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-15 03:13 -0400
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2024-09-16 01:45 -0400
Re: Tonights Tradeoff - Background Execution Buffers Robert Finch <robfi680@gmail.com> - 2024-09-24 16:03 -0400
Re: Tonights Tradeoff - Background Execution Buffers mitchalsup@aol.com (MitchAlsup1) - 2024-09-24 20:38 +0000
Re: Tonights Tradeoff - Background Execution Buffers Robert Finch <robfi680@gmail.com> - 2024-09-26 04:13 -0400
Re: Tonights Tradeoff - Background Execution Buffers mitchalsup@aol.com (MitchAlsup1) - 2024-09-26 14:11 +0000
Re: Tonights Tradeoff - Background Execution Buffers Robert Finch <robfi680@gmail.com> - 2024-09-27 08:58 -0400
Re: Tonights Tradeoff - Background Execution Buffers Robert Finch <robfi680@gmail.com> - 2024-10-04 00:04 -0400
Re: Tonights Tradeoff - Background Execution Buffers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-04 06:19 +0000
Re: Tonights Tradeoff - Background Execution Buffers Robert Finch <robfi680@gmail.com> - 2024-10-04 11:54 -0400
Re: Tonights Tradeoff - Background Execution Buffers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-05 09:43 +0000
Re: Tonights Tradeoff - Background Execution Buffers Robert Finch <robfi680@gmail.com> - 2024-10-09 06:44 -0400
Re: Tonights Tradeoff - Background Execution Buffers scott@slp53.sl.home (Scott Lurndal) - 2024-10-09 14:43 +0000
Re: Tonights Tradeoff - Background Execution Buffers mitchalsup@aol.com (MitchAlsup1) - 2024-10-09 16:19 +0000
Re: Tonights Tradeoff - Background Execution Buffers Robert Finch <robfi680@gmail.com> - 2024-10-09 15:37 -0400
Re: Tonights Tradeoff - Background Execution Buffers BGB <cr88192@gmail.com> - 2024-10-12 14:10 -0500
Re: Tonights Tradeoff - Carry and Overflow Robert Finch <robfi680@gmail.com> - 2024-10-12 05:38 -0400
Re: Tonights Tradeoff - Carry and Overflow mitchalsup@aol.com (MitchAlsup1) - 2024-10-12 18:50 +0000
Re: Tonights Tradeoff - Carry and Overflow BGB <cr88192@gmail.com> - 2024-10-12 15:14 -0500
Re: Tonights Tradeoff - Carry and Overflow Robert Finch <robfi680@gmail.com> - 2024-10-12 18:20 -0400
Re: Tonights Tradeoff - Carry and Overflow mitchalsup@aol.com (MitchAlsup1) - 2024-10-12 23:28 +0000
Re: Tonights Tradeoff - ATOM Robert Finch <robfi680@gmail.com> - 2024-10-13 02:46 -0400
Re: Tonights Tradeoff - ATOM mitchalsup@aol.com (MitchAlsup1) - 2024-10-13 18:19 +0000
Re: Tonights Tradeoff - Carry and Overflow BGB <cr88192@gmail.com> - 2024-10-12 20:36 -0500
Page fetching cache controller Robert Finch <robfi680@gmail.com> - 2024-10-31 05:18 -0400
Re: Page fetching cache controller mitchalsup@aol.com (MitchAlsup1) - 2024-10-31 19:11 +0000
Re: Q+ Fibonacci Robert Finch <robfi680@gmail.com> - 2024-11-05 23:30 -0500
Re: register sets Robert Finch <robfi680@gmail.com> - 2025-04-16 23:42 -0400
Re: register sets Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-04-16 23:26 -0700
Re: register sets scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 13:35 +0000
Re: register sets Robert Finch <robfi680@gmail.com> - 2025-04-17 14:24 -0400
Re: register sets mitchalsup@aol.com (MitchAlsup1) - 2025-04-17 18:26 +0000
Re: register sets Robert Finch <robfi680@gmail.com> - 2025-04-17 21:56 -0400
Re: register sets mitchalsup@aol.com (MitchAlsup1) - 2025-04-18 17:12 +0000
Re: register sets Robert Finch <robfi680@gmail.com> - 2025-04-20 02:44 -0400
Re: auto predicating branches Robert Finch <robfi680@gmail.com> - 2025-04-20 21:26 -0400
Re: auto predicating branches anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-21 06:05 +0000
Is an instruction on the critical path? (was: auto predicating branches) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-21 13:39 +0000
Re: auto predicating branches mitchalsup@aol.com (MitchAlsup1) - 2025-04-21 17:29 +0000
Re: auto predicating branches anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-22 05:10 +0000
Re: auto predicating branches EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-22 11:23 -0400
Re: auto predicating branches anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-22 17:31 +0000
Re: auto predicating branches mitchalsup@aol.com (MitchAlsup1) - 2025-04-22 22:32 +0000
Re: auto predicating branches Stefan Monnier <monnier@iro.umontreal.ca> - 2025-04-22 22:59 -0400
Re: auto predicating branches anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-23 18:09 +0000
Re: auto predicating branches EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-24 10:10 -0400
Re: auto predicating branches mitchalsup@aol.com (MitchAlsup1) - 2025-04-25 20:51 +0000
Re: auto predicating branches EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-24 09:47 -0400
Re: auto predicating branches anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-23 17:44 +0000
Re: auto predicating branches mitchalsup@aol.com (MitchAlsup1) - 2025-04-23 21:34 +0000
Re: asynch register rename Robert Finch <robfi680@gmail.com> - 2025-04-23 23:31 -0400
Re: fractional PCs Robert Finch <robfi680@gmail.com> - 2025-04-27 07:36 -0400
Re: fractional PCs mitchalsup@aol.com (MitchAlsup1) - 2025-04-27 20:53 +0000
Re: fractional PCs Robert Finch <robfi680@gmail.com> - 2025-04-27 22:32 -0400
Re: fractional PCs EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-28 10:06 -0400
Re: fractional PCs EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-28 10:50 -0400
Re: fractional PCs Robert Finch <robfi680@gmail.com> - 2025-04-28 22:35 -0400
Re: fractional PCs mitchalsup@aol.com (MitchAlsup1) - 2025-04-29 21:39 +0000
Re: fractional PCs Robert Finch <robfi680@gmail.com> - 2025-04-30 01:21 -0400
Re: fractional PCs Thomas Koenig <tkoenig@netcologne.de> - 2025-04-30 18:09 +0000
Re: fractional PCs Robert Finch <robfi680@gmail.com> - 2025-04-30 19:00 -0400
Re: fractional PCs EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-02 11:18 -0400
Re: fractional PCs moi <findlaybill@blueyonder.co.uk> - 2025-05-02 17:03 +0100
Re: fractional PCs EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-02 13:22 -0400
Re: fractional PCs moi <findlaybill@blueyonder.co.uk> - 2025-05-02 20:01 +0100
Re: millicode, extracode, fractional PCs John Levine <johnl@taugh.com> - 2025-05-02 17:26 +0000
Re: millicode, extracode, fractional PCs moi <findlaybill@blueyonder.co.uk> - 2025-05-02 20:00 +0100
Re: fractional PCs mitchalsup@aol.com (MitchAlsup1) - 2025-04-30 19:04 +0000
Re: fractional PCs mitchalsup@aol.com (MitchAlsup1) - 2025-04-28 22:02 +0000
Re: fractional PCs Robert Finch <robfi680@gmail.com> - 2025-04-28 22:00 -0400
Re: control co-processor Robert Finch <robfi680@gmail.com> - 2025-05-05 00:40 -0400
Re: control co-processor Al Kossow <aek@bitsavers.org> - 2025-05-05 03:01 -0700
Re: control co-processor scott@slp53.sl.home (Scott Lurndal) - 2025-05-05 13:46 +0000
Re: control co-processor Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-05 10:02 -0400
Re: control co-processor scott@slp53.sl.home (Scott Lurndal) - 2025-05-05 16:19 +0000
Scan chains (was: control co-processor) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-06 23:12 -0400
Re: Scan chains (was: control co-processor) Al Kossow <aek@bitsavers.org> - 2025-05-06 21:08 -0700
Re: Scan chains Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-07 10:58 -0400
Re: Scan chains mitchalsup@aol.com (MitchAlsup1) - 2025-05-07 16:57 +0000
Re: Scan chains Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-07 15:03 -0400
Re: Scan chains mitchalsup@aol.com (MitchAlsup1) - 2025-05-08 01:04 +0000
Re: Scan chains mitchalsup@aol.com (MitchAlsup1) - 2025-07-15 17:21 +0000
Re: control co-processor mitchalsup@aol.com (MitchAlsup1) - 2025-05-06 22:17 +0000
Re: control co-processor EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-06 19:58 -0400
Re: control co-processor mitchalsup@aol.com (MitchAlsup1) - 2025-05-07 16:44 +0000
Re: control co-processor mitchalsup@aol.com (MitchAlsup1) - 2025-07-15 17:09 +0000
Re: auto predicating branches EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-25 13:19 -0400
Re: auto predicating branches EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-24 08:54 -0400
Re: auto predicating branches mitchalsup@aol.com (MitchAlsup1) - 2025-04-22 16:45 +0000
Re: register sets John Savard <quadibloc@invalid.invalid> - 2025-07-15 04:56 +0000
Re: register sets mitchalsup@aol.com (MitchAlsup1) - 2025-07-15 17:16 +0000
Re: register sets Robert Finch <robfi680@gmail.com> - 2025-07-19 08:18 -0400
Re: register sets anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-19 16:37 +0000
Re: register sets mitchalsup@aol.com (MitchAlsup1) - 2025-07-19 20:02 +0000
Re: register sets John Savard <quadibloc@invalid.invalid> - 2025-07-15 04:49 +0000
Re: register sets scott@slp53.sl.home (Scott Lurndal) - 2025-07-15 14:10 +0000
Re: register sets mitchalsup@aol.com (MitchAlsup1) - 2025-07-15 17:14 +0000
Re: Tonights Tradeoff - Carry and Overflow EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-15 09:49 -0400
Re: Tonights Tradeoff - Background Execution Buffers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-13 16:43 +0000
Re: Tonights Tradeoff - Background Execution Buffers BGB <cr88192@gmail.com> - 2024-10-04 12:28 -0500
Re: Tonights Tradeoff - Background Execution Buffers mitchalsup@aol.com (MitchAlsup1) - 2024-10-05 23:02 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-10-28 23:52 -0400
Re: Tonights Tradeoff Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-10-29 00:14 -0700
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-10-29 08:41 -0400
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-10-29 08:50 -0400
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-10-29 13:04 -0500
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-29 17:44 +0000
Re: Tonights Tradeoff Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-10-29 11:29 -0700
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-29 22:31 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-30 16:10 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-10-30 12:29 -0500
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-30 16:46 +0000
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-10-30 23:39 +0200
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-30 22:19 +0000
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-10-31 00:57 +0200
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-31 14:48 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-10-31 13:21 -0500
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-10-31 14:32 -0500
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-02 02:21 -0600
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-02 10:06 -0500
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-02 14:58 -0600
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-02 16:56 -0500
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-02 17:21 -0600
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-10-31 21:12 +0100
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-30 22:00 +0000
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-01 19:18 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-10-29 04:29 -0500
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-29 18:47 +0000
Re: Tonights Tradeoff Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-10-29 13:05 -0700
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-29 21:52 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-10-29 15:58 -0500
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-10-29 18:26 -0400
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-10-29 18:48 -0500
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-10-29 18:15 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-10-29 14:02 -0500
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-10-29 18:01 -0400
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-10-30 07:13 +0000
Re: Tonights Tradeoff scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 13:53 +0000
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-10-30 17:58 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-30 22:06 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-29 18:33 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-10-29 18:20 -0400
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-30 16:09 +0000
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-10-31 21:09 +0100
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-01 18:19 +0000
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-11-01 21:08 +0000
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-02 11:36 +0100
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-02 15:56 +0200
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-02 16:09 +0100
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-02 18:14 +0200
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-02 20:19 +0100
Re: Tonights Tradeoff scott@slp53.sl.home (Scott Lurndal) - 2025-11-03 15:22 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-03 11:53 -0600
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-03 23:04 +0200
Re: Tonights Tradeoff scott@slp53.sl.home (Scott Lurndal) - 2025-11-04 15:19 +0000
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-04 17:41 +0200
Re: Tonights Tradeoff scott@slp53.sl.home (Scott Lurndal) - 2025-11-04 17:12 +0000
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-04 20:16 +0100
Re: Tonights Tradeoff Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-04 07:47 -0800
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-04 16:52 +0100
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-04 18:54 +0200
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-04 20:13 +0100
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-11-04 21:07 +0000
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-04 22:52 +0100
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-05 11:18 +0200
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-05 15:42 +0100
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-04 22:51 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-04 23:43 -0600
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-11-05 07:13 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-05 09:25 -0500
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 20:53 +0000
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-11-06 17:44 +0000
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-05 11:21 +0200
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-05 10:15 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 21:06 +0000
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-06 11:24 +0200
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-06 13:11 -0600
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-07 14:28 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-07 22:57 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-07 20:23 -0600
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-07 22:18 -0500
Re: Tonights Tradeoff - PI as decimal float Robert Finch <robfi680@gmail.com> - 2025-11-08 00:34 -0500
Re: Tonights Tradeoff - PI as decimal float BGB <cr88192@gmail.com> - 2025-11-08 01:30 -0600
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-11-08 11:28 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-09 17:22 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-10 02:12 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-10 03:40 -0600
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-11-10 06:30 +0000
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-10 08:16 +0100
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-10 13:54 -0600
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-11 00:08 +0200
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-10 21:25 -0600
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-11 12:02 +0200
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-11 04:44 -0600
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-11 14:03 +0200
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-11 21:34 -0600
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-12 11:47 +0200
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-13 09:24 +0000
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-13 12:18 +0200
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-13 18:09 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-13 20:40 +0000
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-13 21:50 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-13 22:13 +0000
Re: Tonights Tradeoff Paul Clayton <paaronclayton@gmail.com> - 2026-01-26 20:00 -0500
Re: Tonights Tradeoff scott@slp53.sl.home (Scott Lurndal) - 2026-01-28 02:10 +0000
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-01 17:51 +0100
Re: Interruptible instructions, was Tonights Tradeoff John Levine <johnl@taugh.com> - 2026-01-28 04:47 +0000
Re: Interruptible instructions, was Tonights Tradeoff Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-28 07:34 -0800
Re: Tonights Tradeoff jgd@cix.co.uk (John Dallman) - 2026-01-28 15:34 +0000
Re: Tonights Tradeoff Paul Clayton <paaronclayton@gmail.com> - 2026-02-04 22:31 -0500
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-05 19:02 +0000
Re: Tonights Tradeoff "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-02-05 14:35 -0800
Re: Tonights Tradeoff Paul Clayton <paaronclayton@gmail.com> - 2026-02-08 18:22 -0500
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-09 19:33 +0000
Re: Tonights Tradeoff Paul Clayton <paaronclayton@gmail.com> - 2026-02-09 21:18 -0500
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-18 15:51 -0600
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2026-02-10 17:53 +0000
Re: Tonights Tradeoff George Neuner <gneuner2@comcast.net> - 2026-02-10 14:13 -0500
Re: Tonights Tradeoff David Brown <david.brown@hesbynett.no> - 2026-02-11 15:05 +0100
Re: Tonights Tradeoff George Neuner <gneuner2@comcast.net> - 2026-02-12 10:27 -0500
Re: Tonights Tradeoff jgd@cix.co.uk (John Dallman) - 2026-02-06 15:54 +0000
Re: Tonights Tradeoff Paul Clayton <paaronclayton@gmail.com> - 2026-02-16 20:05 -0500
Re: Tonights Tradeoff jgd@cix.co.uk (John Dallman) - 2026-02-19 08:02 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-19 05:53 -0600
Re: Tonights Tradeoff John Levine <johnl@taugh.com> - 2026-02-19 19:59 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-19 17:04 -0600
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-20 15:14 +0100
Re: Tonights Tradeoff jgd@cix.co.uk (John Dallman) - 2026-02-19 23:10 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-20 00:06 +0000
Re: Tonights Tradeoff Stefan Monnier <monnier@iro.umontreal.ca> - 2026-02-19 22:35 -0500
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 18:41 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-21 20:38 +0000
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-22 13:37 +0000
Re: IA64 and VLIW, Tonights Tradeoff John Levine <johnl@taugh.com> - 2026-02-22 03:00 +0000
Re: IA64 and VLIW, Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-22 09:16 +0000
Re: IA64 and VLIW, Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-22 19:20 +0000
Re: Tonights Tradeoff Stefan Monnier <monnier@iro.umontreal.ca> - 2026-02-22 11:51 -0500
Re: IA-64 and trace scheduling, Tonights Tradeoff John Levine <johnl@taugh.com> - 2026-02-22 20:14 +0000
Re: IA-64 and trace scheduling, Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-22 23:08 +0000
Re: IA-64 and trace scheduling, Tonights Tradeoff John Levine <johnl@taugh.com> - 2026-02-23 01:32 +0000
Re: IA-64 and trace scheduling, Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-23 06:55 +0000
Re: IA-64 and trace scheduling, Tonights Tradeoff jgd@cix.co.uk (John Dallman) - 2026-02-23 21:22 +0000
Re: IA-64 and trace scheduling, Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-24 10:41 +0100
Re: Tonights Tradeoff kegs@provalid.com (Kent Dickey) - 2026-03-01 21:12 +0000
Re: Tonights Tradeoff Stefan Monnier <monnier@iro.umontreal.ca> - 2026-03-03 11:22 -0500
Re: Tonights Tradeoff jgd@cix.co.uk (John Dallman) - 2026-03-03 20:19 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-20 15:29 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-20 23:49 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-21 01:00 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-21 20:15 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-21 14:59 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-21 22:56 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-24 17:32 -0600
Re: Tonights Tradeoff jgd@cix.co.uk (John Dallman) - 2026-02-22 21:52 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-26 14:54 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-27 19:27 +0000
Re: Tonights Tradeoff scott@slp53.sl.home (Scott Lurndal) - 2026-02-27 19:57 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-27 16:14 -0600
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-02-27 17:01 -0600
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-28 16:57 +0100
Re: Tonights Tradeoff scott@slp53.sl.home (Scott Lurndal) - 2026-02-28 17:36 +0000
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2026-03-01 12:18 +0000
Re: Tonights Tradeoff David Brown <david.brown@hesbynett.no> - 2026-03-01 19:19 +0100
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2026-03-01 20:24 +0000
Re: Tonights Tradeoff Andy Valencia <vandys@vsta.org> - 2026-03-01 07:55 -0800
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-28 16:41 +0100
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2026-03-18 05:38 -0500
IA-64 (was: Tonights Tradeoff) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 16:18 +0000
Re: IA-64 (was: Tonights Tradeoff) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-21 20:28 +0000
Re: IA-64 (was: Tonights Tradeoff) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-22 13:17 +0000
Re: IA-64 (was: Tonights Tradeoff) Michael S <already5chosen@yahoo.com> - 2026-02-22 17:05 +0200
Re: IA-64 (was: Tonights Tradeoff) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-23 08:06 +0000
Re: IA-64 (was: Tonights Tradeoff) Michael S <already5chosen@yahoo.com> - 2026-02-23 13:03 +0200
Re: IA-64 (was: Tonights Tradeoff) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-24 10:46 +0000
Re: IA-64 (was: Tonights Tradeoff) Thomas Koenig <tkoenig@netcologne.de> - 2026-02-24 12:30 +0000
Re: IA-64 (was: Tonights Tradeoff) Michael S <already5chosen@yahoo.com> - 2026-02-24 18:26 +0200
Re: IA-64 (was: Tonights Tradeoff) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-25 08:17 +0000
Re: IA-64 (was: Tonights Tradeoff) Michael S <already5chosen@yahoo.com> - 2026-02-23 13:44 +0200
large binary array searches (was: IA-64) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-24 09:50 +0000
Re: large binary array searches (was: IA-64) Michael S <already5chosen@yahoo.com> - 2026-02-24 17:23 +0200
Re: large binary array searches (was: IA-64) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-24 17:30 +0000
Re: large binary array searches (was: IA-64) Michael S <already5chosen@yahoo.com> - 2026-02-24 22:22 +0200
Re: large binary array searches (was: IA-64) Michael S <already5chosen@yahoo.com> - 2026-02-25 15:07 +0200
Re: large binary array searches (was: IA-64) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-25 18:32 +0000
Re: IA-64 (was: Tonights Tradeoff) Thomas Koenig <tkoenig@netcologne.de> - 2026-02-23 21:33 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-23 10:14 -0800
Re: IA-64 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-24 11:25 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-24 07:51 -0800
Re: IA-64 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-25 07:33 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-26 09:08 -0800
Re: IA-64 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-27 09:52 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-28 10:08 -0800
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-01 21:13 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-03-03 09:15 -0800
Re: IA-64 scott@slp53.sl.home (Scott Lurndal) - 2026-03-03 17:37 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-03-03 09:53 -0800
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-03 19:01 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-03-03 11:35 -0800
Re: IA-64 scott@slp53.sl.home (Scott Lurndal) - 2026-03-03 21:55 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-03-04 07:44 -0800
Re: IA-64 scott@slp53.sl.home (Scott Lurndal) - 2026-03-04 15:57 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-04 20:06 +0200
Re: IA-64 scott@slp53.sl.home (Scott Lurndal) - 2026-03-04 20:15 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-06 14:06 -0600
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-07 01:49 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-07 15:03 -0600
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-08 00:28 +0200
Re: Page size in root pointer Robert Finch <robfi680@gmail.com> - 2026-03-08 05:16 -0400
Re: Page size in root pointer MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-08 20:54 +0000
Re: Page size in root pointer BGB <cr88192@gmail.com> - 2026-03-08 16:37 -0500
Re: Page size in root pointer Brett <ggtgp@yahoo.com> - 2026-03-09 04:50 +0000
Re: Page size in root pointer Robert Finch <robfi680@gmail.com> - 2026-03-09 03:01 -0400
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-08 12:13 +0100
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-08 13:37 +0200
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-08 15:10 +0100
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-08 18:30 +0200
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-08 19:39 +0100
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-08 21:03 +0200
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-08 18:59 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-08 14:34 -0500
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-15 16:09 +0000
Re: IA-64 antispam@fricas.org (Waldek Hebisch) - 2026-03-17 01:11 +0000
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-17 21:39 +0000
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-17 21:57 +0000
Re: IA-64 antispam@fricas.org (Waldek Hebisch) - 2026-03-17 23:27 +0000
Re: IA-64 EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-17 20:38 -0400
Re: IA-64 Robert Finch <robfi680@gmail.com> - 2026-03-17 21:00 -0400
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-18 15:56 +0000
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-18 17:30 +0100
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-18 15:51 -0500
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-18 21:41 +0000
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-18 21:49 +0000
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-17 19:20 +0000
Re: IA-64 EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-17 15:48 -0400
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-17 21:51 +0000
Re: IA-64 EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-17 18:06 -0400
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-18 15:14 -0500
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-19 22:14 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-20 04:49 -0500
Re: IA-64 Torbjorn Lindgren <tl@none.invalid> - 2026-03-20 14:03 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-20 17:04 +0200
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-20 16:26 +0100
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-20 17:31 +0200
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-20 18:56 +0100
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-20 16:20 +0100
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-20 14:39 -0500
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-21 15:20 +0100
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-21 13:31 -0500
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-21 13:47 -0500
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-22 13:05 +0100
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-20 19:35 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-20 15:09 -0500
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-21 15:35 +0100
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-21 23:51 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-22 02:48 +0200
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-22 13:20 +0100
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-22 15:34 +0000
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-22 16:59 +0100
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-22 13:10 +0100
Re: IA-64 scott@slp53.sl.home (Scott Lurndal) - 2026-03-22 16:34 +0000
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-23 11:14 +0100
Re: IA-64 scott@slp53.sl.home (Scott Lurndal) - 2026-03-20 21:19 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-21 18:52 +0200
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-21 18:44 +0100
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-22 00:54 +0200
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-08 21:08 +0000
Re: IA-64 Stefan Monnier <monnier@iro.umontreal.ca> - 2026-03-08 10:56 -0400
Re: IA-64 EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-08 12:53 -0400
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-08 19:43 +0100
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-08 21:18 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-08 17:06 -0500
Re: IA-64 EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-08 17:18 -0400
multi-bit per cell RAM (was: IA-64) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-09 08:04 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-08 14:19 -0500
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-04 18:51 +0000
Re: IA-64 Torbjorn Lindgren <tl@none.invalid> - 2026-03-05 12:57 +0000
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-27 18:55 +0000
Re: IA-64 antispam@fricas.org (Waldek Hebisch) - 2026-02-28 21:49 +0000
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-03-02 17:12 -0800
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-03 02:34 +0000
Re: IA-64 Stefan Monnier <monnier@iro.umontreal.ca> - 2026-03-04 09:22 -0500
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-03-04 07:19 -0800
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-04 19:03 +0100
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-04 20:25 +0200
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-04 19:38 +0100
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-04 21:17 +0200
Re: IA-64 Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-03-04 11:49 -0800
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-07 23:48 +0200
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-07 13:21 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-07 19:03 +0200
Re: IA-64 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-08 08:27 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-08 13:15 +0200
Re: IA-64 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-08 12:36 +0000
Re: IA-64 kegs@provalid.com (Kent Dickey) - 2026-03-04 21:07 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-04 23:35 +0200
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-04 23:46 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-05 12:07 +0200
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-05 17:49 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-05 12:22 +0200
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-03-07 13:29 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-07 19:19 +0200
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-07 19:07 +0000
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-07 21:21 +0200
Re: IA-64 EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-05 11:07 -0500
Re: IA-64 EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-05 14:47 -0500
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-06 20:08 +0000
Re: IA-64 Andy Valencia <vandys@vsta.org> - 2026-03-05 08:36 -0800
Re: IA-64 Stefan Monnier <monnier@iro.umontreal.ca> - 2026-03-05 12:02 -0500
Re: IA-64 scott@slp53.sl.home (Scott Lurndal) - 2026-03-05 17:14 +0000
Re: IA-64 Stefan Monnier <monnier@iro.umontreal.ca> - 2026-03-05 14:18 -0500
Re: IA-64 Michael S <already5chosen@yahoo.com> - 2026-03-05 19:41 +0200
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-05 18:10 +0000
Re: IA-64 kegs@provalid.com (Kent Dickey) - 2026-03-06 19:52 +0000
Re: IA-64 Andy Valencia <vandys@vsta.org> - 2026-03-07 15:53 -0800
Re: IA-64 Andy Valencia <vandys@vsta.org> - 2026-03-06 11:34 -0800
Re: IA-64 George Neuner <gneuner2@comcast.net> - 2026-03-07 16:03 -0500
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-09 22:42 +0100
Re: IA-64 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 21:07 -0700
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-14 16:27 +0100
Re: GPU books? Robert Finch <robfi680@gmail.com> - 2026-03-15 01:07 -0400
Re: GPU books? EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-16 12:06 -0400
Re: GPU books? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-16 12:34 -0700
Re: GPU books? MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-17 17:57 +0000
Re: IA-64 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 14:14 -0700
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-16 15:35 +0100
Re: IA-64 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-18 01:01 -0700
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-18 17:38 +0100
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-18 20:28 +0100
Re: IA-64 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-18 21:05 -0700
Re: IA-64 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-23 21:01 -0700
Re: IA-64 David Brown <david.brown@hesbynett.no> - 2026-03-24 09:24 +0100
Re: IA-64 antispam@fricas.org (Waldek Hebisch) - 2026-03-05 02:54 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-02-26 14:54 -0600
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-27 19:04 +0000
Re: IA-64 Thomas Koenig <tkoenig@netcologne.de> - 2026-02-27 19:31 +0000
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-28 16:48 +0100
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-01 05:39 -0600
Re: IA-64 Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-01 19:02 +0100
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-01 18:05 -0600
Re: IA-64 MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-02 02:03 +0000
Re: IA-64 BGB <cr88192@gmail.com> - 2026-03-03 04:24 -0600
Re: IA-64 (was: Tonights Tradeoff) jgd@cix.co.uk (John Dallman) - 2026-03-08 17:53 +0000
Re: IA-64 (was: Tonights Tradeoff) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-08 21:15 +0000
Re: IA-64 (was: Tonights Tradeoff) BGB <cr88192@gmail.com> - 2026-03-08 16:43 -0500
Re: IA-64 (was: Tonights Tradeoff) EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-09 13:14 -0400
Re: IA-64 (was: Tonights Tradeoff) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-09 19:30 +0000
Re: IA-64 (was: Tonights Tradeoff) EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-10 13:04 -0400
Re: IA-64 (was: Tonights Tradeoff) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-10 18:28 +0000
Re: IA-64 (was: Tonights Tradeoff) EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-11 12:14 -0400
Re: IA-64 (was: Tonights Tradeoff) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-11 21:37 +0000
Re: IA-64 (was: Tonights Tradeoff) EricP <ThatWouldBeTelling@thevillage.com> - 2026-03-12 10:56 -0400
Re: IA-64 (was: Tonights Tradeoff) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-12 18:15 +0000
Re: Tonights Tradeoff Paul Clayton <paaronclayton@gmail.com> - 2026-02-21 23:51 -0500
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-28 19:19 +0000
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2026-01-29 07:13 +0000
Re: Tonights Tradeoff Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-29 12:30 -0500
Re: Tonights Tradeoff Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-29 12:30 -0500
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-01 18:01 +0100
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-11-14 14:18 +0000
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-14 22:32 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-13 14:34 -0600
Re: Tonights Tradeoff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-13 21:58 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-14 00:43 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-13 19:17 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-14 03:59 +0000
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-19 12:53 -0600
Multi-precision addition and architectural progress (was: Tonights ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-14 07:18 +0000
Re: Multi-precision addition and architectural progress (was: Tonights ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-14 18:48 +0000
Re: Multi-precision addition and architectural progress (was: Tonights ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-14 22:38 +0000
Re: Multi-precision addition and architectural progress (was: Tonights ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-15 01:22 +0000
Re: Multi-precision addition and architectural progress (was: Tonights ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-15 01:28 +0000
Re: Multi-precision addition and architectural progress (was: Tonights ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-16 14:45 +0000
Re: Multi-precision addition and architectural progress Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-15 15:36 +0100
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-15 18:04 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-16 14:34 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-16 18:41 +0000
Multi-precision multiplication (was: Multi-precision addition ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-15 18:01 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-11-14 15:00 -0500
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-15 10:46 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-11-15 07:48 -0500
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-15 18:07 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-16 08:22 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-16 18:36 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-11-17 02:49 -0500
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-17 08:33 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-11-17 08:17 -0500
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-17 17:36 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-17 18:54 +0000
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-17 20:58 +0000
Re: Multi-precision addition and architectural progress Michael S <already5chosen@yahoo.com> - 2025-11-17 23:35 +0200
SPARC and register renaming (was: Multi-precision addition ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-18 15:16 +0000
Re: SPARC and register renaming Paul Clayton <paaronclayton@gmail.com> - 2026-02-16 17:24 -0500
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-18 08:58 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-17 18:45 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-11-17 16:58 -0500
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-17 18:41 +0000
Re: Multi-precision addition and architectural progress BGB <cr88192@gmail.com> - 2025-11-18 13:22 -0600
Re: Multi-precision addition and architectural progress BGB <cr88192@gmail.com> - 2025-11-18 13:15 -0600
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-18 19:28 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-18 22:25 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-20 07:33 +0000
Re: Multi-precision addition and architectural progress antispam@fricas.org (Waldek Hebisch) - 2025-11-25 00:40 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-26 07:53 +0000
Re: Multi-precision addition and architectural progress Michael S <already5chosen@yahoo.com> - 2025-11-26 12:17 +0200
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-26 18:08 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-26 21:00 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-11-18 20:26 -0500
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-19 01:47 +0000
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-19 07:47 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-20 08:05 +0000
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-23 16:32 +0000
Re: Multi-precision addition and architectural progress scott@slp53.sl.home (Scott Lurndal) - 2025-11-23 16:51 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-23 17:25 +0000
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-23 20:46 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-23 22:40 +0000
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-28 20:39 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-28 23:06 +0000
Re: Interrupt enable down-count Robert Finch <robfi680@gmail.com> - 2025-11-29 09:29 -0500
Re: Interrupt enable down-count Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-29 07:37 -0800
Re: Interrupt enable down-count Robert Finch <robfi680@gmail.com> - 2025-11-29 13:28 -0500
Re: Interrupt enable down-count MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-29 19:23 +0000
Re: Interrupt enable down-count MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-29 19:05 +0000
Re: Interrupt enable down-count Robert Finch <robfi680@gmail.com> - 2025-11-29 15:42 -0500
Re: Interrupt enable down-count MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-29 22:17 +0000
Re: Interrupt enable down-count EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-29 16:10 -0500
Re: Interrupt enable down-count MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-29 22:26 +0000
Re: Interrupt enable down-count Robert Finch <robfi680@gmail.com> - 2025-11-29 17:45 -0500
Re: Interrupt enable down-count MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-29 23:14 +0000
Re: Interrupt enable down-count Robert Finch <robfi680@gmail.com> - 2025-11-30 02:17 -0500
Re: Interrupt enable down-count Thomas Koenig <tkoenig@netcologne.de> - 2025-11-30 10:10 +0000
Re: Interrupt enable down-count Robert Finch <robfi680@gmail.com> - 2025-11-30 06:29 -0500
Re: Interrupt enable down-count Robert Finch <robfi680@gmail.com> - 2025-11-30 06:41 -0500
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-29 23:37 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-30 14:14 +0000
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-30 15:47 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-30 16:39 +0000
Re: Multi-precision addition and architectural progress Thomas Koenig <tkoenig@netcologne.de> - 2025-11-30 18:59 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-30 22:11 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-12-06 00:40 -0500
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-06 07:26 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-12-06 05:13 -0500
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-06 17:31 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-06 17:29 +0000
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-12-06 18:33 -0500
Re: Multi-precision addition and architectural progress Robert Finch <robfi680@gmail.com> - 2025-12-06 18:55 -0500
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-07 03:29 +0000
Re: Multi-precision addition and architectural progress scott@slp53.sl.home (Scott Lurndal) - 2025-11-24 18:03 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-30 15:18 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-30 19:33 +0000
Re: Multi-precision addition and architectural progress Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-30 22:38 +0200
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-30 22:17 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-01 00:12 +0000
Memory ordering (Re: Multi-precision addition ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-01 07:56 +0000
Re: Memory ordering (Re: Multi-precision addition ...) Michael S <already5chosen@yahoo.com> - 2025-12-01 13:23 +0200
Re: Memory ordering (Re: Multi-precision addition ...) kegs@provalid.com (Kent Dickey) - 2025-12-04 16:54 +0000
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-04 18:37 +0000
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-05 11:10 +0100
Re: Memory ordering (Re: Multi-precision addition ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-05 14:37 +0000
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-05 18:29 +0100
Re: Memory ordering (Re: Multi-precision addition ...) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-12-15 12:30 -0500
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-05 17:57 +0000
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-05 20:10 +0100
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-05 20:54 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-05 14:55 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-06 17:22 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-07 15:09 -0800
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-06 14:42 +0100
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-06 17:44 +0000
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-08 10:07 +0100
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-08 20:20 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-07 15:17 -0800
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-08 10:12 +0100
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-08 04:32 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-08 20:06 +0000
Re: Memory ordering (Re: Multi-precision addition ...) scott@slp53.sl.home (Scott Lurndal) - 2025-12-08 20:15 +0000
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-08 21:58 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 14:37 -0800
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 14:39 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-12 23:39 +0000
Re: Memory ordering (Re: Multi-precision addition ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-13 09:31 +0000
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-13 19:12 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-13 11:46 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-13 21:58 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 14:47 -0800
Re: Memory ordering (Re: Multi-precision addition ...) scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 17:16 +0000
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-06 18:07 +0000
Re: Memory ordering (Re: Multi-precision addition ...) scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 19:04 +0000
Re: Memory ordering (Re: Multi-precision addition ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-06 21:36 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-07 16:08 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-06 21:44 +0000
Re: Memory ordering (Re: Multi-precision addition ...) scott@slp53.sl.home (Scott Lurndal) - 2025-12-07 16:13 +0000
Re: Memory ordering (Re: Multi-precision addition ...) Robert Finch <robfi680@gmail.com> - 2025-12-08 07:25 -0500
Re: Memory ordering (Re: Multi-precision addition ...) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-12-08 08:23 -0800
Re: Memory ordering (Re: Multi-precision addition ...) scott@slp53.sl.home (Scott Lurndal) - 2025-12-08 17:14 +0000
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-08 20:35 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-08 16:31 -0800
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 15:56 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-13 19:03 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-13 11:49 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-13 22:03 +0000
Re: double alias register renaming Robert Finch <robfi680@gmail.com> - 2025-12-14 05:13 -0500
Re: double alias register renaming MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-16 20:43 +0000
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-17 13:52 -0800
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-09 09:13 +0100
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-09 19:15 +0000
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-09 20:51 +0100
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-09 21:28 +0000
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-10 10:07 +0100
Re: Memory ordering (Re: Multi-precision addition ...) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-12-10 08:51 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-10 20:10 +0000
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-11 10:05 +0100
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-11 20:26 +0000
Re: Memory ordering (Re: Multi-precision addition ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-11 20:47 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) John Levine <johnl@taugh.com> - 2025-12-12 01:41 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-11 18:27 -0800
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) John Levine <johnl@taugh.com> - 2025-12-12 02:48 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-12 19:17 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-12 21:02 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-12 22:05 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 14:19 -0800
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 14:22 -0800
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-12 08:14 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-12 13:05 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-12 15:28 +0100
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-12 16:25 +0000
Re: instruction ordering, was Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-12 21:12 +0100
Re: Memory ordering (Re: Multi-precision addition ...) Michael S <already5chosen@yahoo.com> - 2025-12-11 23:51 +0200
Re: Memory ordering (Re: Multi-precision addition ...) David Brown <david.brown@hesbynett.no> - 2025-12-12 08:59 +0100
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-11 15:02 -0800
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-11 15:03 -0800
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-11 15:00 -0800
Re: Memory ordering (Re: Multi-precision addition ...) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-12-09 13:55 -0800
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-09 22:52 +0000
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-08 20:30 +0000
Re: Memory ordering (Re: Multi-precision addition ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-07 09:30 +0000
Re: Memory ordering (Re: Multi-precision addition ...) Michael S <already5chosen@yahoo.com> - 2025-12-07 16:05 +0200
Re: Memory ordering (Re: Multi-precision addition ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-07 16:55 +0000
Re: Memory ordering (Re: Multi-precision addition ...) scott@slp53.sl.home (Scott Lurndal) - 2025-12-07 16:28 +0000
Re: Memory ordering (Re: Multi-precision addition ...) EricP <ThatWouldBeTelling@thevillage.com> - 2025-12-07 12:19 -0500
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 15:52 -0800
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-07 16:36 -0800
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-05 15:03 -0800
Re: Memory ordering (Re: Multi-precision addition ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-07 14:51 -0800
Re: Memory ordering (Re: Multi-precision addition ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-07 17:48 +0000
Re: Memory ordering (Re: Multi-precision addition ...) EricP <ThatWouldBeTelling@thevillage.com> - 2025-12-01 14:07 -0500
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-01 23:03 +0000
Re: Memory ordering (Re: Multi-precision addition ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-01 22:50 +0000
Re: Unaligned Memory Access Robert Finch <robfi680@gmail.com> - 2025-12-02 07:10 -0500
Re: Unaligned Memory Access anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-02 18:50 +0000
Re: Unaligned Memory Access MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-02 19:55 +0000
Re: Unaligned Memory Access Robert Finch <robfi680@gmail.com> - 2025-12-02 21:20 -0500
Re: Unaligned Memory Access Paul Clayton <paaronclayton@gmail.com> - 2026-02-16 18:04 -0500
Re: Hardware hardware interrupt Robert Finch <robfi680@gmail.com> - 2026-02-18 01:04 -0500
Re: Unaligned Memory Access quadi <quadibloc@ca.invalid> - 2026-03-09 03:36 +0000
Re: Unaligned Memory Access Stefan Monnier <monnier@iro.umontreal.ca> - 2026-03-09 11:05 -0400
Re: Unaligned Memory Access John Levine <johnl@taugh.com> - 2026-03-10 06:07 +0000
Re: Unaligned Memory Access "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-10 17:20 -0700
Re: Unaligned Memory Access Thomas Koenig <tkoenig@netcologne.de> - 2026-03-13 07:10 +0000
Re: Unaligned Memory Access MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-13 16:14 +0000
Re: Unaligned Memory Access Thomas Koenig <tkoenig@netcologne.de> - 2026-03-14 14:03 +0000
Re: Unaligned Memory Access John Levine <johnl@taugh.com> - 2026-03-14 19:35 +0000
Re: Unaligned Memory Access Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-14 16:30 +0100
Re: Unaligned Memory Access BGB <cr88192@gmail.com> - 2026-03-18 23:02 -0500
Re: Unaligned Memory Access MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-19 22:20 +0000
Re: Float multiplies Robert Finch <robfi680@gmail.com> - 2026-03-21 16:58 -0400
Re: Float multiplies MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-22 16:46 +0000
Re: Float multiplies Robert Finch <robfi680@gmail.com> - 2026-03-23 01:31 -0400
Re: Float multiplies BGB <cr88192@gmail.com> - 2026-03-23 04:44 -0500
Re: Unaligned Memory Access anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-14 16:08 +0000
Re: Unaligned Memory Access Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-15 14:12 +0100
Re: Unaligned Memory Access Michael S <already5chosen@yahoo.com> - 2026-03-15 17:36 +0200
Unaligned stores (was: Unaligned Memory Access) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-15 17:30 +0000
Re: Unaligned Memory Access Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-16 15:09 +0100
Re: Unaligned Memory Access Michael S <already5chosen@yahoo.com> - 2026-03-16 18:01 +0200
Re: Unaligned Memory Access MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-17 17:55 +0000
Re: Unaligned Memory Access BGB <cr88192@gmail.com> - 2026-03-10 16:41 -0500
Re: Unaligned Memory Access MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-11 00:18 +0000
Re: Unaligned Memory Access Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-11 16:40 +0100
Re: Unaligned Memory Access "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-11 12:40 -0700
Re: Unaligned Memory Access MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-03-11 21:40 +0000
Re: Unaligned Memory Access scott@slp53.sl.home (Scott Lurndal) - 2026-03-11 21:44 +0000
Re: Unaligned Memory Access Terje Mathisen <terje.mathisen@tmsw.no> - 2026-03-14 16:23 +0100
Re: Unaligned Memory Access "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-16 12:38 -0700
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-23 20:16 +0000
Re: Multi-precision addition and architectural progress MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-23 20:15 +0000
Re: Multi-precision addition and architectural progress anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-20 07:55 +0000
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-14 15:57 +0100
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-14 14:39 -0600
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-13 19:04 +0000
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-21 15:31 +0200
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-21 13:36 -0600
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-21 22:09 -0500
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-22 04:54 -0600
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-22 12:45 -0500
Re: Tonights Tradeoff BGB <cr88192@gmail.com> - 2025-11-22 14:29 -0600
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-11-22 18:50 +0200
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-12-16 19:47 +0200
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-12-16 17:51 +0000
Re: Tonights Tradeoff Michael S <already5chosen@yahoo.com> - 2025-12-17 12:02 +0200
Re: Tonights Tradeoff - write port history Robert Finch <robfi680@gmail.com> - 2025-12-18 21:33 -0500
Re: Tonights Tradeoff Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-04 08:50 +0100
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-03 19:03 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-05 01:41 -0500
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 20:30 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-02 09:39 -0500
Re: Tonights Tradeoff Thomas Koenig <tkoenig@netcologne.de> - 2025-11-03 18:47 +0000
branch splitting (was: Tonights Tradeoff) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-04 07:50 +0000
Re: branch splitting (was: Tonights Tradeoff) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-04 19:15 +0000
Re: branch splitting Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-04 22:44 +0100
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 00:44 +0000
Re: branch splitting BGB <cr88192@gmail.com> - 2025-11-05 01:00 -0600
Re: branch splitting BGB <cr88192@gmail.com> - 2025-11-05 01:38 -0600
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 20:43 +0000
Re: branch splitting Paul Clayton <paaronclayton@gmail.com> - 2026-02-08 10:24 -0500
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-09 19:20 +0000
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2026-04-05 06:49 +0000
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-05 20:35 +0000
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2026-04-06 05:11 +0000
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-06 16:24 +0000
Re: round mode register Robert Finch <robfi680@gmail.com> - 2026-04-07 22:53 -0400
Re: branch splitting Paul Clayton <paaronclayton@gmail.com> - 2026-02-16 16:14 -0500
Re: branch splitting BGB <cr88192@gmail.com> - 2026-02-18 14:45 -0600
Re: branch splitting Paul Clayton <paaronclayton@gmail.com> - 2026-02-23 17:17 -0500
Re: branch splitting BGB <cr88192@gmail.com> - 2026-02-25 17:40 -0600
Re: branch splitting Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-04 15:46 -0800
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 02:51 +0000
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-05 05:17 +0000
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2025-11-05 06:44 +0000
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-05 06:55 +0000
Re: branch splitting EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-05 10:49 -0500
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-06 18:14 +0000
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2025-11-06 20:04 +0000
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-07 10:32 +0000
Re: branch splitting EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-06 16:24 -0500
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-06 22:53 +0000
Re: branch splitting EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-06 20:10 -0500
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2025-11-05 18:03 +0000
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-06 18:17 +0000
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2025-11-06 20:07 +0000
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-06 20:24 +0000
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2025-11-07 06:55 +0000
Re: branch splitting Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-04 22:53 -0800
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-06 08:46 +0000
Re: branch splitting Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-06 12:37 +0200
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-07 08:08 +0000
Re: branch splitting Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-06 07:57 -0800
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-07 10:09 +0000
Re: branch splitting Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-07 08:26 -0800
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-07 17:15 +0000
Re: branch splitting Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-07 10:45 -0800
Re: branch splitting EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-08 10:31 -0500
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-08 18:13 +0000
Re: branch splitting Michael S <already5chosen@yahoo.com> - 2025-11-08 21:47 +0200
Re: branch splitting scott@slp53.sl.home (Scott Lurndal) - 2025-11-09 17:06 +0000
Re: PDP-8 history, branch splitting John Levine <johnl@taugh.com> - 2025-11-09 20:00 +0000
Re: PDP-8 history, branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-09 21:14 +0000
Re: PDP-8 history, branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-10 07:46 +0000
Re: PDP-8 history, branch splitting scott@slp53.sl.home (Scott Lurndal) - 2025-11-10 14:52 +0000
Re: PDP-8 history, branch splitting John Levine <johnl@taugh.com> - 2025-11-10 18:53 +0000
Re: branch splitting Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-10 08:27 +0100
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-08 18:25 +0000
Re: branch splitting Michael S <already5chosen@yahoo.com> - 2025-11-08 20:56 +0200
Re: jumping around, branch splitting John Levine <johnl@taugh.com> - 2025-11-08 21:08 +0000
Re: jumping around, branch splitting EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-09 13:01 -0500
Re: jumping around, branch splitting John Levine <johnl@taugh.com> - 2025-11-09 20:18 +0000
Re: jumping around, branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-09 21:11 +0000
Re: jumping around, branch splitting Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-11 19:58 +0200
Re: jumping around, branch splitting scott@slp53.sl.home (Scott Lurndal) - 2025-11-11 18:48 +0000
Re: indirect chains, jumping around, branch splitting John Levine <johnl@taugh.com> - 2025-11-11 21:10 +0000
Re: indirect chains, jumping around, branch splitting Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-11 16:06 -0800
Re: branch splitting John Levine <johnl@taugh.com> - 2025-11-08 21:07 +0000
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-06 18:45 +0000
Re: label variables, was branch splitting John Levine <johnl@taugh.com> - 2025-11-06 22:09 +0000
Re: label variables, was branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-07 15:26 +0000
Re: label variables, was branch splitting Bill Findlay <findlaybill@blueyonder.co.uk> - 2025-11-07 17:54 +0000
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2025-11-08 10:02 +0000
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-08 18:04 +0000
Re: branch splitting Thomas Koenig <tkoenig@netcologne.de> - 2025-11-08 19:32 +0000
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-08 18:37 +0000
Re: goto, was branch splitting John Levine <johnl@taugh.com> - 2025-11-08 21:14 +0000
Re: branch splitting BGB <cr88192@gmail.com> - 2025-11-05 02:01 -0600
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 21:04 +0000
Re: branch splitting Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-05 17:26 +0200
Re: branch splitting BGB <cr88192@gmail.com> - 2025-11-05 10:23 -0600
Re: branch splitting scott@slp53.sl.home (Scott Lurndal) - 2025-11-05 17:22 +0000
Re: branch splitting Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-05 21:30 +0200
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 21:28 +0000
Re: branch splitting Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-06 00:45 +0200
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-06 18:28 +0000
Re: branch splitting Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-11 18:50 +0200
Re: branch splitting EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-11 14:23 -0500
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-11 20:44 +0000
Re: branch splitting EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-11 21:16 -0500
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-13 08:42 +0000
Re: branch splitting Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> - 2025-11-13 19:32 +0100
Re: branch splitting antispam@fricas.org (Waldek Hebisch) - 2025-11-13 01:35 +0000
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-13 09:45 +0000
Re: branch splitting antispam@fricas.org (Waldek Hebisch) - 2025-11-13 17:35 +0000
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-11 19:46 +0000
Re: branch splitting Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-11 15:55 -0800
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-12 00:31 +0000
Re: branch splitting Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-11 17:18 -0800
Re: branch splitting Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-12 21:56 +0200
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-12 20:25 +0000
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-06 22:21 +0000
Re: branch splitting MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 21:24 +0000
Re: branch splitting Michael S <already5chosen@yahoo.com> - 2025-11-06 11:43 +0200
Re: branch splitting Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-11-06 12:11 +0200
Re: branch splitting Michael S <already5chosen@yahoo.com> - 2025-11-06 13:14 +0200
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-07 08:06 +0000
Re: branch splitting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-06 17:52 +0000
Re: branch splitting Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-05 15:27 +0100
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-05 01:47 -0500
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-05 02:06 -0500
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 20:52 +0000
Re: Tonights Tradeoff Robert Finch <robfi680@gmail.com> - 2025-11-05 20:41 -0500
Re: Tonights Tradeoff Paul Clayton <paaronclayton@gmail.com> - 2026-02-07 21:49 -0500
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-09 19:09 +0000
Re: Tonights Tradeoff MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-03 19:13 +0000
Re: Tonights Tradeoff - constants / routing Robert Finch <robfi680@gmail.com> - 2025-11-05 09:56 -0500
Re: Tonights Tradeoff - constants / routing MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-05 21:21 +0000
Re: Tonights Tradeoff - constants / routing Robert Finch <robfi680@gmail.com> - 2025-11-05 21:49 -0500
Re: Tonights Tradeoff - constants / routing MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-06 18:36 +0000
Re: Tonights Tradeoff - constants / routing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-05 19:20 -0800
Re: Tonights Tradeoff - constants / routing MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-06 18:39 +0000
Re: Tonights Tradeoff - constants / routing Thomas Koenig <tkoenig@netcologne.de> - 2025-11-08 14:11 +0000
Re: Tonights Tradeoff - constants / routing MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-08 18:08 +0000
Re: Tonights Tradeoff - constants / routing Thomas Koenig <tkoenig@netcologne.de> - 2025-11-06 19:38 +0000
Re: Tonights Tradeoff - constants / routing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-06 12:14 -0800
Re: Tonights Tradeoff - constants / routing Thomas Koenig <tkoenig@netcologne.de> - 2025-11-07 17:29 +0000
Re: Tonights Tradeoff - constants / routing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-09 14:54 -0800
Re: Tonights Tradeoff - constants / routing MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-10 02:00 +0000
Re: Tonights Tradeoff - constants / routing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-11-09 20:03 -0800
Re: Tonights Tradeoff - constants / routing MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-06 21:59 +0000
Re: Tonights Tradeoff - constants / routing kegs@provalid.com (Kent Dickey) - 2025-11-12 06:20 +0000
Re: Tonights Tradeoff - constants / routing Thomas Koenig <tkoenig@netcologne.de> - 2025-11-12 08:01 +0000
Re: Tonights Tradeoff - constants / routing MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-12 19:22 +0000
Re: Tonights Tradeoff / Fusing branch ops Robert Finch <robfi680@gmail.com> - 2025-11-06 07:44 -0500
Re: Tonights Tradeoff - Cache-line constants Robert Finch <robfi680@gmail.com> - 2025-11-07 22:30 -0500
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-10 21:56 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-11 19:30 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-11 21:42 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-23 03:20 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-22 23:16 -0500
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-22 23:36 -0500
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-23 07:04 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-23 20:13 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-23 23:58 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-24 20:00 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-25 21:08 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-26 20:57 +0000
Re: Tonights Tradeoff - NaN boxed precisions scott@slp53.sl.home (Scott Lurndal) - 2025-11-26 22:16 +0000
Re: Tonights Tradeoff - NaN boxed precisions "Brian G. Lucas" <bagel99@gmail.com> - 2025-11-26 17:20 -0500
Re: Tonights Tradeoff - NaN boxed precisions scott@slp53.sl.home (Scott Lurndal) - 2025-11-26 22:29 +0000
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-26 23:53 +0000
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-26 23:46 +0000
Re: Tonights Tradeoff - NaN boxed precisions anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-11-28 07:21 +0000
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-28 20:05 +0000
Re: Tonights Tradeoff - NaN boxed precisions Thomas Koenig <tkoenig@netcologne.de> - 2025-11-28 06:45 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-26 18:19 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-27 00:08 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-27 00:36 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-28 19:35 +0000
Re: Tonights Tradeoff - NaN boxed precisions George Neuner <gneuner2@comcast.net> - 2025-11-27 00:44 -0500
Re: Tonights Tradeoff - NaN boxed precisions Terje Mathisen <terje.mathisen@tmsw.no> - 2025-11-26 22:26 +0100
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-26 21:58 +0000
Re: Tonights Tradeoff - NaN boxed precisions kegs@provalid.com (Kent Dickey) - 2025-11-27 15:50 +0000
Re: Tonights Tradeoff - NaN boxed precisions Michael S <already5chosen@yahoo.com> - 2025-11-27 19:16 +0200
Re: Tonights Tradeoff - NaN boxed precisions Thomas Koenig <tkoenig@netcologne.de> - 2025-11-28 07:17 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-28 02:59 -0500
Re: Tonights Tradeoff - NaN boxed precisions EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-28 12:56 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-28 20:41 +0000
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-28 20:09 +0000
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-28 19:49 +0000
Re: Tonights Tradeoff - NaN boxed precisions kegs@provalid.com (Kent Dickey) - 2025-11-29 15:48 +0000
Re: Tonights Tradeoff - NaN boxed precisions Thomas Koenig <tkoenig@netcologne.de> - 2025-11-29 19:11 +0000
Re: Tonights Tradeoff - NaN boxed precisions EricP <ThatWouldBeTelling@thevillage.com> - 2025-11-29 15:08 -0500
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-29 22:07 +0000
Re: Tonights Tradeoff - NaN boxed precisions Thomas Koenig <tkoenig@netcologne.de> - 2025-11-11 21:18 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-11 21:46 -0500
Re: Tonights Tradeoff - NaN boxed precisions Thomas Koenig <tkoenig@netcologne.de> - 2025-11-12 07:19 +0000
Re: Tonights Tradeoff - NaN boxed precisions MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-11-12 20:27 +0000
Re: Tonights Tradeoff - NaN boxed precisions Robert Finch <robfi680@gmail.com> - 2025-11-12 23:59 -0500
Re: Tonights Tradeoff - NaN boxed precisions Thomas Koenig <tkoenig@netcologne.de> - 2025-11-13 07:24 +0000
Page 41 of 46 — ← Prev page 1 … 39 40 [41] 42 43 … 46 Next page →
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-08 18:04 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <1762625044-5857@newsgrouper.org> |
| In reply to | #114021 |
Thomas Koenig <tkoenig@netcologne.de> posted:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> > void engine(char *source)
> > {
> > void *insts[] = {&&add, &&load, &&ip, ...};
> >
> > void **ip=compile_to_vm_code(source,insts);
> >
> > goto *ip++;
> >
> > add:
> > ...
> > goto *ip++;
>
> One problem with assigned GOTO is data flow analysis for a comiler.
>
> Compilers typically break down structured control flow into GOTO
> and then perform analysis. A label whose address is assigned
> anywhere in the program unit to a variable must be considered to
> be reachable by any GOTO to said variable, so any variable in that
> piece of code must be in a known place (i.e. memory). If it
> is kept in a register in some places that could jump to that
> particular label, the contents of that register must be stored
> to memory before the jump is executed. Alternatively, memory
> allocation must make sure that the same register is always used.
>
> This was probably less of a problem when assigned goto was invented
> (I assume this was for FORTRAN 66)
I think FORTRAN 66 inherited from FORTRAN II or even FORTRAN (1),
it was available in WATFOR and WATFIV.
> when few varibles were kept in
> registers, and register allocation was in its infancy. Now, this is
> a much bigger impediment to optimization.
>
> In other words, assigned goto confuses both programmers and
> compilers.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-11-08 19:32 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <10eo5su$2pdvp$2@dont-email.me> |
| In reply to | #114025 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > > Thomas Koenig <tkoenig@netcologne.de> posted: >> This was probably less of a problem when assigned goto was invented >> (I assume this was for FORTRAN 66) > > I think FORTRAN 66 inherited from FORTRAN II or even FORTRAN (1), > it was available in WATFOR and WATFIV. I looked it up: It was at least in Fortran II, according to https://archive.computerhistory.org/resources/text/Fortran/102663119.05.01.acc.pdf -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-11-08 18:37 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <2025Nov8.193748@mips.complang.tuwien.ac.at> |
| In reply to | #114021 |
Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> void engine(char *source)
>> {
>> void *insts[] = {&&add, &&load, &&ip, ...};
>>
>> void **ip=compile_to_vm_code(source,insts);
>>
>> goto *ip++;
>>
>> add:
>> ...
>> goto *ip++;
>
>One problem with assigned GOTO is data flow analysis for a comiler.
>
>Compilers typically break down structured control flow into GOTO
>and then perform analysis. A label whose address is assigned
>anywhere in the program unit to a variable must be considered to
>be reachable by any GOTO to said variable, so any variable in that
>piece of code must be in a known place (i.e. memory). If it
>is kept in a register in some places that could jump to that
>particular label, the contents of that register must be stored
>to memory before the jump is executed. Alternatively, memory
>allocation must make sure that the same register is always used.
The data flow analysis for labels-as-values (and assigned goto) is
just the same as for any other control flow. Every goto * has to be
considered to potentially jump to any label whose address ist taken
with &&label, just as a switch has to be considered to go to any of
the case labels, an if has to be considered to go to either of the two
paths. Similarly, a label has to be considered to be reachable from
any of the gotos that jump to it, and the statement behind a switch
statement has to be considered to be reachable from any of the break
statements in the switch statement. So, having many outgoing or
incoming control flow edges is nothing that only labels-as-values
produces. Consider that the replicated switch is intended to produce
a control-flow graph that's as close as possible to the one produced
by using labels-as-values.
Concerning register allocation (never heard of memory allocation), of
course variables have to live in the same register or memory location
at either end of a control-flow edge; and when multiple control-flow
edges start or end at the same point, they have to live in the same
location for all of these edges.
This is certainly something that gcc has known how to do from when
labels-as-values were introduced in 2.0 (admittedly I only tried using
it a few months later, when the version was already at 2.2.2).
There have been a few episodes (e.g., in gcc-3.0 and 3.1) when gcc put
a lot of register-memory-shuffling code in each VM instructions, but
they were fixed, or we found a workaround (a recent case was due to
auto-vectorization, and we fixed it with -fno-tree-vectorize, which
would be counterproductive for the engine() function anyway).
As for the control-flow, all these edges going from every goto to
every label whose address is taken lead to a quadratic number of
control-flow edges, so starting with gcc-3.x gcc replaced all goto *
with gotos to a common goto *. So now you have m edges to that goto *
(for m instances of goto * in the source code) and n edges from that
goto * to the labels whose address is taken (for n such labels),
resulting in n+m edges instead of n*m edges. During the 3.x and early
4.x series gcc failed to turn the jump-to-indirect-jump instructions
back into plain indirect-jump instructions afterwards, but they have
fixed that later in the 4.x series, and that works now (we still have
workarounds for that in Gforth).
By contrast, clang completely drops the ball: First of all, it takes
forever to compile the code, and then the code contains lots of
shuffling between registers and memory, leading to low performance.
Why is clang doing worse in 2021 (and probably in 2025, too) than gcc
was doing in 1992?
I described this in <2021May29.164810@mips.complang.tuwien.ac.at>,
here are some of the data from there:
Building gforth on a Ryzen 5800X:
| gcc10 clang11
| make -j make -j
|real 11.930s 33m22.542s
|user 53.876s 143m45.884s
|sys 3.110s 22.699s
Running Gforth's small benchmarks:
| Time in seconds user time
| sieve bubble matrix fib fft
| 0.056 0.055 0.034 0.047 0.021 Ryzen 5800X gcc-10
| 1.100 0.933 0.970 1.265 0.560 Ryzen 5800X clang-11
|
|I looked at the generated code, and for a primitive like + which can
|be done in 4 instructions and which gcc-10 does in 5 instructions:
|
|563FB2DED3BF: add r13,$08
|563FB2DED3C3: add r15,$08
|563FB2DED3C7: add r8,$00[r13]
|563FB2DED3CB: mov rcx,-$08[r15]
|563FB2DED3CF: jmp ecx
|
|clang-11 produces 183 instructions for +.
>This was probably less of a problem when assigned goto was invented
>(I assume this was for FORTRAN 66) when few varibles were kept in
>registers, and register allocation was in its infancy. Now, this is
>a much bigger impediment to optimization.
On what basis do you make this claim? Labels-as-values does not
impede optimization, so why should the assigned goto do so?
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-11-08 21:14 +0000 |
| Subject | Re: goto, was branch splitting |
| Message-ID | <10eobre$2jii$3@gal.iecc.com> |
| In reply to | #114021 |
According to Thomas Koenig <tkoenig@netcologne.de>: >This was probably less of a problem when assigned goto was invented >(I assume this was for FORTRAN 66) .. Not 1966, 1956. It was in the original FORTRAN compiler. In its defense, there were no user defined subroutines so that was how you faked it. The biggest improvement in FORTRAN II was SUBROUTINE and FUNCTION. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-05 02:01 -0600 |
| Subject | Re: branch splitting |
| Message-ID | <10ef097$7d4s$3@dont-email.me> |
| In reply to | #113938 |
On 11/4/2025 11:17 PM, Anton Ertl wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
>>
>>> On 11/4/2025 11:15 AM, MitchAlsup wrote:
>>>> PL/1 allows for Label variables so one can build their own
>>>> switches (and state machines with variable paths). I used
>>>> these in a checkers playing program 1974.
>>>
>>> Wasn't this PL/1 feature "inherited" from the, now rightly deprecated,
>>> Alter/Goto in COBOL and Assigned GOTO in Fortran?
>
> Assigned GOTO has been deleted from the Fortran standard (in Fortran
> 95, obsolescent in Fortran 90), but at least Intel's Fortran compiler
> supports it
> <https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2024-2/goto-assigned.html>
>
> What makes you think that it is "rightly" to deprecate or delete this
> feature?
>
> <https://riptutorial.com/fortran/example/11872/assigned-goto> says:
> |It can be avoided in modern code by using procedures, internal
> |procedures, procedure pointers and other features.
>
> I know no feature in Fortran or standard C which replaces my use of
> labels-as-values, the GNU C equivalent of the assigned goto. If you
> look at <https://www.complang.tuwien.ac.at/forth/threading/>, "direct"
> and "indirect" use labels-as-values, whereas "switch", "call" and
> "repl. switch" use standard C features (switch, indirect calls, and
> switch+goto respectively). "direct" and "indirect" usually outperform
> these others, sometimes by a lot.
>
I usually used call threading, because:
In my testing it was one of the faster options;
At least if excluding 32-bit x86,
which often has slow function calls.
Because pretty much every function needs a stack frame, ...
It is usable in standard C.
Often "while loop and switch()" was notably slower than using unrolled
lists of indirect function calls (usually with the main dispatch loop
based on "traces", which would call each of the opcode functions and
then return the next trace to be run).
Granted, "while loop and switch" is the more traditional way of writing
an interpreter.
>> I also find it amusing that the backbone of modern software is
>> a static version of label variables -- we call them switch state-
>> ments.
>
> I am not sure if it's "the" backbone. Fortran has (had?) a feature
> called "computed goto" that's closer to C's switch than "assigned
> goto". Ironically, the gcc people usually call their labels-as-values
> feature "computed goto" rather than "labels as values" or "assigned
> goto".
>
>> But you can be sure COBOL got them from assembly language programmers.
>
> Yes, assigned goto and labels-as-values (and probably the Cobol
> alter/goto and PL/1 label variables) are there because computer
> architectures have indirect branches and the programming language
> designer wanted to give the programmers a way to express what they
> would otherwise have to express in assembly language.
>
> Why does standard C not have it? C had it up to and including the 6th
> edition Unix <3714DA77.6150C99A@bell-labs.com>, but it went away
> between 6th and 7th edition. Ritchie wrote
> <37178013.A1EE3D4F@bell-labs.com>:
>
> | I eliminated them because I didn't know what to say about their
> | semantics.
>
> Stallman obviously knew what to say about their semantics when he
> added labels-as-values to GNU C with gcc 2.0.
>
But, if you use it, you are basically stuck with GCC...
> - anton
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-05 21:04 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <1762376697-5857@newsgrouper.org> |
| In reply to | #113948 |
BGB <cr88192@gmail.com> posted:
> On 11/4/2025 11:17 PM, Anton Ertl wrote:
> > MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >>
> >> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
> >>
> >>> On 11/4/2025 11:15 AM, MitchAlsup wrote:
> >>>> PL/1 allows for Label variables so one can build their own
> >>>> switches (and state machines with variable paths). I used
> >>>> these in a checkers playing program 1974.
> >>>
> >>> Wasn't this PL/1 feature "inherited" from the, now rightly deprecated,
> >>> Alter/Goto in COBOL and Assigned GOTO in Fortran?
> >
> > Assigned GOTO has been deleted from the Fortran standard (in Fortran
> > 95, obsolescent in Fortran 90), but at least Intel's Fortran compiler
> > supports it
> > <https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2024-2/goto-assigned.html>
> >
> > What makes you think that it is "rightly" to deprecate or delete this
> > feature?
> >
> > <https://riptutorial.com/fortran/example/11872/assigned-goto> says:
> > |It can be avoided in modern code by using procedures, internal
> > |procedures, procedure pointers and other features.
> >
> > I know no feature in Fortran or standard C which replaces my use of
> > labels-as-values, the GNU C equivalent of the assigned goto. If you
> > look at <https://www.complang.tuwien.ac.at/forth/threading/>, "direct"
> > and "indirect" use labels-as-values, whereas "switch", "call" and
> > "repl. switch" use standard C features (switch, indirect calls, and
> > switch+goto respectively). "direct" and "indirect" usually outperform
> > these others, sometimes by a lot.
> >
>
> I usually used call threading, because:
> In my testing it was one of the faster options;
> At least if excluding 32-bit x86,
> which often has slow function calls.
> Because pretty much every function needs a stack frame, ...
> It is usable in standard C.
I have converged on call-threading as a way to eliminate "if-statements"
-----------------------
extern uint64_t operation( uint64_t src1, uint64_t src1 );
static uint64_t (*int2op[32])( uint64_t src1, uint64_t src1 ) =
{ // integer 2-operand decoding table
/* 00 */ operation,
/* 01 */ operation,
/* 02 */ uadd,
/* 03 */ sadd,
/* 04 */ umul,
/* 05 */ smul,
/* 06 */ udiv,
/* 07 */ sdiv,
/* 10 */ cmp,
/* 11 */ operation,
/* 12 */ operation,
/* 13 */ operation,
/* 14 */ umax,
/* 15 */ smax,
/* 16 */ umin,
/* 17 */ smin,
/* 20 */ or,
/* 21 */ operation,
/* 22 */ xor,
/* 23 */ operation,
/* 24 */ and,
/* 25 */ operation,
/* 26 */ operation,
/* 27 */ operation,
/* 30 */ operation,
/* 31 */ operation,
/* 32 */ operation,
/* 33 */ operation,
/* 34 */ operation,
/* 35 */ operation,
/* 36 */ operation,
/* 37 */ operation;
};
/*
* Integer 2-Operand Table Caller
*/
bool intimm16( coreStack *cpu, Context *c, Major I )
{
uint8_t or = I.or;
uint64_t src1 = c->ctx.reg[ I.src1 ],
src2 = c->ctx.reg[ I.src2 ],
*dst = &c->ctx.reg[ I.dst ];
*dst = int2op[ (I.major&15)<<1 ]( src1, src2, 0 );
return true;
}
bool int2op( coreStack *cpu, Context *c, OpRoute I )
{
uint8_t or = I.or,
s = I.size;
uint64_t *src1 = &c->ctx.reg[ I.src1 ],
*src2 = &c->ctx.reg[ I.src2 ],
*dst = &c->ctx.reg[ I.dst ];
iorTable[ or ]( *c, I, src1, src2 );
*dst = int2op[ I.minor ]( src1, src2, s );
return true;
}
-----------------------
One does not have to check for unimplemented instructions, just place
a call to the operation() subroutine where they are not defined. The
operation() subroutine raises an exception which is caught at the
next instruction fetch.
I show both 16-bit immediates and general 2-Operand instructions use
the same table (with a trifling of bit twiddling).
> Often "while loop and switch()" was notably slower than using unrolled
> lists of indirect function calls (usually with the main dispatch loop
> based on "traces", which would call each of the opcode functions and
> then return the next trace to be run).
Table-calls are faster than many switches unless you can demonstrate
the switch is dense and there are no missing cases.
> Granted, "while loop and switch" is the more traditional way of writing
> an interpreter.
Just not a fast one...
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2025-11-05 17:26 +0200 |
| Subject | Re: branch splitting |
| Message-ID | <mn18lkF8vddU1@mid.individual.net> |
| In reply to | #113938 |
On 2025-11-05 7:17, Anton Ertl wrote:
[ snip ]
> Yes, assigned goto and labels-as-values (and probably the Cobol
> alter/goto and PL/1 label variables) are there because computer
> architectures have indirect branches and the programming language
> designer wanted to give the programmers a way to express what they
> would otherwise have to express in assembly language.
>
> Why does standard C not have it? C had it up to and including the 6th
> edition Unix <3714DA77.6150C99A@bell-labs.com>, but it went away
> between 6th and 7th edition. Ritchie wrote
> <37178013.A1EE3D4F@bell-labs.com>:
>
> | I eliminated them because I didn't know what to say about their
> | semantics.
>
> Stallman obviously knew what to say about their semantics when he
> added labels-as-values to GNU C with gcc 2.0.
I don't know what Stallman said, or would have said if asked, but I
guess something like "the semantics is a jump to the (address of the)
label to which the value refers", which is machine-level semantics and
not semantics in the abstract C machine.
The problem in the abstract C machine is a "goto label-value" statement
where the label-value refers to a label in a different function. Does
gcc prevent that at compile time? If not, I would expect the semantics
to be Undefined Behavior, the usual cop-out when nothing useful can be said.
(In an earlier discussion on this group, some years ago, I explained how
labels-as-values could be added to Ada, using the type system to ensure
safe and defined semantics. But I don't think such an extension would be
accepted for the Ada standard.)
Niklas
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-05 10:23 -0600 |
| Subject | Re: branch splitting |
| Message-ID | <10eftls$h0sb$2@dont-email.me> |
| In reply to | #113955 |
On 11/5/2025 9:26 AM, Niklas Holsti wrote: > On 2025-11-05 7:17, Anton Ertl wrote: > > [ snip ] > >> Yes, assigned goto and labels-as-values (and probably the Cobol >> alter/goto and PL/1 label variables) are there because computer >> architectures have indirect branches and the programming language >> designer wanted to give the programmers a way to express what they >> would otherwise have to express in assembly language. >> >> Why does standard C not have it? C had it up to and including the 6th >> edition Unix <3714DA77.6150C99A@bell-labs.com>, but it went away >> between 6th and 7th edition. Ritchie wrote >> <37178013.A1EE3D4F@bell-labs.com>: >> >> | I eliminated them because I didn't know what to say about their >> | semantics. >> >> Stallman obviously knew what to say about their semantics when he >> added labels-as-values to GNU C with gcc 2.0. > > > I don't know what Stallman said, or would have said if asked, but I > guess something like "the semantics is a jump to the (address of the) > label to which the value refers", which is machine-level semantics and > not semantics in the abstract C machine. > > The problem in the abstract C machine is a "goto label-value" statement > where the label-value refers to a label in a different function. Does > gcc prevent that at compile time? If not, I would expect the semantics > to be Undefined Behavior, the usual cop-out when nothing useful can be > said. > > (In an earlier discussion on this group, some years ago, I explained how > labels-as-values could be added to Ada, using the type system to ensure > safe and defined semantics. But I don't think such an extension would be > accepted for the Ada standard.) > My guess here: It is an "oh crap" situation and program either immediately or (maybe not as immediately) explodes... Otherwise, it would need to function more like a longjmp, which would mean that it would likely be painfully slow. So, yeah, most likely UB, of a "particularly destructive" / "unlikely to be useful" kind. FWIW: This was not a feature that I feel inclined to support in BGBCC... > Niklas
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-11-05 17:22 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <IJLOQ.191006$TvT6.67504@fx36.iad> |
| In reply to | #113958 |
BGB <cr88192@gmail.com> writes: >On 11/5/2025 9:26 AM, Niklas Holsti wrote: >> On 2025-11-05 7:17, Anton Ertl wrote: <computed goto> >My guess here: >It is an "oh crap" situation and program either immediately or (maybe >not as immediately) explodes... > >Otherwise, it would need to function more like a longjmp, which would >mean that it would likely be painfully slow. In my experience, longjmp is far faster than e.g. C++ exceptions. Granted, the code needs to be designed to allow longjmp without orphaning or leaking memory (i.e. in a context where there isn't any dynamic memory allocation) for the best speed.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2025-11-05 21:30 +0200 |
| Subject | Re: branch splitting |
| Message-ID | <mn1mu3F8vdbU1@mid.individual.net> |
| In reply to | #113958 |
On 2025-11-05 18:23, BGB wrote: > On 11/5/2025 9:26 AM, Niklas Holsti wrote: >> On 2025-11-05 7:17, Anton Ertl wrote: >> >> [ snip ] >> >>> Yes, assigned goto and labels-as-values (and probably the Cobol >>> alter/goto and PL/1 label variables) are there because computer >>> architectures have indirect branches and the programming language >>> designer wanted to give the programmers a way to express what they >>> would otherwise have to express in assembly language. >>> >>> Why does standard C not have it? C had it up to and including the 6th >>> edition Unix <3714DA77.6150C99A@bell-labs.com>, but it went away >>> between 6th and 7th edition. Ritchie wrote >>> <37178013.A1EE3D4F@bell-labs.com>: >>> >>> | I eliminated them because I didn't know what to say about their >>> | semantics. >>> >>> Stallman obviously knew what to say about their semantics when he >>> added labels-as-values to GNU C with gcc 2.0. >> >> >> I don't know what Stallman said, or would have said if asked, but I >> guess something like "the semantics is a jump to the (address of the) >> label to which the value refers", which is machine-level semantics and >> not semantics in the abstract C machine. >> >> The problem in the abstract C machine is a "goto label-value" >> statement where the label-value refers to a label in a different >> function. Does gcc prevent that at compile time? If not, I would >> expect the semantics to be Undefined Behavior, the usual cop-out when >> nothing useful can be said. >> >> (In an earlier discussion on this group, some years ago, I explained >> how labels-as-values could be added to Ada, using the type system to >> ensure safe and defined semantics. But I don't think such an extension >> would be accepted for the Ada standard.) >> > > My guess here: > It is an "oh crap" situation and program either immediately or (maybe > not as immediately) explodes... Or silently produces wrong results. > Otherwise, it would need to function more like a longjmp, which would > mean that it would likely be painfully slow. But then you could get the problem of a longjmp to a setjmp value that is stale because the targeted function invocation (stack frame) is no longer there. Niklas
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-05 21:28 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <1762378096-5857@newsgrouper.org> |
| In reply to | #113961 |
Niklas Holsti <niklas.holsti@tidorum.invalid> posted: > On 2025-11-05 18:23, BGB wrote: > > On 11/5/2025 9:26 AM, Niklas Holsti wrote: > >> On 2025-11-05 7:17, Anton Ertl wrote: > >> > >> [ snip ] > >> > >>> Yes, assigned goto and labels-as-values (and probably the Cobol > >>> alter/goto and PL/1 label variables) are there because computer > >>> architectures have indirect branches and the programming language > >>> designer wanted to give the programmers a way to express what they > >>> would otherwise have to express in assembly language. > >>> > >>> Why does standard C not have it? C had it up to and including the 6th > >>> edition Unix <3714DA77.6150C99A@bell-labs.com>, but it went away > >>> between 6th and 7th edition. Ritchie wrote > >>> <37178013.A1EE3D4F@bell-labs.com>: > >>> > >>> | I eliminated them because I didn't know what to say about their > >>> | semantics. > >>> > >>> Stallman obviously knew what to say about their semantics when he > >>> added labels-as-values to GNU C with gcc 2.0. > >> > >> > >> I don't know what Stallman said, or would have said if asked, but I > >> guess something like "the semantics is a jump to the (address of the) > >> label to which the value refers", which is machine-level semantics and > >> not semantics in the abstract C machine. > >> > >> The problem in the abstract C machine is a "goto label-value" > >> statement where the label-value refers to a label in a different > >> function. Does gcc prevent that at compile time? If not, I would > >> expect the semantics to be Undefined Behavior, the usual cop-out when > >> nothing useful can be said. > >> > >> (In an earlier discussion on this group, some years ago, I explained > >> how labels-as-values could be added to Ada, using the type system to > >> ensure safe and defined semantics. But I don't think such an extension > >> would be accepted for the Ada standard.) > >> > > > > My guess here: > > It is an "oh crap" situation and program either immediately or (maybe > > not as immediately) explodes... > > Or silently produces wrong results. > > > Otherwise, it would need to function more like a longjmp, which would > > mean that it would likely be painfully slow. > > But then you could get the problem of a longjmp to a setjmp value that > is stale because the targeted function invocation (stack frame) is no > longer there. But YOU had to pass the jumpbuf out of the setjump() scope. Now, YOU complain there is a hole in your own foot with a smoking gun in your own hand. > Niklas >
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2025-11-06 00:45 +0200 |
| Subject | Re: branch splitting |
| Message-ID | <mn22bvF8vdbU2@mid.individual.net> |
| In reply to | #113970 |
On 2025-11-05 23:28, MitchAlsup wrote: > > Niklas Holsti <niklas.holsti@tidorum.invalid> posted: > >> On 2025-11-05 18:23, BGB wrote: >>> On 11/5/2025 9:26 AM, Niklas Holsti wrote: >>>> On 2025-11-05 7:17, Anton Ertl wrote: >>>> >>>> [ snip ] >>>> >>>>> Yes, assigned goto and labels-as-values (and probably the Cobol >>>>> alter/goto and PL/1 label variables) are there because computer >>>>> architectures have indirect branches and the programming language >>>>> designer wanted to give the programmers a way to express what they >>>>> would otherwise have to express in assembly language. >>>>> >>>>> Why does standard C not have it? C had it up to and including the 6th >>>>> edition Unix <3714DA77.6150C99A@bell-labs.com>, but it went away >>>>> between 6th and 7th edition. Ritchie wrote >>>>> <37178013.A1EE3D4F@bell-labs.com>: >>>>> >>>>> | I eliminated them because I didn't know what to say about their >>>>> | semantics. >>>>> >>>>> Stallman obviously knew what to say about their semantics when he >>>>> added labels-as-values to GNU C with gcc 2.0. >>>> >>>> >>>> I don't know what Stallman said, or would have said if asked, but I >>>> guess something like "the semantics is a jump to the (address of the) >>>> label to which the value refers", which is machine-level semantics and >>>> not semantics in the abstract C machine. >>>> >>>> The problem in the abstract C machine is a "goto label-value" >>>> statement where the label-value refers to a label in a different >>>> function. Does gcc prevent that at compile time? If not, I would >>>> expect the semantics to be Undefined Behavior, the usual cop-out when >>>> nothing useful can be said. >>>> >>>> (In an earlier discussion on this group, some years ago, I explained >>>> how labels-as-values could be added to Ada, using the type system to >>>> ensure safe and defined semantics. But I don't think such an extension >>>> would be accepted for the Ada standard.) >>>> >>> >>> My guess here: >>> It is an "oh crap" situation and program either immediately or (maybe >>> not as immediately) explodes... >> >> Or silently produces wrong results. >> >>> Otherwise, it would need to function more like a longjmp, which would >>> mean that it would likely be painfully slow. >> >> But then you could get the problem of a longjmp to a setjmp value that >> is stale because the targeted function invocation (stack frame) is no >> longer there. > > But YOU had to pass the jumpbuf out of the setjump() scope. > > Now, YOU complain there is a hole in your own foot with a smoking gun > in your own hand. That is not the issue. The question is if the semantics of "goto label-valued-variable" are hard to define, as Ritchie said, or not, as Anton thinks Stallman said or would have said. The discussion above shows that whether a label value is implemented as a bare code address, or as a jumpbuf, some cases will have Undefined Behavior semantics. So I think Ritchie was right, unless the undefined cases can be excluded at compile time. The undefined cases could be excluded at compile-time, even in C, by requiring all label-valued variables to be local to some function and forbidding passing such values as parameters or function results. In addition, the use of an uninitialized label-valued variable should be prevented or detected. Perhaps Anton could accept such restrictions. Niklas
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-06 18:28 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <1762453699-5857@newsgrouper.org> |
| In reply to | #113971 |
Niklas Holsti <niklas.holsti@tidorum.invalid> posted: > On 2025-11-05 23:28, MitchAlsup wrote: > > > > Niklas Holsti <niklas.holsti@tidorum.invalid> posted: >---------------- > >> But then you could get the problem of a longjmp to a setjmp value that > >> is stale because the targeted function invocation (stack frame) is no > >> longer there. > > > > But YOU had to pass the jumpbuf out of the setjump() scope. > > > > Now, YOU complain there is a hole in your own foot with a smoking gun > > in your own hand. > > That is not the issue. The question is if the semantics of "goto > label-valued-variable" are hard to define, as Ritchie said, or not, as > Anton thinks Stallman said or would have said. So, label-variables are hard to define, but function-variables are not ?!? > The discussion above shows that whether a label value is implemented as > a bare code address, or as a jumpbuf, some cases will have Undefined > Behavior semantics. So I think Ritchie was right, unless the undefined > cases can be excluded at compile time. > > The undefined cases could be excluded at compile-time, even in C, by > requiring all label-valued variables to be local to some function and > forbidding passing such values as parameters or function results. In > addition, the use of an uninitialized label-valued variable should be > prevented or detected. Perhaps Anton could accept such restrictions. > > Niklas >
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2025-11-11 18:50 +0200 |
| Subject | Re: branch splitting |
| Message-ID | <mnh7qcFs851U1@mid.individual.net> |
| In reply to | #113986 |
On 2025-11-06 20:28, MitchAlsup wrote: > > Niklas Holsti <niklas.holsti@tidorum.invalid> posted: > >> On 2025-11-05 23:28, MitchAlsup wrote: >>> >>> Niklas Holsti <niklas.holsti@tidorum.invalid> posted: >> ---------------- >>>> But then you could get the problem of a longjmp to a setjmp value that >>>> is stale because the targeted function invocation (stack frame) is no >>>> longer there. >>> >>> But YOU had to pass the jumpbuf out of the setjump() scope. >>> >>> Now, YOU complain there is a hole in your own foot with a smoking gun >>> in your own hand. >> >> That is not the issue. The question is if the semantics of "goto >> label-valued-variable" are hard to define, as Ritchie said, or not, as >> Anton thinks Stallman said or would have said. > > So, label-variables are hard to define, but function-variables are not ?!? Depends on the level at which you want to define it. At the machine level, where semantics are (usually) defined for each instruction separately, a jump to a dynamic address (using a "label-variable") is not much different from a call to a dynamic address (using a "function-variable"), and the effect of the single instruction on the machine state is much the same as for the static address case. The higher-level effect on the further execution of the program is out of scope, whatever the actual value of the target address in the instruction. It is only if your machine has some semantics for instruction combinations, such as your VEC-LOOP pair, that you have to define what happens if a jump or call to some address leads to later executing only some of those instructions or executing them in the wrong order, such as trying to execute a LOOP without having executed a preceding VEC. At the higher programming-language level, the label case can be much harder to define and less useful than the function case, depending on the programming language and its abstract model of execution, and also depending on what compile-time checks you assume. Consider an imperative language such as C with no functions nested within other functions or other blocks (where by "block" I mean some syntactical construct that sets up its local context with local variables etc.). If you have a function-variable (that is, a pointer to a function) that actually refers to a function with the same parameter profile, it is easy to define the semantics of a call via this function variable: it is the same as for a call that names the referenced function statically, and such a call is always legal. Problems arise only if the function-variable has some invalid value such as NULL, or the address of a function with a different profile, or some code address that does not refer to (the start of) a function. Such invalid values can be prevented at compile time, except (usually) for NULL. In the same language setting, the semantics of a jump using a label-variable are easy to define only if the label-variable refers to a label in the same block as the jump. A jump from one block into another would mess up the context, omitting the set-up of the target block's context and/or omitting the tear-down of the source block's context. The further results of program execution are machine-dependent and so undefined behavior. A compiler could enforce the label-in-same-block rule, but it seems that GNU C does not do so. In a programming language that allows nested functions the same kind of context-crossing problems arise for function-variables. Traditional languages solve them by allowing, at compile-time, calls via function-variables only if it is certain that the containing context of the callee still exists (if the callee is nested), or by (expensively) preserving that context as a dynamically constructed closure. In either case, the caller's context never needs to be torn down to execute the call, differing from the jump case. In summary, jumps via label-variables are useful only for control transfers within one function, and do not help to build up a computation by combining several functions -- the main method of program design at present. In contrast, calls via function-variables are a useful extension to static calls, actually helping to combine several functions in a computation, as shown by the general adoption of class/object/method coding styles. Niklas
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-11-11 14:23 -0500 |
| Subject | Re: branch splitting |
| Message-ID | <94MQQ.2055094$ctz9.1186196@fx16.iad> |
| In reply to | #114064 |
Niklas Holsti wrote:
> On 2025-11-06 20:28, MitchAlsup wrote:
>>
>> Niklas Holsti <niklas.holsti@tidorum.invalid> posted:
>>
>>> On 2025-11-05 23:28, MitchAlsup wrote:
>>>>
>>>> Niklas Holsti <niklas.holsti@tidorum.invalid> posted:
>>> ----------------
>>>>> But then you could get the problem of a longjmp to a setjmp value that
>>>>> is stale because the targeted function invocation (stack frame) is no
>>>>> longer there.
>>>>
>>>> But YOU had to pass the jumpbuf out of the setjump() scope.
>>>>
>>>> Now, YOU complain there is a hole in your own foot with a smoking gun
>>>> in your own hand.
>>>
>>> That is not the issue. The question is if the semantics of "goto
>>> label-valued-variable" are hard to define, as Ritchie said, or not, as
>>> Anton thinks Stallman said or would have said.
>>
>> So, label-variables are hard to define, but function-variables are not
>> ?!?
>
> Depends on the level at which you want to define it.
>
> At the machine level, where semantics are (usually) defined for each
> instruction separately, a jump to a dynamic address (using a
> "label-variable") is not much different from a call to a dynamic address
> (using a "function-variable"), and the effect of the single instruction
> on the machine state is much the same as for the static address case.
> The higher-level effect on the further execution of the program is out
> of scope, whatever the actual value of the target address in the
> instruction.
>
> It is only if your machine has some semantics for instruction
> combinations, such as your VEC-LOOP pair, that you have to define what
> happens if a jump or call to some address leads to later executing only
> some of those instructions or executing them in the wrong order, such as
> trying to execute a LOOP without having executed a preceding VEC.
>
> At the higher programming-language level, the label case can be much
> harder to define and less useful than the function case, depending on
> the programming language and its abstract model of execution, and also
> depending on what compile-time checks you assume.
>
> Consider an imperative language such as C with no functions nested
> within other functions or other blocks (where by "block" I mean some
> syntactical construct that sets up its local context with local
> variables etc.). If you have a function-variable (that is, a pointer to
> a function) that actually refers to a function with the same parameter
> profile, it is easy to define the semantics of a call via this function
> variable: it is the same as for a call that names the referenced
> function statically, and such a call is always legal. Problems arise
> only if the function-variable has some invalid value such as NULL, or
> the address of a function with a different profile, or some code address
> that does not refer to (the start of) a function. Such invalid values
> can be prevented at compile time, except (usually) for NULL.
>
> In the same language setting, the semantics of a jump using a
> label-variable are easy to define only if the label-variable refers to a
> label in the same block as the jump. A jump from one block into another
> would mess up the context, omitting the set-up of the target block's
> context and/or omitting the tear-down of the source block's context. The
> further results of program execution are machine-dependent and so
> undefined behavior.
>
> A compiler could enforce the label-in-same-block rule, but it seems that
> GNU C does not do so.
>
> In a programming language that allows nested functions the same kind of
> context-crossing problems arise for function-variables. Traditional
> languages solve them by allowing, at compile-time, calls via
> function-variables only if it is certain that the containing context of
> the callee still exists (if the callee is nested), or by (expensively)
> preserving that context as a dynamically constructed closure. In either
> case, the caller's context never needs to be torn down to execute the
> call, differing from the jump case.
>
> In summary, jumps via label-variables are useful only for control
> transfers within one function, and do not help to build up a computation
> by combining several functions -- the main method of program design at
> present. In contrast, calls via function-variables are a useful
> extension to static calls, actually helping to combine several functions
> in a computation, as shown by the general adoption of
> class/object/method coding styles.
>
> Niklas
>
I was curious about the interaction between dynamic stack allocations
and goto variables to see if it handled the block scoping correctly.
Ada should have the same issues as C.
It appears GCC x86-64 15.2 with -O3 does not properly recover
stack space with dynamic goto's.
Test1 allocates a dynamic sized buffer and has a static goto Loop
for which GCC generates a jne .L6 to a mov rsp, rbx that recovers
the stack allocation inside the {} block.
Test2 is the same but does a goto *dest and GCC does not generate
code to recover the inner {} block allocation. It just loops over
the sub rsp, rbx so the stack space just grows.
long Sub (long len, char buf[]);
void Test1 (long len)
{
long ok;
Loop:
{
char buf[len];
ok = Sub (len, buf);
if (ok)
goto Loop;
}
}
# Compilation provided by Compiler Explorer at https://godbolt.org/
Test1(long):
push rbp
mov rbp, rsp
push r13
mov r13, rdi
push r12
lea r12, [rdi+15]
push rbx
shr r12, 4
sal r12, 4
sub rsp, 8
jmp .L2
.L6:
mov rsp, rbx
.L2:
mov rbx, rsp
sub rsp, r12
mov rdi, r13
mov rsi, rsp
call Sub(long, char*)
test rax, rax
jne .L6
lea rsp, [rbp-24]
pop rbx
pop r12
pop r13
pop rbp
ret
void Test2 (long len)
{
long ok;
void *dest;
dest = &&Loop;
Loop:
{
char buf[len];
ok = Sub (len, buf);
if (ok)
goto *dest;
}
}
Test2(long):
push rbp
mov rbp, rsp
push r12
mov r12, rdi
push rbx
lea rbx, [rdi+15]
shr rbx, 4
sal rbx, 4
.L8:
sub rsp, rbx
mov rdi, r12
mov rsi, rsp
call Sub(long, char*)
test rax, rax
jne .L8
lea rsp, [rbp-16]
pop rbx
pop r12
pop rbp
ret
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-11-11 20:44 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <2025Nov11.214447@mips.complang.tuwien.ac.at> |
| In reply to | #114067 |
EricP <ThatWouldBeTelling@thevillage.com> writes:
>Test1 allocates a dynamic sized buffer and has a static goto Loop
>for which GCC generates a jne .L6 to a mov rsp, rbx that recovers
>the stack allocation inside the {} block.
>
>Test2 is the same but does a goto *dest and GCC does not generate
>code to recover the inner {} block allocation. It just loops over
>the sub rsp, rbx so the stack space just grows.
Interestingly, gcc optimizes the indirect branch with a constant
target into a direct branch, but then does not continue with the same
code as you get with a plain goto.
>void Test2 (long len)
>{
> long ok;
> void *dest;
>
> dest = &&Loop;
> Loop:
> {
> char buf[len];
>
> ok = Sub (len, buf);
> if (ok)
> goto *dest;
> }
>}
>
>Test2(long):
> push rbp
> mov rbp, rsp
> push r12
> mov r12, rdi
> push rbx
> lea rbx, [rdi+15]
> shr rbx, 4
> sal rbx, 4
>.L8:
> sub rsp, rbx
> mov rdi, r12
> mov rsi, rsp
> call Sub(long, char*)
> test rax, rax
> jne .L8
> lea rsp, [rbp-16]
> pop rbx
> pop r12
> pop rbp
> ret
Interesting that this bug has not been fixed in the >33 years that
labels-as-values have been in gcc; I don't know how long these
dynamically sized arrays have been in gcc, but IIRC alloca(), a
similar feature, has been available at least as long as
labels-as-values. The bug has apparently been avoided or worked
around by the users of labels-as-values (e.g., Gforth does not use
alloca or dynamically-sized arrays in the function that contains all
the taken labels and all the "goto *"s.
As long as all taken labels have the same stack depth, the bugfix does
not look particularly hard: just put code before each goto * that
adjusts the stack depth to the depth of these labels.
Things become more interesting if there are labels with different
stack depths, because labels are stored in "void *" variables, and
there is not enough room for a target and a stack depth. One can ue
the same approach as is used in Test1, however: have the stack depth
for a specific target in some location, and have a copy from that
location to the stack pointer right behind the label.
...
> jmp .L2
>.L6:
> mov rsp, rbx
>.L2:
...
> jne .L6
All the code that works now would not need these extra copy
intructions, so the bugfix should special-case the case where all the
targets have the same depth.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-11-11 21:16 -0500 |
| Subject | Re: branch splitting |
| Message-ID | <o6SQQ.1462808$k_17.493545@fx10.iad> |
| In reply to | #114070 |
Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Test1 allocates a dynamic sized buffer and has a static goto Loop
>> for which GCC generates a jne .L6 to a mov rsp, rbx that recovers
>> the stack allocation inside the {} block.
>>
>> Test2 is the same but does a goto *dest and GCC does not generate
>> code to recover the inner {} block allocation. It just loops over
>> the sub rsp, rbx so the stack space just grows.
>
> Interestingly, gcc optimizes the indirect branch with a constant
> target into a direct branch, but then does not continue with the same
> code as you get with a plain goto.
>
>> void Test2 (long len)
>> {
>> long ok;
>> void *dest;
>>
>> dest = &&Loop;
>> Loop:
>> {
>> char buf[len];
>>
>> ok = Sub (len, buf);
>> if (ok)
>> goto *dest;
>> }
>> }
>>
>> Test2(long):
>> push rbp
>> mov rbp, rsp
>> push r12
>> mov r12, rdi
>> push rbx
>> lea rbx, [rdi+15]
>> shr rbx, 4
>> sal rbx, 4
>> .L8:
>> sub rsp, rbx
>> mov rdi, r12
>> mov rsi, rsp
>> call Sub(long, char*)
>> test rax, rax
>> jne .L8
>> lea rsp, [rbp-16]
>> pop rbx
>> pop r12
>> pop rbp
>> ret
>
> Interesting that this bug has not been fixed in the >33 years that
> labels-as-values have been in gcc; I don't know how long these
> dynamically sized arrays have been in gcc, but IIRC alloca(), a
> similar feature, has been available at least as long as
> labels-as-values. The bug has apparently been avoided or worked
> around by the users of labels-as-values (e.g., Gforth does not use
> alloca or dynamically-sized arrays in the function that contains all
> the taken labels and all the "goto *"s.
alloca is not required to recover storage at the {} block level.
MS C does not recover alloca space until the subroutine returns.
But when they added dynamic allocation to C as a first class feature
I figured it should recover storage at the end of a {} block,
and I wondered it the superficially non-deterministic nature of
goto variable would be a problem.
> As long as all taken labels have the same stack depth, the bugfix does
> not look particularly hard: just put code before each goto * that
> adjusts the stack depth to the depth of these labels.
>
> Things become more interesting if there are labels with different
> stack depths, because labels are stored in "void *" variables, and
> there is not enough room for a target and a stack depth. One can ue
> the same approach as is used in Test1, however: have the stack depth
> for a specific target in some location, and have a copy from that
> location to the stack pointer right behind the label.
>
> ....
>> jmp .L2
>> .L6:
>> mov rsp, rbx
>> .L2:
> ....
>> jne .L6
>
> All the code that works now would not need these extra copy
> intructions, so the bugfix should special-case the case where all the
> targets have the same depth.
>
> - anton
Below in Test3 I replace the goto variable with a switch statement
arranged to be nondeterministic, and it does get it right.
I suggest GCC forgot to treat the goto variable as equivalent to a switch
statement and threw up its hands and treated the buffer as an alloca.
This all relates to Niklas's comments as to why the label variables must
all be within the current context, so it knows when to recover storage.
If the language had destructors the goto variable could have to call them
which alloca also does not deal with.
long Sub (long len, char buf[]);
void Test3 (long len)
{
long ok, dest;
dest = 0;
Loop:
{
char buf[len];
ok = Sub (len, buf);
if (ok)
dest = 1;
switch (dest)
{
case 0:
goto Loop;
case 1:
goto Out;
}
Out:
;
}
}
# Compilation provided by Compiler Explorer at https://godbolt.org/
Test3(long):
push rbp
mov rbp, rsp
push r13
mov r13, rdi
push r12
lea r12, [rdi+15]
push rbx
shr r12, 4
sal r12, 4
sub rsp, 8
jmp .L2
.L6:
mov rsp, rbx
.L2:
mov rbx, rsp
sub rsp, r12
mov rdi, r13
mov rsi, rsp
call Sub(long, char*)
test rax, rax
je .L6
lea rsp, [rbp-24]
pop rbx
pop r12
pop r13
pop rbp
ret
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-11-13 08:42 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <2025Nov13.094235@mips.complang.tuwien.ac.at> |
| In reply to | #114077 |
EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> void Test2 (long len)
>>> {
>>> long ok;
>>> void *dest;
>>>
>>> dest = &&Loop;
>>> Loop:
>>> {
>>> char buf[len];
>>>
>>> ok = Sub (len, buf);
>>> if (ok)
>>> goto *dest;
>>> }
>>> }
>>>
>>> Test2(long):
>>> push rbp
>>> mov rbp, rsp
>>> push r12
>>> mov r12, rdi
>>> push rbx
>>> lea rbx, [rdi+15]
>>> shr rbx, 4
>>> sal rbx, 4
>>> .L8:
>>> sub rsp, rbx
>>> mov rdi, r12
>>> mov rsi, rsp
>>> call Sub(long, char*)
>>> test rax, rax
>>> jne .L8
>>> lea rsp, [rbp-16]
>>> pop rbx
>>> pop r12
>>> pop rbp
>>> ret
>>
>> Interesting that this bug has not been fixed in the >33 years that
>> labels-as-values have been in gcc; I don't know how long these
>> dynamically sized arrays have been in gcc, but IIRC alloca(), a
>> similar feature, has been available at least as long as
>> labels-as-values. The bug has apparently been avoided or worked
>> around by the users of labels-as-values (e.g., Gforth does not use
>> alloca or dynamically-sized arrays in the function that contains all
>> the taken labels and all the "goto *"s.
>
>alloca is not required to recover storage at the {} block level.
Good point. So if you do
for (i=0; i<1000000000; i++) {
char *s = alloca(1000+i%1024);
... use s ...
}
and the program runs out of memory, it's a bug in your C source code,
whereas if you do
for (i=0; i<1000000000; i++) {
char s[1000+i%1024];
... use s ...
}
and the program runs out of memory, it's a bug in the compiler.
So this bug has only existed since dynamically-sized arrays were added
to gcc (probably just a quarter-century or so).
>But when they added dynamic allocation to C as a first class feature
>I figured it should recover storage at the end of a {} block,
>and I wondered it the superficially non-deterministic nature of
>goto variable would be a problem.
I outlined a correct implementation in my previous posting. The
general way is basically the same that gcc already uses for the direct
goto, as shown in your test1. Have a jump target that copies the
stack depth for the label from another location, and use that jump
target as the taken address. E.g.:
L1:
...
{ int foo[n];
...
L2:
...
{ int bar[n2];
...
L3:
...
void *labels[] = {&&L1, &&L2, &&L3, &&L4, &&L5};
...
goto *labels[i];
}
...
L4:
...
}
...
L5:
...
would be compiled to
L1x: # used for &&L1 and for direct gotos where %rsp may be different
mov L1L5_depth(%rbp), %rsp
L1y: # used for direct gotos where %rsp is the same
...
L2x: # used for &&L2 and for direct gotos where %rsp may be different
mov L2L4_depth(%rbp), %rsp
L2y:
...
L3x: # the only goto * is at the same %rsp depth, so no mov needed
L3y:
...
jmp *rcx
...
L4x: # used for &&L2 and for direct gotos where %rsp may be different
mov L2L4_depth(%rbp), %rsp
L4y:
...
L5x: # used for &&L1 and for direct gotos where %rsp may be different
mov L1L5_depth(%rbp), %rsp
L5y: # used for direct gotos where %rsp is the same
...
And of course, for those programs that do not combine these features,
all labels would turn out like L3, i.e., without the extra mov.
>This all relates to Niklas's comments as to why the label variables must
>all be within the current context, so it knows when to recover storage.
The gcc documentation specifies that the labels must be in the same
function as the goto, so the compiler does not have to do stack
unwinding which the Pascal compiler has to do for the Pascal goto.
>If the language had destructors the goto variable could have to call them
>which alloca also does not deal with.
GNU C has no destructors.
>long Sub (long len, char buf[]);
>
>void Test3 (long len)
>{
> long ok, dest;
>
> dest = 0;
> Loop:
> {
> char buf[len];
>
> ok = Sub (len, buf);
> if (ok)
> dest = 1;
>
> switch (dest)
> {
> case 0:
> goto Loop;
> case 1:
> goto Out;
> }
> Out:
> ;
> }
>}
That actually tests direct goto. For the switch, one could wonder
about stuff like
switch (...) {
char s[n];
case 1:
... s[i] ...
{ char t[m];
case 2:
... t[i]...
}
}
But I expect that this has been declared undefined behaviour at some point.
At least the block structure protects the switch from having case
labels in outer scopes (in contrast to the labels-as-values example
above).
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> |
|---|---|
| Date | 2025-11-13 19:32 +0100 |
| Subject | Re: branch splitting |
| Message-ID | <10f587c$2be6u$1@dont-email.me> |
| In reply to | #114095 |
On 11/13/25 09:42, Anton Ertl wrote: > GNU C has no destructors. It has, in limited form via __attribute__((__cleanup__(...))) see https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Common-Variable-Attributes.html#index-cleanup-variable-attribute Regards, Bernd
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-13 01:35 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <10f3cl7$7li8$1@paganini.bofh.team> |
| In reply to | #114067 |
EricP <ThatWouldBeTelling@thevillage.com> wrote:
> Niklas Holsti wrote:
>> On 2025-11-06 20:28, MitchAlsup wrote:
>>>
>>> Niklas Holsti <niklas.holsti@tidorum.invalid> posted:
>>>
>>>> On 2025-11-05 23:28, MitchAlsup wrote:
>>>>>
>>>>> Niklas Holsti <niklas.holsti@tidorum.invalid> posted:
>>>> ----------------
>>>>>> But then you could get the problem of a longjmp to a setjmp value that
>>>>>> is stale because the targeted function invocation (stack frame) is no
>>>>>> longer there.
>>>>>
>>>>> But YOU had to pass the jumpbuf out of the setjump() scope.
>>>>>
>>>>> Now, YOU complain there is a hole in your own foot with a smoking gun
>>>>> in your own hand.
>>>>
>>>> That is not the issue. The question is if the semantics of "goto
>>>> label-valued-variable" are hard to define, as Ritchie said, or not, as
>>>> Anton thinks Stallman said or would have said.
>>>
>>> So, label-variables are hard to define, but function-variables are not
>>> ?!?
>>
>> Depends on the level at which you want to define it.
>>
>> At the machine level, where semantics are (usually) defined for each
>> instruction separately, a jump to a dynamic address (using a
>> "label-variable") is not much different from a call to a dynamic address
>> (using a "function-variable"), and the effect of the single instruction
>> on the machine state is much the same as for the static address case.
>> The higher-level effect on the further execution of the program is out
>> of scope, whatever the actual value of the target address in the
>> instruction.
>>
>> It is only if your machine has some semantics for instruction
>> combinations, such as your VEC-LOOP pair, that you have to define what
>> happens if a jump or call to some address leads to later executing only
>> some of those instructions or executing them in the wrong order, such as
>> trying to execute a LOOP without having executed a preceding VEC.
>>
>> At the higher programming-language level, the label case can be much
>> harder to define and less useful than the function case, depending on
>> the programming language and its abstract model of execution, and also
>> depending on what compile-time checks you assume.
>>
>> Consider an imperative language such as C with no functions nested
>> within other functions or other blocks (where by "block" I mean some
>> syntactical construct that sets up its local context with local
>> variables etc.). If you have a function-variable (that is, a pointer to
>> a function) that actually refers to a function with the same parameter
>> profile, it is easy to define the semantics of a call via this function
>> variable: it is the same as for a call that names the referenced
>> function statically, and such a call is always legal. Problems arise
>> only if the function-variable has some invalid value such as NULL, or
>> the address of a function with a different profile, or some code address
>> that does not refer to (the start of) a function. Such invalid values
>> can be prevented at compile time, except (usually) for NULL.
>>
>> In the same language setting, the semantics of a jump using a
>> label-variable are easy to define only if the label-variable refers to a
>> label in the same block as the jump. A jump from one block into another
>> would mess up the context, omitting the set-up of the target block's
>> context and/or omitting the tear-down of the source block's context. The
>> further results of program execution are machine-dependent and so
>> undefined behavior.
>>
>> A compiler could enforce the label-in-same-block rule, but it seems that
>> GNU C does not do so.
>>
>> In a programming language that allows nested functions the same kind of
>> context-crossing problems arise for function-variables. Traditional
>> languages solve them by allowing, at compile-time, calls via
>> function-variables only if it is certain that the containing context of
>> the callee still exists (if the callee is nested), or by (expensively)
>> preserving that context as a dynamically constructed closure. In either
>> case, the caller's context never needs to be torn down to execute the
>> call, differing from the jump case.
>>
>> In summary, jumps via label-variables are useful only for control
>> transfers within one function, and do not help to build up a computation
>> by combining several functions -- the main method of program design at
>> present. In contrast, calls via function-variables are a useful
>> extension to static calls, actually helping to combine several functions
>> in a computation, as shown by the general adoption of
>> class/object/method coding styles.
>>
>> Niklas
>>
>
> I was curious about the interaction between dynamic stack allocations
> and goto variables to see if it handled the block scoping correctly.
> Ada should have the same issues as C.
> It appears GCC x86-64 15.2 with -O3 does not properly recover
> stack space with dynamic goto's.
>
> Test1 allocates a dynamic sized buffer and has a static goto Loop
> for which GCC generates a jne .L6 to a mov rsp, rbx that recovers
> the stack allocation inside the {} block.
>
> Test2 is the same but does a goto *dest and GCC does not generate
> code to recover the inner {} block allocation. It just loops over
> the sub rsp, rbx so the stack space just grows.
>
> long Sub (long len, char buf[]);
>
> void Test1 (long len)
> {
> long ok;
>
> Loop:
> {
> char buf[len];
>
> ok = Sub (len, buf);
> if (ok)
> goto Loop;
> }
> }
IIRC there is clear statement in the C standard that you are not
allowed to jump into a scope after a dynamic declaration. This
restriction is because otherwise compiler would need some twisty
logic to run allocation code. With label variables that obvoiusly
generalizes to jumps outside of scope of dynamic allocation:
compiler does not try to recover allocated storage. Your code
does not differ much from infinite recursion. In case of
infinte recursion compiler _may_ be able to optimize things
so that they run in constant memory, but usually such
recursion will lead to stack overflow.
So natural restriction is: when jumping to label variable
dynamic locals may be released only at function exit.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 41 of 46 — ← Prev page 1 … 39 40 [41] 42 43 … 46 Next page →
Back to top | Article view | comp.arch
csiph-web