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 9 of 46 — ← Prev page 1 … 7 8 [9] 10 11 … 46 Next page →
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-10-30 07:13 +0000 |
| Message-ID | <10dv37i$3gk1r$1@dont-email.me> |
| In reply to | #113877 |
Robert Finch <robfi680@gmail.com> schrieb: > On 2025-10-29 2:15 p.m., Thomas Koenig wrote: >> Robert Finch <robfi680@gmail.com> schrieb: >>> Started working on yet another CPU – Qupls4. Fixed 40-bit instructions, >>> 64 GPRs. GPRs may be used in pairs for 128-bit ops. Registers are named >>> as if there were 32 GPRs, A0 (arg 0 register is r1) and A0H (arg 0 high >>> is r33). Sameo for other registers. GPRs may contain either integer or >>> floating-point values. >> >> I understand the temptation to go for more bits :-) What is your >> instruction alignment? Bytewise so 40 bits fit, or do you have some >> alignment that the first instruction of a cache line is always aligned? > > The 40-bit instructions are byte aligned. This does add more shifting in > the align stage. Once shifted though instructions are easily peeled off > from fixed positions. One consequence is jump targets must be byte > aligned OR routines could be required to be 32-bit aligned for instance.> That raises an interesting question. If you want to align a branch target on a 32-bit boundary, or even a cache line, how do you fill up the rest? If all instructions are 40 bits, you cannot have a NOP that is not 40 bits, so there would need to be a jump before a gap that is does not fit 40 bits. >> If you have that many bits available, do you still go for a load-store >> architecture, or do you have memory operations? This could offset the >> larger size of your instructions. > > It is load/store with no memory ops excepting possibly atomic memory ops.> OK. Starting with 40 vs 32 bits, you have a factor of 1.25 disadvantage in code density to start with. Having memory operations could offset that by a certain factor, that was why I was asking. >>> Using operand routing for immediate constants and an operation size for >>> the instruction. Constants and operation size may be specified >>> independently. With 40-bit instruction words, constants may be 10,50,90 >>> or 130 bits. >> >> Those sizes are not really a good fit for constants from programs, >> where quite a few constants tend to be 32 or 64 bits. Would a >> 64-bit FP constant leave 26 bits empty? >> > I found that 16-bit immediates could be encoded instead of 10-bit. OK. That should also help for offsets in load/store. > So, now there are 16,56,96 and 136 bit constants possible. The > 56-bitconstant likely has enough range for most 64-bit ops. For addresses, it will take some time for this to overflow :-) For floating point constants, that will be hard. I have done some analysis on frequency of floating point constants in different programs, and what I found was that there are a few floating point constants that keep coming up, like a few integers around zero (biased towards the positive side), plus a few more golden oldies like 0.5, 1.5 and pi. Apart from that, I found that different programs have wildly different floating point constants, which is not surprising. (I based that analysis on the grand total of three packages, namely Perl, gnuplot and GSL, so cover is not really extensive). > Otherwise using > a 96-bit constant for 64-bit ops would leave the upper 32-bit of the > constant unused. There are also 32-bit floating point constants, and 32-bit integers as constants. There are also very many small integer constants, but of course there also could be others. >136 bit constants may not be implemented, but a size > code is reserved for that size. I'm still hoping for good 128-bit IEEE hardware float support. POWER has this, but stuck it on their their decimal float arithmetic, which is not highly performing... -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-30 13:53 +0000 |
| Message-ID | <45KMQ.86733$P8zb.46225@fx04.iad> |
| In reply to | #113882 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Robert Finch <robfi680@gmail.com> schrieb: >> On 2025-10-29 2:15 p.m., Thomas Koenig wrote: >>> Robert Finch <robfi680@gmail.com> schrieb: >>>> Started working on yet another CPU – Qupls4. Fixed 40-bit instructions, >>>> 64 GPRs. GPRs may be used in pairs for 128-bit ops. Registers are named >>>> as if there were 32 GPRs, A0 (arg 0 register is r1) and A0H (arg 0 high >>>> is r33). Sameo for other registers. GPRs may contain either integer or >>>> floating-point values. >>> >>> I understand the temptation to go for more bits :-) What is your >>> instruction alignment? Bytewise so 40 bits fit, or do you have some >>> alignment that the first instruction of a cache line is always aligned? >> >> The 40-bit instructions are byte aligned. This does add more shifting in >> the align stage. Once shifted though instructions are easily peeled off >> from fixed positions. One consequence is jump targets must be byte >> aligned OR routines could be required to be 32-bit aligned for instance.> > >That raises an interesting question. If you want to align a branch >target on a 32-bit boundary, or even a cache line, how do you fill >up the rest? If all instructions are 40 bits, you cannot have a >NOP that is not 40 bits, so there would need to be a jump before >a gap that is does not fit 40 bits. iCache lines could be a multiple of 5-bytes in size (e.g. 80 bytes instead of 64).
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-10-30 17:58 +0000 |
| Message-ID | <10e090a$3s77a$1@dont-email.me> |
| In reply to | #113883 |
Scott Lurndal <scott@slp53.sl.home> schrieb: > Thomas Koenig <tkoenig@netcologne.de> writes: >>Robert Finch <robfi680@gmail.com> schrieb: >>> On 2025-10-29 2:15 p.m., Thomas Koenig wrote: >>>> Robert Finch <robfi680@gmail.com> schrieb: >>>>> Started working on yet another CPU – Qupls4. Fixed 40-bit instructions, >>>>> 64 GPRs. GPRs may be used in pairs for 128-bit ops. Registers are named >>>>> as if there were 32 GPRs, A0 (arg 0 register is r1) and A0H (arg 0 high >>>>> is r33). Sameo for other registers. GPRs may contain either integer or >>>>> floating-point values. >>>> >>>> I understand the temptation to go for more bits :-) What is your >>>> instruction alignment? Bytewise so 40 bits fit, or do you have some >>>> alignment that the first instruction of a cache line is always aligned? >>> >>> The 40-bit instructions are byte aligned. This does add more shifting in >>> the align stage. Once shifted though instructions are easily peeled off >>> from fixed positions. One consequence is jump targets must be byte >>> aligned OR routines could be required to be 32-bit aligned for instance.> >> >>That raises an interesting question. If you want to align a branch >>target on a 32-bit boundary, or even a cache line, how do you fill >>up the rest? If all instructions are 40 bits, you cannot have a >>NOP that is not 40 bits, so there would need to be a jump before >>a gap that is does not fit 40 bits. > > iCache lines could be a multiple of 5-bytes in size (e.g. 80 bytes > instead of 64). There is a cache level (L2 usually, I believe) when icache and dcache are no longer separate. Wouldn't this cause problemso or inefficiencies? -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-10-30 22:06 +0000 |
| Message-ID | <1761861995-5857@newsgrouper.org> |
| In reply to | #113888 |
Thomas Koenig <tkoenig@netcologne.de> posted: > Scott Lurndal <scott@slp53.sl.home> schrieb: > > Thomas Koenig <tkoenig@netcologne.de> writes: > >>Robert Finch <robfi680@gmail.com> schrieb: > >>> On 2025-10-29 2:15 p.m., Thomas Koenig wrote: > >>>> Robert Finch <robfi680@gmail.com> schrieb: > >>>>> Started working on yet another CPU – Qupls4. Fixed 40-bit instructions, > >>>>> 64 GPRs. GPRs may be used in pairs for 128-bit ops. Registers are named > >>>>> as if there were 32 GPRs, A0 (arg 0 register is r1) and A0H (arg 0 high > >>>>> is r33). Sameo for other registers. GPRs may contain either integer or > >>>>> floating-point values. > >>>> > >>>> I understand the temptation to go for more bits :-) What is your > >>>> instruction alignment? Bytewise so 40 bits fit, or do you have some > >>>> alignment that the first instruction of a cache line is always aligned? > >>> > >>> The 40-bit instructions are byte aligned. This does add more shifting in > >>> the align stage. Once shifted though instructions are easily peeled off > >>> from fixed positions. One consequence is jump targets must be byte > >>> aligned OR routines could be required to be 32-bit aligned for instance.> > >> > >>That raises an interesting question. If you want to align a branch > >>target on a 32-bit boundary, or even a cache line, how do you fill > >>up the rest? If all instructions are 40 bits, you cannot have a > >>NOP that is not 40 bits, so there would need to be a jump before > >>a gap that is does not fit 40 bits. > > > > iCache lines could be a multiple of 5-bytes in size (e.g. 80 bytes > > instead of 64). > > There is a cache level (L2 usually, I believe) when icache and > dcache are no longer separate. Wouldn't this cause problems > or inefficiencies? Consider trying to invalidate an ICache line--this requires looking at 2 DCache lines to see if they, too, need invalidation. Consider self-modifying code, the data stream overwrites an instruction, then later the FETCH engine runs over the modified line, but the modified line is 64-bytes of the needed 80-bytes, so you take a hit and a miss on a single fetch. It also prevents SNARFing updates to ICache instructions, unless the SNARFed data is entirely retained in a single ICache line.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-10-29 18:33 +0000 |
| Message-ID | <1761762826-5857@newsgrouper.org> |
| In reply to | #113862 |
Robert Finch <robfi680@gmail.com> posted:
> Started working on yet another CPU – Qupls4. Fixed 40-bit instructions,
> 64 GPRs. GPRs may be used in pairs for 128-bit ops. Registers are named
> as if there were 32 GPRs, A0 (arg 0 register is r1) and A0H (arg 0 high
> is r33). Sameo for other registers. GPRs may contain either integer or
> floating-point values.
>
> Going with a bit result vector in any GPR for compares, then a branch on
> bit-set/clear for conditional branches. Might also include branch true /
> false.
I have both the bit-vector compare and branch, but also a compare to zero
and branch as a single instruction. I suggest you should too, if for no
other reason than:
if( p && p->next )
> Using operand routing for immediate constants and an operation size for
> the instruction. Constants and operation size may be specified
> independently. With 40-bit instruction words, constants may be 10,50,90
> or 130 bits.
My 66000 allows for occasional use of 128-bit values but is designed mainly
for 64-bit and smaller.
With 32-bit instructions, I provide, {5, 16, 32, and 64}-bit constants.
Just last week we discovered a case where HW can do a better job than SW.
Previously, the compiler would emit:
CVTfd Rt,Rf
FMUL Rt,Rt,#1.425D0
CVTdf Rd,Rt
Which is subject to double rounding once at the FMUL and again at the
down conversion. I though about the problem and it seems fairly easy
to gate the 24-bit fraction into the multiplier tree along with the
53-bit fraction of the constant, and then normalize and round the
result dropping out of the tree--avoiding the double rounding case.
Now, the compiler emits:
FMULf Rd,Rf,#1.425D0
saving 2 instructions alongwith the higher precision.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-10-29 18:20 -0400 |
| Message-ID | <10du403$37sgq$2@dont-email.me> |
| In reply to | #113871 |
On 2025-10-29 2:33 p.m., MitchAlsup wrote:
>
> Robert Finch <robfi680@gmail.com> posted:
>
>> Started working on yet another CPU – Qupls4. Fixed 40-bit instructions,
>> 64 GPRs. GPRs may be used in pairs for 128-bit ops. Registers are named
>> as if there were 32 GPRs, A0 (arg 0 register is r1) and A0H (arg 0 high
>> is r33). Sameo for other registers. GPRs may contain either integer or
>> floating-point values.
>>
>> Going with a bit result vector in any GPR for compares, then a branch on
>> bit-set/clear for conditional branches. Might also include branch true /
>> false.
>
> I have both the bit-vector compare and branch, but also a compare to zero
> and branch as a single instruction. I suggest you should too, if for no
> other reason than:
>
> if( p && p->next )
>
Yes, I was going to have at least branch on register 0 (false) 1 (true)
as there is encoding room to support it. It does add more cases in the
branch eval, but is probably well worth it.
>> Using operand routing for immediate constants and an operation size for
>> the instruction. Constants and operation size may be specified
>> independently. With 40-bit instruction words, constants may be 10,50,90
>> or 130 bits.
>
> My 66000 allows for occasional use of 128-bit values but is designed mainly
> for 64-bit and smaller.
>
Following the same philosophy. Expecting only some use for 128-bit
floats. Integers can only handle 8,16,32, or 64-bits.
> With 32-bit instructions, I provide, {5, 16, 32, and 64}-bit constants.
>
> Just last week we discovered a case where HW can do a better job than SW.
> Previously, the compiler would emit:
>
> CVTfd Rt,Rf
> FMUL Rt,Rt,#1.425D0
> CVTdf Rd,Rt
>
> Which is subject to double rounding once at the FMUL and again at the
> down conversion. I though about the problem and it seems fairly easy
> to gate the 24-bit fraction into the multiplier tree along with the
> 53-bit fraction of the constant, and then normalize and round the
> result dropping out of the tree--avoiding the double rounding case.
>
> Now, the compiler emits:
>
> FMULf Rd,Rf,#1.425D0
>
> saving 2 instructions alongwith the higher precision.
Improves the accuracy? of algorithms, but seems a bit specific to me.
Are there other instruction sequence where double-rounding would be good
to avoid? Seems like HW could detect the sequence and fuse the instructions.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-10-30 16:09 +0000 |
| Message-ID | <1761840540-5857@newsgrouper.org> |
| In reply to | #113878 |
Robert Finch <robfi680@gmail.com> posted:
> On 2025-10-29 2:33 p.m., MitchAlsup wrote:
> >
> > Robert Finch <robfi680@gmail.com> posted:
> >
> >> Started working on yet another CPU – Qupls4. Fixed 40-bit instructions,
> >> 64 GPRs. GPRs may be used in pairs for 128-bit ops. Registers are named
> >> as if there were 32 GPRs, A0 (arg 0 register is r1) and A0H (arg 0 high
> >> is r33). Sameo for other registers. GPRs may contain either integer or
> >> floating-point values.
> >>
> >> Going with a bit result vector in any GPR for compares, then a branch on
> >> bit-set/clear for conditional branches. Might also include branch true /
> >> false.
> >
> > I have both the bit-vector compare and branch, but also a compare to zero
> > and branch as a single instruction. I suggest you should too, if for no
> > other reason than:
> >
> > if( p && p->next )
> >
>
> Yes, I was going to have at least branch on register 0 (false) 1 (true)
> as there is encoding room to support it. It does add more cases in the
> branch eval, but is probably well worth it.
> >> Using operand routing for immediate constants and an operation size for
> >> the instruction. Constants and operation size may be specified
> >> independently. With 40-bit instruction words, constants may be 10,50,90
> >> or 130 bits.
> >
> > My 66000 allows for occasional use of 128-bit values but is designed mainly
> > for 64-bit and smaller.
> >
>
> Following the same philosophy. Expecting only some use for 128-bit
> floats. Integers can only handle 8,16,32, or 64-bits.
>
> > With 32-bit instructions, I provide, {5, 16, 32, and 64}-bit constants.
> >
> > Just last week we discovered a case where HW can do a better job than SW.
> > Previously, the compiler would emit:
> >
> > CVTfd Rt,Rf
> > FMUL Rt,Rt,#1.425D0
> > CVTdf Rd,Rt
> >
> > Which is subject to double rounding once at the FMUL and again at the
> > down conversion. I though about the problem and it seems fairly easy
> > to gate the 24-bit fraction into the multiplier tree along with the
> > 53-bit fraction of the constant, and then normalize and round the
> > result dropping out of the tree--avoiding the double rounding case.
> >
> > Now, the compiler emits:
> >
> > FMULf Rd,Rf,#1.425D0
> >
> > saving 2 instructions along with the higher precision.
>
> Improves the accuracy? of algorithms, but seems a bit specific to me.
It is down in the 1% footprint area.
> Are there other instruction sequence where double-rounding would be good
> to avoid?
Back when I joined Moto (1983) there was a lot of talk about double
roundings and how it could screw up various algorithms but mainly in
the 64-bit versus 80-bit stuff of 68881, where you got 11-more bits
of precision and thus took a change of 2/2^10 of a double rounding.
Today with 32-bit versus 64-bit you take a chance of 2/2^28 so the
problem is greatly ameliorated although technically still present.
The problem arises due to a cross products of various {machine,
language, compiler} features not working "all ends towards the middle".
LLVM promotes FP calculations with a constant to 64-bits whenever the
constant cannot be represented exactly in 32-bits. {Strike one}
C makes no <useful> statements about precision of calculation control.
{strike two}
HW almost never provides mixed mode calculations which provide the
means to avoid the double rounding. {strike three}
So, technically, My 66000 does not provide general-mixed-mode FP,
but I wrote a special rule to allow for larger constants used with
narrower registers to cover exactly this case. {It also saves 2 CVT
instructions (latency and footprint).
> Seems like HW could detect the sequence and fuse the instructions.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-10-31 21:09 +0100 |
| Message-ID | <10e351k$p4qs$1@dont-email.me> |
| In reply to | #113884 |
MitchAlsup wrote: > > Robert Finch <robfi680@gmail.com> posted: >> Improves the accuracy? of algorithms, but seems a bit specific to me. > > It is down in the 1% footprint area. > >> Are there other instruction sequence where double-rounding would be good >> to avoid? > > Back when I joined Moto (1983) there was a lot of talk about double > roundings and how it could screw up various algorithms but mainly in > the 64-bit versus 80-bit stuff of 68881, where you got 11-more bits > of precision and thus took a change of 2/2^10 of a double rounding. > Today with 32-bit versus 64-bit you take a chance of 2/2^28 so the > problem is greatly ameliorated although technically still present. Actually, for the five required basic operations, you can always do the op in the next higher precision, then round again down to the target, and get exactly the same result. This is because the mantissa lengths (including the hidden bit) increase to at least 2n+2: f16 1:5:10 (1+10=11, 11*2+2 = 22) f32 1:8:23 (1+23=24, 24*2+2 = 50) f64 1:11:52 (1+52=53, 53*2+2 = 108) f128 1:15:112 (1+112=113) You can however NOT use f128 FMUL + FADD to emulate f64 FMAC, since that would require a triple sized mantissa. The Intel+Motorola 80-bit format was a bastard that made it effectively impossible to produce bit-for-bit identical results even when the FPU was set to 64-bit precision. 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-01 18:19 +0000 |
| Message-ID | <1762021188-5857@newsgrouper.org> |
| In reply to | #113897 |
Terje Mathisen <terje.mathisen@tmsw.no> posted: > MitchAlsup wrote: > > > > Robert Finch <robfi680@gmail.com> posted: > >> Improves the accuracy? of algorithms, but seems a bit specific to me. > > > > It is down in the 1% footprint area. > > > >> Are there other instruction sequence where double-rounding would be good > >> to avoid? > > > > Back when I joined Moto (1983) there was a lot of talk about double > > roundings and how it could screw up various algorithms but mainly in > > the 64-bit versus 80-bit stuff of 68881, where you got 11-more bits > > of precision and thus took a change of 2/2^10 of a double rounding. > > Today with 32-bit versus 64-bit you take a chance of 2/2^28 so the > > problem is greatly ameliorated although technically still present. > > Actually, for the five required basic operations, you can always do the > op in the next higher precision, then round again down to the target, > and get exactly the same result. https://guillaume.melquiond.fr/doc/05-imacs17_1-article.pdf > This is because the mantissa lengths (including the hidden bit) increase > to at least 2n+2: > > f16 1:5:10 (1+10=11, 11*2+2 = 22) > f32 1:8:23 (1+23=24, 24*2+2 = 50) > f64 1:11:52 (1+52=53, 53*2+2 = 108) > f128 1:15:112 (1+112=113) > > You can however NOT use f128 FMUL + FADD to emulate f64 FMAC, since that > would require a triple sized mantissa. > > The Intel+Motorola 80-bit format was a bastard that made it effectively > impossible to produce bit-for-bit identical results even when the FPU > was set to 64-bit precision. > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-11-01 21:08 +0000 |
| Message-ID | <10e5ssj$1j7qg$1@dont-email.me> |
| In reply to | #113899 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > > Terje Mathisen <terje.mathisen@tmsw.no> posted: >> Actually, for the five required basic operations, you can always do the >> op in the next higher precision, then round again down to the target, >> and get exactly the same result. > > https://guillaume.melquiond.fr/doc/05-imacs17_1-article.pdf The PowerISA version 3.0 introduced rounding to odd for its 128-bit floating point arithmetic, for that very reason (I assume). -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-11-02 11:36 +0100 |
| Message-ID | <10e7c7l$2176q$1@dont-email.me> |
| In reply to | #113901 |
Thomas Koenig wrote: > MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: >> >> Terje Mathisen <terje.mathisen@tmsw.no> posted: > >>> Actually, for the five required basic operations, you can always do the >>> op in the next higher precision, then round again down to the target, >>> and get exactly the same result. >> >> https://guillaume.melquiond.fr/doc/05-imacs17_1-article.pdf > > The PowerISA version 3.0 introduced rounding to odd for its 128-bit > floating point arithmetic, for that very reason (I assume). Rounding to odd is basically the same as rounding to sticky, i.e if there are any trailing 1 bits in the exact result, then put that in the ulp position. We have known since before the 1978 ieee754 standard that guard+sticky (plus sign and ulp) is enough to get the rounding correct in all modes. The single exception is when rounding up from the maximum magnitude value to inf should be suppressed, there you do in fact need to check all the bits. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-02 15:56 +0200 |
| Message-ID | <20251102155612.00001ea0@yahoo.com> |
| In reply to | #113903 |
On Sun, 2 Nov 2025 11:36:36 +0100 Terje Mathisen <terje.mathisen@tmsw.no> wrote: > Thomas Koenig wrote: > > MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > >> > >> Terje Mathisen <terje.mathisen@tmsw.no> posted: > > > >>> Actually, for the five required basic operations, you can always > >>> do the op in the next higher precision, then round again down to > >>> the target, and get exactly the same result. > >> > >> https://guillaume.melquiond.fr/doc/05-imacs17_1-article.pdf > > > > The PowerISA version 3.0 introduced rounding to odd for its 128-bit > > floating point arithmetic, for that very reason (I assume). > > Rounding to odd is basically the same as rounding to sticky, i.e if > there are any trailing 1 bits in the exact result, then put that in > the ulp position. > > We have known since before the 1978 ieee754 standard that > guard+sticky (plus sign and ulp) is enough to get the rounding > correct in all modes. > > The single exception is when rounding up from the maximum magnitude > value to inf should be suppressed, there you do in fact need to check > all the bits. > > Terje > People use names like guard and sticky bits and sometimes also rounding bit (e.g. in Wikipedia article) without explanation, as if everybody had agreed about what they mean. But I don't think that everybody really agree. Shockingly, an absence of strict definitions apples even to most widely refereed article of David Goldberg "What Every Computer Scientist Should Know About Floating-Point Arithmetic". It seems, people copy the name of the article one from another, but very small fraction of them bothered to actually read it.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-11-02 16:09 +0100 |
| Message-ID | <10e7s6n$264vh$1@dont-email.me> |
| In reply to | #113904 |
Michael S wrote: > On Sun, 2 Nov 2025 11:36:36 +0100 > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > >> Thomas Koenig wrote: >>> MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: >>>> >>>> Terje Mathisen <terje.mathisen@tmsw.no> posted: >>> >>>>> Actually, for the five required basic operations, you can always >>>>> do the op in the next higher precision, then round again down to >>>>> the target, and get exactly the same result. >>>> >>>> https://guillaume.melquiond.fr/doc/05-imacs17_1-article.pdf >>> >>> The PowerISA version 3.0 introduced rounding to odd for its 128-bit >>> floating point arithmetic, for that very reason (I assume). >> >> Rounding to odd is basically the same as rounding to sticky, i.e if >> there are any trailing 1 bits in the exact result, then put that in >> the ulp position. >> >> We have known since before the 1978 ieee754 standard that >> guard+sticky (plus sign and ulp) is enough to get the rounding >> correct in all modes. >> >> The single exception is when rounding up from the maximum magnitude >> value to inf should be suppressed, there you do in fact need to check >> all the bits. >> >> Terje >> > > People use names like guard and sticky bits and sometimes also rounding > bit (e.g. in Wikipedia article) without explanation, as if everybody > had agreed about what they mean. But I don't think that everybody > really agree. Within the 754 working group the definition is totally clear: Guard is the first bit after the normal mantissa. Sticky is the bit following the guard bit, it is generated by OR'ing together all subsequent bits in the exact/infinitely precise result. I.e if an exact result is exactly halfway between two representable numbers, the Guard bit will be set and Sticky unset. Ulp (Unit in Last Place)) is the final mantissa bit Sign is of course the sign in the Sign-Magnitude format used for all fp numbers. This means that those four bits in combination suffices to separate between rounding directions: Default rounding is nearest or even: (In this case Sign does not matter.) Ulp | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | Guard | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | Sticky | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | Round | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-02 18:14 +0200 |
| Message-ID | <20251102181454.0000412f@yahoo.com> |
| In reply to | #113907 |
On Sun, 2 Nov 2025 16:09:10 +0100 Terje Mathisen <terje.mathisen@tmsw.no> wrote: > Michael S wrote: > > On Sun, 2 Nov 2025 11:36:36 +0100 > > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > > > >> Thomas Koenig wrote: > >>> MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > >>>> > >>>> Terje Mathisen <terje.mathisen@tmsw.no> posted: > >>> > >>>>> Actually, for the five required basic operations, you can always > >>>>> do the op in the next higher precision, then round again down to > >>>>> the target, and get exactly the same result. > >>>> > >>>> https://guillaume.melquiond.fr/doc/05-imacs17_1-article.pdf > >>> > >>> The PowerISA version 3.0 introduced rounding to odd for its > >>> 128-bit floating point arithmetic, for that very reason (I > >>> assume). > >> > >> Rounding to odd is basically the same as rounding to sticky, i.e if > >> there are any trailing 1 bits in the exact result, then put that in > >> the ulp position. > >> > >> We have known since before the 1978 ieee754 standard that > >> guard+sticky (plus sign and ulp) is enough to get the rounding > >> correct in all modes. > >> > >> The single exception is when rounding up from the maximum magnitude > >> value to inf should be suppressed, there you do in fact need to > >> check all the bits. > >> > >> Terje > >> > > > > People use names like guard and sticky bits and sometimes also > > rounding bit (e.g. in Wikipedia article) without explanation, as if > > everybody had agreed about what they mean. But I don't think that > > everybody really agree. > > Within the 754 working group the definition is totally clear: > I could believe that there is consensus about these names between current members of 754 working group. But nothing of that sort is mentioned in the text of the Standard. Which among other things means that you can not rely on being understood even by new members of 754 working group. > Guard is the first bit after the normal mantissa. > > Sticky is the bit following the guard bit, it is generated by OR'ing > together all subsequent bits in the exact/infinitely precise result. > > I.e if an exact result is exactly halfway between two representable > numbers, the Guard bit will be set and Sticky unset. > > Ulp (Unit in Last Place)) is the final mantissa bit > > Sign is of course the sign in the Sign-Magnitude format used for all > fp numbers. > > This means that those four bits in combination suffices to separate > between rounding directions: > > Default rounding is nearest or even: (In this case Sign does not > matter.) > > Ulp | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | > Guard | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | > Sticky | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | > > Round | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | > > Terje > I mostly use ULP/Guard/Sticky in the same meaning. Except when I use them, esp. Guard, differently. Given the choice, [in the context of binary floating point] I'd rather not use the term 'guard' at all. Names like 'rounding bit' or 'half-ULP' are far more self-describing.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-11-02 20:19 +0100 |
| Message-ID | <10e8arf$2b2en$1@dont-email.me> |
| In reply to | #113908 |
Michael S wrote: > On Sun, 2 Nov 2025 16:09:10 +0100 > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > >> Michael S wrote: >>> On Sun, 2 Nov 2025 11:36:36 +0100 >>> Terje Mathisen <terje.mathisen@tmsw.no> wrote: >>> >>>> Thomas Koenig wrote: >>>>> MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: >>>>>> >>>>>> Terje Mathisen <terje.mathisen@tmsw.no> posted: >>>>> >>>>>>> Actually, for the five required basic operations, you can always >>>>>>> do the op in the next higher precision, then round again down to >>>>>>> the target, and get exactly the same result. >>>>>> >>>>>> https://guillaume.melquiond.fr/doc/05-imacs17_1-article.pdf >>>>> >>>>> The PowerISA version 3.0 introduced rounding to odd for its >>>>> 128-bit floating point arithmetic, for that very reason (I >>>>> assume). >>>> >>>> Rounding to odd is basically the same as rounding to sticky, i.e if >>>> there are any trailing 1 bits in the exact result, then put that in >>>> the ulp position. >>>> >>>> We have known since before the 1978 ieee754 standard that >>>> guard+sticky (plus sign and ulp) is enough to get the rounding >>>> correct in all modes. >>>> >>>> The single exception is when rounding up from the maximum magnitude >>>> value to inf should be suppressed, there you do in fact need to >>>> check all the bits. >>>> >>>> Terje >>>> >>> >>> People use names like guard and sticky bits and sometimes also >>> rounding bit (e.g. in Wikipedia article) without explanation, as if >>> everybody had agreed about what they mean. But I don't think that >>> everybody really agree. >> >> Within the 754 working group the definition is totally clear: >> > > I could believe that there is consensus about these names between > current members of 754 working group. But nothing of that sort is > mentioned in the text of the Standard. Which among other things means > that you can not rely on being understood even by new members of 754 > working group. > >> Guard is the first bit after the normal mantissa. >> >> Sticky is the bit following the guard bit, it is generated by OR'ing >> together all subsequent bits in the exact/infinitely precise result. >> >> I.e if an exact result is exactly halfway between two representable >> numbers, the Guard bit will be set and Sticky unset. >> >> Ulp (Unit in Last Place)) is the final mantissa bit >> >> Sign is of course the sign in the Sign-Magnitude format used for all >> fp numbers. >> >> This means that those four bits in combination suffices to separate >> between rounding directions: >> >> Default rounding is nearest or even: (In this case Sign does not >> matter.) >> >> Ulp | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | >> Guard | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | >> Sticky | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | >> >> Round | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | >> >> Terje >> > > I mostly use ULP/Guard/Sticky in the same meaning. Except when I use > them, esp. Guard, differently. > Given the choice, [in the context of binary floating point] I'd rather > not use the term 'guard' at all. Names like 'rounding bit' or > 'half-ULP' are far more self-describing. Guard also works for decimal FP, where you need a single Sticky bit if the Guard digit is equal to 5. If you work with the binary representation for decimal, then you just need two extra bits, just like BFP. Correct rounding also work when Guard temporarily contains more than one bit, possibly due to normalization, but you would normally squash this down (Guard, Sticky) by OR'ing any secondary guard bits into Sticky. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-11-03 15:22 +0000 |
| Message-ID | <8N3OQ.314438$T_d8.162511@fx44.iad> |
| In reply to | #113909 |
Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Michael S wrote:
>> I mostly use ULP/Guard/Sticky in the same meaning. Except when I use
>> them, esp. Guard, differently.
>> Given the choice, [in the context of binary floating point] I'd rather
>> not use the term 'guard' at all. Names like 'rounding bit' or
>> 'half-ULP' are far more self-describing.
>
>Guard also works for decimal FP, where you need a single Sticky bit if
>the Guard digit is equal to 5.
By decimal FP, do you mean BCD? I.e. a format where
you have a BCD exponent sign digit (BCD 'C' or 'D')
followed by two BCD exponent digits, followed by a
mantissa sign digit ('C' or 'D') followed by a variable
number of mantissa digits (1 to 100)?
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-03 11:53 -0600 |
| Message-ID | <10eaq7m$329ol$1@dont-email.me> |
| In reply to | #113913 |
On 11/3/2025 9:22 AM, Scott Lurndal wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> Michael S wrote:
>
>>> I mostly use ULP/Guard/Sticky in the same meaning. Except when I use
>>> them, esp. Guard, differently.
>>> Given the choice, [in the context of binary floating point] I'd rather
>>> not use the term 'guard' at all. Names like 'rounding bit' or
>>> 'half-ULP' are far more self-describing.
>>
>> Guard also works for decimal FP, where you need a single Sticky bit if
>> the Guard digit is equal to 5.
>
> By decimal FP, do you mean BCD? I.e. a format where
> you have a BCD exponent sign digit (BCD 'C' or 'D')
> followed by two BCD exponent digits, followed by a
> mantissa sign digit ('C' or 'D') followed by a variable
> number of mantissa digits (1 to 100)?
I would assume he meant something like either the newer IEEE-754 decimal
formats, or a decimal-FP format that MS had used in .NET, ...
The IEEE formats are generally one of:
Linear mantissa understood as decimal;
Groups of 10-bits, each used to encode 3 digits.
As Densely Packed Decimal.
With a power-of-10 exponent.
The .NET format was similar, except using groups of 32 bits as linear
values representing 9 digits.
When I looked at it before, the most practical way to me to support
something like this seemed to be to not do it directly in hardware, but
to support a subset of operations:
Operations to pack and unpack DPD into BCD;
Say: 64 bit value holds 15 BCD digits, mapped to 50 bits of DPD.
Some basic operations to help with arithmetic on BCD.
I partly implemented these as an experiment before, but then noted I
have basically no use case for Decimal-FP in my project.
And, ironically, the main benefit the helpers would have provided would
be to allow for faster Binary<->Decimal conversion. But, even then are
debatable, as Binary<->Decimal conversion isn't itself enough CPU time
to justify making it faster at the cost of needing to drag around BCD
helper instructions.
One downside is that there was no multiplier, so the BCD helpers would
need to be used to effectively implement a Radix-10 Shift-and-Add.
...
Though, it is debatable, something more like the .NET approach could
make more sense for a SW implementation.
If one wants to make the encoding more efficiently use the bits, a
hybrid approach could make sense, say:
Use 3 groups of 30 bits, and another group of 20 (6 digits)
Use an 17 bit linear exponent and sign bit.
This would be slightly cheaper to implement vs what is defined in the
standard (for the BID variant), and could achieve a similar effect
(though, with 33 digits rather than 34).
Internally, it could work similar to the .NET approach, just with a
little more up-front to pack/unpack the 30 bit components. The merit of
30 bit groups being that they map internally onto 32-bit integer
operations (which would also provide a space internally for carry/borrow
signaling in operations).
Most CPUs at least have native support for 32-bit integer math, and for
SW (on a 32/64 bit machine) this could be an easier chunking size than
10 bits. Someone could argue for 60 bit chunking on a 64-bit machine
(or, one 60 bit chunk, and a 50 bit chunk), but likely this wouldn't
save much over 30 bit chunking.
Also, 60-bit chunking would imply access to a 64*64->128 bit widening
multiply; which is asking more than 32*32->64. And, also precludes some
ways to more cheaply implement the divide/modulo step for each chunk
(*). So, it is likely in this sense 30 bit chunks could still be preferable.
*:
high=product>>30;
low=product-(high*1000000000LL);
if(low>=1000000000)
{ high++; low-=1000000000; }
Where, 60 bit chunking would require 128-bit math here.
Where, effectively, the multiply step is operating in radix-1-billion.
...
Still don't have much of a use-case though.
In general, Decimal-FP seems more like a solution in search of a problem.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-03 23:04 +0200 |
| Message-ID | <20251103230453.0000429e@yahoo.com> |
| In reply to | #113913 |
On Mon, 03 Nov 2025 15:22:44 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
> >Michael S wrote:
>
> >> I mostly use ULP/Guard/Sticky in the same meaning. Except when I
> >> use them, esp. Guard, differently.
> >> Given the choice, [in the context of binary floating point] I'd
> >> rather not use the term 'guard' at all. Names like 'rounding bit'
> >> or 'half-ULP' are far more self-describing.
> >
> >Guard also works for decimal FP, where you need a single Sticky bit
> >if the Guard digit is equal to 5.
>
> By decimal FP, do you mean BCD? I.e. a format where
> you have a BCD exponent sign digit (BCD 'C' or 'D')
> followed by two BCD exponent digits, followed by a
> mantissa sign digit ('C' or 'D') followed by a variable
> number of mantissa digits (1 to 100)?
I am pretty sure that by decimal FP Terje means decimal FP :-). As
defined in IEEE 754 (formerly it was in 854, but since 2008 it became a
part of the main standard).
IEEE 754 has two options for encoding of mantissa, IBM's DPD which is
a clever variation of Base 1000 and Intel's binary.
DPD encoding is considered preferable for hardware implementations
while binary encoding is easier for software implementations.
BCD is not an option, it's information density is insufficient to
supply required semantics in given size of container.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-11-04 15:19 +0000 |
| Message-ID | <MPoOQ.1421027$xYr1.460440@fx14.iad> |
| In reply to | #113918 |
Michael S <already5chosen@yahoo.com> writes:
>On Mon, 03 Nov 2025 15:22:44 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>> By decimal FP, do you mean BCD? I.e. a format where
>> you have a BCD exponent sign digit (BCD 'C' or 'D')
>> followed by two BCD exponent digits, followed by a
>> mantissa sign digit ('C' or 'D') followed by a variable
>> number of mantissa digits (1 to 100)?
>
>I am pretty sure that by decimal FP Terje means decimal FP :-). As
>defined in IEEE 754 (formerly it was in 854, but since 2008 it became a
>part of the main standard).
>IEEE 754 has two options for encoding of mantissa, IBM's DPD which is
>a clever variation of Base 1000 and Intel's binary.
>DPD encoding is considered preferable for hardware implementations
>while binary encoding is easier for software implementations.
>BCD is not an option, it's information density is insufficient to
>supply required semantics in given size of container.
How so? The B3500 supported 100 digit (400 bit) signed mantissa and
a two digit signed exponent using a BCD representation.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-04 17:41 +0200 |
| Message-ID | <20251104174107.00003056@yahoo.com> |
| In reply to | #113921 |
On Tue, 04 Nov 2025 15:19:08 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> Michael S <already5chosen@yahoo.com> writes:
> >On Mon, 03 Nov 2025 15:22:44 GMT
> >scott@slp53.sl.home (Scott Lurndal) wrote:
>
> >> By decimal FP, do you mean BCD? I.e. a format where
> >> you have a BCD exponent sign digit (BCD 'C' or 'D')
> >> followed by two BCD exponent digits, followed by a
> >> mantissa sign digit ('C' or 'D') followed by a variable
> >> number of mantissa digits (1 to 100)?
> >
> >I am pretty sure that by decimal FP Terje means decimal FP :-). As
> >defined in IEEE 754 (formerly it was in 854, but since 2008 it
> >became a part of the main standard).
> >IEEE 754 has two options for encoding of mantissa, IBM's DPD which is
> >a clever variation of Base 1000 and Intel's binary.
> >DPD encoding is considered preferable for hardware implementations
> >while binary encoding is easier for software implementations.
> >BCD is not an option, it's information density is insufficient to
> >supply required semantics in given size of container.
>
> How so? The B3500 supported 100 digit (400 bit) signed mantissa and
> a two digit signed exponent using a BCD representation.
What is not clear about 'in given size of container' ?
Semantics of IEEE Decimal128 call for 33 decimal digits + 1 binary bit
to be contained within 111 bits.
With BCD encoding one would need 133 bits.
Decimal32 and Decimal64 would suffer from similar mismatch, but those
formats probably not important. IMHO, IEEE defined them for sake of
completeness rather than because they are useful in real world.
[toc] | [prev] | [next] | [standalone]
Page 9 of 46 — ← Prev page 1 … 7 8 [9] 10 11 … 46 Next page →
Back to top | Article view | comp.arch
csiph-web