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 45 of 46 — ← Prev page 1 … 43 44 [45] 46 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-11-28 07:21 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <2025Nov28.082114@mips.complang.tuwien.ac.at> |
| In reply to | #114190 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>scott@slp53.sl.home (Scott Lurndal) posted:
>
>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>> >My 66000 ENTER and EXIT instruction use SP == R31 implicitly. But,
>> >instead of giving it a number of registers, there is a start register
>> >and a stop register, so 1-to-32 regsiters can be saved/restored. The
>> >immediate contains how much stack space to allocate/deallocate.
>>
>> That seems both confining for the compiler designers and less
>> useful than the VAX-11 register mask stored in the instruction stream
>> at the function entry point(s).
>
>We, and by that I mean Brian, have not found that so. In the early stages
>we did see a bit of that, and then Brian found a way to allocate registers
>from R31-down-to-R16 that fit the ENTER/EXIT model and we find essentially
>nothing (that is no more instructions in the stream than necessary).
>
>Part of the distinction is::
>a) how arguments/results are passed to/from subroutines.
>b) having a minimum of 7-temporary registers at entry point.
>c) how the stack frame is designed/allocated wrt:
> 1) my arguments and my results,
> 2) his arguments and his results,
> 3) varargs,
> 4) dynamic arrays on stack,
> 5) stack frame allocation at ENTER,
>d) freedom to use R30 as FP or as joe-random-register.
>
>These were all co-designed together, after much of the instruction
>emission logic was sorted out.
What is "my" and "his"?
>Consider this as a VAX CALL model except that the mask was replaced by
>a list of registers, which were then packed towards R31 instead of a bit
>vector.
Do you need both a start and a stop register?
As far as I understand, ENTER is at the entry point of the callee, and
EXIT is before the return or tail call; actually, the tail call case
answers my question above:
If the tail-caller has m callee-saved registers and the tail-callee
has n callee-saved registers, then
if m>n, generate an EXIT that restores the m-n registers;
if m<n, generate an ENTER that saves the n-m registers;
Generate a jump to behind the ENTER instruction of the callee.
That is, assuming that the tail-callee is in the same compilation unit
as the tail-caller; otherwise the tail-caller needs to do a full EXIT
and then jump to the normal entry point of the tail-callee, which does
a full ENTER.
And in these ENTERs and EXITs, you don't end (or start) at the same
point as in the regular ENTERs and EXITs.
And yes, for saving the callee-saved registers I don't see a need for
a mask. For caller-saved registers, it's different. Consider:
long foo(...)
{
long x = ...;
long y = ...;
long z = ...;
if (...) {
bar(...);
x = ...;
} else if (...){
baz(...);
y = ...;
} else {
bla(...);
z = ...;
}
return x+y+z;
}
Here one could put x, y, and z in callee-saved registers (and use ENTER
and EXIT for them), but that would need to save and later restore
three registers on every path through foo().
Or one could put it in caller-saved registers and save only two
registers on every path through foo(). Then one needs to save y and z
around the call to bar(), x and z around the call to baz(), and x and
y around the call to bla(). For any register allocation, in one of
the cases the registers to be saved are not contiguous. So if one
would use a save-multiple or load-multiple instruction for that, a
mask would be needed.
- 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 | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-28 20:05 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <1764360300-5857@newsgrouper.org> |
| In reply to | #114203 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >
> >scott@slp53.sl.home (Scott Lurndal) posted:
> >
> >> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >> >My 66000 ENTER and EXIT instruction use SP == R31 implicitly. But,
> >> >instead of giving it a number of registers, there is a start register
> >> >and a stop register, so 1-to-32 regsiters can be saved/restored. The
> >> >immediate contains how much stack space to allocate/deallocate.
> >>
> >> That seems both confining for the compiler designers and less
> >> useful than the VAX-11 register mask stored in the instruction stream
> >> at the function entry point(s).
> >
> >We, and by that I mean Brian, have not found that so. In the early stages
> >we did see a bit of that, and then Brian found a way to allocate registers
> >from R31-down-to-R16 that fit the ENTER/EXIT model and we find essentially
> >nothing (that is no more instructions in the stream than necessary).
> >
> >Part of the distinction is::
> >a) how arguments/results are passed to/from subroutines.
> >b) having a minimum of 7-temporary registers at entry point.
> >c) how the stack frame is designed/allocated wrt:
> > 1) my arguments and my results,
> > 2) his arguments and his results,
> > 3) varargs,
> > 4) dynamic arrays on stack,
> > 5) stack frame allocation at ENTER,
> >d) freedom to use R30 as FP or as joe-random-register.
> >
> >These were all co-designed together, after much of the instruction
> >emission logic was sorted out.
>
> What is "my" and "his"?
My arguments are the arguments to me (this subroutine)
His arguments are the arguments to subroutines I call
> >Consider this as a VAX CALL model except that the mask was replaced by
> >a list of registers, which were then packed towards R31 instead of a bit
> >vector.
>
> Do you need both a start and a stop register?
Consider:
ENTER R19,R31,#constant
versus
ENTER R19,R0,#constant
The former saves R19-through-R31 and leave the return address in R0
The later saves R19-through-R0 leaving the return address on the stack.
This should illustrate that the stopping register is compiler chosen.
It is obvious that the starting point should be compiler chosen.
Thus, start and stop are independent.
Now Consider:
ENTER R19,R9,#constant
Not only are R19-R0 saved on the stack, R1-R9 are saved on the stack
immediately preceding the memory based arguments, thus varargs only
changes the stop register in ENTER; and this makes a linear vector
of arguments for valist.
> As far as I understand, ENTER is at the entry point of the callee, and
> EXIT is before the return or tail call; actually, the tail call case
> answers my question above:
>
> If the tail-caller has m callee-saved registers and the tail-callee
> has n callee-saved registers, then
>
> if m>n, generate an EXIT that restores the m-n registers;
> if m<n, generate an ENTER that saves the n-m registers;
> Generate a jump to behind the ENTER instruction of the callee.
The above sounds complicated enough to simply avoid the tail-call
optimization it the arguments lists are not similar enough.
> That is, assuming that the tail-callee is in the same compilation unit
> as the tail-caller; otherwise the tail-caller needs to do a full EXIT
> and then jump to the normal entry point of the tail-callee, which does
> a full ENTER.
>
> And in these ENTERs and EXITs, you don't end (or start) at the same
> point as in the regular ENTERs and EXITs.
>
> And yes, for saving the callee-saved registers I don't see a need for
> a mask. For caller-saved registers, it's different. Consider:
>
> long foo(...)
> {
> long x = ...;
> long y = ...;
> long z = ...;
> if (...) {
> bar(...);
> x = ...;
> } else if (...){
> baz(...);
> y = ...;
> } else {
> bla(...);
> z = ...;
> }
> return x+y+z;
> }
>
> Here one could put x, y, and z in callee-saved registers (and use ENTER
> and EXIT for them), but that would need to save and later restore
> three registers on every path through foo().
>
> Or one could put it in caller-saved registers and save only two
> registers on every path through foo(). Then one needs to save y and z
> around the call to bar(), x and z around the call to baz(), and x and
> y around the call to bla(). For any register allocation, in one of
> the cases the registers to be saved are not contiguous. So if one
> would use a save-multiple or load-multiple instruction for that, a
> mask would be needed.
There is a delicate balance between callee-save and caller-save
registers. In many situations caller-save is better (counting
instructions) but callee-save is better (counting cycles--mostly
due to second order cache effects).
> - anton
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-11-28 06:45 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10gbgf6$24ur9$1@dont-email.me> |
| In reply to | #114186 |
Scott Lurndal <scott@slp53.sl.home> schrieb: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> >>Robert Finch <robfi680@gmail.com> posted: >> > >>> The Qulps PUSH and POP instructions have room for six register fields. >>> Should one of the fields be used to identify the stack pointer register >>> allowing five registers to be pushed or popped? Or should the stack >>> pointer register be assumed so that six registers may be pushed or popped? >> >>My 66000 ENTER and EXIT instruction use SP == R31 implicitly. But, >>instead of giving it a number of registers, there is a start register >>and a stop register, so 1-to-32 regsiters can be saved/restored. The >>immediate contains how much stack space to allocate/deallocate. > > That seems both confining for the compiler designers and less > useful than the VAX-11 register mask stored in the instruction stream > at the function entry point(s). That's the nice thing if the ISA, the ABI including calling convention and the compiler are designed together - this allows ENTER and EXIT to work just as well, without needing the full generality. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-11-26 18:19 -0500 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10g81u5$sqt2$1@dont-email.me> |
| In reply to | #114182 |
On 2025-11-26 3:57 p.m., MitchAlsup wrote:
>
> Robert Finch <robfi680@gmail.com> posted:
>
>>> In this case, put the cause in a container the instruction drags down
>>> the pipe, and retrieve it when you do have address access to where it
>>> needs to go.
>>
>> I may change things to pass the address around in the float package.
>> Putting the address into the NaN later may cause issues with timing. It
>> adds a mux into things. May be better to use the original NaN mux in the
>> float modules. May call it a NaN identity field instead of an address.
>
> For example: when a My 66000 instruction needs to raise an exception
> the Inst *I argument contains a field I->raised which is set (1<<excpt)
> and at the end of the pipe (at retire), t->raised |= I->raised. Where
> we have a *t there is also t->ip. So, you don't have to drag Thread *t
> through all the subroutine calls, but you can easily access t->raised
> at the point you do have access to t->ip.
>
Had trouble reading that, sounds like goobly-goop. But I believe I
figured it out.
Sounds like the address is inserted at the end of the pipe which I am
sure is not the case.
I figured this out: the NaN address must be embedded in the result by
the time the result updates the bypass network and registers so that it
is available to other instructions.
The address is available at the start of the calc from the reservation
station entry. Me thinks it must be embedded when the NaN result status
is set, provided there is not already a NaN. The existing (first) NaN
must propagate through.
>> Modified NaN support in the float package to store to the HOBs.
>>
>> Survey says:
>>
>> The Qulps PUSH and POP instructions have room for six register fields.
>> Should one of the fields be used to identify the stack pointer register
>> allowing five registers to be pushed or popped? Or should the stack
>> pointer register be assumed so that six registers may be pushed or popped?
>
> My 66000 ENTER and EXIT instruction use SP == R31 implicitly. But,
> instead of giving it a number of registers, there is a start register
> and a stop register, so 1-to-32 regsiters can be saved/restored. The
> immediate contains how much stack space to allocate/deallocate.
>
> {{when Safe-Stack is enabled:: Rstart-to-R0 are placed on the inaccessible
> stack, while R1-to-Rstop are placed on the normal stack.}}
>
> Because the stack is always DoubleWord aligned, the 3-LoBs of the
> immediate are used to indicate "special" activities on a couple of
> registers {R0, R31, R30}, R31 is rarely saves and reloaded from Stack
> but just returned to its previous value by integer arithmetic. FP can
> be updated or it can be treated like "just another register". R0 can
> be loaded directly to t->ip, or loaded into R0 for stack walk-backs.
>
> The corresponding LDM and STM are seldom used.
>
I ran out of micro-ops for ENTER and EXIT, so they only save the LR and
FP (on the safe stack). A separate PUSH/POP on safe stack instruction is
used.
I figured LDM and STM are not used often enough. PUSH / POP is used in
many places LDM / STM might be.
For context switching a whole bunch of load / store instructions are
used. There is context switching in only a couple of places.
>> I think the SP should be identified as PUSH / POP would be the only
>> instructions assuming the SP register. Otherwise any register could be
>> chosen by the compiler.
>
> I started with that philosophy--and begrudgingly went away from it as
> a) the compiler took form
> b) we started adding instructions to ISA to remove instructions from
> code footprint.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-27 00:08 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <1764202099-5857@newsgrouper.org> |
| In reply to | #114189 |
Robert Finch <robfi680@gmail.com> posted:
> On 2025-11-26 3:57 p.m., MitchAlsup wrote:
> >
> > Robert Finch <robfi680@gmail.com> posted:
> >
> >>> In this case, put the cause in a container the instruction drags down
> >>> the pipe, and retrieve it when you do have address access to where it
> >>> needs to go.
> >>
> >> I may change things to pass the address around in the float package.
> >> Putting the address into the NaN later may cause issues with timing. It
> >> adds a mux into things. May be better to use the original NaN mux in the
> >> float modules. May call it a NaN identity field instead of an address.
> >
> > For example: when a My 66000 instruction needs to raise an exception
> > the Inst *I argument contains a field I->raised which is set (1<<excpt)
> > and at the end of the pipe (at retire), t->raised |= I->raised. Where
> > we have a *t there is also t->ip. So, you don't have to drag Thread *t
> > through all the subroutine calls, but you can easily access t->raised
> > at the point you do have access to t->ip.
> >
> Had trouble reading that, sounds like goobly-goop. But I believe I
> figured it out.
>
> Sounds like the address is inserted at the end of the pipe which I am
> sure is not the case.
>
> I figured this out: the NaN address must be embedded in the result by
> the time the result updates the bypass network and registers so that it
> is available to other instructions.
>
> The address is available at the start of the calc from the reservation
> station entry. Me thinks it must be embedded when the NaN result status
> is set, provided there is not already a NaN. The existing (first) NaN
> must propagate through.
See last calculation line in the following::
void RunInst( Chip *chip )
{
for( uint64_t i = 0; i < chip->cores; i++ )
{
ContextStack *cpu = &core[i];
uint8_t cs = cpu->cs;
Thread *t;
Inst *I;
uint16_t raised;
if( cpu->interrupt.raised & ((((signed)1)<<63) >> cpu->priority) )
{ // take an interrupt
cpu->cs = cpu->interrupt.cs;
cpu->priority = cpu->interrupt.priority;
t = context[cpu->cs];
t->reg[0] = cpu->interrupt.message;
}
else if( raised = t->raised & t->enabled )
{ // take an exception
cpu->cs--;
t = context[cpu->cs];
t->reg[0] = FT1( raised ) | EXCPT;
t->reg[1] = I->inst;
t->reg[2] = I->src1;
t->reg[3] = I->src2;
t->reg[4] = I->src3;
}
else
{ // run an instruction
t = context[cpu->cs];
memory( FETCH, t->ip, &I->inst );
t->ip += 4;
majorTable[ I->inst.major ]( t, I );
t->raised |= I->raised; // propagate raised here
}
}
}
>
> >> Modified NaN support in the float package to store to the HOBs.
> >>
> >> Survey says:
> >>
> >> The Qulps PUSH and POP instructions have room for six register fields.
> >> Should one of the fields be used to identify the stack pointer register
> >> allowing five registers to be pushed or popped? Or should the stack
> >> pointer register be assumed so that six registers may be pushed or popped?
> >
> > My 66000 ENTER and EXIT instruction use SP == R31 implicitly. But,
> > instead of giving it a number of registers, there is a start register
> > and a stop register, so 1-to-32 regsiters can be saved/restored. The
> > immediate contains how much stack space to allocate/deallocate.
> >
> > {{when Safe-Stack is enabled:: Rstart-to-R0 are placed on the inaccessible
> > stack, while R1-to-Rstop are placed on the normal stack.}}
> >
> > Because the stack is always DoubleWord aligned, the 3-LoBs of the
> > immediate are used to indicate "special" activities on a couple of
> > registers {R0, R31, R30}, R31 is rarely saves and reloaded from Stack
> > but just returned to its previous value by integer arithmetic. FP can
> > be updated or it can be treated like "just another register". R0 can
> > be loaded directly to t->ip, or loaded into R0 for stack walk-backs.
> >
> > The corresponding LDM and STM are seldom used.
> >
> I ran out of micro-ops for ENTER and EXIT, so they only save the LR and
> FP (on the safe stack). A separate PUSH/POP on safe stack instruction is
> used.
>
> I figured LDM and STM are not used often enough. PUSH / POP is used in
> many places LDM / STM might be.
Its a fine line.
I found more uses for an instruction that moves a number of registers
randomly allocated to fixed positions (arguments to a call) than to
move random string of registers to/from memory.
.
MOV R1,R10
MOV R2,R25
MOV R3,R17
CALL Subroutine
. ; deal with any result
> For context switching a whole bunch of load / store instructions are
> used. There is context switching in only a couple of places.
I use a cache-model for thread-state {program-status-line and the
register file}.
The high level simulator, leaves all of the context in memory without
loading it or storing it. Thus this serves as a pipeline Oracle so if
the OoO pipeline makes a timing error, the Oracle stops the thread in
its tracks.
Thus::
.
.
-----interrupt detected
. change CS (cs--) <---
. access threadState[cs]
. t->ip = dispatcher
. t->reg[0] = why
dispatcher in control
.
.
.
RET
SVR
.
.
In your typical interrupt/exception control transfers, there is
no code to actually switch state. Just like there is no code to
switch a cache line that takes a miss.
(*) The cs-- is all that is necessary to change from one Thread State
to another in its entirety.
> >> I think the SP should be identified as PUSH / POP would be the only
> >> instructions assuming the SP register. Otherwise any register could be
> >> chosen by the compiler.
> >
> > I started with that philosophy--and begrudgingly went away from it as
> > a) the compiler took form
> > b) we started adding instructions to ISA to remove instructions from
> > code footprint.
>
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-11-27 00:36 -0500 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10g8o1p$147ok$1@dont-email.me> |
| In reply to | #114192 |
On 2025-11-26 7:08 p.m., MitchAlsup wrote:
>
> Robert Finch <robfi680@gmail.com> posted:
>
>> On 2025-11-26 3:57 p.m., MitchAlsup wrote:
>>>
>>> Robert Finch <robfi680@gmail.com> posted:
>>>
>>>>> In this case, put the cause in a container the instruction drags down
>>>>> the pipe, and retrieve it when you do have address access to where it
>>>>> needs to go.
>>>>
>>>> I may change things to pass the address around in the float package.
>>>> Putting the address into the NaN later may cause issues with timing. It
>>>> adds a mux into things. May be better to use the original NaN mux in the
>>>> float modules. May call it a NaN identity field instead of an address.
>>>
>>> For example: when a My 66000 instruction needs to raise an exception
>>> the Inst *I argument contains a field I->raised which is set (1<<excpt)
>>> and at the end of the pipe (at retire), t->raised |= I->raised. Where
>>> we have a *t there is also t->ip. So, you don't have to drag Thread *t
>>> through all the subroutine calls, but you can easily access t->raised
>>> at the point you do have access to t->ip.
>>>
>> Had trouble reading that, sounds like goobly-goop. But I believe I
>> figured it out.
>>
>> Sounds like the address is inserted at the end of the pipe which I am
>> sure is not the case.
>>
>> I figured this out: the NaN address must be embedded in the result by
>> the time the result updates the bypass network and registers so that it
>> is available to other instructions.
>>
>> The address is available at the start of the calc from the reservation
>> station entry. Me thinks it must be embedded when the NaN result status
>> is set, provided there is not already a NaN. The existing (first) NaN
>> must propagate through.
>
> See last calculation line in the following::
>
> void RunInst( Chip *chip )
> {
> for( uint64_t i = 0; i < chip->cores; i++ )
> {
> ContextStack *cpu = &core[i];
> uint8_t cs = cpu->cs;
> Thread *t;
> Inst *I;
> uint16_t raised;
>
> if( cpu->interrupt.raised & ((((signed)1)<<63) >> cpu->priority) )
> { // take an interrupt
> cpu->cs = cpu->interrupt.cs;
> cpu->priority = cpu->interrupt.priority;
> t = context[cpu->cs];
> t->reg[0] = cpu->interrupt.message;
> }
> else if( raised = t->raised & t->enabled )
> { // take an exception
> cpu->cs--;
> t = context[cpu->cs];
> t->reg[0] = FT1( raised ) | EXCPT;
> t->reg[1] = I->inst;
> t->reg[2] = I->src1;
> t->reg[3] = I->src2;
> t->reg[4] = I->src3;
> }
> else
> { // run an instruction
> t = context[cpu->cs];
> memory( FETCH, t->ip, &I->inst );
> t->ip += 4;
> majorTable[ I->inst.major ]( t, I );
> t->raised |= I->raised; // propagate raised here
> }
> }
> }
That looks like code for a simulator. How closely does it follow the
operation of the CPU? I do not see where 'I' is initialized.
It has been a while since I worked on simulator code.
The IP value is just muxed in in a five to one mux for the significand.
Had to account for NaN's infinities and overflow anyway. Address gets
propagated with some some flops, but flops are inexpensive in an FPGA.
always_comb
casez({aNan5,bNan5,qNaNOutab5,aInf5,bInf5,overab5})
6'b1?????: moab6 <=
{1'b1,1'b1,a5[fp64Pkg::FMSB-1:0],{fp64Pkg::FMSB+1{1'b0}}};
6'b01????: moab6 <=
{1'b1,1'b1,b5[fp64Pkg::FMSB-1:0],{fp64Pkg::FMSB+1{1'b0}}};
6'b001???: moab6 <= {1'b1,qNaN|(64'd4 <<
(fp64Pkg::FMSB-4))|adr5[63:16],{fp64Pkg::FMSB+1{1'b0}}}; // multiply inf
* zero
6'b0001??: moab6 <= 0; // mul inf's
6'b00001?: moab6 <= 0; // mul inf's
6'b000001: moab6 <= 0; // mul overflow
default: moab6 <= fractab5;
endcase
>>
>>>> Modified NaN support in the float package to store to the HOBs.
>>>>
>>>> Survey says:
>>>>
>>>> The Qulps PUSH and POP instructions have room for six register fields.
>>>> Should one of the fields be used to identify the stack pointer register
>>>> allowing five registers to be pushed or popped? Or should the stack
>>>> pointer register be assumed so that six registers may be pushed or popped?
>>>
>>> My 66000 ENTER and EXIT instruction use SP == R31 implicitly. But,
>>> instead of giving it a number of registers, there is a start register
>>> and a stop register, so 1-to-32 regsiters can be saved/restored. The
>>> immediate contains how much stack space to allocate/deallocate.
>>>
>>> {{when Safe-Stack is enabled:: Rstart-to-R0 are placed on the inaccessible
>>> stack, while R1-to-Rstop are placed on the normal stack.}}
>>>
>>> Because the stack is always DoubleWord aligned, the 3-LoBs of the
>>> immediate are used to indicate "special" activities on a couple of
>>> registers {R0, R31, R30}, R31 is rarely saves and reloaded from Stack
>>> but just returned to its previous value by integer arithmetic. FP can
>>> be updated or it can be treated like "just another register". R0 can
>>> be loaded directly to t->ip, or loaded into R0 for stack walk-backs.
>>>
>>> The corresponding LDM and STM are seldom used.
>>>
>> I ran out of micro-ops for ENTER and EXIT, so they only save the LR and
>> FP (on the safe stack). A separate PUSH/POP on safe stack instruction is
>> used.
>>
>> I figured LDM and STM are not used often enough. PUSH / POP is used in
>> many places LDM / STM might be.
>
> Its a fine line.
>
> I found more uses for an instruction that moves a number of registers
> randomly allocated to fixed positions (arguments to a call) than to
> move random string of registers to/from memory.
>
> .
> MOV R1,R10
> MOV R2,R25
> MOV R3,R17
> CALL Subroutine
> . ; deal with any result
>
My 66000 has an instruction to do that? I'd not seen an instruction like
that. It is almost like a byte map. I can see how it could be done.
Another instruction to add to the ISA. My compiler does not do such a
nice job of packing the register moves together though.
>> For context switching a whole bunch of load / store instructions are
>> used. There is context switching in only a couple of places.
>
> I use a cache-model for thread-state {program-status-line and the
> register file}.
>
> The high level simulator, leaves all of the context in memory without
> loading it or storing it. Thus this serves as a pipeline Oracle so if
> the OoO pipeline makes a timing error, the Oracle stops the thread in
> its tracks.
>
> Thus::
>
> .
> .
> -----interrupt detected
> . change CS (cs--) <---
> . access threadState[cs]
> . t->ip = dispatcher
> . t->reg[0] = why
> dispatcher in control
> .
> .
> .
> RET
> SVR
> .
> .
>
> In your typical interrupt/exception control transfers, there is
> no code to actually switch state. Just like there is no code to
> switch a cache line that takes a miss.
The My 66000 hardware takes care of it automatically? Interrupts push
and pop context in my system.
>
> (*) The cs-- is all that is necessary to change from one Thread State
> to another in its entirety.
>
>>>> I think the SP should be identified as PUSH / POP would be the only
>>>> instructions assuming the SP register. Otherwise any register could be
>>>> chosen by the compiler.
>>>
>>> I started with that philosophy--and begrudgingly went away from it as
>>> a) the compiler took form
>>> b) we started adding instructions to ISA to remove instructions from
>>> code footprint.
>>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-28 19:35 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <1764358516-5857@newsgrouper.org> |
| In reply to | #114193 |
Robert Finch <robfi680@gmail.com> posted:
> On 2025-11-26 7:08 p.m., MitchAlsup wrote:
> >
> > Robert Finch <robfi680@gmail.com> posted:
> >
> >> On 2025-11-26 3:57 p.m., MitchAlsup wrote:
> >>>
> >>> Robert Finch <robfi680@gmail.com> posted:
> >>>
> >>>>> In this case, put the cause in a container the instruction drags down
> >>>>> the pipe, and retrieve it when you do have address access to where it
> >>>>> needs to go.
> >>>>
> >>>> I may change things to pass the address around in the float package.
> >>>> Putting the address into the NaN later may cause issues with timing. It
> >>>> adds a mux into things. May be better to use the original NaN mux in the
> >>>> float modules. May call it a NaN identity field instead of an address.
> >>>
> >>> For example: when a My 66000 instruction needs to raise an exception
> >>> the Inst *I argument contains a field I->raised which is set (1<<excpt)
> >>> and at the end of the pipe (at retire), t->raised |= I->raised. Where
> >>> we have a *t there is also t->ip. So, you don't have to drag Thread *t
> >>> through all the subroutine calls, but you can easily access t->raised
> >>> at the point you do have access to t->ip.
> >>>
> >> Had trouble reading that, sounds like goobly-goop. But I believe I
> >> figured it out.
> >>
> >> Sounds like the address is inserted at the end of the pipe which I am
> >> sure is not the case.
> >>
> >> I figured this out: the NaN address must be embedded in the result by
> >> the time the result updates the bypass network and registers so that it
> >> is available to other instructions.
> >>
> >> The address is available at the start of the calc from the reservation
> >> station entry. Me thinks it must be embedded when the NaN result status
> >> is set, provided there is not already a NaN. The existing (first) NaN
> >> must propagate through.
> >
> > See last calculation line in the following::
> >
> > void RunInst( Chip *chip )
> > {
> > for( uint64_t i = 0; i < chip->cores; i++ )
> > {
> > ContextStack *cpu = &core[i];
> > uint8_t cs = cpu->cs;
> > Thread *t;
> > Inst *I;
> > uint16_t raised;
> >
> > if( cpu->interrupt.raised & ((((signed)1)<<63) >> cpu->priority) )
> > { // take an interrupt
> > cpu->cs = cpu->interrupt.cs;
> > cpu->priority = cpu->interrupt.priority;
> > t = context[cpu->cs];
> > t->reg[0] = cpu->interrupt.message;
> > }
> > else if( raised = t->raised & t->enabled )
> > { // take an exception
> > cpu->cs--;
> > t = context[cpu->cs];
> > t->reg[0] = FT1( raised ) | EXCPT;
> > t->reg[1] = I->inst;
> > t->reg[2] = I->src1;
> > t->reg[3] = I->src2;
> > t->reg[4] = I->src3;
> > }
> > else
> > { // run an instruction
> > t = context[cpu->cs];
> > memory( FETCH, t->ip, &I->inst );
> > t->ip += 4;
> > majorTable[ I->inst.major ]( t, I );
> > t->raised |= I->raised; // propagate raised here
> > }
> > }
> > }
>
> That looks like code for a simulator.
It is (IS) code for a non-timing simulator {a "right answer" simulator
if you please.}
> How closely does it follow the
> operation of the CPU?
CPUs have a pipeline, I is the quantity that gets dragged down the
pipe, *t is the control registers of that CPU.
> I do not see where 'I' is initialized.
Call to memory(). Then as I gets dragged down the pipeline, more
fields are initialized. I drag the whole structure mostly for
debug purposes.
> It has been a while since I worked on simulator code.
>
> The IP value is just muxed in in a five to one mux for the significand.
> Had to account for NaN's infinities and overflow anyway. Address gets
> propagated with some some flops, but flops are inexpensive in an FPGA.
>
> always_comb
> casez({aNan5,bNan5,qNaNOutab5,aInf5,bInf5,overab5})
> 6'b1?????: moab6 <=
> {1'b1,1'b1,a5[fp64Pkg::FMSB-1:0],{fp64Pkg::FMSB+1{1'b0}}};
> 6'b01????: moab6 <=
> {1'b1,1'b1,b5[fp64Pkg::FMSB-1:0],{fp64Pkg::FMSB+1{1'b0}}};
> 6'b001???: moab6 <= {1'b1,qNaN|(64'd4 <<
> (fp64Pkg::FMSB-4))|adr5[63:16],{fp64Pkg::FMSB+1{1'b0}}}; // multiply inf
> * zero
> 6'b0001??: moab6 <= 0; // mul inf's
> 6'b00001?: moab6 <= 0; // mul inf's
> 6'b000001: moab6 <= 0; // mul overflow
> default: moab6 <= fractab5;
> endcase
>
>
> >>
> >>>> Modified NaN support in the float package to store to the HOBs.
> >>>>
> >>>> Survey says:
> >>>>
> >>>> The Qulps PUSH and POP instructions have room for six register fields.
> >>>> Should one of the fields be used to identify the stack pointer register
> >>>> allowing five registers to be pushed or popped? Or should the stack
> >>>> pointer register be assumed so that six registers may be pushed or popped?
> >>>
> >>> My 66000 ENTER and EXIT instruction use SP == R31 implicitly. But,
> >>> instead of giving it a number of registers, there is a start register
> >>> and a stop register, so 1-to-32 regsiters can be saved/restored. The
> >>> immediate contains how much stack space to allocate/deallocate.
> >>>
> >>> {{when Safe-Stack is enabled:: Rstart-to-R0 are placed on the inaccessible
> >>> stack, while R1-to-Rstop are placed on the normal stack.}}
> >>>
> >>> Because the stack is always DoubleWord aligned, the 3-LoBs of the
> >>> immediate are used to indicate "special" activities on a couple of
> >>> registers {R0, R31, R30}, R31 is rarely saves and reloaded from Stack
> >>> but just returned to its previous value by integer arithmetic. FP can
> >>> be updated or it can be treated like "just another register". R0 can
> >>> be loaded directly to t->ip, or loaded into R0 for stack walk-backs.
> >>>
> >>> The corresponding LDM and STM are seldom used.
> >>>
> >> I ran out of micro-ops for ENTER and EXIT, so they only save the LR and
> >> FP (on the safe stack). A separate PUSH/POP on safe stack instruction is
> >> used.
> >>
> >> I figured LDM and STM are not used often enough. PUSH / POP is used in
> >> many places LDM / STM might be.
> >
> > Its a fine line.
> >
> > I found more uses for an instruction that moves a number of registers
> > randomly allocated to fixed positions (arguments to a call) than to
> > move random string of registers to/from memory.
> >
> > .
> > MOV R1,R10
> > MOV R2,R25
> > MOV R3,R17
> > CALL Subroutine
> > . ; deal with any result
> >
>
> My 66000 has an instruction to do that?
No, but the thought that it could be profitable to have such an
instruction is a common recurrence.
> I'd not seen an instruction like
> that. It is almost like a byte map. I can see how it could be done.
> Another instruction to add to the ISA. My compiler does not do such a
> nice job of packing the register moves together though.
Your instruction size can support such a thing, mine would be difficult.
> >> For context switching a whole bunch of load / store instructions are
> >> used. There is context switching in only a couple of places.
> >
> > I use a cache-model for thread-state {program-status-line and the
> > register file}.
> >
> > The high level simulator, leaves all of the context in memory without
> > loading it or storing it. Thus this serves as a pipeline Oracle so if
> > the OoO pipeline makes a timing error, the Oracle stops the thread in
> > its tracks.
> >
> > Thus::
> >
> > .
> > .
> > -----interrupt detected
> > . change CS (cs--) <---
> > . access threadState[cs]
> > . t->ip = dispatcher
> > . t->reg[0] = why
> > dispatcher in control
> > .
> > .
> > .
> > RET
> > SVR
> > .
> > .
> >
> > In your typical interrupt/exception control transfers, there is
> > no code to actually switch state. Just like there is no code to
> > switch a cache line that takes a miss.
>
> The My 66000 hardware takes care of it automatically? Interrupts push
> and pop context in my system.
Yes, context switching is automatic and re-entrant. Whereas exceptions
walk up the privilege stack, interrupts go directly to the specified
context on the stack. So, you could be operating at high privilege
and low priority, only to get interrupted by lower privilege at higher
priority.
> > (*) The cs-- is all that is necessary to change from one Thread State
> > to another in its entirety.
> >
> >>>> I think the SP should be identified as PUSH / POP would be the only
> >>>> instructions assuming the SP register. Otherwise any register could be
> >>>> chosen by the compiler.
> >>>
> >>> I started with that philosophy--and begrudgingly went away from it as
> >>> a) the compiler took form
> >>> b) we started adding instructions to ISA to remove instructions from
> >>> code footprint.
> >>
>
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-11-27 00:44 -0500 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <1hnfikdqn5hjdk59e3srtljvn2sv6nql4i@4ax.com> |
| In reply to | #114174 |
On Sun, 23 Nov 2025 23:58:16 -0500, Robert Finch <robfi680@gmail.com> wrote: >On 2025-11-23 3:13 p.m., MitchAlsup wrote: >> >> Robert Finch <robfi680@gmail.com> posted: >>> On 2025-11-22 10:20 p.m., MitchAlsup wrote: >>>> Robert Finch <robfi680@gmail.com> posted: >>>>> On 2025-11-11 2:30 p.m., MitchAlsup wrote: >>>>>> Robert Finch <robfi680@gmail.com> posted: >>>>>> >>>>>>> Typical process for NaN boxing is to set the high order bits of the >>>>>>> value which causes the value to appear to be a NaN at higher precision. >>>>>> >>>>>> Any FP value representable in lower precision can be exactly represented >>>>>> in higher precision. >>>>>> >>>>>>> I have been thinking about using some of the high order bits of the NaN >>>>>>> (eg bits 32 to 51) to indicate the precision of the boxed value. >>>>>> >>>>>> When My 66000 generates a NaN it inserts the cause in the 3 HoBs and >>>>>> inserts IP in the LoBs. Nothing prevents you from overwriting the NaN, >>>>>> but I thought it was best to point at the causing-instruction and an >>>>>> encoded "why" the nan was generated. The cause is a 3-bit index to the >>>>>> 7 defined IEEE exceptions. >>>>>> >>>>> My float package puts the cause in the 3 LoBs. The cause is always in >>>>> the low order bits of the register then, even when the precision is >>>>> different. But the address is not tracked. The package does not have >>>>> access to the address. Seems like NaN trace hardware might be useful. >>>> >>>> Suggest you read:: >>>> https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf >>>> For conversation about LoBs versus HoBs. >>>> >>> >>> Okay, it sounds like there are good reasons to use the HoBs. But I think >>> it is only when converting precisions that it makes a difference. I have >>> the float package moving the LoBs of a larger precision to the LoBs of >>> the lower precision if a NaN (or infinity) is present. I do not think >>> this consumes any more logic. It looks like just wires. It looks to be a >>> three bit mux on the low order bits going the other way. >> >> The other part of the paper's reasoning is that if you want to insert >> some portion of IP in NaN, doing it bit-reversed enables conversions >> to smaller and larger to loose as few bits as possible. The realization >> was a surprise to me (yesterday). >> > >It is probably not possible to embed enough IP information in smaller >floating-point formats (<=16-bit) to be worthwhile. For 32-bit floats >only about 18-bits of the address can be stored. It looks like different >formats are going to handle NaNs differently, which I find somewhat >undesirable. This discussion reminds me somewhat of Ivan Godard's description of NAR faults on the Mill. Because of wide issue, just having the address of the offending instruction was not very helpful - you needed to know which of the many operations within the instruction was the culprit. And because NARs flow through speculated code, the offending site could be hundreds of operations away by the time the fault is signaled and pops out. Ivan discusses NARs in the "metadata" talk. Around 1h:25m, he describes the way Mill (approximately) encodes a fault location using a hash code created from the address of the code block, the instruction's issue cycle within the block, and the slot of the operation that failed. They stick the LO bits of this hash into however many bits are available for the payload. The NAR itself has a type, and the payload width depends on the data type produced by the faulting operation. Obviously that all is Mill specific, but it may stimulate another, better idea that is relevant to your design. YMMV.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-11-26 22:26 +0100 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10g7r9n$pnkk$1@dont-email.me> |
| In reply to | #114169 |
MitchAlsup wrote: > > Robert Finch <robfi680@gmail.com> posted: > >> On 2025-11-22 10:20 p.m., MitchAlsup wrote: >>> >>> Robert Finch <robfi680@gmail.com> posted: >>> >>>> On 2025-11-11 2:30 p.m., MitchAlsup wrote: >>>>> >>>>> Robert Finch <robfi680@gmail.com> posted: >>>>> >>>>>> Typical process for NaN boxing is to set the high order bits of the >>>>>> value which causes the value to appear to be a NaN at higher precision. >>>>> >>>>> Any FP value representable in lower precision can be exactly represented >>>>> in higher precision. >>>>> >>>>>> I have been thinking about using some of the high order bits of the NaN >>>>>> (eg bits 32 to 51) to indicate the precision of the boxed value. >>>>> >>>>> When My 66000 generates a NaN it inserts the cause in the 3 HoBs and >>>>> inserts IP in the LoBs. Nothing prevents you from overwriting the NaN, >>>>> but I thought it was best to point at the causing-instruction and an >>>>> encoded "why" the nan was generated. The cause is a 3-bit index to the >>>>> 7 defined IEEE exceptions. >>>>> >>>> My float package puts the cause in the 3 LoBs. The cause is always in >>>> the low order bits of the register then, even when the precision is >>>> different. But the address is not tracked. The package does not have >>>> access to the address. Seems like NaN trace hardware might be useful. >>> >>> Suggest you read:: >>> https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf >>> For conversation about LoBs versus HoBs. >>> >> >> Okay, it sounds like there are good reasons to use the HoBs. But I think >> it is only when converting precisions that it makes a difference. I have >> the float package moving the LoBs of a larger precision to the LoBs of >> the lower precision if a NaN (or infinity) is present. I do not think >> this consumes any more logic. It looks like just wires. It looks to be a >> three bit mux on the low order bits going the other way. > > The other part of the paper's reasoning is that if you want to insert > some portion of IP in NaN, doing it bit-reversed enables conversions > to smaller and larger to loose as few bits as possible. The realization > was a surprise to me (yesterday). I think I read about IBM's approach years before the 754-2019 process started. Storing the offending address in byte-reversed order would do pretty much the same thing, but at lower HW cost, right? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-26 21:58 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <1764194293-5857@newsgrouper.org> |
| In reply to | #114184 |
Terje Mathisen <terje.mathisen@tmsw.no> posted: > MitchAlsup wrote: > > > > Robert Finch <robfi680@gmail.com> posted: > > > >> On 2025-11-22 10:20 p.m., MitchAlsup wrote: > >>> > >>> Robert Finch <robfi680@gmail.com> posted: > >>> > >>>> On 2025-11-11 2:30 p.m., MitchAlsup wrote: > >>>>> > >>>>> Robert Finch <robfi680@gmail.com> posted: > >>>>> > >>>>>> Typical process for NaN boxing is to set the high order bits of the > >>>>>> value which causes the value to appear to be a NaN at higher precision. > >>>>> > >>>>> Any FP value representable in lower precision can be exactly represented > >>>>> in higher precision. > >>>>> > >>>>>> I have been thinking about using some of the high order bits of the NaN > >>>>>> (eg bits 32 to 51) to indicate the precision of the boxed value. > >>>>> > >>>>> When My 66000 generates a NaN it inserts the cause in the 3 HoBs and > >>>>> inserts IP in the LoBs. Nothing prevents you from overwriting the NaN, > >>>>> but I thought it was best to point at the causing-instruction and an > >>>>> encoded "why" the nan was generated. The cause is a 3-bit index to the > >>>>> 7 defined IEEE exceptions. > >>>>> > >>>> My float package puts the cause in the 3 LoBs. The cause is always in > >>>> the low order bits of the register then, even when the precision is > >>>> different. But the address is not tracked. The package does not have > >>>> access to the address. Seems like NaN trace hardware might be useful. > >>> > >>> Suggest you read:: > >>> https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf > >>> For conversation about LoBs versus HoBs. > >>> > >> > >> Okay, it sounds like there are good reasons to use the HoBs. But I think > >> it is only when converting precisions that it makes a difference. I have > >> the float package moving the LoBs of a larger precision to the LoBs of > >> the lower precision if a NaN (or infinity) is present. I do not think > >> this consumes any more logic. It looks like just wires. It looks to be a > >> three bit mux on the low order bits going the other way. > > > > The other part of the paper's reasoning is that if you want to insert > > some portion of IP in NaN, doing it bit-reversed enables conversions > > to smaller and larger to loose as few bits as possible. The realization > > was a surprise to me (yesterday). > > I think I read about IBM's approach years before the 754-2019 process > started. > > Storing the offending address in byte-reversed order would do pretty > much the same thing, but at lower HW cost, right? Yes, no, and maybe. In order to byte/bit-reverse a field/register, you take the horizontal data-path bit-lines and turn them 90ยบ degrees. Once so turned, the difference in cost between bit-reversal and byte reversal is about too small to worry about. So, no. On the other hand, shifters, and bit-field-reversers are often part of the data path (calculation circuits), so you can pretty much get one or the other or both at vey little extra charge. So, yes. It is only at SW use of the bit-vector does one or the other matter a little (or a lot). In a machine with either bit-reverse instruction or byte reverse instruction, the ISA determines which one is better. So, maybe. My 66000 has a bit reverse instructions that can also perform pair-reverse, quad-reverse, byte-reverse, half-reverse, and word-reverse. So, in this ISA it does not matter which HW choice was made. > Terje > >
[toc] | [prev] | [next] | [standalone]
| From | kegs@provalid.com (Kent Dickey) |
|---|---|
| Date | 2025-11-27 15:50 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10g9s0d$1hq73$1@dont-email.me> |
| In reply to | #114162 |
In article <1763868010-5857@newsgrouper.org>, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >Robert Finch <robfi680@gmail.com> posted: >> My float package puts the cause in the 3 LoBs. The cause is always in >> the low order bits of the register then, even when the precision is >> different. But the address is not tracked. The package does not have >> access to the address. Seems like NaN trace hardware might be useful. > >Suggest you read:: >https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf >For conversation about LoBs versus HoBs. I wasn't sure where to join the NaN conversation, but this seems like a good spot. We've had 40+ years of different architectures handling NaNs, (what to encode in them to indicate where the first problem occurred) and all architectures do something different when operating on two NaNs: From that paper: - Intel using x87 instructions: NaN2 if both quiet, NaN1 if NaN2 is signalling - Intel using SSE instructions: NaN1 - AMD using x87 instructions: NaN2 - AMD using SSE instructions: NaN1 - IBM Power PC: NaN1 - IBM Z mainframe: NaN1 if both quiet, [precedence] to signalling NaN - ARM: NaN1 if both quiet, [precedence] to signalling NaN And adding one more not in that paper: - RISC-V: Always returns canonical NaN only, for Single: 0x7fc00000 I'll just say whatever your NaN handling is, for the source code: A = B + C + D + E then for whatever values B,C,D,E having NaN or not, the value of A should be well defined and not dependent on the order of operations. How can you use bits in the NaN value for debugging if the hardware is returning arbitrary results when NaNs collide? Users have almost no control over whether A = B + C treats B as the first argument or the second. I think encoding stuff in NaN is a very 80's idea: turning on exceptions costs performance, so we want to debug after-the-fact using NaNs. But I think RISC-V has the right modern idea: make hardware fast so you can simply always enable Invalid Operation Traps (and maybe Overflow, if infinities are happening), and then stop right at the point of NaN being first created. So the NaN propagation doesn't matter. I think the common current debug strategy for NaNs is run at full speed with exceptions masked, and if you get NaNs in your answer, you re-run with exceptions on and then debug the traps that occur. And no one looks at the NaN values at all, just their presence. So rather than spending time on NaN encoding, make it so that FP performance is not affected by enabling exceptions, so we can skip the re-running step, and just run with Invalid Operations trapping enabled. And then just return canonical NaNs. Kent
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-27 19:16 +0200 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <20251127191624.00007503@yahoo.com> |
| In reply to | #114195 |
On Thu, 27 Nov 2025 15:50:37 -0000 (UTC) kegs@provalid.com (Kent Dickey) wrote: > In article <1763868010-5857@newsgrouper.org>, > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > >Robert Finch <robfi680@gmail.com> posted: > >> My float package puts the cause in the 3 LoBs. The cause is always > >> in the low order bits of the register then, even when the > >> precision is different. But the address is not tracked. The > >> package does not have access to the address. Seems like NaN trace > >> hardware might be useful. > > > >Suggest you read:: > >https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf > >For conversation about LoBs versus HoBs. > > I wasn't sure where to join the NaN conversation, but this seems like > a good spot. > > We've had 40+ years of different architectures handling NaNs, (what to > encode in them to indicate where the first problem occurred) and all > architectures do something different when operating on two NaNs: > > From that paper: > - Intel using x87 instructions: NaN2 if both quiet, NaN1 if NaN2 is > signalling > - Intel using SSE instructions: NaN1 > - AMD using x87 instructions: NaN2 > - AMD using SSE instructions: NaN1 > - IBM Power PC: NaN1 > - IBM Z mainframe: NaN1 if both quiet, [precedence] to signalling NaN > - ARM: NaN1 if both quiet, [precedence] to signalling NaN > > And adding one more not in that paper: > - RISC-V: Always returns canonical NaN only, for Single: 0x7fc00000 > > I'll just say whatever your NaN handling is, for the source code: > > A = B + C + D + E > > then for whatever values B,C,D,E having NaN or not, the value of A > should be well defined and not dependent on the order of operations. > How can you use bits in the NaN value for debugging if the hardware > is returning arbitrary results when NaNs collide? Users have almost > no control over whether A = B + C treats B as the first argument or > the second. > > I think encoding stuff in NaN is a very 80's idea: turning on > exceptions costs performance, so we want to debug after-the-fact > using NaNs. > > But I think RISC-V has the right modern idea: make hardware fast so > you can simply always enable Invalid Operation Traps (and maybe > Overflow, if infinities are happening), and then stop right at the > point of NaN being first created. So the NaN propagation doesn't > matter. > > I think the common current debug strategy for NaNs is run at full > speed with exceptions masked, and if you get NaNs in your answer, you > re-run with exceptions on and then debug the traps that occur. And > no one looks at the NaN values at all, just their presence. > > So rather than spending time on NaN encoding, make it so that FP > performance is not affected by enabling exceptions, so we can skip > the re-running step, and just run with Invalid Operations trapping > enabled. And then just return canonical NaNs. > > Kent How do you ship your software to the end user? Are exceptions masked off or enabled?
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-11-28 07:17 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10gbi9j$25egn$1@dont-email.me> |
| In reply to | #114195 |
Kent Dickey <kegs@provalid.com> schrieb: > I'll just say whatever your NaN handling is, for the source code: > > A = B + C + D + E > > then for whatever values B,C,D,E having NaN or not, the value of A should > be well defined and not dependent on the order of operations. That is not possible in general with normal floating point (you could guarantee if you keep track of all digits9. But normally, 1 + 1e-9 - 1 will be different from 1 - 1 + 1e9. (BTW, Fortran is allowed re-arrangement, unless there are parentheses, these have to be honored). -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-11-28 02:59 -0500 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10gbkp9$25rds$1@dont-email.me> |
| In reply to | #114195 |
On 2025-11-27 10:50 a.m., Kent Dickey wrote: > In article <1763868010-5857@newsgrouper.org>, > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >> >> Robert Finch <robfi680@gmail.com> posted: >>> My float package puts the cause in the 3 LoBs. The cause is always in >>> the low order bits of the register then, even when the precision is >>> different. But the address is not tracked. The package does not have >>> access to the address. Seems like NaN trace hardware might be useful. >> >> Suggest you read:: >> https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf >> For conversation about LoBs versus HoBs. > > I wasn't sure where to join the NaN conversation, but this seems like a > good spot. > > We've had 40+ years of different architectures handling NaNs, (what to > encode in them to indicate where the first problem occurred) and all > architectures do something different when operating on two NaNs: > > From that paper: > - Intel using x87 instructions: NaN2 if both quiet, NaN1 if NaN2 is signalling > - Intel using SSE instructions: NaN1 > - AMD using x87 instructions: NaN2 > - AMD using SSE instructions: NaN1 > - IBM Power PC: NaN1 > - IBM Z mainframe: NaN1 if both quiet, [precedence] to signalling NaN > - ARM: NaN1 if both quiet, [precedence] to signalling NaN > > And adding one more not in that paper: > - RISC-V: Always returns canonical NaN only, for Single: 0x7fc00000 > > I'll just say whatever your NaN handling is, for the source code: > > A = B + C + D + E > > then for whatever values B,C,D,E having NaN or not, the value of A should > be well defined and not dependent on the order of operations. How can you > use bits in the NaN value for debugging if the hardware is returning arbitrary > results when NaNs collide? Users have almost no control over whether > A = B + C treats B as the first argument or the second. > > I think encoding stuff in NaN is a very 80's idea: turning on exceptions > costs performance, so we want to debug after-the-fact using NaNs. > > But I think RISC-V has the right modern idea: make hardware fast so you can > simply always enable Invalid Operation Traps (and maybe Overflow, if > infinities are happening), and then stop right at the point of NaN being > first created. So the NaN propagation doesn't matter. > > I think the common current debug strategy for NaNs is run at full speed > with exceptions masked, and if you get NaNs in your answer, you re-run > with exceptions on and then debug the traps that occur. And no one looks at > the NaN values at all, just their presence. > > So rather than spending time on NaN encoding, make it so that FP performance > is not affected by enabling exceptions, so we can skip the re-running step, > and just run with Invalid Operations trapping enabled. And then just > return canonical NaNs. > > Kent I do not know how one would make FP performance improve and have exceptions at the same time. The FP would have to operate asynchronous. The only thing I can think of is to have core(s) specifically dedicated to performance FP that do not service interrupts. Given that nobody looks at the NaN values it is tempting to leave out the NaN info, but I think I will still have it as an input to modules where NaNs can be generated (when I get around to it). The NaN info can always be set to zeros then and the extra logic should disappear then. I think that there may be a reason why nobody looks at the NaN values. IDK but maybe the debug does not make it easy to spot. A NaN display with a random assortment of digits is pretty useless. But if debug where to display all the address and other info, would it get used?
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-11-28 12:56 -0500 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <RnlWQ.63585$C8i7.43602@fx16.iad> |
| In reply to | #114202 |
Robert Finch wrote: > On 2025-11-27 10:50 a.m., Kent Dickey wrote: >> >> I think encoding stuff in NaN is a very 80's idea: turning on exceptions >> costs performance, so we want to debug after-the-fact using NaNs. >> But I think RISC-V has the right modern idea: make hardware fast so >> you can >> simply always enable Invalid Operation Traps (and maybe Overflow, if >> infinities are happening), and then stop right at the point of NaN being >> first created. So the NaN propagation doesn't matter. >> >> I think the common current debug strategy for NaNs is run at full speed >> with exceptions masked, and if you get NaNs in your answer, you re-run >> with exceptions on and then debug the traps that occur. And no one >> looks at >> the NaN values at all, just their presence. >> >> So rather than spending time on NaN encoding, make it so that FP >> performance >> is not affected by enabling exceptions, so we can skip the re-running >> step, >> and just run with Invalid Operations trapping enabled. And then just >> return canonical NaNs. >> >> Kent > > I do not know how one would make FP performance improve and have > exceptions at the same time. The FP would have to operate asynchronous. > The only thing I can think of is to have core(s) specifically dedicated > to performance FP that do not service interrupts. Why do you think that enabling FP exceptions "costs performance", by which I assume you mean that, say, an FPADD with exceptions enabled is slower than disabled? The FP exceptions are rising-edge triggered based on individual instruction calculation status, that is before being merged (OR'd) into the overall FP status. If an FP instruction has unmasked exceptions then mark the uOp as Except'd and recognize it at Retire like any other exception. This also assumes that the overall FP status is updated (merged) at Retire so it only contains status flags for FP instructions older than the exception point.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-28 20:41 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <1764362508-5857@newsgrouper.org> |
| In reply to | #114204 |
EricP <ThatWouldBeTelling@thevillage.com> posted:
> Robert Finch wrote:
> > On 2025-11-27 10:50 a.m., Kent Dickey wrote:
> >>
> >> I think encoding stuff in NaN is a very 80's idea: turning on exceptions
> >> costs performance, so we want to debug after-the-fact using NaNs.
> >> But I think RISC-V has the right modern idea: make hardware fast so
> >> you can
> >> simply always enable Invalid Operation Traps (and maybe Overflow, if
> >> infinities are happening), and then stop right at the point of NaN being
> >> first created. So the NaN propagation doesn't matter.
> >>
> >> I think the common current debug strategy for NaNs is run at full speed
> >> with exceptions masked, and if you get NaNs in your answer, you re-run
> >> with exceptions on and then debug the traps that occur. And no one
> >> looks at
> >> the NaN values at all, just their presence.
> >>
> >> So rather than spending time on NaN encoding, make it so that FP
> >> performance
> >> is not affected by enabling exceptions, so we can skip the re-running
> >> step,
> >> and just run with Invalid Operations trapping enabled. And then just
> >> return canonical NaNs.
> >>
> >> Kent
> >
> > I do not know how one would make FP performance improve and have
> > exceptions at the same time. The FP would have to operate asynchronous.
> > The only thing I can think of is to have core(s) specifically dedicated
> > to performance FP that do not service interrupts.
>
> Why do you think that enabling FP exceptions "costs performance",
> by which I assume you mean that, say, an FPADD with exceptions
> enabled is slower than disabled?
It is the control transfer to and from the handler on the occurrence
of an exception that diminishes performance; and the time consumed
by the handler itself. The enabled and disabled FPU takes the same
time regardless of whether an exception transpired or not.
> The FP exceptions are rising-edge triggered based on individual
> instruction calculation status, that is before being merged (OR'd)
> into the overall FP status. If an FP instruction has unmasked exceptions
> then mark the uOp as Except'd and recognize
and order
> it at Retire like any
> other exception. This also assumes that the overall FP status is
> updated (merged) at Retire so it only contains status flags for
> FP instructions older than the
retire
> point.
>
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-28 20:09 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <1764360552-5857@newsgrouper.org> |
| In reply to | #114202 |
Robert Finch <robfi680@gmail.com> posted: > On 2025-11-27 10:50 a.m., Kent Dickey wrote: > > In article <1763868010-5857@newsgrouper.org>, > > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >> > >> Robert Finch <robfi680@gmail.com> posted: > >>> My float package puts the cause in the 3 LoBs. The cause is always in > >>> the low order bits of the register then, even when the precision is > >>> different. But the address is not tracked. The package does not have > >>> access to the address. Seems like NaN trace hardware might be useful. > >> > >> Suggest you read:: > >> https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf > >> For conversation about LoBs versus HoBs. > > > > I wasn't sure where to join the NaN conversation, but this seems like a > > good spot. > > > > We've had 40+ years of different architectures handling NaNs, (what to > > encode in them to indicate where the first problem occurred) and all > > architectures do something different when operating on two NaNs: > > > > From that paper: > > - Intel using x87 instructions: NaN2 if both quiet, NaN1 if NaN2 is signalling > > - Intel using SSE instructions: NaN1 > > - AMD using x87 instructions: NaN2 > > - AMD using SSE instructions: NaN1 > > - IBM Power PC: NaN1 > > - IBM Z mainframe: NaN1 if both quiet, [precedence] to signalling NaN > > - ARM: NaN1 if both quiet, [precedence] to signalling NaN > > > > And adding one more not in that paper: > > - RISC-V: Always returns canonical NaN only, for Single: 0x7fc00000 > > > > I'll just say whatever your NaN handling is, for the source code: > > > > A = B + C + D + E > > > > then for whatever values B,C,D,E having NaN or not, the value of A should > > be well defined and not dependent on the order of operations. How can you > > use bits in the NaN value for debugging if the hardware is returning arbitrary > > results when NaNs collide? Users have almost no control over whether > > A = B + C treats B as the first argument or the second. > > > > I think encoding stuff in NaN is a very 80's idea: turning on exceptions > > costs performance, so we want to debug after-the-fact using NaNs. > > > But I think RISC-V has the right modern idea: make hardware fast so > you can > > simply always enable Invalid Operation Traps (and maybe Overflow, if > > infinities are happening), and then stop right at the point of NaN being > > first created. So the NaN propagation doesn't matter. > > > > I think the common current debug strategy for NaNs is run at full speed > > with exceptions masked, and if you get NaNs in your answer, you re-run > > with exceptions on and then debug the traps that occur. And no one looks at > > the NaN values at all, just their presence. > > > > So rather than spending time on NaN encoding, make it so that FP performance > > is not affected by enabling exceptions, so we can skip the re-running step, > > and just run with Invalid Operations trapping enabled. And then just > > return canonical NaNs. > > > > Kent > > I do not know how one would make FP performance improve and have > exceptions at the same time. The FP would have to operate asynchronous. What is it that you fail to understand what reservation stations do to instructions arriving at various FPUs !?!?! The stations effectively turn the FPUs into asynchronous calculation units. > The only thing I can think of is to have core(s) specifically dedicated > to performance FP that do not service interrupts. > > Given that nobody looks at the NaN values it is tempting to leave out > the NaN info, but I think I will still have it as an input to modules > where NaNs can be generated (when I get around to it). The NaN info can > always be set to zeros then and the extra logic should disappear then. > > I think that there may be a reason why nobody looks at the NaN values. > IDK but maybe the debug does not make it easy to spot. A NaN display > with a random assortment of digits is pretty useless. But if debug where > to display all the address and other info, would it get used? That is the idea behind the why code and the IP in My 66000 NaNs. I still do not think they will be used "all that often" simply because so many other ways to generate and propagate NaNs exist--and there is no "universal" consensus. >
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-28 19:49 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <1764359371-5857@newsgrouper.org> |
| In reply to | #114195 |
kegs@provalid.com (Kent Dickey) posted:
> In article <1763868010-5857@newsgrouper.org>,
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> >
> >Robert Finch <robfi680@gmail.com> posted:
> >> My float package puts the cause in the 3 LoBs. The cause is always in
> >> the low order bits of the register then, even when the precision is
> >> different. But the address is not tracked. The package does not have
> >> access to the address. Seems like NaN trace hardware might be useful.
> >
> >Suggest you read::
> >https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf
> >For conversation about LoBs versus HoBs.
>
> I wasn't sure where to join the NaN conversation, but this seems like a
> good spot.
>
> We've had 40+ years of different architectures handling NaNs, (what to
> encode in them to indicate where the first problem occurred) and all
> architectures do something different when operating on two NaNs:
>
> From that paper:
> - Intel using x87 instructions: NaN2 if both quiet, NaN1 if NaN2 is signalling
> - Intel using SSE instructions: NaN1
> - AMD using x87 instructions: NaN2
> - AMD using SSE instructions: NaN1
> - IBM Power PC: NaN1
> - IBM Z mainframe: NaN1 if both quiet, [precedence] to signalling NaN
> - ARM: NaN1 if both quiet, [precedence] to signalling NaN
>
> And adding one more not in that paper:
> - RISC-V: Always returns canonical NaN only, for Single: 0x7fc00000
>
> I'll just say whatever your NaN handling is, for the source code:
>
> A = B + C + D + E
>
> then for whatever values B,C,D,E having NaN or not, the value of A should
> be well defined and not dependent on the order of operations.
I nice philosophy, but how does one achieve that when the compiler is allowed
to encode the above as::
A = (B+C)+(D+E)
or
A = (B+D)+(C+E)
or
A = (B+E)+(C+D)
or
A = (B+C)+(E+D)
or
...
No single set of rules can give the first created NaN because which
is first created is dependent on how the compiler ordered the FADDs.
> How can you
> use bits in the NaN value for debugging if the hardware is returning arbitrary
> results when NaNs collide?
My 66000 has specific rules covering {Operand NaNs, Created NaNs}
which attempt to preserve the earliest created NaN and to properly
propagate Operand NaN values.
> Users have almost no control over whether
> A = B + C treats B as the first argument or the second.
Optimizers treat B and C as independent optimization opportunities.
> I think encoding stuff in NaN is a very 80's idea: turning on exceptions
> costs performance, so we want to debug after-the-fact using NaNs.
>
> But I think RISC-V has the right modern idea: make hardware fast so you can
> simply always enable Invalid Operation Traps (and maybe Overflow, if
> infinities are happening), and then stop right at the point of NaN being
> first created. So the NaN propagation doesn't matter.
This is a 1960s idea. Stop at the first occurrence of trouble. More
workable than NaNs, but has its own set of baggage--for example how
does one stop 13 elements into a Vector instruction ???
{{BTW: My 66000 has a way to scalarize vector code 13 elements into
the vector, and after the exception has been handled, to reenter
vector operation.}}
> I think the common current debug strategy for NaNs is run at full speed
> with exceptions masked, and if you get NaNs in your answer, you re-run
> with exceptions on and then debug the traps that occur. And no one looks at
> the NaN values at all, just their presence.
Yes, this is a common strategy, and with the list of architectures that
"all do it differently" what else could one expect.
> So rather than spending time on NaN encoding, make it so that FP performance
> is not affected by enabling exceptions, so we can skip the re-running step,
> and just run with Invalid Operations trapping enabled. And then just
> return canonical NaNs.
My 66000 has that option available.
>
> Kent
[toc] | [prev] | [next] | [standalone]
| From | kegs@provalid.com (Kent Dickey) |
|---|---|
| Date | 2025-11-29 15:48 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10gf4k5$3g8cd$1@dont-email.me> |
| In reply to | #114206 |
In article <1764359371-5857@newsgrouper.org>, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >kegs@provalid.com (Kent Dickey) posted: > >> In article <1763868010-5857@newsgrouper.org>, >> MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >> > >> >Robert Finch <robfi680@gmail.com> posted: >> >> My float package puts the cause in the 3 LoBs. The cause is always in >> >> the low order bits of the register then, even when the precision is >> >> different. But the address is not tracked. The package does not have >> >> access to the address. Seems like NaN trace hardware might be useful. >> > >> >Suggest you read:: >> >>https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf >> >For conversation about LoBs versus HoBs. [snip] >> I'll just say whatever your NaN handling is, for the source code: >> >> A = B + C + D + E >> >> then for whatever values B,C,D,E having NaN or not, the value of A should >> be well defined and not dependent on the order of operations. > >I nice philosophy, but how does one achieve that when the compiler is allowed >to encode the above as:: > > A = (B+C)+(D+E) >or > A = (B+D)+(C+E) >or > A = (B+E)+(C+D) >or > A = (B+C)+(E+D) >or > ... > >No single set of rules can give the first created NaN because which >is first created is dependent on how the compiler ordered the FADDs. This is my point: I don't see a great way to encode the first NaN, which is why I propose not making that a goal. You're not getting the first NaN in any case even if you try to do so in hardware, since the order of operations is a fragile thing that's hard to control unless you write assembly code, or the most tedious source code imaginable. Several rules easily satisfy my property: canonical NaN (always return 0x7fc00000 as the result of any invalid op or any operation involving a NaN), or Max(NaN.mantissa), where you return the largest mantissa value of any NaN. An OR of the NaN mantissas also works. This lets you at least encode the most serious NaN if you order them, or lets you know all the different invalid ops that occured with the OR of flags stored in the mantissa. But canonical NaN is so much simpler. There's no need to preserve and mux around the NaN mantissas, which might save a tiny amount of datapath logic in FP units. Perhaps clever algorithms involving integer ops on FP values will come around and we'll WANT to have simpler FP handling so the integer accelerations will be easier to get right. Kent
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-11-29 19:11 +0000 |
| Subject | Re: Tonights Tradeoff - NaN boxed precisions |
| Message-ID | <10gfgh2$3l13t$1@dont-email.me> |
| In reply to | #114215 |
Kent Dickey <kegs@provalid.com> schrieb: > This is my point: I don't see a great way to encode the first NaN, which > is why I propose not making that a goal. You're not getting the first > NaN in any case even if you try to do so in hardware, since the order of > operations is a fragile thing that's hard to control unless you write > assembly code, or the most tedious source code imaginable. Using Fortran, parentheses have to be honored. If you write A = (B + C) + (D + E) then B + C and D + E have to be calculated before the total sum. If you write A = B + (C + (D + E)) then you prescribe the order completetely. I can imagine source code that is much more tedious than this :-) -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
Page 45 of 46 — ← Prev page 1 … 43 44 [45] 46 Next page →
Back to top | Article view | comp.arch
csiph-web