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 40 of 46 — ← Prev page 1 … 38 39 [40] 41 42 … 46 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-11-10 07:46 +0000 |
| Subject | Re: PDP-8 history, branch splitting |
| Message-ID | <2025Nov10.084647@mips.complang.tuwien.ac.at> |
| In reply to | #114038 |
John Levine <johnl@taugh.com> writes: [indirect branches through auto-increment locations] >I suppose you could use them for threaded code, but I didn't run into >any PDP-8 progams that used that. You can use them for (direct) threaded code if the indirect branch is not to the auto-incremented address, but if there is one additional indirection involved. E.g, on RISC-V this is a direct-threaded code dispatch: addi s5,s5,8 ld a5,0(s5) jr a5 If the use of the auto-increment location would be equivalent to addi s5,s5,8 jr s5 it would not be useful for direct-threaded code. The paper on (direct) threaded code was only published in 1973, so that technique may not have been widely known at the time when much of the PDP-8 software was developed. - 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-11-10 14:52 +0000 |
| Subject | Re: PDP-8 history, branch splitting |
| Message-ID | <U_mQQ.1283566$7Ika.381139@fx17.iad> |
| In reply to | #114038 |
John Levine <johnl@taugh.com> writes: >According to Scott Lurndal <slp53@pacbell.net>: >>>PDP-8, 4004, IBM 650, ... And any machine without "registers". >> >>To be fair, addresses 10 through 17 in the PDP-8 were effectively >>auto-increment registers and indirect branches were their >>primary function. .... > >I did a fair amount of PDP-8 programming and I don't ever recall using >the auto-index locations for branches. They were used to step >through a table of data, e.g. to add up a list of numbers: > >10, 1007 ; list starts at 1010 > >100, -50 ; list is 50 (octal long) > > CLA >LOOP, > TAD I 10 > ISZ 100 > JMP LOOP >; sum is in the accumulator > >I suppose you could use them for threaded code, but I didn't run into >any PDP-8 progams that used that. Yes, mainly for data. I do have a vague recollection of hand[*]disassembling the basic interpreter and finding some unexpected indirect branches through 010-017. [*] Paper and pencil from an octal dump in high school.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-11-10 18:53 +0000 |
| Subject | Re: PDP-8 history, branch splitting |
| Message-ID | <10etcbe$8j0$1@gal.iecc.com> |
| In reply to | #114054 |
According to Scott Lurndal <slp53@pacbell.net>: >>I suppose you could use them for threaded code, but I didn't run into >>any PDP-8 progams that used that. > >Yes, mainly for data. I do have a vague recollection of hand[*]disassembling >the basic interpreter and finding some unexpected indirect branches through >010-017. The usual way to do threaded code needs double indirection, like on the PDP-11 JMP @(R5)+ which jumps to the address that the word at R5 points to, then increments R5. The PDP-8 only had single indirect so the autoindex would have to point at a list of JMP instructions, which in turn would usually have to be indirect unless the routine was so small it could fit on the page with the JMP list. People did all sorts of strange stuff to cram programs into the PDP-8 so I can imagine other sorts of autoindex JMP tricks, like doing one thing the first time through a loop and something else after that. -- 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 | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-11-10 08:27 +0100 |
| Subject | Re: branch splitting |
| Message-ID | <10es45s$3r3dn$1@dont-email.me> |
| In reply to | #114027 |
MitchAlsup wrote: > > EricP <ThatWouldBeTelling@thevillage.com> posted: > >> Anton Ertl wrote: >>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>>> No, and I defer to you, or others here, on how these features are >>>> implemented, specifically whether code modification is required. I was >>>> referring to features such as assigned goto in Fortran, and Alter goto >>>> in Cobol. >>> >>> On modern architectures higher-order functions are implemented with >>> indirect branches or indirect calls (depending on whether it's a >>> tail-call or not); likewise for method dispatch. >>> >>> I do not know how Lisp, FORTRAN, Algol 60 and other early languages >>> with higher-order functions were implemented on architectures that do >>> not have indirect branches; but if the assigned goto was implemented >>> with self-modifying code, the call to a function in a variable was >>> probably implemented like that, too. >> >> What architecture cannot do an indirect branch, which I assume >> means a branch/jump to a variable location in a register? > > PDP-8, 4004, IBM 650, ... And any machine without "registers". > >> And how would the operating system on such a machine get programs running? > > Load them at a known location and branch to the known location. > >> Even if an ISA did not have a JMP reg instruction one can create it >> using CALL to copy the IP to the stack where you modify it and >> RET to pop the new IP value. > > Pure stack machines did a lot of this. We even did similar stuff in low-level x86 code, like when very early 8088 cpus could allow an interrupt between the loading of the stack pointer and the stack segment (double-plus ungood!), the fix was to instead munge the stack so that an IRET could be used instead. I seem to remember that there could also be a similar issue when doing a far return? If so, also solved with setting up the stack to allow IRET to have the same effect. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-11-08 18:25 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <2025Nov8.192518@mips.complang.tuwien.ac.at> |
| In reply to | #114024 |
EricP <ThatWouldBeTelling@thevillage.com> writes: >What architecture cannot do an indirect branch, which I assume >means a branch/jump to a variable location in a register? Or, in case of the 6502, in memory. I don't know of any architecture (except maybe some one-instruction proof-of-concepts) that does not have indirect branches in one form or another, but I am not that familiar with architectures from the 1950s or some of the extremely deprived embedded-control processors. Maybe the thing about self-modifying code was thrown in to taint the assigned goto through guilt-by-association. >Even if an ISA did not have a JMP reg instruction one can create it >using CALL to copy the IP to the stack where you modify it and >RET to pop the new IP value. In most cases that is possible (even if the return address is stored in a register and not on the stack), but the return addresses might live on a separate stack (IIRC the Intel 8008 or the 8080 has such a stack), and the call might be the only thing that pushes on that stack. But yes, in most cases, it's a good argument that even very deprived processors usually have some form of indirect branching. - 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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-08 20:56 +0200 |
| Subject | Re: branch splitting |
| Message-ID | <20251108205633.00000566@yahoo.com> |
| In reply to | #114028 |
On Sat, 08 Nov 2025 18:25:18 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > EricP <ThatWouldBeTelling@thevillage.com> writes: > >What architecture cannot do an indirect branch, which I assume > >means a branch/jump to a variable location in a register? > > Or, in case of the 6502, in memory. > > I don't know of any architecture (except maybe some one-instruction > proof-of-concepts) that does not have indirect branches in one form or > another, but I am not that familiar with architectures from the 1950s > or some of the extremely deprived embedded-control processors. > > Maybe the thing about self-modifying code was thrown in to taint the > assigned goto through guilt-by-association. > > >Even if an ISA did not have a JMP reg instruction one can create it > >using CALL to copy the IP to the stack where you modify it and > >RET to pop the new IP value. > > In most cases that is possible (even if the return address is stored > in a register and not on the stack), but the return addresses might > live on a separate stack (IIRC the Intel 8008 or the 8080 has such a > stack), and the call might be the only thing that pushes on that > stack. But yes, in most cases, it's a good argument that even very > deprived processors usually have some form of indirect branching. > > - anton I would imagine that in old times return iinstruction was less common than indirect addressing itself.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-11-08 21:08 +0000 |
| Subject | Re: jumping around, branch splitting |
| Message-ID | <10eobgn$2jii$2@gal.iecc.com> |
| In reply to | #114029 |
According to Michael S <already5chosen@yahoo.com>: >I would imagine that in old times return iinstruction was less common >than indirect addressing itself. On several of the machines I used a subroutine call stored the return address in the first word of the routine and branched to that address+1. The return was just an indirect jump. Stacks? What's a stack? We barely had registers. -- 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 | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-11-09 13:01 -0500 |
| Subject | Re: jumping around, branch splitting |
| Message-ID | <JG4QQ.169511$x587.10273@fx01.iad> |
| In reply to | #114034 |
John Levine wrote: > According to Michael S <already5chosen@yahoo.com>: >> I would imagine that in old times return iinstruction was less common >> than indirect addressing itself. > > On several of the machines I used a subroutine call stored the return > address in the first word of the routine and branched to that address+1. > The return was just an indirect jump. > > Stacks? What's a stack? We barely had registers. Yes, I saw the PDP-8 did that for JMS Jump Subroutine. I've never used one but it looks like by playing with the Indirect and Page-zero memory addressing options you could treat page-zero a bit like a register bank, but also store some short but critical routines in page-zero to manually move the return PC to/from a stack. And use indirect addressing to access its full sumptuous 4kW address space.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-11-09 20:18 +0000 |
| Subject | Re: jumping around, branch splitting |
| Message-ID | <10eqsun$1vdu$1@gal.iecc.com> |
| In reply to | #114037 |
It appears that EricP <ThatWouldBeTelling@thevillage.com> said: >> On several of the machines I used a subroutine call stored the return >> address in the first word of the routine and branched to that address+1. >> The return was just an indirect jump. >> >> Stacks? What's a stack? We barely had registers. > >Yes, I saw the PDP-8 did that for JMS Jump Subroutine. >I've never used one but it looks like by playing with the >Indirect and Page-zero memory addressing options you could >treat page-zero a bit like a register bank, >but also store some short but critical routines in page-zero >to manually move the return PC to/from a stack. >And use indirect addressing to access its full sumptuous 4kW address space. You wouldn't put routines in page zero but you might put pointers to them so you could do JMS I 123 to call the routine pointed to by page zero location 123. We rarely did recursive stuff so there wasn't any need to simulate a stack. Storing the return address in the first word was pretty common. Even the PDP-6/10 had a JSR instruction that did that. On machines without index registers, there's no better place to put the return address. -- 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 | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-09 21:11 +0000 |
| Subject | Re: jumping around, branch splitting |
| Message-ID | <1762722712-5857@newsgrouper.org> |
| In reply to | #114034 |
John Levine <johnl@taugh.com> posted: > According to Michael S <already5chosen@yahoo.com>: > >I would imagine that in old times return iinstruction was less common > >than indirect addressing itself. > > On several of the machines I used a subroutine call stored the return > address in the first word of the routine and branched to that address+1. > The return was just an indirect jump. > > Stacks? What's a stack? We barely had registers. Heck, back then we barely had memory !! > >
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2025-11-11 19:58 +0200 |
| Subject | Re: jumping around, branch splitting |
| Message-ID | <mnhbqvFs851U2@mid.individual.net> |
| In reply to | #114034 |
On 2025-11-08 23:08, John Levine wrote:
> According to Michael S <already5chosen@yahoo.com>:
>> I would imagine that in old times return iinstruction was less common
>> than indirect addressing itself.
>
> On several of the machines I used a subroutine call stored the return
> address in the first word of the routine and branched to that address+1.
> The return was just an indirect jump.
One such machine was the HP 2100; I used some of those.
> Stacks? What's a stack? We barely had registers.
And indeed the Algol 60 compiler for the HP 2100 did not support
recursion. My programs did real-time control, so I wrote a small
non-preemptive but priority-driven multi-threading kernel. Thread switch
was easy as there were very few registers and no stack. But you had to
be careful because no subroutines were re-entrant.
Speaking of indirect addressing, the HP 2100 had a special feature: it
had a 64 KB address space, but with word addressing of 16-bit words, so
addresses were only 15 bits, leaving the MSbit in each word free.
When using indirect addressing there was an "indirect" bit in the
instruction which, in the usual way, made the machine use the 16-bit
content of the (directly) addressed word as the actual target address,
but only if the MSbit of that content was zero. If the MSbit was one, it
caused a further level of indirection, using the 15 other bits as the
address of another word that again would contain the actual target
address, if the MSbit of /that/ content was zero, and so on.
So an indirect instruction could cause a chain of indirections which
ended when an address-word had a zero in its MSbit. And the machine
could get stuck in an eternal indirection loop, which IIRC happened to
me once :-)
--
Niklas Holsti
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-11-11 18:48 +0000 |
| Subject | Re: jumping around, branch splitting |
| Message-ID | <jyLQQ.370573$T_d8.163434@fx44.iad> |
| In reply to | #114065 |
Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >On 2025-11-08 23:08, John Levine wrote: >> According to Michael S <already5chosen@yahoo.com>: >>> I would imagine that in old times return iinstruction was less common >>> than indirect addressing itself. >> >> On several of the machines I used a subroutine call stored the return >> address in the first word of the routine and branched to that address+1. >> The return was just an indirect jump. > >One such machine was the HP 2100; I used some of those. > >> Stacks? What's a stack? We barely had registers. >And indeed the Algol 60 compiler for the HP 2100 did not support >recursion. My programs did real-time control, so I wrote a small >non-preemptive but priority-driven multi-threading kernel. Thread switch >was easy as there were very few registers and no stack. But you had to >be careful because no subroutines were re-entrant. > >Speaking of indirect addressing, the HP 2100 had a special feature: it >had a 64 KB address space, but with word addressing of 16-bit words, so >addresses were only 15 bits, leaving the MSbit in each word free. > >When using indirect addressing there was an "indirect" bit in the >instruction which, in the usual way, made the machine use the 16-bit >content of the (directly) addressed word as the actual target address, >but only if the MSbit of that content was zero. If the MSbit was one, it >caused a further level of indirection, using the 15 other bits as the >address of another word that again would contain the actual target >address, if the MSbit of /that/ content was zero, and so on. > >So an indirect instruction could cause a chain of indirections which >ended when an address-word had a zero in its MSbit. And the machine >could get stuck in an eternal indirection loop, which IIRC happened to >me once :-) The Burroughs B3500 and sucessors had a similar feature. An instruction operand contained the address of the operand plus four control bits (BCD architecture). Two of the control bits could select one of three index registers that would be summed with the address (the index registers are signed, the address unsigned). The other two control bits specified the operand type (UN - Unsigned Numeric, SN - Signed Numeric, UA - Unsigned Alphanumeric, IA - Indirect Address). If the IA bit was set for an operand, the processor would read a new operand from the target address and process it as if it were an operand. This indirection continued until an operand specified a data type other than IA. The processor started a timer before each instruction, if the instruction execution time exceeded the timer value, the MCP would terminate the program. In the B3500 operands were six digits, and the controller bits consumed the high-order digit, allowing addresses ranging from 000000 to 099999 (100 kilo digits). The B4700 added extended operands which supported 000000 through 999999 by placing an undigit (12 or 0xC) in the second digit position of the operand and extending the operand to 32 bits (8 BCD digits). The first digit still contained the operand type bits, the second digit the value 0xc and the remaining six digits were the program address. The V380 (upgraded B4900) extended further by supporting four additional index registers; if the second digit of the operand was 0xd, the data type index register bits selected IX4 through IX7. In all cases, a "segment" was limited to one million digits in size. Before the V380, a program was limited to a single segment; the V380 added an entirely new virtual memory subsystem (segment based) that supported 100,000 environments per process, with up to 100 segments per environment. A single segment was still limited to 500KB, however, for backward binary compatibility with programs from 1965. Large programs (e.g. the COBOL compiler) used an operating system (MCP) provided overlay mechanism (the MCP cached overlays in other parts of main memory or on a fast RAMdisk).
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-11-11 21:10 +0000 |
| Subject | Re: indirect chains, jumping around, branch splitting |
| Message-ID | <10f08nh$204j$1@gal.iecc.com> |
| In reply to | #114065 |
According to Niklas Holsti <niklas.holsti@tidorum.invalid>: >Speaking of indirect addressing, the HP 2100 had a special feature: it >had a 64 KB address space, but with word addressing of 16-bit words, so >addresses were only 15 bits, leaving the MSbit in each word free. > >[multi-level indirect chains] That was quite common back in the day. The Data General Nova and Varian 620i (both popular for OEM applications) did exactly the same thing, 15 bit addresses with the high bit saying indirect. The PDP-6/10 was a 36 bit machine with 18 bit addresses and a rather overimplemented addressing scheme -- each instruction had an address, an indirect bit, and an index register, so it added the address to the index register (if the register number wasn't zero), then if the indirect bit was set, fetch the addressed word and interpret its address, indirect bit, and index register the same way, ad infinitum. An interesting question is what happened if a computer got into an indirect loop. The Nova just hung unless it had the memory protection option which limited it to two levels of indirection. The PDP-6/10 could take an interrupt before each address calculation, which restarted when the interrupt returned. One day when I was feeling bored I wrote a program that did an ever longer indirect chain until the program stalled because it took longer than a clock interrupt time. The system was fine, only my program stalled. Dunno what the 620i did, I never ran into that particular bug and the manual doesn't say. -- 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 | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-11-11 16:06 -0800 |
| Subject | Re: indirect chains, jumping around, branch splitting |
| Message-ID | <10f0j2o$13sbu$1@dont-email.me> |
| In reply to | #114071 |
On 11/11/2025 1:10 PM, John Levine wrote: > According to Niklas Holsti <niklas.holsti@tidorum.invalid>: >> Speaking of indirect addressing, the HP 2100 had a special feature: it >> had a 64 KB address space, but with word addressing of 16-bit words, so >> addresses were only 15 bits, leaving the MSbit in each word free. >> >> [multi-level indirect chains] > > That was quite common back in the day. Yes, as I mentioned earlier in this thread, so did the Univac 1100 series.> > The Data General Nova and Varian 620i (both popular for OEM > applications) did exactly the same thing, 15 bit addresses with the > high bit saying indirect. > > The PDP-6/10 was a 36 bit machine with 18 bit addresses and a rather > overimplemented addressing scheme -- each instruction had an address, an > indirect bit, and an index register, so it added the address to the index > register (if the register number wasn't zero), then if the indirect bit was set, > fetch the addressed word and interpret its address, indirect bit, and index > register the same way, ad infinitum. Yup. Similarly the 1100 series, a 36 bit machine with 18 bit addresses, had all of those features, plus one more. If the index register increment bit was set (in the instruction itself, or in each of the indirect words), the upper 18 bits of the index register were added (after indexing) to the lower 18 bits. This allowed some really "interesting" possible code when this was within a loop. :-) > > An interesting question is what happened if a computer got into an indirect > loop. Yup. The 1100 prevented an infinite loop by having a hardware timer for each instruction. If the timer expired, an illegal operation exception occurred. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-11-08 21:07 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <10eobdl$2jii$1@gal.iecc.com> |
| In reply to | #114028 |
It appears that Anton Ertl <anton@mips.complang.tuwien.ac.at> said: >I don't know of any architecture (except maybe some one-instruction >proof-of-concepts) that does not have indirect branches in one form or >another, but I am not that familiar with architectures from the 1950s >or some of the extremely deprived embedded-control processors. Some of the 1950s machines didn't have indirect branches. You got the effect by patching the address into a branch instruction and then flowing or jumping to it. >Maybe the thing about self-modifying code was thrown in to taint the >assigned goto through guilt-by-association. if you want guilt by association, the word is ALTER. >stack. But yes, in most cases, it's a good argument that even very >deprived processors usually have some form of indirect branching. I agree. Indirect addressing and indexing appeared quite early. -- 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 | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-06 18:45 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <1762454741-5857@newsgrouper.org> |
| In reply to | #113976 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
> >On 11/4/2025 9: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?
> >
> >Because it could, and often did, make the code "unfollowable". That is,
> >you are reading the code, following it to try to figure out what it is
> >doing and come to an assigned/alter goto, and you don't know where to go
> >next. The value was set some place else in the code, who knows where,
> >and thus what value it was set to, and people/programmers just aren't
> >used to being able to follow code like that.
>
> Take an example use: A VM interpreter. With labels-as-values it looks
> like this:
>
> void engine(char *source)
> {
> void *insts[] = {&&add, &&load, &&ip, ...};
>
> void **ip=compile_to_vm_code(source,insts);
>
> goto *ip++;
>
> add:
> ...
> goto *ip++;
> load:
> ...
> goto *ip++;
> store:
> ...
> goto *ip++;
> ...
> }
>
> So of course you don't know where one of the gotos goes to, because
> that depends on the VM code, which depends on the source code.
>
> Now let's see how it looks with switch:
>
> void engine(char *source)
> {
> typedef enum {add, load, store,...} inst;
> inst *ip=compile_to_vm_code(source,insts);
>
> for (;;) {
> switch (*ip++) {
> add:
> ...
> break;
> load:
> ...
> break;
> store:
> ...
> break;
> ...
> }
> }
> }
Now let us look at it with tabularized functions:: {Ignore the
interrupt and exception stuff at your peril}
bool RunInst( Chip chip )
{
for( uint64_t i = 0; i < cores; i++ )
{
ContextStack *cpu = &core[i];
uint8_t cs = cpu->cs;
Thread *t = cpu->context[cs];
Inst I;
if( cpu->interrupt & ((((signed)1)<<63) >> cpu->priority) )
{ // take an interrupt
cpu->cs = cpu->interrupt.cs;
cpu->priority = cpu->interrupt.priority;
t = context[cpu->cs];
t->reg[0] = cpu->interrupt.message;
}
else if( uint16_t raised = c->raised & c->enabled )
{ // take an exception
cpu->cs--;
t = context[cpu->cs];
t->reg[0] = FT1( raised ) | EXCPT;
t->reg[1] = I.inst;
t->reg[2] = I.src1;
t->reg[3] = I.src2;
t->reg[4] = I.src3;
}
else
{ // run an instruction
t->ip += memory( FETCH, t->ip, &I.inst );
t->raised |= majorTable[ I.major ]( cpu, t, &I );
}
}
}
> Do you know any better which of the "..." is executed next? Of course
> not, for the same reason. Likewise for call threading, but there the
> VM instruction implementations can be discributed across many source
> files. With the replicated switch, the problem of predictability is
> the same, but there is lots of extra code, with many direct gotos.
>
> If you implement, say, a state machine using labels-as-values, or
> switch, again, the logic behind it is the same and the predictability
> is the same between the two implementations.
>
> >BTW, you mentioned that it could be implemented as an indirect jump. It
> >could for those architectures that supported that feature, but it could
> >also be implemented by having the Alter/Assign modify the code (i.e.
> >change the address in the jump/branch instruction), and self modifying
> >code is just bad.
>
> On such architectures switch would also be implemented by modifying
> the code, and indirect calls and method dispatch would also be
> implemented by modifying the code. If self-modifying code is "just
> bad", and any language features that are implemented on some long-gone
> architectures using self-modifying code are bad by association, then
> we have to get rid of all of these language features ASAP.
>
> One interesting aspect here is that the Fortran assigned goto and GNU
> C's goto * (to go with labels-as-values) look more like something that
> may have been inspired by a modern indirect branch than by
> self-modifying code. I only dimly remember the Cobol thing, but IIRC
> this looked more like something that's intended to be implemented by
> self-modifying code. I don't know how the PL/I solution looked like.
>
> >As did COBOL, called goto depending on, but those features didn't suffer
> >the problems of assigned/alter gotos.
>
> As demonstrated above, they do. And if you fall back to using ifs, it
> does not get any better, either.
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-11-06 22:09 +0000 |
| Subject | Re: label variables, was branch splitting |
| Message-ID | <10ej6al$2mg5$1@gal.iecc.com> |
| In reply to | #113990 |
It appears that MitchAlsup <user5857@newsgrouper.org.invalid> said: >> 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 ?!? Relatively speaking, yeah. In languages with nested scopes, label gotos can jump to an outer scope so they have to unwind some frames. Back when people used such things, a common use was on an error to jump out to some recovery code. Function pointers have a sort of similar problem in that they need to carry along pointers to all of the enclosing frames the function can see. That is reasonably well solved by displays, give or take the infamous Knuth man or boy program, 13 lines of Algol60 horror that Knuth himself got the results wrong. -- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-11-07 15:26 +0000 |
| Subject | Re: label variables, was branch splitting |
| Message-ID | <2025Nov7.162638@mips.complang.tuwien.ac.at> |
| In reply to | #113999 |
John Levine <johnl@taugh.com> writes: >In languages with nested scopes, label gotos >can jump to an outer scope so they have to unwind some frames. Back when >people used such things, a common use was on an error to jump out to some >recovery code. Pascal has that feature. Concerning error handling, jumping to an error handler in a statically enclosing scope has fallen out of favour, but throwing an exception to the next dynamically enclosing exception handler is supported in a number of languages. >Function pointers have a sort of similar problem in that they need to carry >along pointers to all of the enclosing frames the function can see. That is >reasonably well solved by displays, give or take the infamous Knuth man or boy >program, 13 lines of Algol60 horror that Knuth himself got the results wrong. Displays and static link chains are among the techniques that can be used to implement static scoping correctly, i.e., where the man-or-boy test produces the correct result. Knuth initially got the result wrong, because he only had boy compilers, and the computation is too involved to do it by hand. The main horror in the original version is that for some of the Algol 60 syntax that is used, it is not obvious without studying the Algol 60 report what it means. <https://rosettacode.org/wiki/Man_or_boy_test#ALGOL_60> contains some discussion, and one can find it in various other programming languages, more or (often) less close to the original. The discussion at <https://rosettacode.org/wiki/Man_or_boy_test#TXR> and the difference between the "proper job" version from the "crib the Common Lisp or Scheme solution" version gives some insight. The fact that "less close" also produces the correct result suggests that the man-or-boy test is less discerning than Knuth probably intended. That's a common problem with testing. - 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 | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2025-11-07 17:54 +0000 |
| Subject | Re: label variables, was branch splitting |
| Message-ID | <0001HW.2EBE69D90018F83730DEB138F@news.individual.net> |
| In reply to | #114008 |
On 7 Nov 2025, Anton Ertl wrote
(in article<2025Nov7.162638@mips.complang.tuwien.ac.at>):
> John Levine <johnl@taugh.com> writes:
> > In languages with nested scopes, label gotos
> > can jump to an outer scope so they have to unwind some frames. Back when
> > people used such things, a common use was on an error to jump out to some
> > recovery code.
>
> Pascal has that feature. Concerning error handling, jumping to an
> error handler in a statically enclosing scope has fallen out of
> favour, but throwing an exception to the next dynamically enclosing
> exception handler is supported in a number of languages.
>
> > Function pointers have a sort of similar problem in that they need to carry
> > along pointers to all of the enclosing frames the function can see. That is
> > reasonably well solved by displays, give or take the infamous Knuth man or
> > boy
> > program, 13 lines of Algol60 horror that Knuth himself got the results
> > wrong.
>
> Displays and static link chains are among the techniques that can be
> used to implement static scoping correctly, i.e., where the man-or-boy
> test produces the correct result. Knuth initially got the result
> wrong, because he only had boy compilers, and the computation is too
> involved to do it by hand.
I append a run of MANORBOY in Pascal for the KDF9.
No display was used.
A static frame pointer as part of the functional parameter
suffices logically and gives better performance.
Paskal : the KDF9 Pascal cross-compiler V19.2a, compiled ... on 2025-11-07.
1 u | %storage = 32767
2 u | %ystores = 30100
3 u |
4 u | program MAN_OR_BOY;
5 u |
6 u | { See: }
7 u | { "Man or boy?", }
8 u | { by Donald Knuth, }
9 u | { ALGOL Bulletin 17.2.4, p7; July 1964. }
10 u |
11 u | var
12 u | i : integer;
13 u | function A (
14 u | k : integer;
15 u | function x1 : integer;
16 u | function x2 : integer;
17 u | function x3 : integer;
18 u | function x4 : integer;
19 u | function x5 : integer
20 u | ) : integer;
21 u |
22 u | function B : integer;
23 u 1b| begin
24 u | k := k - 1;
25 u | B := A (k, B, x1, x2, x3, x4);
26 u 1e| end { B };
27 u |
28 u 1b| begin { A }
29 u | if k <= 0 then
30 u | A := x4 + x5
31 u | else
32 u | A := B;
33 u 1e| end { A };
34 u |
35 u | function pos_one : integer;
36 u | begin pos_one := 1 end;
37 u |
38 u | function neg_one : integer;
39 u | begin neg_one := -1 end;
40 u |
41 u | function zero : integer;
42 u | begin zero := 0 end;
43 u |
44 u 1b| begin { MAN_OR_BOY }
45 u | rewrite(1, 3);
46 u | for i := 0 to 11 do
47 u | write(A(i, pos_one, neg_one, neg_one, pos_one, zero):6);
48 u | writeln;
49 u 1e| end { MAN_OR_BOY }.
Compilation complete : 0 error(s) and 0 warning(s) were reported.
...
This is ee9 17.0a, compiled by GNAT ... on 2025-11-07.
Running the KDF9 problem program Binary/MANORBOY
...
Final State: Normal end of run.
...
LP0 on buffer #05 printed 1 line.
LP0:
===
1 0 -2 0 1 0 1 -1 -10 -30 -67 -138
===
--
Bill Findlay
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-11-08 10:02 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <10en4fg$2fbgo$1@dont-email.me> |
| In reply to | #113976 |
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) 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.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
Page 40 of 46 — ← Prev page 1 … 38 39 [40] 41 42 … 46 Next page →
Back to top | Article view | comp.arch
csiph-web