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 14 of 46 — ← Prev page 1 … 12 13 [14] 15 16 … 46 Next page →
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-02-22 11:51 -0500 |
| Message-ID | <jwvldgkd90g.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #115072 |
Anton Ertl [2026-02-21 18:41:12] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>>> At the time of conception, there were amny arguments that {sooner or
>>> later} compilers COULD figure stuff like this out.
>> I can't remember seeing such arguments comping from compiler people, tho.
> Actually, the IA-64 people could point to the work on VLIW (in
> particular, Multiflow (trace scheduling) and Cydrome (software
> pipelining)), which in turn is based on the work on compilers for
> microcode.
Of course, compiler people have worked on such problems and solved some
cases. But what I wrote above is that "I can't remember seeing
... compiler people" claiming that "{sooner or later} compilers COULD
figure stuff like this out".
> The major problem was that the premise was wrong. They assumed that
> in-order would give them a clock rate edge, but that was not the case,
> right from the start (The 1GHz Itanium II (released July 2002)
> competed with 2.53GHz Pentium 4 (released May 2002) and 1800MHz Athlon
> XP (released June 2002)). They also assumed that explicit parallelism
> would provide at least as much ILP as hardware scheduling of OoO CPUs,
> but that was not the case for general-purpose code, and in any case,
> they needed a lot of additional ILP to make up for their clock speed
> disadvantage.
Definitely.
>>The odd thing is that these were hardware companies betting on "someone
>>else" solving their problem, yet if compiler people truly had managed to
>>solve those problems, then other hardware companies could have taken
>>advantage just as well.
> I am sure they had patents on stuff like the advanced load and the
> ALAT, so no, other hardware companies would have had a hard time.
I'm pretty sure that if compiler people ever solve the problems that
plagued the Itanium, those same solutions can bring similar benefits to
architectures using other (non-patented) mechanisms.
=== Stefan
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-02-22 20:14 +0000 |
| Subject | Re: IA-64 and trace scheduling, Tonights Tradeoff |
| Message-ID | <10nfo2i$2ov6$1@gal.iecc.com> |
| In reply to | #115095 |
According to Stefan Monnier <monnier@iro.umontreal.ca>:
>> particular, Multiflow (trace scheduling) and Cydrome (software
>> pipelining)), which in turn is based on the work on compilers for
>> microcode.
>
>Of course, compiler people have worked on such problems and solved some
>cases. But what I wrote above is that "I can't remember seeing
>... compiler people" claiming that "{sooner or later} compilers COULD
>figure stuff like this out".
I recall Multiflow people telling me that trace scheduling did a great job
of scheduling memory accesses when the patterns were predictable and that it
didn't when they weren't, i.e., data dependent.
Apropos another thread I can believe that IA-64 was obsolete before it was shipped
for that reason, static scheduling will never keep up with dynamic except in
applications where the access patterns are predictable.
Are there enough applications like that to make VLIWs worth it? Some kinds of DSP?
--
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 | 2026-02-22 23:08 +0000 |
| Subject | Re: IA-64 and trace scheduling, Tonights Tradeoff |
| Message-ID | <2026Feb23.000805@mips.complang.tuwien.ac.at> |
| In reply to | #115099 |
John Levine <johnl@taugh.com> writes: >Apropos another thread I can believe that IA-64 was obsolete before it was shipped >for that reason, static scheduling will never keep up with dynamic except in >applications where the access patterns are predictable. Concerning the scheduling, hardware scheduling looked pretty dumb at the time (always schedule the oldest ready instruction(s)), and compilers could pick the instructions on the critical path in their scheduling, but given the scheduling barriers in compilers (e.g., calls and returns), and the window sizes in current hardware, even dumb is superior to smart. Another aspect where hardware is far superior is branch prediction. >Are there enough applications like that to make VLIWs worth it? Some kinds of DSP? There have certainly been DSPs from TI (C60 series IIRC), and Phillips (TriMedia) that have VLIW architectures, so at least for a while, VLIW was competetive there. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-02-23 01:32 +0000 |
| Subject | Re: IA-64 and trace scheduling, Tonights Tradeoff |
| Message-ID | <10ngao4$d5o$1@gal.iecc.com> |
| In reply to | #115102 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >John Levine <johnl@taugh.com> writes: >>Apropos another thread I can believe that IA-64 was obsolete before it was shipped >>for that reason, static scheduling will never keep up with dynamic except in >>applications where the access patterns are predictable. > >Concerning the scheduling, hardware scheduling looked pretty dumb at >the time (always schedule the oldest ready instruction(s)), ... I was thinking of memory scheduling. You have multiple banks of memory each of which can only do one fetch or store at a time, and the goal was to keep all of the banks as busy as possible. If you're accessing an array in predictable order, trace scheduling works well, but if you're fetching a[b[i]] where b varies at runtime, it doesn't. >Another aspect where hardware is far superior is branch prediction. I gather speculative execution of both branch paths worked OK if the branch tree wasn't too bushy. There were certainly ugly details, e.g., if there's a trap on a path that turns out not to be taken. -- 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 | 2026-02-23 06:55 +0000 |
| Subject | Re: IA-64 and trace scheduling, Tonights Tradeoff |
| Message-ID | <2026Feb23.075508@mips.complang.tuwien.ac.at> |
| In reply to | #115106 |
John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>John Levine <johnl@taugh.com> writes:
>>>Apropos another thread I can believe that IA-64 was obsolete before it was shipped
>>>for that reason, static scheduling will never keep up with dynamic except in
>>>applications where the access patterns are predictable.
>>
>>Concerning the scheduling, hardware scheduling looked pretty dumb at
>>the time (always schedule the oldest ready instruction(s)), ...
>
>I was thinking of memory scheduling. You have multiple banks of memory
>each of which can only do one fetch or store at a time, and the goal
>was to keep all of the banks as busy as possible. If you're accessing
>an array in predictable order, trace scheduling works well, but if
>you're fetching a[b[i]] where b varies at runtime, it doesn't.
More advanced in-order uarchs have dealt with this by submitting
requests to the load-store unit in-order, performing the requests as
the resources and the memory model allow, and only letting uses of the
loads wait for the results (Mitch Alsup has been calling such things
OoO, too, but that's far from the modern OoO with speculative
execution and in-order completion; in particular, there is no
speculative execution).
Plus, there is the option of inserting prefetch instructions, which
give the same memory-level parallelism on in-order CPUs as on OoO
CPUs; for a[b[i]] patterns they might be useful, unless the hardware
prefetchers also know how to prefetch that.
Moreover, AVX-512 has a gathering load instruction (and a scattering
store instruction) that were designed for an optimized in-order
implementation in Knights Ferry.
>>Another aspect where hardware is far superior is branch prediction.
>
>I gather speculative execution of both branch paths worked OK if the
>branch tree wasn't too bushy.
If one goes that way, if-conversion (conversion to predicated
execution) looked like the way to go, but it turns a control
dependency (which vanishes if the branch is predicted correctly) into
a data dependency. Even without that, pulling instructions from all
ways up across branches soon runs into resource limitations. Static
branch prediction is not great (~20% mispredicts when using
heuristics, ~10% when using profile feedback), but it is still far
better than assuming that all branches go both ways equally likely.
Augustus K. Uht suggested that one keeps track of the likelyhood of
statically not-predicted branches; after following a few prediction,
the likelyhood of the path to the currently predicted branch would be
smaller than the likelyhood of one of the earlier not-predicted
branches. He suggested that the compiler should use these likelyhoods
to guide speculation decisions.
But in the early 1990s dynamic (hardware) branch prediction started
producing significantly lower misprediction rates than static and even
semi-static branch prediction, and branch predictors have improved
since then; e.g., for our LaTeX benchmark Zen 4 produces the following
results:
1_325_396_218 cycles 4.961 GHz ( +- 0.12% )
3_565_310_588 instructions 2.69 insn per cycle
656_903_470 branches 2.459 G/sec ( +- 0.01% )
8_417_229 branch-misses 1.28% of all branches ( +- 0.21% )
That's not just 1.28% branch mispredictions, but also 2.36 branch
mispredictions per 1000 instruction (MPKI), or 423 instructions
between branch mispredictions on average. This means that the
hardware scheduler can schedule across hundreds of instructions before
hitting a scheduling barrier. It also means that all the speculation
within those 423 instructions will actually be useful, whereas
speculating on both sides of a branch (or if-conversion) guarantees
that most of the speculated instructions will be useless.
But yes, for instructions from behind an if that do not depend on the
values computed in the if, one can schedule them above the if without
duplication along both paths, and this looked like one of the
smartness advantages of compilers over OoO hardware. But given the
very high branch prediction accuracies that hardware exhibits, this
advantage is small, and as IA-64 demonstrated, does not outweigh the
disadvantages of EPIC by far.
>There were certainly ugly details, e.g.,
>if there's a trap on a path that turns out not to be taken.
IA-64 (and EPIC in general) has the advanced load for that; IA-64 also
does not implement division in hardware (i.e., division by zero is
checked by software). This means that any trapping can happen once
the branch is guaranteed to be taken, but the speculative execution
happens earlier. If static branch prediction worked as well as
dynamic branch prediction, that would have been one of the important
parts in making IA-64 have as much ILP as OoO.
I have actually written a paper on the topic:
@InProceedings{ertl&krall94,
author = "M. Anton Ertl and Andreas Krall",
title = "Delayed Exceptions --- Speculative Execution of
Trapping Instructions",
booktitle = "Compiler Construction (CC '94)",
year = "1994",
publisher = "Springer LNCS~786",
address = "Edinburgh",
month = "April",
pages = "158--171",
url = "https://www.complang.tuwien.ac.at/papers/ertl-krall94cc.ps.gz",
abstract = "Superscalar processors, which execute basic blocks
sequentially, cannot use much instruction level
parallelism. Speculative execution has been proposed
to execute basic blocks in parallel. A pure software
approach suffers from low performance, because
exception-generating instructions cannot be executed
speculatively. We propose delayed exceptions, a
combination of hardware and compiler extensions that
can provide high performance and correct exception
handling in compiler-based speculative execution.
Delayed exceptions exploit the fact that exceptions
are rare. The compiler assumes the typical case (no
exceptions), schedules the code accordingly, and
inserts run-time checks and fix-up code that ensure
correct execution when exceptions do happen."
}
- 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 | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-02-23 21:22 +0000 |
| Subject | Re: IA-64 and trace scheduling, Tonights Tradeoff |
| Message-ID | <memo.20260223212251.15252g@jgd.cix.co.uk> |
| In reply to | #115106 |
In article <10ngao4$d5o$1@gal.iecc.com>, johnl@taugh.com (John Levine) wrote: > I gather speculative execution of both branch paths worked OK if the > branch tree wasn't too bushy. There were certainly ugly details, > e.g., if there's a trap on a path that turns out not to be taken. Found a good CPU bug like that on an old AMD chip, the K6-II. It happened with a floating point divide by zero in the x87 registers, guarded by a test for division by zero, with floating-point traps enabled. The divide got speculatively executed, the trap was stored, the test revealed the divide would be by zero, the CPU tried to clean up, hit its bug, and just stopped. Power switch time. This only happened with the reverse divide instruction, which took the operands off the x87 stack in the opposite order from the usual FDIV. It was rarely used, so the bug didn't become widely known. But Microsoft's compiler used it occasionally. John
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-02-24 10:41 +0100 |
| Subject | Re: IA-64 and trace scheduling, Tonights Tradeoff |
| Message-ID | <10njrp6$3ohb1$1@dont-email.me> |
| In reply to | #115116 |
John Dallman wrote: > In article <10ngao4$d5o$1@gal.iecc.com>, johnl@taugh.com (John Levine) > wrote: > >> I gather speculative execution of both branch paths worked OK if the >> branch tree wasn't too bushy. There were certainly ugly details, >> e.g., if there's a trap on a path that turns out not to be taken. > > Found a good CPU bug like that on an old AMD chip, the K6-II. > > It happened with a floating point divide by zero in the x87 registers, > guarded by a test for division by zero, with floating-point traps enabled. > The divide got speculatively executed, the trap was stored, the test > revealed the divide would be by zero, the CPU tried to clean up, hit its > bug, and just stopped. Power switch time. > > This only happened with the reverse divide instruction, which took the > operands off the x87 stack in the opposite order from the usual FDIV. It > was rarely used, so the bug didn't become widely known. But Microsoft's > compiler used it occasionally. Still an impressive find! I can see that since it would be (almost?) 100% reproducible, you could bisect the executable (in a debugger) to hone in on where it froze? Trying to single-step up to the crash would negate the required speculation, right? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | kegs@provalid.com (Kent Dickey) |
|---|---|
| Date | 2026-03-01 21:12 +0000 |
| Message-ID | <10o2a47$j1pl$1@dont-email.me> |
| In reply to | #115072 |
In article <2026Feb21.194112@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> At the time of conception, there were amny arguments that {sooner or
>>> later} compilers COULD figure stuff like this out.
>>
>>I can't remember seeing such arguments comping from compiler people, tho.
>
>Actually, the IA-64 people could point to the work on VLIW (in
>particular, Multiflow (trace scheduling) and Cydrome (software
>pipelining)), which in turn is based on the work on compilers for
>microcode.
>
>That did not solve memory latency, but that's a problem even for OoO
>cores.
>
>>> I suspect a big part of the problem was tension between Intel and HP
>>> were the only political solution was allowing the architects from both
>>> sides to "dump in" their favorite ideas. A recipe for disaster.
>
>The HP side had people like Bob Rau (Cydrome) and Josh Fisher
>(Multiflow), and given their premise, the architecture is ok; somewhat
>on the complex side, but they wanted to cover all the good ideas from
>earlier designs; after all, it was to be the one architecture to rule
>them all (especially performancewise). You cannot leave out a feature
>that a competitor could then add to outperform IA-64.
>
>The major problem was that the premise was wrong. They assumed that
>in-order would give them a clock rate edge, but that was not the case,
>right from the start (The 1GHz Itanium II (released July 2002)
>competed with 2.53GHz Pentium 4 (released May 2002) and 1800MHz Athlon
>XP (released June 2002)). They also assumed that explicit parallelism
>would provide at least as much ILP as hardware scheduling of OoO CPUs,
>but that was not the case for general-purpose code, and in any case,
>they needed a lot of additional ILP to make up for their clock speed
>disadvantage.
As I've said before: I worked at HP during IA64, and it was not driven
by technical issues, but rather political/financial issues.
On HP's side, IA64 was driven by HP Labs, which was an independent group
doing technical investigations without any clear line to products. They
had to "sell" their ideas to the HP development groups, who could ignore them.
They managed to get some upper level HP managers interested in IA64,
and took that directly to Intel. The HP internal development groups (the
ones making CPUs and server/workstation chipsets) did almost nothing with
IA64 until after Intel announced the IA64 agreement.
IA64 was called PrecisionArchitecture-WideWord (PA-WW) by HP Labs as a
follow on to PA-RISC. The initial version of PA-WW had no register
interlocks whatsoever, code had to be written to know the L1 and L2
cache latency, and not touch the result registers too soon. This was
laughed out of the room, and they came back with interlocks in the next
iteration. This happened in 1993-1994, which was before the Out-of-Order
RISCs came to market (but they were in development in HP and Intel), so the
IA64 decisions were being made in the time window before folks really got to
see what OoO could do.
Also on HP's side, we had our own fab, which was having trouble keeping up
with the rest of the industry. Designers felt performance was not
predictable, and the fab's costs were escalating. The fab was going to
have trouble getting to 180nm and beyond. So HP wanted access to Intel's
fabs, and that was part of the IA64 deal--we could make PA-RISC chips on
Intel's fabs for a long time.
On Intel's side, Intel was divided very strongly geographically. At the
time, Hillsboro was "winning" in the x86 CPU area, and Santa Clara was
on the outs (I think they did 860 and other failures like that). So
when Santa Clara heard of IA64, they jumped on the opportunity--a way to
leap past Hillsboro. IA64 solved the AMD problem--with all new IA64
patents, AMD couldn't clone it like x86, so management was interested.
Technically, IA64 just had to be "as good as" x86, to make it worth
while to jump to a new architecture which removes their competitor. I
can see how even smart folks could get sucked in to thinking
"architecture doesn't matter, and this new one prevents clones, so we
should do it to eventually make more money".
Both companies had selfish mid-level managers who saw a way to pad their
resumes to leap to VP of engineering almost anywhere else. And they were
right--on HP's side, I think every manager involved moved to a promotion
at another company just before Merced came out. So IA64 was not going to
get canceled--the managers didn't want to admit they were wrong.
Both companies also saw IA64 as a way to kill off the RISC competitors.
And on this point, they were right, IA64 did kill the RISC minicomputer
market.
The technical merits of IA64 don't make the top 5 in the list of reasons to
do IA64 for either company.
But HP using Intel's fabs didn't work out well. HP's first CPU on
Intel's fabs was the 360MHz PA-8500. This was a disappointing step up
from the 240MHz PA-8200 (which was partly speed limited by external L1
cache memory, running at 4ns, and the 8500 moved to on-chip L1 cache
memory, removing that limit). It turned out Intel's fab advantage was
consistency and yield, not speed, and so it would take tuning to get the
speed up. Intel did this tuning with large teams, and this was not easy
for HP to replicate. And by this time, IBM was marketing a 180nm copper
wire SOI process which WAS much faster (and yields weren't a concern for
HP), so after getting the PA-8500 up to 550MHz after a lot of work, HP
jumped to IBM as a fab, and the speeds went up to 750MHz and then 875MHz with
some light tuning (and a lot less work).
Everyone technically minded knew IA64 was technically not that great, but
both companies had their reasons to do it anyway.
Kent
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-03-03 11:22 -0500 |
| Message-ID | <jwvecm0ubop.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #115181 |
Thanks for this account of what happened with IA64.
It's the first time I see an explanation that really makes sense.
=== Stefan
Kent Dickey [2026-03-01 21:12:39] wrote:
> In article <2026Feb21.194112@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> At the time of conception, there were amny arguments that {sooner or
>>>> later} compilers COULD figure stuff like this out.
>>>
>>>I can't remember seeing such arguments comping from compiler people, tho.
>>
>>Actually, the IA-64 people could point to the work on VLIW (in
>>particular, Multiflow (trace scheduling) and Cydrome (software
>>pipelining)), which in turn is based on the work on compilers for
>>microcode.
>>
>>That did not solve memory latency, but that's a problem even for OoO
>>cores.
>>
>>>> I suspect a big part of the problem was tension between Intel and HP
>>>> were the only political solution was allowing the architects from both
>>>> sides to "dump in" their favorite ideas. A recipe for disaster.
>>
>>The HP side had people like Bob Rau (Cydrome) and Josh Fisher
>>(Multiflow), and given their premise, the architecture is ok; somewhat
>>on the complex side, but they wanted to cover all the good ideas from
>>earlier designs; after all, it was to be the one architecture to rule
>>them all (especially performancewise). You cannot leave out a feature
>>that a competitor could then add to outperform IA-64.
>>
>>The major problem was that the premise was wrong. They assumed that
>>in-order would give them a clock rate edge, but that was not the case,
>>right from the start (The 1GHz Itanium II (released July 2002)
>>competed with 2.53GHz Pentium 4 (released May 2002) and 1800MHz Athlon
>>XP (released June 2002)). They also assumed that explicit parallelism
>>would provide at least as much ILP as hardware scheduling of OoO CPUs,
>>but that was not the case for general-purpose code, and in any case,
>>they needed a lot of additional ILP to make up for their clock speed
>>disadvantage.
>
> As I've said before: I worked at HP during IA64, and it was not driven
> by technical issues, but rather political/financial issues.
>
> On HP's side, IA64 was driven by HP Labs, which was an independent group
> doing technical investigations without any clear line to products. They
> had to "sell" their ideas to the HP development groups, who could ignore them.
> They managed to get some upper level HP managers interested in IA64,
> and took that directly to Intel. The HP internal development groups (the
> ones making CPUs and server/workstation chipsets) did almost nothing with
> IA64 until after Intel announced the IA64 agreement.
>
> IA64 was called PrecisionArchitecture-WideWord (PA-WW) by HP Labs as a
> follow on to PA-RISC. The initial version of PA-WW had no register
> interlocks whatsoever, code had to be written to know the L1 and L2
> cache latency, and not touch the result registers too soon. This was
> laughed out of the room, and they came back with interlocks in the next
> iteration. This happened in 1993-1994, which was before the Out-of-Order
> RISCs came to market (but they were in development in HP and Intel), so the
> IA64 decisions were being made in the time window before folks really got to
> see what OoO could do.
>
> Also on HP's side, we had our own fab, which was having trouble keeping up
> with the rest of the industry. Designers felt performance was not
> predictable, and the fab's costs were escalating. The fab was going to
> have trouble getting to 180nm and beyond. So HP wanted access to Intel's
> fabs, and that was part of the IA64 deal--we could make PA-RISC chips on
> Intel's fabs for a long time.
>
> On Intel's side, Intel was divided very strongly geographically. At the
> time, Hillsboro was "winning" in the x86 CPU area, and Santa Clara was
> on the outs (I think they did 860 and other failures like that). So
> when Santa Clara heard of IA64, they jumped on the opportunity--a way to
> leap past Hillsboro. IA64 solved the AMD problem--with all new IA64
> patents, AMD couldn't clone it like x86, so management was interested.
> Technically, IA64 just had to be "as good as" x86, to make it worth
> while to jump to a new architecture which removes their competitor. I
> can see how even smart folks could get sucked in to thinking
> "architecture doesn't matter, and this new one prevents clones, so we
> should do it to eventually make more money".
>
> Both companies had selfish mid-level managers who saw a way to pad their
> resumes to leap to VP of engineering almost anywhere else. And they were
> right--on HP's side, I think every manager involved moved to a promotion
> at another company just before Merced came out. So IA64 was not going to
> get canceled--the managers didn't want to admit they were wrong.
>
> Both companies also saw IA64 as a way to kill off the RISC competitors.
> And on this point, they were right, IA64 did kill the RISC minicomputer
> market.
>
> The technical merits of IA64 don't make the top 5 in the list of reasons to
> do IA64 for either company.
>
> But HP using Intel's fabs didn't work out well. HP's first CPU on
> Intel's fabs was the 360MHz PA-8500. This was a disappointing step up
> from the 240MHz PA-8200 (which was partly speed limited by external L1
> cache memory, running at 4ns, and the 8500 moved to on-chip L1 cache
> memory, removing that limit). It turned out Intel's fab advantage was
> consistency and yield, not speed, and so it would take tuning to get the
> speed up. Intel did this tuning with large teams, and this was not easy
> for HP to replicate. And by this time, IBM was marketing a 180nm copper
> wire SOI process which WAS much faster (and yields weren't a concern for
> HP), so after getting the PA-8500 up to 550MHz after a lot of work, HP
> jumped to IBM as a fab, and the speeds went up to 750MHz and then 875MHz with
> some light tuning (and a lot less work).
>
> Everyone technically minded knew IA64 was technically not that great, but
> both companies had their reasons to do it anyway.
>
> Kent
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-03-03 20:19 +0000 |
| Message-ID | <memo.20260303201936.20100A@jgd.cix.co.uk> |
| In reply to | #115181 |
In article <10o2a47$j1pl$1@dont-email.me>, kegs@provalid.com (Kent Dickey) wrote: > Technically, IA64 just had to be "as good as" x86, to make it worth > while to jump to a new architecture which removes their competitor. > I can see how even smart folks could get sucked in to thinking > "architecture doesn't matter, and this new one prevents clones, so > we should do it to eventually make more money". It very notably failed to offer the end-users anything attractive. Since those days, I've worked on the basis that you need to do that, and if you can manage it consistently, that keeps you competitive. > Everyone technically minded knew IA64 was technically not that > great, but both companies had their reasons to do it anyway. The problem with floating-point advance loads not always working if there was a function call between the load and the check made sure that IA64 would be inferior on a technical level. There wasn't a way to fix that and retain software compatibility. Once that was clear, I was always looking to get rid of the architecture. We just said "no" to a US Government customer who wanted IA64 Linux. The policy I set for sales for other operating systems amounted to the same thing: "Find out the maximum they're willing to pay. Quote them three times that much." John
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-02-20 15:29 -0600 |
| Message-ID | <10nak0a$nrac$2@dont-email.me> |
| In reply to | #115052 |
On 2/19/2026 5:10 PM, John Dallman wrote:
>> My own limited experience with MS-DOS programming mostly showed
>> them using integer file-handles an a vaguely Unix-like interface
>> for file IO at the "int 21h" level.
>>
>> Which is, ironically, in conflict with the "FILE *" interface used
>> by C's stdio API.
>
> However, it's entirely concordant with Unix's lower-level file
> descriptors, as used in the read() and write() calls.
>
> <https://en.wikipedia.org/wiki/File_descriptor>
> <https://en.wikipedia.org/wiki/Read_(system_call)>
>
> The FILE* interface is normally implemented on top of the lower-level
> calls, with a buffer in the process' address space, managed by the C
> run-time library. The file descriptor is normally a member of the FILE
> structure.
>
> MS-DOS is not a great design, but it isn't crazy either.
>
Yeah.
>> Well, apart from some vague (unconfirmed) memories of being exposed
>> to Pascal via the "Mac Programmer's Workbench" thing at one point
>> and being totally lost (was very confused, used a CLI but the CLI
>> commands didn't make sense).
>
> I used it very briefly. It was a very weird CLI, seemingly designed by
> someone opposed to the basic idea of a CLI.
>
My vague memories was that its commands were just sort of straight up
paradoxical. I don't remember much about them now though, other than
being confused trying to look at them (or getting anything to happen).
But, yeah, at my level of mental development at the time, whole
experience was confusing. Also it using external drives (sorta like on
the Apple II) but connected up with what looked like printer cables.
But, I don't really know exactly why the guy with the computer showed
up, or why he left, but he didn't seem pleased in any case.
Exact timeline is fuzzy, but I do remember enough familiarity with
MS-DOS to recognize they were almost completely different.
And, unlike the Apple II/e, which had essentially used BASIC.
But, either way, the experience (of MPW weirdness) was not something I
would have been ready for at that stage of development.
Well, and apparently a detail I missed in all of this, being that one
didn't just do a SHIFT+RETURN, but it was apparently necessary to select
the text for the command one wanted to run (with the mouse) before
hitting SHIFT+RETURN (or, hitting the keys without selecting something
first does nothing). Could be related to my difficulties/bewilderment at
the time (compared with DOS, which was more like "type command and hit
ENTER").
Somehow I didn't remember anything about the "select command first"
part. More seeing it like "click on the command window and do keyboard
shortcuts" and then having it not work.
But, I guess, some memories of mine, namely the thing of needing to do a
ritual of dragging the drive to the trash-can and then also push a
button on the front of the drive, is reasonably correct for those drives.
Well, vs the 3.5" drive: Drag to trash, it ejects itself.
Or, DOS/Windows/etc, wait until drive stops, press button to eject disk.
Was very important in this case though to drag the drive to the trash
and then wait for the light on the drive to go off, then press the eject
button (and with a good solid press, the disk ejects).
Also, it using a black-and-white monitor in an era where most others
around were color (though with a typically lower screen resolution).
Does seem like a sort of weird almost surreal memory.
Does imply that my younger self was notable, and not seen as just some
otherwise worthless nerd.
Even if I totally failed at the tasks the guy had wanted from me.
So, I was confused, and the guy left in frustration.
>> In a way, it showed that they screwed up the design pretty hard
>> that x86-64 ended up being the faster and more efficient option...
>
> They did. They really did.
>
Yeah.
>> I guess one question is if they had any other particular drawbacks
>> other than, say:
>> Their code density was one of the worst around;
>> 128 registers is a little excessive;
>> 128 predicate register bits is a bit WTF;
>
> Those huge register files had a lot to do with the low code density. They
> had two much bigger problems, though.
>
> They'd correctly understood that the low speed of affordable dynamic RAM
> as compared to CPUs running at hundreds of MHz was the biggest barrier to
> making code run fast. Their solution was have the compiler schedule loads
> well in advance. They assumed, without evidence, that a compiler with
> plenty of time to think could schedule loads better than hardware doing
> it dynamically. It's an appealing idea, but it's wrong.
>
My CPU core doesn't do speculative prefetch either, but this seems more
like a "big OoO CPU" feature.
There is a sort of form of very limited/naive prefetch, where if it
guesses that one line of a like pair is likely to be followed by an
access to the following line in the pair (via heuristics), it will
prefetch the following line. This can help with things like linear
memory walks.
Could be better if there was a good/reliable way to detect linear walks.
Say, ideal case would be that in linear walk scenarios, most of the
memory fetches for the walk are via prefetches (while limiting the
number of hard misses).
For the L1 I$, one can assume linear walking by default.
Though, arguably the effectiveness of a prefetch is reduced in cases
where the hard-miss is likely to happen before the result of the
prefetch arrives (even if it is an L2 hit), but does maybe give the L2
cache a few cycles of "heads up" in the case of an L2 miss.
In my case, as noted, I ended up using 64 registers, but can note:
32 is near-optimal for generic code;
Works well for 32-bit instruction words;
64 deals better with high-pressure scenarios;
Is a little tight for 32-bit instruction words;
128 is likely invariably overkill
Not particularly viable with 32-bit instruction words.
Using register-paired types does result in "spikes" in register
pressure, and is a strong case where supporting 64 registers makes sense
(eg, so code generation doesn't get "owned"/"pwnt" when dealing with
int128 or paired-128-bit-SIMD).
Though, in the case of paired 128-bit ops, the even-registers-only rule
does have a side benefit of allowing for use of 5-bit register fields
while accessing all 64 registers (though still leaves a pain point when
accessing one of the 64-bit halves of the pair, say if it happens to be
on the "wrong side" in the case of an ISA like RISC-V).
For 128 predicate registers, this part doesn't make as much sense:
Typically, 1 predicate bit is sufficient;
When exploring schemes for more advanced predication (Eg, 2 or 7/8
predicate registers), they didn't really even hit break-even.
Even if going for an IA64 like approach, probably made more sense to
have gone with an 8-register config, say:
P0: Hard-wired to 1/True
P1..P7: Dynamic Predicates
But, as noted, it was uncommon to find scenarios where having more than
a single predicate bit offered enough of an advantage over 1 predicated
bit to make it worthwhile, so the single-bit scheme seemed to remain the
most viable (with some more complex scenarios instead using GPRs for
boolean logic tasks, even if using a GPR for boolean logic tasks is
arguably wasteful).
For XG3, had ended up with a scenario where directing Boolean operations
to X0/RO was understood as updating the predicate bit:
SLT, SGE, SEQ, SNE: Rd=X0, Sets/Clears SR.T
AND/OR: Rd=X0, Also modifies SR.T (understood as a Boolean op).
Contrast (Rd=X0):
ADD/ADDI: NOP
LHU/LWU: Reserved for Mode-Hops (XG3 supported) / NOP (unsupported).
LHU: Jumps to RV64GC Mode (behaves like a JALR with Rd=X0)
LWU: Jumps to XG3 Mode (behaves like a JALR with Rd=X0)
Both being fall-through if XG3 is not supported.
If it doesn't branch, it means only RISC-V ops are supported.
Currently, the detection features are not used, as they only really make
sense in a mixed-mode binary that could potentially be used on a plain
RISC-V target.
But, in other contexts, the typical pattern is to use pointer tagging,
where:
(0)=0: Jump to an address within the same mode, (63:48) ignored
(1)=1: Jump with possible mode change, (63:48)=mode
One other special feature is that the mode bits also encode a tag, which
can be used to mark a pointer with the current process (with a value
assigned by an RNG), with the LSB also being required to be set, if Rs1==X1.
This can be used to add resistance against stack-stomping via buffer
overflows, but is potentially risky with RISC-V:
AUIPC X1, AddrHi
JALR X0, AddrLo(X1)
Can nuke the process, when officially it is allowed (vs forcing the use
of a different register to encode a long branch).
Where, for other contexts, AUIPC would necessarily need to produce an
untagged address.
> It might be possible to do that effectively in a single-core,
> single-thread, single-task system that isn't taking many (if any)
> interrupts. In a multi-core system, running a complex operating system,
> several multi-threaded applications, and taking frequent interrupts and
> context switches, it is _not possible_. There is no knowledge of any of
> the interrupts, context switches or other applications at compile time,
> so the compiler has no idea what is in cache and what isn't. I don't
> understand why HP and Intel didn't realise this. It took me years, but I
> am no CPU designer.
>
No idea there, but either way, seems like a difficult problem.
> Speculative execution addresses that problem quite effectively. We don't
> have a better way, almost thirty years after Itanium design decisions
> were taken. They didn't want to do speculative execution, and they close
> an instruction format and register set that made adding it later hard. If
> it was ever tried, nothing was released that had it AFAIK.
>
> The other problem was that they had three (or six, or twelve) in-order
> pipelines running in parallel. That meant the compilers had to provide
> enough ILP to keep those pipelines fed, or they'd just eat cache capacity
> and memory bandwidth executing no-ops ... in a very bulky instruction set.
> They didn't have a general way to extract enough ILP. Nobody does, even
> now. They just assumed that with an army of developers they'd find enough
> heuristics to make it work well enough. They didn't.
>
Yeah...
In my case, there is only 1 pipeline per core for now.
But ISA is still mostly RISC-like.
Not so much the 128-bits with 3-instructions thing, and then needing to
NOP pad if one can't find 3 useful instructions which fit into the pipeline.
My compiler would probably also be pretty awful if trying to target IA64.
Though did get around to re-adding a repurposed version of the WEXifier
for XG3 and RV, though its purpose was a little different in that these
ISA's have no way to flag for parallel execution, so the purpose is more
to shuffle instructions around to try to reduce register-RAW
dependencies and to help out the in-order superscalar stuff.
> There was also an architectural misfeature with floating-point advance
> loads that could make them disappear entirely if there was a call
> instruction between an advance-load instruction and the corresponding
> check-load instruction. That cost me a couple of weeks working out and
> reporting the bug, which was unfixable. The only work-around was to
> re-issue all outstanding all floating-point advance-load instruction
> after each call returned. The effective code density went down further,
> and there were lots of extra read instructions issued.
>
>> I guess it is more of an open question of what would have happened,
>> say, if Intel had gone for an ISA design more like ARM64 or RISC-V
>> or something.
>
> ARM64 seems to me to be the product of a lot more experience with
> speculatively-executing processors than was available in 1998. RISC-V has
> not demonstrated really high performance yet, and it's been around long
> enough that I'm starting to doubt it ever will.
>
There seem to be some questionable design choices here, and also a lot
of foot dragging for things that could help.
They also seem to be relatively focused on the assumption of CPUs having
low-latency ALU and Memory-Load ops, which seems like a dangerous
assumption to make.
Like, how about one not try to bake in assumptions about 1-cycle ALU and
2-cycle Load being practical?...
Vs, say, 2-cycle ALU ops and 3-cycle Loads; with an ideal of putting 5
instructions between an instruction that generates a result and the
instruction that consumes the result as this is more likely to work with
in-order superscalar.
But, then one runs into the issue that if a basic operation then
requires a multi-op sequence, the implied latency goes up considerably
(say, could call this "soft latency", or SL).
So, for example, it means that, say:
2-instruction sign extension:
RV working assumption: 2 cycles
Hard latency (2c ALU): 4 cycles
Soft latency: 12 cycles.
For a 3-op sequence, the effective soft-latency goes up to 18, ...
And, in cases where the soft-latency significantly exceeds the total
length of the loop body, it is no longer viable to schedule the loop
efficiently.
So, in this case, an indexed-load instruction has an effective 9c SL,
whereas SLLI+ADD+LD has a 21 cycle SL.
where, in this case, the goal of something like the WEXifier is to
minimize this soft-latency cost (in cases where a dependency is seen,
any remaining soft-latency is counted as penalty).
But, then again, maybe the concept of this sort of "soft latency" seems
a bit alien.
Granted, not sure how this maps over to OoO, but had noted that even
with modern CPUs, there still seems to be benefit from assuming a sort
of implicit high latency for instructions over assuming a lower latency.
>> Well, or something like PowerPC, but then again, IBM still had
>> difficulty keeping PPC competitive, so dunno. Then again, I think
>> IBM's PPC issues were more related to trying to keep up in the chip
>> fab race that was still going strong at the time, rather than an
>> ISA design issue.
>
> I think that was fabs, rather than architecture. While I was providing
> libraries for PowerPC (strictly, POWER4, POWER5 and POWER6, one after
> another) it always had rather decent performance for its clockspeed and
> process.
>
OK.
I guess it is a question here of what if IBM had outsourced their fab
stuff earlier.
Though, there is still the potential downside of licensing based
production (say, if they went for something more like in the ARM model),
which is possibly worse than the argued threat of vendor-based market
fragmentation (the usual counter-argument against RISc-V, *1).
*1: Where people argue that if each vendor can do a CPU with their own
custom ISA variants and without needing to license or get approval from
a central authority, that invariably everything would decay into an
incoherent mess where there is no binary compatibility between
processors from different vendors (usual implication being that people
are then better off staying within the ARM ecosystem to avoid RV's
lawlessness).
> John
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-02-20 23:49 +0000 |
| Message-ID | <1771631394-5857@newsgrouper.org> |
| In reply to | #115064 |
BGB <cr88192@gmail.com> posted:
> On 2/19/2026 5:10 PM, John Dallman wrote:
> ------------------------------------
> This can be used to add resistance against stack-stomping via buffer
> overflows, but is potentially risky with RISC-V:
> AUIPC X1, AddrHi
> JALR X0, AddrLo(X1)
> Can nuke the process, when officially it is allowed (vs forcing the use
> of a different register to encode a long branch).
That should be:
AUPIC x1,hi(offset)
JALR x0,lo(offset)
using:
SETHI x1,AddrHi
JALR x0,AddrLo
would work.
---------------------
> Like, how about one not try to bake in assumptions about 1-cycle ALU and
> 2-cycle Load being practical?...
for the above to work::
ALU is < ½ cycle leaving ¼ cycle output drive and ¼ cycle input mux
SRAM is ½ cycle, AGEN to SRAM decode is ¼ cycle, SRAM output to shifter
is < ¼ cycle, and set-selection is ½ cycle; leaving ¼ cycle for output
drive.
> Vs, say, 2-cycle ALU ops and 3-cycle Loads; with an ideal of putting 5
> instructions between an instruction that generates a result and the
> instruction that consumes the result as this is more likely to work with
> in-order superscalar.
1-cycle ALU with 3 cycle LD is not very hard at 16-gates per cycle.
2-cycle LD is absolutely impossible with 1-cycle addr-in to data-out
SRAM. So, we generally consider any design with 2-cycle LD to be
frequency limited.
> But, then one runs into the issue that if a basic operation then
> requires a multi-op sequence, the implied latency goes up considerably
> (say, could call this "soft latency", or SL).
>
> So, for example, it means that, say:
> 2-instruction sign extension:
> RV working assumption: 2 cycles
> Hard latency (2c ALU): 4 cycles
> Soft latency: 12 cycles.
> For a 3-op sequence, the effective soft-latency goes up to 18, ...
One of the reasons a 16-gate design works better in practice than
a 12-gate design. And why a 1-cycle ALU, 3-cycle LD runs at higher
frequency.
> And, in cases where the soft-latency significantly exceeds the total
> length of the loop body, it is no longer viable to schedule the loop
> efficiently.
In software, there remains no significant problem running the loop
in HW.
> So, in this case, an indexed-load instruction has an effective 9c SL,
> whereas SLLI+ADD+LD has a 21 cycle SL.
3-cycle indexed LD with cache hit in may µArchitectures--with scaled
indexing. This is one of the driving influences of "raising" the
semantic content of LD/ST instructions to [Rbase+Rindex<<sc+Disp]
> where, in this case, the goal of something like the WEXifier is to
> minimize this soft-latency cost (in cases where a dependency is seen,
> any remaining soft-latency is counted as penalty).
>
> But, then again, maybe the concept of this sort of "soft latency" seems
> a bit alien.
Those ISAs without scaled indexing have longer effective latency through
cache than those with: those without full range Dsip have similar problems:
those without both are effectively adding 3-4 cycles to LD latency.
Which is why the size of the execution windows grew from 60-ish to 300-ish
to double performance--the ISA is adding latency and the size of execution
window is the easiest way to absorb such latency.
{{60-ish ~= Athlon; 300-ish ~= M4}}
> Granted, not sure how this maps over to OoO, but had noted that even
> with modern CPUs, there still seems to be benefit from assuming a sort
> of implicit high latency for instructions over assuming a lower latency.
Execution window size is how it maps.
> *1: Where people argue that if each vendor can do a CPU with their own
> custom ISA variants and without needing to license or get approval from
> a central authority, that invariably everything would decay into an
> incoherent mess where there is no binary compatibility between
> processors from different vendors (usual implication being that people
> are then better off staying within the ARM ecosystem to avoid RV's
> lawlessness).
RISC-V seems to be "eating" a year (or a bit more) to bring this mess into
a coherent framework.
>
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-02-21 01:00 -0600 |
| Message-ID | <10nble9$1261n$1@dont-email.me> |
| In reply to | #115065 |
On 2/20/2026 5:49 PM, MitchAlsup wrote:
>
> BGB <cr88192@gmail.com> posted:
>
>> On 2/19/2026 5:10 PM, John Dallman wrote:
>> ------------------------------------
>> This can be used to add resistance against stack-stomping via buffer
>> overflows, but is potentially risky with RISC-V:
>> AUIPC X1, AddrHi
>> JALR X0, AddrLo(X1)
>> Can nuke the process, when officially it is allowed (vs forcing the use
>> of a different register to encode a long branch).
>
> That should be:
> AUPIC x1,hi(offset)
> JALR x0,lo(offset)
>
> using:
> SETHI x1,AddrHi
> JALR x0,AddrLo
>
> would work.
>
Usual notation seems to be that AUIPC uses a direct-immediate notation
(eg "AUIPC X1, 0x12345"), and "JALR X0, 0x678(X1)".
Though, GAS and friends can use:
AUIPC X1, %hi(symbol)
JALR X0, X1, %lo(symbol)
Well, and for JALR:
JALR Xd, Disp(Xs)
JALR Xd, Xs, Disp
Being basically equivalent.
...
If expressing it using a symbol rather than a literal displacement...
But, either way, it is using X1 that was the relevant point here, which
is technically allowed in RISC-V, but would explode if one tries to
constrain X1 to being used as a link register and then also uses
enforced tag checking in this case.
In BGBCC's native ASM notation, the symbol case would typically be
expressed as:
BRA symbol
Which them implies the 2-op form if the "symbol is within +/- 1MB check"
fails. But, would differ in that this pseudo-op will stomp X5.
But, yeah, RISC-V ASM notation conventions seem to get a little
confusing sometimes...
But, errm, my point wasn't so much about RISC-V's ASM syntax patterns.
There is a non-zero risk though when one disallows uses that are
theoretically allowed in the ISA, even if GCC doesn't use them.
Though, the reason to sanity-check X1 is that it is pretty much
universally used as the link register, and sanitizing the link-register
can be used to trap on potential stack-corruption in buffer overflow
exploits (more so with a compiler that tends not to use stack canary
checks).
Well, and in terms of typical ASM notation, there is this mess:
(Rb) / @Rb / @(Rb) //load/store register
(Rb, Disp) / Disp(Rb) //load/store disp
@(Rb, Disp) / @(Disp, Rb) //load/store disp (but with @)
Then:
(Rb, Ri) //indexed (element sized index)
Ri(Rb) //indexed (byte-scaled index)
(Rb, Ri, Sc) //indexed with scale
Disp(Rb, Ri) //indexed with displacement
Disp(Rb, Ri, Sc) //indexed with displacement and scale
Then:
@Rb+ / (Rb)+ //post-increment
@-Rb / -(Rb) //pre-decrement
@Rb- / (Rb)- //post-decrement
@+Rb / +(Rb) //pre-increment
And, in some variants, all the registers prefixed with '%'.
Comparably, the Intel style notation is more consistent, but don't
necessarily want to also throw Intel notation into this particular mix.
Well, more so as there is an implicit visual hint, say in x86:
movl 128(%ebx), %eax
mov eax, [ebx+128]
Where the notation partly also keys one into the register ordering, but
if on had Intel style memory notation while using AT&T style ordering,
this would be a problem (confusing mess).
Well, or the other messy feature that BGBCC tries to infer the register
order based on which nmemonics are used:
OP Rd, Rs1, Rs2 //used in RV mnemonics dominate
OP Rs1, Rs2, Rd //otherwise
Likely, if [] notation were supported then it would likely signal "dest,
source" ordering (like Intel x86, and ARM), though in this case
[Rb+Disp] and [Rb,Disp] likely being treated as analogous.
But, alas, kind of a mess...
And, if trying to mix/match styles, "there be dragons here"...
> ---------------------
>> Like, how about one not try to bake in assumptions about 1-cycle ALU and
>> 2-cycle Load being practical?...
>
> for the above to work::
> ALU is < ½ cycle leaving ¼ cycle output drive and ¼ cycle input mux
> SRAM is ½ cycle, AGEN to SRAM decode is ¼ cycle, SRAM output to shifter
> is < ¼ cycle, and set-selection is ½ cycle; leaving ¼ cycle for output
> drive.
>
>> Vs, say, 2-cycle ALU ops and 3-cycle Loads; with an ideal of putting 5
>> instructions between an instruction that generates a result and the
>> instruction that consumes the result as this is more likely to work with
>> in-order superscalar.
>
> 1-cycle ALU with 3 cycle LD is not very hard at 16-gates per cycle.
> 2-cycle LD is absolutely impossible with 1-cycle addr-in to data-out
> SRAM. So, we generally consider any design with 2-cycle LD to be
> frequency limited.
>
My stuff mostly assumes:
ADD and similar: 2 cycles
Load: 3 cycles.
In this case, some 1 cycle ops exist:
MOV Rs, Rd / MV Xd, Xs
MOV Imm, Rd / LI Xd, Imm
For the RV and XG3 decoders, some special instructions are decoded as
one of the above:
ADDI Xd, Xs, 0 => MV
ADDI Xd, X0, Imm => LI
But, most remain as 2/3 cycle.
A few instructions had a 4 cycle latency, mostly those which combined a
Load with a format-conversion or similar.
>> But, then one runs into the issue that if a basic operation then
>> requires a multi-op sequence, the implied latency goes up considerably
>> (say, could call this "soft latency", or SL).
>>
>> So, for example, it means that, say:
>> 2-instruction sign extension:
>> RV working assumption: 2 cycles
>> Hard latency (2c ALU): 4 cycles
>> Soft latency: 12 cycles.
>> For a 3-op sequence, the effective soft-latency goes up to 18, ...
>
> One of the reasons a 16-gate design works better in practice than
> a 12-gate design. And why a 1-cycle ALU, 3-cycle LD runs at higher
> frequency.
>
OK.
I ended up going for a slightly lower clock speed and slightly more
complex operations because often this resulted in better performance.
And, while I could probably run an RV32IM core at 100 MHz, I would need
to pay in other areas.
>> And, in cases where the soft-latency significantly exceeds the total
>> length of the loop body, it is no longer viable to schedule the loop
>> efficiently.
>
> In software, there remains no significant problem running the loop
> in HW.
>
Another traditional option is modulo scheduling, but actually doing so
in the compiler is more complex (and BGBCC does not do so).
Can often do a "poor man's" version in C, which while a less elegant
solution, often works out better in practice.
One can try to effectively unroll the loop enough that the latency can
be covered efficiently, but then the issue may become one of running out
of working registers, and one doesn't want to unroll so much that the
code starts thrashing, which tends to hurt worse than the potential loss
of ILP by being narrower.
>> So, in this case, an indexed-load instruction has an effective 9c SL,
>> whereas SLLI+ADD+LD has a 21 cycle SL.
>
> 3-cycle indexed LD with cache hit in may µArchitectures--with scaled
> indexing. This is one of the driving influences of "raising" the
> semantic content of LD/ST instructions to [Rbase+Rindex<<sc+Disp]
>
Yeah, pretty much, or at lease [Rb+Ri<<Sc], but more of the full
[Rb+Ri<<Sc+Disp] scenario often being uncommon IME.
Well, with a possible exception of [GP+Ri<<Sc+Disp] which would see a
localized spike due to:
someGlobalArray[index]
As-is, this case tends to manifest in my case as, say:
LEA.Q (GP, Disp), R5
MOV.Q (R5, R10), R11
>> where, in this case, the goal of something like the WEXifier is to
>> minimize this soft-latency cost (in cases where a dependency is seen,
>> any remaining soft-latency is counted as penalty).
>>
>> But, then again, maybe the concept of this sort of "soft latency" seems
>> a bit alien.
>
> Those ISAs without scaled indexing have longer effective latency through
> cache than those with: those without full range Dsip have similar problems:
> those without both are effectively adding 3-4 cycles to LD latency.
>
> Which is why the size of the execution windows grew from 60-ish to 300-ish
> to double performance--the ISA is adding latency and the size of execution
> window is the easiest way to absorb such latency.
> {{60-ish ~= Athlon; 300-ish ~= M4}}
>
OK.
FWIW, there are reasons I have indexed addressing and jumbo-prefixes for
larger immediate values and displacements.
But, seemingly, the idea of deviating from 2R1W and 16/32 instruction
encodings fills the RISC-V people with fear.
>> Granted, not sure how this maps over to OoO, but had noted that even
>> with modern CPUs, there still seems to be benefit from assuming a sort
>> of implicit high latency for instructions over assuming a lower latency.
>
> Execution window size is how it maps.
>
OK.
>> *1: Where people argue that if each vendor can do a CPU with their own
>> custom ISA variants and without needing to license or get approval from
>> a central authority, that invariably everything would decay into an
>> incoherent mess where there is no binary compatibility between
>> processors from different vendors (usual implication being that people
>> are then better off staying within the ARM ecosystem to avoid RV's
>> lawlessness).
>
> RISC-V seems to be "eating" a year (or a bit more) to bring this mess into
> a coherent framework.
Yeah, and while ARC drags their feet,
Qualcomm/Huawei/ByteDance/T-Head/... each go off and do similar things
but in different ways...
If I were organizing it, would likely handle it differently, by having a
nested structure:
Formal / Frozen //parts of the ISA that are fully settled.
Semi-formal / non-frozen //details subject to change.
provisional / experimental //very unstable.
vendor-specific //excluded from standardization.
In the provisional space, encodings could be defined, but could be
reclaimed if the feature is "dead"; but would be in encoding blocks
where they could be standardized later.
The main difference being that the provisional space, there would be a
semi-official website listing registered encodings. Rather than these
encodings being scattered in the ISA documentation for the various
vendor processors (requiring digging though a bunch of PDFs and so on to
try to figure out which encodings are already in-use).
Then sometimes there are encodings that are defined in way that don't
make sense, like apparently there is a RISC-V core from MIPS
Technologies, where they went and added Load/Store Pair, but with two
data source/dest register fields and a very small displacement.
This contrast strongly with, say, having even-pair registers and a
non-tiny displacement (displacement needs to be at least big enough to
cover a typical load/store area for a prolog/epilog).
I had at first reused LDU/SDU encodings, but then the proposal for
Load/Store indexed didn't go with my encoding scheme, but a different
one that also used LDU/SDU (but, maybe this is ultimately a better place
to put them; vs my approach of shoving them in an odd corner within the
'A' extension's block).
I ended up migrating Load/Store pair to the FLQ/FSQ encodings, partly as
I had no intention to implement the Q extension as-is (and I needed
somewhere to relocate them to). But, then this led to the "Pseudo Q" idea.
In my case, there is XG3, but I consider this in a different category
as, while it retains compatibility with RV64G and partial with RV64GC
(mostly by providing for interoperability); it is in some ways a notable
departure from "pure" RISC-V (well, in that modes, tagged pointers, and
swapping out RV-C encodings for a different 32-bit encoding space, are
not particularly small additions if one didn't already have a CPU
designed in this way).
...
>>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-02-21 20:15 +0000 |
| Message-ID | <1771704934-5857@newsgrouper.org> |
| In reply to | #115067 |
BGB <cr88192@gmail.com> posted:
> On 2/20/2026 5:49 PM, MitchAlsup wrote:
> > ----------------------------
>
> There is a non-zero risk though when one disallows uses that are
> theoretically allowed in the ISA, even if GCC doesn't use them.
This is why one must decode all 32-bits of each instruction--so that
there is no hole in the decoder that would allow the core to do some-
thing not directly specified in ISA. {And one of the things that make
an industrial quality ISA so hard to fully specify.}}
---------------------
>
> Well, and in terms of typical ASM notation, there is this mess:
> (Rb) / @Rb / @(Rb) //load/store register
> (Rb, Disp) / Disp(Rb) //load/store disp
> @(Rb, Disp) / @(Disp, Rb) //load/store disp (but with @)
> Then:
> (Rb, Ri) //indexed (element sized index)
> Ri(Rb) //indexed (byte-scaled index)
> (Rb, Ri, Sc) //indexed with scale
> Disp(Rb, Ri) //indexed with displacement
> Disp(Rb, Ri, Sc) //indexed with displacement and scale
> Then:
> @Rb+ / (Rb)+ //post-increment
> @-Rb / -(Rb) //pre-decrement
> @Rb- / (Rb)- //post-decrement
> @+Rb / +(Rb) //pre-increment
>
> And, in some variants, all the registers prefixed with '%'.
Leading to SERIAL DECODE--which is BAD.
-----------------------
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-02-21 14:59 -0600 |
| Message-ID | <10nd6ku$1imqp$1@dont-email.me> |
| In reply to | #115074 |
On 2/21/2026 2:15 PM, MitchAlsup wrote:
>
> BGB <cr88192@gmail.com> posted:
>
>> On 2/20/2026 5:49 PM, MitchAlsup wrote:
>>> ----------------------------
>>
>> There is a non-zero risk though when one disallows uses that are
>> theoretically allowed in the ISA, even if GCC doesn't use them.
>
> This is why one must decode all 32-bits of each instruction--so that
> there is no hole in the decoder that would allow the core to do some-
> thing not directly specified in ISA. {And one of the things that make
> an industrial quality ISA so hard to fully specify.}}
> ---------------------
Sometimes there is a tension:
What is theoretically allowed in the ISA;
What is the theoretically expected behavior in some abstract model;
What stuff is actually used by compilers;
What features or behaviors does one want;
...
Implementing RISC-V strictly as per an abstract model would limit both
efficiency and hinder some use-cases.
Then it comes down to "what do compilers do" and "what unintentional
behaviors could an ASM programmer stumble onto unintentionally".
Stuff like "Program misbehaves or crashes on a fairly mundane piece of
code" are preferably avoided.
Alternatives being, say:
Define behaviors what programs are allowed to rely on;
Be slightly conservative with how one defines edge cases;
Avoid over-defining things too far outside the scope of what is actually
relevant.
Sometimes design elegance can become a trap.
But, OTOH, having special cases for some instructions based on which
registers or immediate values are used isn't exactly clean or elegant.
Like, yeah:
Using X0 or X1 here invokes magic;
Instruction doesn't work unless X0 or X1;
...
>>
>> Well, and in terms of typical ASM notation, there is this mess:
>> (Rb) / @Rb / @(Rb) //load/store register
>> (Rb, Disp) / Disp(Rb) //load/store disp
>> @(Rb, Disp) / @(Disp, Rb) //load/store disp (but with @)
>> Then:
>> (Rb, Ri) //indexed (element sized index)
>> Ri(Rb) //indexed (byte-scaled index)
>> (Rb, Ri, Sc) //indexed with scale
>> Disp(Rb, Ri) //indexed with displacement
>> Disp(Rb, Ri, Sc) //indexed with displacement and scale
>> Then:
>> @Rb+ / (Rb)+ //post-increment
>> @-Rb / -(Rb) //pre-decrement
>> @Rb- / (Rb)- //post-decrement
>> @+Rb / +(Rb) //pre-increment
>>
>> And, in some variants, all the registers prefixed with '%'.
>
> Leading to SERIAL DECODE--which is BAD.
> -----------------------
Depends on what ISA the ASM syntax is actually attached to...
If it is a VAX, yeah, true enough.
Seemingly most of these syntax variants go back to PDP-11 and VAX origins.
Then some quirks, like '%' on register names, apparently mostly came
from the M68K branch:
PDP/VAX: No '%'
M68K: Added '%'
GAS on x86: Mostly kept using M68K notation.
Then apparently the '@' thing was partly a thing originating either in
Hitachi or Texas Instruments (along with putting '.' in many of the
instruction mnemonics).
So, if working backwards, could drop all the '@' variants, along with
'%', ...
Where, apparently, the syntax scheme I had mostly ended up using for
BGBCC and my own stuff, ended up partly mutating back towards the
original PDP/VAX style syntax.
Namely, was using:
(Rb)
(Rb, Rb)
(Rb, Disp) | Disp(Rb)
...
Though, had mostly kept the dotted names vs reverting to dot-free names.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-02-21 22:56 +0000 |
| Message-ID | <1771714607-5857@newsgrouper.org> |
| In reply to | #115079 |
BGB <cr88192@gmail.com> posted:
> On 2/21/2026 2:15 PM, MitchAlsup wrote:
> >
> > BGB <cr88192@gmail.com> posted:
> >
> >> On 2/20/2026 5:49 PM, MitchAlsup wrote:
> >>> ----------------------------
> >>
> >> There is a non-zero risk though when one disallows uses that are
> >> theoretically allowed in the ISA, even if GCC doesn't use them.
> >
> > This is why one must decode all 32-bits of each instruction--so that
> > there is no hole in the decoder that would allow the core to do some-
> > thing not directly specified in ISA. {And one of the things that make
> > an industrial quality ISA so hard to fully specify.}}
> > ---------------------
>
> Sometimes there is a tension:
> What is theoretically allowed in the ISA;
> What is the theoretically expected behavior in some abstract model;
> What stuff is actually used by compilers;
> What features or behaviors does one want;
> ...
Whether your ISA can be attacked with Spectré and/or Meltdown;
Whether your DFAM can be attacked with RowHammer;
Whether your call/return interface can be attacked with:
{ Return Orienter Programmeing, Buffer Overflows, ...}
That is; whether you care if your system provides a decently robust
programming environment.
I happen to care. Apparently, most do not.
> Implementing RISC-V strictly as per an abstract model would limit both
> efficiency and hinder some use-cases.
One can make an argument that it is GOOD to limit attack vectors, and
provide a system that is robust in the face of attacks.
> Then it comes down to "what do compilers do" and "what unintentional
> behaviors could an ASM programmer stumble onto unintentionally".
Nïeve at best.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-02-24 17:32 -0600 |
| Message-ID | <10nlcnj$aq3i$1@dont-email.me> |
| In reply to | #115081 |
On 2/21/2026 4:56 PM, MitchAlsup wrote:
>
> BGB <cr88192@gmail.com> posted:
>
>> On 2/21/2026 2:15 PM, MitchAlsup wrote:
>>>
>>> BGB <cr88192@gmail.com> posted:
>>>
>>>> On 2/20/2026 5:49 PM, MitchAlsup wrote:
>>>>> ----------------------------
>>>>
>>>> There is a non-zero risk though when one disallows uses that are
>>>> theoretically allowed in the ISA, even if GCC doesn't use them.
>>>
>>> This is why one must decode all 32-bits of each instruction--so that
>>> there is no hole in the decoder that would allow the core to do some-
>>> thing not directly specified in ISA. {And one of the things that make
>>> an industrial quality ISA so hard to fully specify.}}
>>> ---------------------
>>
>> Sometimes there is a tension:
>> What is theoretically allowed in the ISA;
>> What is the theoretically expected behavior in some abstract model;
>> What stuff is actually used by compilers;
>> What features or behaviors does one want;
>> ...
> Whether your ISA can be attacked with Spectré and/or Meltdown;
> Whether your DFAM can be attacked with RowHammer;
> Whether your call/return interface can be attacked with:
> { Return Orienter Programmeing, Buffer Overflows, ...}
>
> That is; whether you care if your system provides a decently robust
> programming environment.
>
> I happen to care. Apparently, most do not.
>
There is a way at least, as noted, to optionally provide some additional
protection against buffer overflows (in a compiler that does not use
stack canaries, eg, GCC).
But, as-noted, it disallows AUIPC+JALR to use X1 in this way.
Even if compiler output does generally use X5 for this case.
>> Implementing RISC-V strictly as per an abstract model would limit both
>> efficiency and hinder some use-cases.
>
> One can make an argument that it is GOOD to limit attack vectors, and
> provide a system that is robust in the face of attacks.
>
This was a partial motivation for deviating from the abstract model.
Deviating from the abstract model in some cases allows closing down
attack vectors.
>> Then it comes down to "what do compilers do" and "what unintentional
>> behaviors could an ASM programmer stumble onto unintentionally".
>
> Nïeve at best.
>
Possibly, but there are some things a case can be made for disallowing:
Using X1 for things other than as a Link Register;
Disallowing JAL and JALR with Rd other than X0 or X1;
Disallowing most instructions, other than a few special cases, from
having X0 or X1 as a destination.
RISC-V has a lot of "Hint" instructions, but a case can be made for
making many of them illegal (where trying to use them will result in an
exception; rather than simply ignoring them).
In some other cases, it may be justified to disallow (and generate an
exception for) things which can be expressed in the ISA, technically,
but don't actually make sense for a program to make use of (some amount
of edge cases that result in NOPs, or sometimes non-NOP behaviors which
don't actually make sense); but are more likely to appear in undesirable
cases (such as the CPU executing random garbage as instructions).
...
Say, for example, the normal/canonical RISC-V NOP can't be expressed
without 0x00 (NUL) bytes, whereas many other HINT type instructions can
be encoded without NUL bytes.
If someone can't as easily compose a NUL-byte-free NOP-slide, it makes
it harder to inject shell code via ASCII strings (as does hindering the
ability to tamper with return addresses), avoiding casual use of RWX
memory, etc.
The JAL/JALR Rd=X0|X1 only case, is one of those cases where one can
argue a use-case exists, but is so rarely used as to make its native
existence in hardware (or in an ISA design) difficult to justify. In
effect, supporting it in HW adds non-zero cost, programs don't actually
use it, and it burns 4 bits of encoding space you aren't really getting
back (and they could have used it for something more useful, say, making
JAL has a 16MB range or something).
While one can't change the encoding now, they can essentially just turn
the generic case into a trap and call it done.
...
Though. yes, even if one nails all this down, there are still often
other (nor-memory) attack vectors (such as attacking program logic).
Saw something not too long ago where there was an RCE exploit for some
random system (which operated via an HTTP servers and HTTP requests; I
think for "enterprise supply-chain stuff" or something), where the
exploit was basically the ability to execute arbitrary shell commands
via expressing them as an HTTP request (with said server effectively
running as "setuid root" or similar).
Or, basically, something so insecure that someone could (in theory) hack
it by typing specific URLs into a web browser or something (or maybe
using "wget" via a bash script).
Like, something like:
http : //someaddress/cgi-bin/system.cgi?cmd=sshd%20...
(Say, spawn an SSH server so they can stop using HTTP requests).
Leaving people to just ROFLOL about how bad it was...
And, how did the original product operate?... Mostly by sending
unsecured shell commands over HTTP.
So, alas...
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-02-22 21:52 +0000 |
| Message-ID | <memo.20260222215250.15252e@jgd.cix.co.uk> |
| In reply to | #115064 |
In article <10nak0a$nrac$2@dont-email.me>, cr88192@gmail.com (BGB) wrote: > Does imply that my younger self was notable, and not seen as just > some otherwise worthless nerd. Educators who are any good notice the weird kids who are actually smart. > For 128 predicate registers, this part doesn't make as much sense: I suspect they wanted to re-use some logic. The tricks Itanium could do with combinations of predicate registers were pretty weird. There was at least one instruction for manipulating them which I was entirely unable to understand, with the manual in front of me and pencil and paper to try examples. Fortunately, it never occurred in code generated by any of the compilers I used. > *1: Where people argue that if each vendor can do a CPU with their > own custom ISA variants and without needing to license or get > approval from a central authority, that invariably everything would > decay into an incoherent mess where there is no binary > compatibility between processors from different vendors (usual > implication being that people are then better off staying within > the ARM ecosystem to avoid RV's lawlessness). The importance of binary compatibility is very much dependent on the market sector you're addressing. It's absolutely vital for consumer apps and games. It's much less important for current "AI" where each vendor has their own software stack anyway. RISC-V seems to be far more interested in the latter at present. John
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-02-26 14:54 -0600 |
| Message-ID | <10nqc67$1ut7a$1@dont-email.me> |
| In reply to | #115101 |
On 2/22/2026 3:52 PM, John Dallman wrote: > In article <10nak0a$nrac$2@dont-email.me>, cr88192@gmail.com (BGB) wrote: > >> Does imply that my younger self was notable, and not seen as just >> some otherwise worthless nerd. > > Educators who are any good notice the weird kids who are actually smart. > Sometimes I question if I really am though. Like, some evidence says I am, but by most metrics of "life success" I have done rather poorly. And, in middle and high-school, they just sorta forced me to sit through normal classes (which sucked really hard). Well, and I apparently missed the point of school, thinking it was more of an endurance thing with sort of a vague pretense of education (and I probably would have learned more if they just let me spend the time doing whatever else). ... But, it seems like a case of: By implication, I am smart, because if I wasn't, even my own (sometimes pointless) hobby interests would have been out of reach. Like, not a world of difficulty justifying them, or debating whether or not something is worth doing, but likely not something someone could do at all. Or, maybe, like encountering things that seem confusing isn't such a rare experience (or that people have learned how to deal more productively with things they can see but don't understand?...). But, there is a thing I have noted: I had a few times mentioned to people about finding that certain AIs had gotten smart enough to start understanding how a 5/6 bit finite state machine to predict repeating 1-4 bit patterns would be constructed. Then, I try to describe it, and then realize that for the people I try to mention it to, it isn't that they have difficulty imagining how one would go about filling in the table and getting all of the 4 bit patterns to fit into 32 possible states. Many seem to have difficulty understanding how such a finite state machine would operate in the first place. Even if, it seems like this part seems like something that pretty much anyone should be able to understand. Initially, I had used this as a test case for the AIs because it posed "moderate difficulty" for problems which could be reasonably completely described in a chat prompt (and is not overly generic). Nevermind if it is still a pain to generate tables by hand, and my attempts at hand-generated tables have tended to have worse adaptation rates than those generated using genetic algorithms (can be more clean looking, but tend to need more input bits to reach the target state if the pattern changes). Sometimes I feel like a poser. Other things, it seems, I had taken for granted. Seems sometimes if I were "actually smart", would have figured out some way to make better and more efficient use of my span of existence. >> For 128 predicate registers, this part doesn't make as much sense: > > I suspect they wanted to re-use some logic. > > The tricks Itanium could do with combinations of predicate registers were > pretty weird. There was at least one instruction for manipulating them > which I was entirely unable to understand, with the manual in front of me > and pencil and paper to try examples. Fortunately, it never occurred in > code generated by any of the compilers I used. > Possibly. I had also looked into a more limited set of predicate registers at one point, but this fizzled in favor of just using GPRs. So, as noted: I have 1 predicate bit (T bit); Had looked into expanding it to 2 predicate bits (using an S bit as a second predicate), but this went nowhere. Had at another time looked into schemes for having a combination of 8x 1-bit predicate registers with operations that could update the T bit. My initial attempt was an x87 style stack machine, and this was a fail. A later design attempt would have added U0..U7 as 8x 1-bit registers. Though, just ended up instead going with GPRs for this (following a pattern more like RISC-V). Though, in XG3, some operation can be directed at R0/XO to update the T bit. In RV-like terms: SLT, SGE, SEQ, SNE, SLTU, SGEU AND, OR //more recent Where, 'AND' partly takes over the role of the 2R "TST" instruction. AND X0, X10, X11 Though, for now using AND/OR directed to X0 for bitwise predication will be specific to XG3 encodings. Say, because someone in their great wisdom decided to use ORI and similar directed to X0 in the RISC-V encoding space to encode the prefetch instructions. Personally, I would have used, say: LB X0, Disp(Xs) Or similar, since presumably any sane prefetch needs to be able to access the memory it is prefetching from, and load-as-prefetch makes more sense to me than ORI as prefetch, but alas... Then again, LHU/LWU encoding with X0 as an implicit branch for an optional feature is similarly suspect (and carries the risk of "what if someone else puts some other behavior here"?...). >> *1: Where people argue that if each vendor can do a CPU with their >> own custom ISA variants and without needing to license or get >> approval from a central authority, that invariably everything would >> decay into an incoherent mess where there is no binary >> compatibility between processors from different vendors (usual >> implication being that people are then better off staying within >> the ARM ecosystem to avoid RV's lawlessness). > > The importance of binary compatibility is very much dependent on the > market sector you're addressing. It's absolutely vital for consumer apps > and games. It's much less important for current "AI" where each vendor > has their own software stack anyway. RISC-V seems to be far more > interested in the latter at present. > Probably true... Likely also the space of customized CPU design / experimentation is much more accepting of fragmentation, where in more mainline "user oriented" hardware, it would be a bigger issue. Still I sit around waiting to see if the whole RISC-V indexed load thing (zilx) becomes an actual extension. In my working version, did end up going and implementing support for it within BGBCC (and in my emulator and CPU core), but am still partly waiting on whether it gains actual approval from the ARC. Most recent news I saw was basically one of the people involved complaining that it would show no significant performance benefit for SPEC running on OoO processor implementations. Say, vs Doom on an in-order CPU, where it makes a much bigger difference. Sometimes, maybe, SPEC on high-end CPUs should not be the primary arbiter (more so when most of the CPUs are likely to end up in segments where in-order tends to dominate). ...
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-02-27 19:27 +0000 |
| Message-ID | <1772220441-5857@newsgrouper.org> |
| In reply to | #115155 |
BGB <cr88192@gmail.com> posted:
> On 2/22/2026 3:52 PM, John Dallman wrote:
> > In article <10nak0a$nrac$2@dont-email.me>, cr88192@gmail.com (BGB) wrote:
> >
> >> Does imply that my younger self was notable, and not seen as just
> >> some otherwise worthless nerd.
> >
> > Educators who are any good notice the weird kids who are actually smart.
> >
>
> Sometimes I question if I really am though.
>
> Like, some evidence says I am, but by most metrics of "life success" I
> have done rather poorly.
>
>
> And, in middle and high-school, they just sorta forced me to sit through
> normal classes (which sucked really hard)
In my case, I remember sitting in the back of advanced algebra class
(mostly senior HS people, me a sophomore) doing chemistry homework while
vaguely listening to the teacher fail to get various students to solve
a typical algebra problem. Then she called on me, I looked up at the board
and in less than a second I rattled off the answer skipping 5 steps along
the way. Moral, don't be bored in class, do something useful instead.
> Well, and I apparently missed
> the point of school, thinking it was more of an endurance thing with
> sort of a vague pretense of education (and I probably would have learned
> more if they just let me spend the time doing whatever else).
For most people, school attempts to give the students just enough knowledge
that they are not burdens on society.
-------------------------
> > The tricks Itanium could do with combinations of predicate registers were
> > pretty weird. There was at least one instruction for manipulating them
> > which I was entirely unable to understand, with the manual in front of me
> > and pencil and paper to try examples. Fortunately, it never occurred in
> > code generated by any of the compilers I used.
It could have been a case where the obvious logic decoding "that" field in
the instruction allowed for "a certain pattern" to perform what they described
in the spec. I did some of this in Mc 88100, and this is what taught me never
to do it again or allow anyone else to do it again.
> Possibly.
>
> I had also looked into a more limited set of predicate registers at one
> point, but this fizzled in favor of just using GPRs.
>
> So, as noted:
> I have 1 predicate bit (T bit);
> Had looked into expanding it to 2 predicate bits (using an S bit as a
> second predicate), but this went nowhere.
I have tried several organizations over the last 40 years of practice::
In my Humble and Honest Opinion, the only constructs predicates should
support are singular comparisons and comparisons using && and || with
deMoganizing logic {~}--not because other forms are unuseful, but be-
cause those are the constructs programmers use writing code.
[toc] | [prev] | [next] | [standalone]
Page 14 of 46 — ← Prev page 1 … 12 13 [14] 15 16 … 46 Next page →
Back to top | Article view | comp.arch
csiph-web