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 37 of 46 — ← Prev page 1 … 35 36 [37] 38 39 … 46 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-16 19:47 +0200 |
| Message-ID | <20251216194756.0000439a@yahoo.com> |
| In reply to | #114084 |
On Wed, 12 Nov 2025 11:47:34 +0200 Michael S <already5chosen@yahoo.com> wrote: > On Tue, 11 Nov 2025 21:34:08 -0600 > BGB <cr88192@gmail.com> wrote: > > > > Going to/from 128-bit integer adds a few "there be dragons here" > > issues regarding performance. > > > > Not really. > That is, conversions are not blazingly fast, but still much better > than any attempt to divide in any form of decimal. And helps to > preserve your sanity. > There is also psychological factor at play - your users expect > division and square root to be slower than other primitive FP > operations, so they are not disappointed. Possibly they are even > pleasantly surprised, when they find out that the difference in > throughput between division and multiplication is smaller than factor > 20-30 that they were accustomed to for 'double' on their 20 y.o. Intel > and AMD. > Today I tested speed of gcc implementation of Decimal128 (BID-encoded, of course) on Intel Core i7-14700. Average time in nsec: op Add Sub Mul Div P-Core 33 33 86 76 E-Core 46 48 121 108 Counter-intuitively, division is faster than multiplications. And both appear much slower than necessary.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-12-16 17:51 +0000 |
| Message-ID | <10hs670$2uaet$1@dont-email.me> |
| In reply to | #114358 |
Michael S <already5chosen@yahoo.com> schrieb: > Today I tested speed of gcc implementation of Decimal128 (BID-encoded, > of course) on Intel Core i7-14700. > Average time in nsec: > op Add Sub Mul Div > P-Core 33 33 86 76 > E-Core 46 48 121 108 > > Counter-intuitively, division is faster than multiplications. > And both appear much slower than necessary. Interesting. Could you provide the benchmark used? -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-17 12:02 +0200 |
| Message-ID | <20251217120212.00002ab0@yahoo.com> |
| In reply to | #114359 |
On Tue, 16 Dec 2025 17:51:28 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
> Michael S <already5chosen@yahoo.com> schrieb:
>
> > Today I tested speed of gcc implementation of Decimal128
> > (BID-encoded, of course) on Intel Core i7-14700.
> > Average time in nsec:
> > op Add Sub Mul Div
> > P-Core 33 33 86 76
> > E-Core 46 48 121 108
> >
> > Counter-intuitively, division is faster than multiplications.
> > And both appear much slower than necessary.
>
> Interesting. Could you provide the benchmark used?
// tb.cpp
#include <cstdio>
#include <cstdlib>
#include <cstdint>
#include <time.h>
#include <random>
#include <algorithm>
extern "C" {
void uut(void*, const void*, const void*);
};
static inline
uint64_t umulh(uint64_t a,uint64_t b) {
return uint64_t(((unsigned __int128)a * b)>>64);
}
int main(int , char** )
{
const int N_PAIRS = 1000000;
const int N_ITER = 17;
typedef unsigned __int128 u128;
std::vector<u128> src(N_PAIRS*2);
std::mt19937_64 prng(1);
const unsigned EXP_BIAS = 6143;
const unsigned EXP_SHIFT = 113;
for (int i = 0; i < N_PAIRS*2; ++i) {
// generate pseudo-random number in range [1e33:1e34-1]
const uint64_t RNG_LO = (long long)1e17;
const uint64_t RNG_HI = (long long)9e16;
const uint64_t BASE_HI = (long long)1e16;
uint64_t lo = umulh(prng(), RNG_LO); // [0:1e17-1]
uint64_t hi = umulh(prng(), RNG_HI) + BASE_HI; // [1e16:1e17-1]
u128 val = (u128)hi*RNG_LO + lo;
unsigned exp = EXP_BIAS + umulh(prng(), 50) - 25;
const u128 exp_val = (u128)exp << EXP_SHIFT;
src[i] = val | exp_val;
}
std::vector<long long> dt(N_ITER);
for (int it = 0; it < N_ITER; ++it) {
struct timespec t0;
clock_gettime(CLOCK_MONOTONIC, &t0);
u128 dummy1 = 0;
const u128* pSrc = src.data();
for (int i = 0; i < N_PAIRS; ++i) {
u128 rat;
uut(&rat, &pSrc[i*2+0], &pSrc[i*2+1]);
dummy1 ^= rat;
}
if (dummy1 == 42)
printf("Blue Moon\n");
struct timespec t1;
clock_gettime(CLOCK_MONOTONIC, &t1);
dt[it] = (t1.tv_sec - t0.tv_sec)*(long long)(1e9) + (long
long)t1.tv_nsec - (long long)t0.tv_nsec; }
// find median
std::nth_element(&dt[0], &dt[N_ITER/2], &dt[N_ITER]);
long long dt_med = dt[N_ITER/2];
printf("%.1f nsec\n", (double)dt_med / N_PAIRS);
return 0;
}
// end tb.cpp
// gcc_dec128add.c
#include <string.h>
void uut(void* pRes, const void* pA, const void* pB)
{
_Decimal128 a, b, res;
memcpy(&a, pA, sizeof(a));
memcpy(&b, pB, sizeof(b));
res = a + b;
memcpy(pRes, &res, sizeof(res));
}
// end gcc_dec128add.c
// gcc_dec128sub.c
#include <string.h>
void uut(void* pRes, const void* pA, const void* pB)
{
_Decimal128 a, b, res;
memcpy(&a, pA, sizeof(a));
memcpy(&b, pB, sizeof(b));
res = a - b;
memcpy(pRes, &res, sizeof(res));
}
// end gcc_dec128sub.c
// gcc_dec128mul.c
#include <string.h>
void uut(void* pRes, const void* pA, const void* pB)
{
_Decimal128 a, b, res;
memcpy(&a, pA, sizeof(a));
memcpy(&b, pB, sizeof(b));
res = a * b;
memcpy(pRes, &res, sizeof(res));
}
// end gcc_dec128mul.c
// gcc_dec128div.c
#include <string.h>
void uut(void* pRat, const void* pNum, const void* pDen)
{
_Decimal128 den, num, rat;
memcpy(&num, pNum, sizeof(num));
memcpy(&den, pDen, sizeof(den));
rat = num / den;
memcpy(pRat, &rat, sizeof(rat));
}
// end gcc_dec128div.c
Build script
COPT="-O2 -Wall -march=haswell -mtune=skylake"
mkdir -p obj
mkdir -p out
g++ -c $COPT tb.cpp -o obj/tb.o
gcc -c $COPT gcc_dec128add.c -o obj/gcc_dec128add.o
gcc -c $COPT gcc_dec128sub.c -o obj/gcc_dec128sub.o
gcc -c $COPT gcc_dec128mul.c -o obj/gcc_dec128mul.o
gcc -c $COPT gcc_dec128div.c -o obj/gcc_dec128div.o
g++ -s obj/tb.o obj/gcc_dec128add.o -o out/tst_add.exe
g++ -s obj/tb.o obj/gcc_dec128sub.o -o out/tst_sub.exe
g++ -s obj/tb.o obj/gcc_dec128mul.o -o out/tst_mul.exe
g++ -s obj/tb.o obj/gcc_dec128div.o -o out/tst_div.exe
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-12-18 21:33 -0500 |
| Subject | Re: Tonights Tradeoff - write port history |
| Message-ID | <10i2dh8$rvk6$1@dont-email.me> |
| In reply to | #114374 |
Tonight’s quandry. Can a register file write history be used in reservation stations to reduce the number of register read ports required on the register file? And would it be smaller, faster than adding register file ports? There are a couple of cases: 1) The operands were ready at time of queue. 2) The operands were not ready at time of queue. That means there must be an outstanding operation that at some point will update the register file. Operands that are valid at time of queue are stored in the re-order buffer temporarily until dispatch. So, it should be possible to update the operands in the reservation stations either from the instruction dispatch, or later when the value is written to the register file. An issue arises between queue and dispatch. If a value was updated in the register file between queue and dispatch then it will not be latched by the reservation station because it does not have the instruction yet. If the reservation station has the instruction already waiting then the register file write port can be used. Rather than having more register file read ports, I was thinking of having the reservation stations track (snoop) the register file write history using a tapped shift register. The only time that must be accounted for is between queue and dispatch. So, assuming that instructions dispatched within a certain time frame, then using write history could work. I was thinking a 64 deep shift register with several taps could be used to supply written values. It is going to be at least two clock cycles between queue and dispatch until operands/instructions are updated in the reservation stations. So, the first tap would be at shift 3. Then maybe taps at 6, 12, 24, and 64 clocks. There is not usually a huge amount of time between queue and dispatch, unless the functional unit is busy. I think the longest operation is <80 clocks, so in worst case a 128-deep shift register should work. LUTs can be turned into shift registers up to 64 bits IIRC. With four 64-bit write ports and 10 bit register tag about 300 LUTs would be required for each shift level. The history could be shared between several reservation stations.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-11-04 08:50 +0100 |
| Message-ID | <10ecb81$3g5cd$1@dont-email.me> |
| In reply to | #113913 |
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)?
No, I meant ieee754 DFP, where you either store the decimal digits in
packed modulo-1000 groups, or as a binary mantissa with a decimal
exponent/scaling value.
When you do math with these you have to handle all the required
(financial?) rounding modes.
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-03 19:03 +0000 |
| Message-ID | <1762196593-5857@newsgrouper.org> |
| In reply to | #113901 |
Thomas Koenig <tkoenig@netcologne.de> posted: > 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). Likely, My 66000 also has RNO and Round Nearest Random is defined but not yet available Round Away from Zero is also defined and available.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-11-05 01:41 -0500 |
| Message-ID | <10eerip$719b$1@dont-email.me> |
| In reply to | #113916 |
On 2025-11-03 2:03 p.m., MitchAlsup wrote: > > Thomas Koenig <tkoenig@netcologne.de> posted: > >> 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). > > Likely, My 66000 also has RNO and > Round Nearest Random is defined but not yet available > Round Away from Zero is also defined and available. Round nearest random? How about round externally guided (RXG) by an input signal? For instance, the rounding could come from a feedback filter of some sort.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-05 20:30 +0000 |
| Message-ID | <1762374605-5857@newsgrouper.org> |
| In reply to | #113939 |
Robert Finch <robfi680@gmail.com> posted: > On 2025-11-03 2:03 p.m., MitchAlsup wrote: > > > > Thomas Koenig <tkoenig@netcologne.de> posted: > > > >> 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). > > > > Likely, My 66000 also has RNO and > > Round Nearest Random is defined but not yet available > > Round Away from Zero is also defined and available. > > Round nearest random? Another unbiased rounding mode. Not yet available because I don't have a truly random source to guide the rounding. > How about round externally guided (RXG) by an > input signal? I guess that would be OK, but you could not make the statement that the rounding mode was unbiased. > For instance, the rounding could come from a feedback > filter of some sort. Sure, just you can state "unbiased".
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-11-02 09:39 -0500 |
| Message-ID | <10e7qev$25g0g$1@dont-email.me> |
| In reply to | #108284 |
Contemplating having conditional branch instructions branch to a target value in a register instead of using a displacement. I think this has about the same code density as having a branch to a displacement from the IP. Using a fused compare-and-branch instruction for Qupls4 there is not enough room in the instruction for a large branch displacement (10 bits). So, my thought is to branch to a register value instead. There is already an add-to-instruction-pointer instruction that can be used to generate relative addresses. By moving the register load outside of a loop, the dynamic instruction count can be reduced. I think this solution is a bit better than having compare and branch as two separate instructions, or having an extended constant added to the branch instruction. One gotcha may be that the branch target needs to be predicted as it cannot be calculated earlier in the pipeline. The 10-bit displacement format could also be supported, but it is yet another branch instruction format. I may leave holes in the instruction set for future support, but I think it is best to start with just a single format. Code: AIPSI R3,1234 ; add displacement to IP and store in R3 (hoist-able) BLT R1,R2,R3 ; branch to R3 if R1 < R2 Versus: CMP R3,R1,R2 BLT R3,displacement
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-11-03 18:47 +0000 |
| Message-ID | <10eatc8$3385d$1@dont-email.me> |
| In reply to | #113905 |
Robert Finch <robfi680@gmail.com> schrieb: > Contemplating having conditional branch instructions branch to a target > value in a register instead of using a displacement. > > I think this has about the same code density as having a branch to a > displacement from the IP. Should be possible. A question is if you want to have a special register for that (like POWER's link register), tell the CPU what the target is (like VEC in My66000) or just use a general purpose register with a general-purpose instruction. > Using a fused compare-and-branch instruction for Qupls4 Is that the name of your architecture, or an instruction? (That may have been mentioned upthread, in that case I don't remember). > there is not > enough room in the instruction for a large branch displacement (10 > bits). So, my thought is to branch to a register value instead. > There is already an add-to-instruction-pointer instruction that can be > used to generate relative addresses. That makes sense. > By moving the register load outside of a loop, the dynamic instruction > count can be reduced. I think this solution is a bit better than having > compare and branch as two separate instructions, or having an extended > constant added to the branch instruction. Are you talking about a normal loop condition or a jump out of a loop? > One gotcha may be that the branch target needs to be predicted as it > cannot be calculated earlier in the pipeline. If you use a link register or a special instruction, the CPU could do that. > The 10-bit displacement format could also be supported, but it is yet > another branch instruction format. I may leave holes in the instruction > set for future support, but I think it is best to start with just a > single format. > > Code: > AIPSI R3,1234 ; add displacement to IP and store in R3 (hoist-able) > BLT R1,R2,R3 ; branch to R3 if R1 < R2 > > Versus: > CMP R3,R1,R2 > BLT R3,displacement -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-11-04 07:50 +0000 |
| Subject | branch splitting (was: Tonights Tradeoff) |
| Message-ID | <2025Nov4.085033@mips.complang.tuwien.ac.at> |
| In reply to | #113915 |
Thomas Koenig <tkoenig@netcologne.de> writes:
>Should be possible. A question is if you want to have a special
>register for that (like POWER's link register),
There is this idea of splitting an (indirect) branch into a
prepare-to-branch instruction and a take-branch instruction. The
prepare-to-branch instruction announces the branch target to the CPU,
and Power's mtlr and mtctr are examples of that (somewhat muddled by
the fact that the ctr register can also be used for counted loops as
well as for indirect branches), and IA-64's branch-target registers
and the instructions that move there are another example. AFAIK SPARC
acquired something in this direction (touted as good for accelerating
Java) in the early 2000s. The take-branch instruction on Power is
blr/bctr.
I used to think that this kind of splitting is a good idea, and it is
certainly better than a branch-delay slot or a branch with a fixed
number of delay slots.
But in practice, it turned out that Intel and AMD processors had much
better performance on indirect-branch intensive workloads in the early
2000s without this architectural feature. What happened?
The IA-32 and AMD64 microarchitects implemented indirect-branch
prediction; in the early 2000s it was based on the BTB, which these
CPUs need for fast direct branching anyway. They were not content
with that, and have implemented history-based indirect branch
predictors in the meantime, which improve the performance even more.
By contrast, Power and IA-64 implementations apparently rely on
getting the target-address early enough, and typically predict that
the indirect branch will go to the current contents of the
branch-target register when the front-end encounters the take-branch
instruction; but if the prepare-to-branch instruction is in the
instruction stream just before the take-branch instruction, it takes
several cycles until the prepare-to-branch actually can move the
target to the branch-target register. In case of an OoO
implementation, the number of cycles tends to be longer. It's
essentially a similar latency as in a branch misprediction.
That all would not be so bad, if the compilers would move the
prepare-to-branch instructions sufficiently far away from the
take-branch instruction. But gcc certainly has not done so whenever I
looked at code it generated for PowerPC or IA-64.
Here is some data for code that focusses on indirect-branch
performance (with indirect branches that vary their targets), from
<https://www.complang.tuwien.ac.at/forth/threading/>:
Numbers are cycles per indirect branch, smaller is faster, the years
are the release dates of the CPUs:
First, machines from the early 2000s:
sub- in- repl.
routine direct direct switch call switch CPU year
9.6 8.0 9.5 23.1 38.6 Alpha 21264B 800MHz ~2000
4.7 8.1 9.5 19.0 21.3 Pentium III 1000MHz 2000
18.4 8.5 10.3 24.5 29.0 Athlon 1200MHz 2000
8.6 14.2 15.3 23.4 30.2 Pentium 4 2.26 2002
13.3 10.3 12.3 15.7 18.7 Itanium 2 (McKinley) 900MHz 2002
5.7 9.2 12.3 16.3 17.9 PPC 7447A 1066MHz 2004
7.8 12.8 12.9 30.2 39.0 PPC 970 2000MHz 2002
Ignore the first column (it uses call and return), the others all need
an indirect branch or indirect call ("call" column) per dispatch, with
varying amounts of other instructions; "direct" needs the least
instructions.
And here are results with some newer machines:
sub- in- repl.
routine direct direct switch call switch CPU year
4.9 5.6 4.3 5.1 7.64 Pentium M 755 2000MHz 2004
4.4 2.2 2.0 20.3 18.6 3.3 Xeon E3-1220 3100MHz 2011
4.0 2.3 2.3 4.0 5.1 3.5 Core i7-4790K 4400MHz 2013
4.2 2.1 2.0 4.9 5.2 2.7 Core i5-6600K 4000MHz 2015
5.7 3.2 3.9 7.0 8.6 3.7 Cortex-A73 1800MHz 2016
4.2 3.3 3.2 17.9 23.1 4.2 Ryzen 5 1600X 3600MHz 2017
6.9 24.5 27.3 37.1 33.5 36.6 Power9 3800MHz 2017
3.8 1.0 1.1 3.8 6.2 2.2 Core i5-1135G7 4200MHz 2020
The age of the Pentium M would suggest putting it into the earlier
table, but given its clear performance-per-clock advantage over the
other IA-32 and AMD64 CPUs of its day, it was probably the first CPU
to have a history-based indirect-branch predictor.
It seems that, while the AMD64 microarchitectures improved not just in
clock rate, but also in performance per clock for this microbenchmark
(thanks to history-based indirect-branch predictors), the Power 9
still relies on its split-branch architectural feature, resulting in
slowness. And it's not just slowness in "direct", but the additional
instructions in the other benchmarks add more cycles than in most
other CPUs.
Particularly notable is the Core i5-1135G7, which takes one indirect
branch per cycle.
I have to take additional measurements with other Power and AMD64
processors.
Couldn't the Power and IA-64 CPUs use history-based branch prediction,
too? Of course, but then it would be even more obvious that the
split-branch architecture provides no benefit.
Bottom line: History-based branch prediction has won, any kind of
delayed branches (including split-branch designs) turn out to be a bad idea.
>tell the CPU
>what the target is (like VEC in My66000)
I have no idea what VEC does, but all indirect-branch architectures
are about telling the CPU what the target is.
> just use a general
>purpose register with a general-purpose instruction.
That turns out to be the winner.
>> One gotcha may be that the branch target needs to be predicted as it
>> cannot be calculated earlier in the pipeline.
If you want to be able to perform one taken branch per cycle (or
more), you always need prediction.
>If you use a link register or a special instruction, the CPU could
>do that.
It turns out that this does not work well in practice.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-04 19:15 +0000 |
| Subject | Re: branch splitting (was: Tonights Tradeoff) |
| Message-ID | <1762283731-5857@newsgrouper.org> |
| In reply to | #113920 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> Thomas Koenig <tkoenig@netcologne.de> writes:
> >Should be possible. A question is if you want to have a special
> >register for that (like POWER's link register),
>
> There is this idea of splitting an (indirect) branch into a
> prepare-to-branch instruction and a take-branch instruction. The
I first heard about this 1982 from Burton Smith.
> prepare-to-branch instruction announces the branch target to the CPU,
> and Power's mtlr and mtctr are examples of that (somewhat muddled by
> the fact that the ctr register can also be used for counted loops as
> well as for indirect branches), and IA-64's branch-target registers
> and the instructions that move there are another example. AFAIK SPARC
> acquired something in this direction (touted as good for accelerating
> Java) in the early 2000s. The take-branch instruction on Power is
> blr/bctr.
>
> I used to think that this kind of splitting is a good idea, and it is
> certainly better than a branch-delay slot or a branch with a fixed
> number of delay slots.
PL/1 allows for Label variables so one can build their own
switches (and state machines with variable paths). I used
these in a checkers playing program 1974.
> But in practice, it turned out that Intel and AMD processors had much
> better performance on indirect-branch intensive workloads in the early
> 2000s without this architectural feature. What happened?
We threw HW at the problem.
> The IA-32 and AMD64 microarchitects implemented indirect-branch
> prediction; in the early 2000s it was based on the BTB, which these
> CPUs need for fast direct branching anyway. They were not content
> with that, and have implemented history-based indirect branch
> predictors in the meantime, which improve the performance even more.
>
> By contrast, Power and IA-64 implementations apparently rely on
> getting the target-address early enough, and typically predict that
> the indirect branch will go to the current contents of the
> branch-target register when the front-end encounters the take-branch
> instruction; but if the prepare-to-branch instruction is in the
> instruction stream just before the take-branch instruction, it takes
> several cycles until the prepare-to-branch actually can move the
> target to the branch-target register. In case of an OoO
> implementation, the number of cycles tends to be longer. It's
> essentially a similar latency as in a branch misprediction.
>
> That all would not be so bad, if the compilers would move the
> prepare-to-branch instructions sufficiently far away from the
> take-branch instruction. But gcc certainly has not done so whenever I
> looked at code it generated for PowerPC or IA-64.
>
> Here is some data for code that focusses on indirect-branch
> performance (with indirect branches that vary their targets), from
> <https://www.complang.tuwien.ac.at/forth/threading/>:
>
> Numbers are cycles per indirect branch, smaller is faster, the years
> are the release dates of the CPUs:
>
> First, machines from the early 2000s:
>
> sub- in- repl.
> routine direct direct switch call switch CPU year
> 9.6 8.0 9.5 23.1 38.6 Alpha 21264B 800MHz ~2000
> 4.7 8.1 9.5 19.0 21.3 Pentium III 1000MHz 2000
> 18.4 8.5 10.3 24.5 29.0 Athlon 1200MHz 2000
> 8.6 14.2 15.3 23.4 30.2 Pentium 4 2.26 2002
> 13.3 10.3 12.3 15.7 18.7 Itanium 2 (McKinley) 900MHz 2002
> 5.7 9.2 12.3 16.3 17.9 PPC 7447A 1066MHz 2004
> 7.8 12.8 12.9 30.2 39.0 PPC 970 2000MHz 2002
>
> Ignore the first column (it uses call and return), the others all need
> an indirect branch or indirect call ("call" column) per dispatch, with
> varying amounts of other instructions; "direct" needs the least
> instructions.
>
> And here are results with some newer machines:
>
> sub- in- repl.
> routine direct direct switch call switch CPU year
> 4.9 5.6 4.3 5.1 7.64 Pentium M 755 2000MHz 2004
> 4.4 2.2 2.0 20.3 18.6 3.3 Xeon E3-1220 3100MHz 2011
> 4.0 2.3 2.3 4.0 5.1 3.5 Core i7-4790K 4400MHz 2013
> 4.2 2.1 2.0 4.9 5.2 2.7 Core i5-6600K 4000MHz 2015
> 5.7 3.2 3.9 7.0 8.6 3.7 Cortex-A73 1800MHz 2016
> 4.2 3.3 3.2 17.9 23.1 4.2 Ryzen 5 1600X 3600MHz 2017
> 6.9 24.5 27.3 37.1 33.5 36.6 Power9 3800MHz 2017
> 3.8 1.0 1.1 3.8 6.2 2.2 Core i5-1135G7 4200MHz 2020
>
> The age of the Pentium M would suggest putting it into the earlier
> table, but given its clear performance-per-clock advantage over the
> other IA-32 and AMD64 CPUs of its day, it was probably the first CPU
> to have a history-based indirect-branch predictor.
>
> It seems that, while the AMD64 microarchitectures improved not just in
> clock rate, but also in performance per clock for this microbenchmark
> (thanks to history-based indirect-branch predictors), the Power 9
> still relies on its split-branch architectural feature, resulting in
> slowness. And it's not just slowness in "direct", but the additional
> instructions in the other benchmarks add more cycles than in most
> other CPUs.
>
> Particularly notable is the Core i5-1135G7, which takes one indirect
> branch per cycle.
>
> I have to take additional measurements with other Power and AMD64
> processors.
>
> Couldn't the Power and IA-64 CPUs use history-based branch prediction,
> too? Of course, but then it would be even more obvious that the
> split-branch architecture provides no benefit.
>
> Bottom line: History-based branch prediction has won, any kind of
> delayed branches (including split-branch designs) turn out to be
> a bad idea.
Or "Never bet against branch prediction".
> >tell the CPU
> >what the target is (like VEC in My66000)
>
> I have no idea what VEC does, but all indirect-branch architectures
> are about telling the CPU what the target is.
VEC is the bracket at the top of a loop. VEC supplies a register
which will contain the address of the instruction at the top of
the loop, and a 21-bit-vector use to specify those registers which
are "Live" out of the loop. VEC is "executed" as the loop is entered
and then not again until the loop is entered again.
The LOOP instruction is the bottom bracket of the loop and performs
the ADD-CMP-BC sequence as a single instruction. There are 3 flavors
{counted, value terminated, counter value terminated} that use the
3 registers similarly but differently.
> > just use a general
> >purpose register with a general-purpose instruction.
>
> That turns out to be the winner.
>
> >> One gotcha may be that the branch target needs to be predicted as it
> >> cannot be calculated earlier in the pipeline.
With VEC-LOOP you are guaranteed that the branch and its target are
100% correlated.
> If you want to be able to perform one taken branch per cycle (or
> more), you always need prediction.
Greater than 1 branch per FETCH latency.
> >If you use a link register or a special instruction, the CPU could
> >do that.
>
> It turns out that this does not work well in practice.
Agreed.
> - anton
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-11-04 22:44 +0100 |
| Subject | Re: branch splitting |
| Message-ID | <10eds3q$3v9cp$1@dont-email.me> |
| In reply to | #113928 |
MitchAlsup wrote: > > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> Bottom line: History-based branch prediction has won, any kind of >> delayed branches (including split-branch designs) turn out to be >> a bad idea. > > Or "Never bet against branch prediction". I have probably mentioned this before, once or twice, but I'm actually quite proud of the meeting I had with Intel Santa Clara in the spring of 1995: I had (accidentally) written the first public mention of the FDIV bug (on comp.sys.intel) in Oct 1994, then together with Cleve Moler of MathWorks/MatLab fame led the effort to develop a minimum cost sw workaround for the bug. (My code became part of all/most x86 compiler runtimes for the next few years.) Due to this Intel invited me to receive an early engineering prototype of the PentiumPro, together with an NDA-covered briefing about its architecture. Before the start of that briefing I suggested that I should start off on the blackboard by showing what I had been able to figure out on my own, then I proceeded to pretty much exactly cover every single feature on the cpu, with one glaring exception: Based on the useful but not great branch predictor on the Pentium I told them that I expected the P6 to employ eager execution, i.e execute both ways of one or two layers of branches, discarding the non-taken paths as the branch direction info became available. That's the point when they got to brag about how having a much, much better branch predictor was better both from a performance and a power viewpoint, since out of order execution could predict much deeper than any eager execution would have the resources for. As you said: "Never bet against branch prediction". 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-05 00:44 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <1762303458-5857@newsgrouper.org> |
| In reply to | #113931 |
Terje Mathisen <terje.mathisen@tmsw.no> posted: > MitchAlsup wrote: > > > > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > > > >> Bottom line: History-based branch prediction has won, any kind of > >> delayed branches (including split-branch designs) turn out to be > >> a bad idea. > > > > Or "Never bet against branch prediction". > > I have probably mentioned this before, once or twice, but I'm actually > quite proud of the meeting I had with Intel Santa Clara in the spring of > 1995: > > I had (accidentally) written the first public mention of the FDIV bug > (on comp.sys.intel) in Oct 1994, then together with Cleve Moler of > MathWorks/MatLab fame led the effort to develop a minimum cost sw > workaround for the bug. (My code became part of all/most x86 compiler > runtimes for the next few years.) > > Due to this Intel invited me to receive an early engineering prototype > of the PentiumPro, together with an NDA-covered briefing about its > architecture. > > Before the start of that briefing I suggested that I should start off on > the blackboard by showing what I had been able to figure out on my own, > then I proceeded to pretty much exactly cover every single feature on > the cpu, with one glaring exception: > > Based on the useful but not great branch predictor on the Pentium I told > them that I expected the P6 to employ eager execution, i.e execute both > ways of one or two layers of branches, discarding the non-taken paths as > the branch direction info became available. > > That's the point when they got to brag about how having a much, much > better branch predictor was better both from a performance and a power > viewpoint, since out of order execution could predict much deeper than > any eager execution would have the resources for. I remember you relating this story about 6-8 years ago. > As you said: "Never bet against branch prediction". > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-05 01:00 -0600 |
| Subject | Re: branch splitting |
| Message-ID | <10eesmr$7d4s$1@dont-email.me> |
| In reply to | #113931 |
On 11/4/2025 3:44 PM, Terje Mathisen wrote:
> MitchAlsup wrote:
>>
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>
>>> Bottom line: History-based branch prediction has won, any kind of
>>> delayed branches (including split-branch designs) turn out to be
>>> a bad idea.
>>
>> Or "Never bet against branch prediction".
>
> I have probably mentioned this before, once or twice, but I'm actually
> quite proud of the meeting I had with Intel Santa Clara in the spring of
> 1995:
>
> I had (accidentally) written the first public mention of the FDIV bug
> (on comp.sys.intel) in Oct 1994, then together with Cleve Moler of
> MathWorks/MatLab fame led the effort to develop a minimum cost sw
> workaround for the bug. (My code became part of all/most x86 compiler
> runtimes for the next few years.)
>
> Due to this Intel invited me to receive an early engineering prototype
> of the PentiumPro, together with an NDA-covered briefing about its
> architecture.
>
> Before the start of that briefing I suggested that I should start off on
> the blackboard by showing what I had been able to figure out on my own,
> then I proceeded to pretty much exactly cover every single feature on
> the cpu, with one glaring exception:
>
> Based on the useful but not great branch predictor on the Pentium I told
> them that I expected the P6 to employ eager execution, i.e execute both
> ways of one or two layers of branches, discarding the non-taken paths as
> the branch direction info became available.
>
> That's the point when they got to brag about how having a much, much
> better branch predictor was better both from a performance and a power
> viewpoint, since out of order execution could predict much deeper than
> any eager execution would have the resources for.
>
> As you said: "Never bet against branch prediction".
>
Branch prediction is fun.
When I looked around online before, a lot of stuff about branch
prediction was talking about fairly large and convoluted schemes for the
branch predictors.
But, then always at the end of it using 2-bit saturating counters:
weakly taken, weakly not-taken, strongly taken, strongly not taken.
But, in my fiddling, there was seemingly a simple but moderately
effective strategy:
Keep a local history of taken/not-taken;
XOR this with the low-order-bits of PC for the table index;
Use a 5/6-bit finite-state-machine or similar.
Can model repeating patterns up to ~ 4 bits.
Where, the idea was that the state-machine in updated with the current
state and branch direction, giving the next state and next predicted
branch direction (for this state).
Could model slightly more complex patterns than the 2-bit saturating
counters, but it is sort of a partial mystery why (for mainstream
processors) more complex lookup schemes and 2 bit state, was preferable
to a simpler lookup scheme and 5-bit state.
Well, apart from the relative "dark arts" needed to cram 4-bit patterns
into a 5 bit FSM (is a bit easier if limiting the patterns to 3 bits).
Then again, had before noted that the LLMs are seemingly also not really
able to figure out how to make a 5 bit FSM to model a full set of 4 bit
patterns.
Then again, I wouldn't expect it to be all that difficult of a problem
for someone that is "actually smart"; so presumably chip designers could
have done similar.
Well, unless maybe the argument is that 5 or 6 bits of storage would
cost more than 2 bits, but then presumably needing to have significantly
larger tables (to compensate for the relative predictive weakness of
2-bit state) would have costed more than the cost of smaller tables of 6
bit state ?...
Say, for example, 2b:
00_0 => 10_0 //Weakly not-taken, dir=0, goes strong not-taken
00_1 => 01_0 //Weakly not-taken, dir=1, goes weakly taken
01_0 => 00_1 //Weakly taken, dir=0, goes weakly not-taken
01_1 => 11_1 //Weakly taken, dir=1, goes strongly taken
10_0 => 10_0 //strongly not taken, dir=0
10_1 => 00_0 //strongly not taken, dir=1 (goes weak)
11_0 => 01_1 //strongly taken, dir=0
11_1 => 11_1 //strongly taken, dir=1 (goes weak)
Can expand it to 3-bits, for 2-bit patterns
As above, and 4-more alternating states
And slightly different transition logic.
Say (abbreviated):
000 weak, not taken
001 weak, taken
010 strong, not taken
011 strong, taken
100 weak, alternating, not-taken
101 weak, alternating, taken
110 strong, alternating, not-taken
111 strong, alternating, taken
The alternating states just flip-flopping between taken and not taken.
The weak states can more between any of the 4.
The strong states used if the pattern is reinforced.
Going up to 3 bit patterns is more of the same (add another bit,
doubling the number of states). Seemingly something goes nasty when
getting to 4 bit patterns though (and can't fit both weak and strong
states for longer patterns, so the 4b patterns effectively only exist as
weak states which partly overlap with the weak states for the 3-bit
patterns).
But, yeah, not going to type out state tables for these ones.
Not proven, but I suspect that an arbitrary 5 bit pattern within a 6 bit
state might be impossible. Although there would be sufficient
state-space for the looping 5-bit patterns, there may not be sufficient
state-space to distinguish whether to move from a mismatched 4-bit
pattern to a 3 or 5 bit pattern. Whereas, at least with 4-bit, any
mismatch of the 4-bit pattern can always decay to a 3-bit pattern, etc.
One needs to be able to express decay both to shorter patterns and to
longer patterns, and I suspect at this point, the pattern breaks down
(but can't easily confirm; it is either this or the pattern extends
indefinitely, I don't know...).
Could almost have this sort of thing as a "brain teaser" puzzle or
something...
Then again, maybe other people would not find any particular difficulty
in these sorts of tasks.
> Terje
>
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-05 01:38 -0600 |
| Subject | Re: branch splitting |
| Message-ID | <10eeutu$7d4s$2@dont-email.me> |
| In reply to | #113944 |
On 11/5/2025 1:00 AM, BGB wrote: > On 11/4/2025 3:44 PM, Terje Mathisen wrote: >> MitchAlsup wrote: >>> >>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >>> >>>> Bottom line: History-based branch prediction has won, any kind of >>>> delayed branches (including split-branch designs) turn out to be >>>> a bad idea. >>> >>> Or "Never bet against branch prediction". >> >> I have probably mentioned this before, once or twice, but I'm actually >> quite proud of the meeting I had with Intel Santa Clara in the spring >> of 1995: >> >> I had (accidentally) written the first public mention of the FDIV bug >> (on comp.sys.intel) in Oct 1994, then together with Cleve Moler of >> MathWorks/MatLab fame led the effort to develop a minimum cost sw >> workaround for the bug. (My code became part of all/most x86 compiler >> runtimes for the next few years.) >> >> Due to this Intel invited me to receive an early engineering prototype >> of the PentiumPro, together with an NDA-covered briefing about its >> architecture. >> >> Before the start of that briefing I suggested that I should start off >> on the blackboard by showing what I had been able to figure out on my >> own, then I proceeded to pretty much exactly cover every single >> feature on the cpu, with one glaring exception: >> >> Based on the useful but not great branch predictor on the Pentium I >> told them that I expected the P6 to employ eager execution, i.e >> execute both ways of one or two layers of branches, discarding the >> non-taken paths as the branch direction info became available. >> >> That's the point when they got to brag about how having a much, much >> better branch predictor was better both from a performance and a power >> viewpoint, since out of order execution could predict much deeper than >> any eager execution would have the resources for. >> >> As you said: "Never bet against branch prediction". >> > > Branch prediction is fun. > > > When I looked around online before, a lot of stuff about branch > prediction was talking about fairly large and convoluted schemes for the > branch predictors. > > But, then always at the end of it using 2-bit saturating counters: > weakly taken, weakly not-taken, strongly taken, strongly not taken. > > But, in my fiddling, there was seemingly a simple but moderately > effective strategy: > Keep a local history of taken/not-taken; > XOR this with the low-order-bits of PC for the table index; > Use a 5/6-bit finite-state-machine or similar. > Can model repeating patterns up to ~ 4 bits. > > Where, the idea was that the state-machine in updated with the current > state and branch direction, giving the next state and next predicted > branch direction (for this state). > > > Could model slightly more complex patterns than the 2-bit saturating > counters, but it is sort of a partial mystery why (for mainstream > processors) more complex lookup schemes and 2 bit state, was preferable > to a simpler lookup scheme and 5-bit state. > > Well, apart from the relative "dark arts" needed to cram 4-bit patterns > into a 5 bit FSM (is a bit easier if limiting the patterns to 3 bits). > > > > Then again, had before noted that the LLMs are seemingly also not really > able to figure out how to make a 5 bit FSM to model a full set of 4 bit > patterns. > Errm... I just decided to test it, and it appears Grok was able to figure it out (more or less). This is concerning, either the AIs are getting smart enough to deal with semi-difficult problems; or in fact it is not difficult and I was just dumb for thinking there is any difficulty in working out the state tables for the longer patterns. I tried before with DeepSeek R1 and similar, which had failed. > > Then again, I wouldn't expect it to be all that difficult of a problem > for someone that is "actually smart"; so presumably chip designers could > have done similar. > > Well, unless maybe the argument is that 5 or 6 bits of storage would > cost more than 2 bits, but then presumably needing to have significantly > larger tables (to compensate for the relative predictive weakness of 2- > bit state) would have costed more than the cost of smaller tables of 6 > bit state ?... > > Say, for example, 2b: > 00_0 => 10_0 //Weakly not-taken, dir=0, goes strong not-taken > 00_1 => 01_0 //Weakly not-taken, dir=1, goes weakly taken > 01_0 => 00_1 //Weakly taken, dir=0, goes weakly not-taken > 01_1 => 11_1 //Weakly taken, dir=1, goes strongly taken > 10_0 => 10_0 //strongly not taken, dir=0 > 10_1 => 00_0 //strongly not taken, dir=1 (goes weak) > 11_0 => 01_1 //strongly taken, dir=0 > 11_1 => 11_1 //strongly taken, dir=1 (goes weak) > > Can expand it to 3-bits, for 2-bit patterns > As above, and 4-more alternating states > And slightly different transition logic. > Say (abbreviated): > 000 weak, not taken > 001 weak, taken > 010 strong, not taken > 011 strong, taken > 100 weak, alternating, not-taken > 101 weak, alternating, taken > 110 strong, alternating, not-taken > 111 strong, alternating, taken > The alternating states just flip-flopping between taken and not taken. > The weak states can more between any of the 4. > The strong states used if the pattern is reinforced. > > Going up to 3 bit patterns is more of the same (add another bit, > doubling the number of states). Seemingly something goes nasty when > getting to 4 bit patterns though (and can't fit both weak and strong > states for longer patterns, so the 4b patterns effectively only exist as > weak states which partly overlap with the weak states for the 3-bit > patterns). > > But, yeah, not going to type out state tables for these ones. > > > Not proven, but I suspect that an arbitrary 5 bit pattern within a 6 bit > state might be impossible. Although there would be sufficient state- > space for the looping 5-bit patterns, there may not be sufficient state- > space to distinguish whether to move from a mismatched 4-bit pattern to > a 3 or 5 bit pattern. Whereas, at least with 4-bit, any mismatch of the > 4-bit pattern can always decay to a 3-bit pattern, etc. One needs to be > able to express decay both to shorter patterns and to longer patterns, > and I suspect at this point, the pattern breaks down (but can't easily > confirm; it is either this or the pattern extends indefinitely, I don't > know...). > > > Could almost have this sort of thing as a "brain teaser" puzzle or > something... > > Then again, maybe other people would not find any particular difficulty > in these sorts of tasks. > But, alas, sometimes I wonder if I am just kinda stupid and everyone else has already kinda figured this out, but doesn't say much... Like, just smart enough to do the things that I do, but not so much otherwise... In theory, I am kinda OK, but often it mostly seems like I mostly just suck at everything. > >> Terje >> >
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-05 20:43 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <1762375438-5857@newsgrouper.org> |
| In reply to | #113944 |
BGB <cr88192@gmail.com> posted:
> On 11/4/2025 3:44 PM, Terje Mathisen wrote:
> > MitchAlsup wrote:
---------------
> >
> > As you said: "Never bet against branch prediction".
> >
>
> Branch prediction is fun.
>
>
> When I looked around online before, a lot of stuff about branch
> prediction was talking about fairly large and convoluted schemes for the
> branch predictors.
>
> But, then always at the end of it using 2-bit saturating counters:
> weakly taken, weakly not-taken, strongly taken, strongly not taken.
>
> But, in my fiddling, there was seemingly a simple but moderately
> effective strategy:
> Keep a local history of taken/not-taken;
> XOR this with the low-order-bits of PC for the table index;
> Use a 5/6-bit finite-state-machine or similar.
> Can model repeating patterns up to ~ 4 bits.
>
> Where, the idea was that the state-machine in updated with the current
> state and branch direction, giving the next state and next predicted
> branch direction (for this state).
>
>
> Could model slightly more complex patterns than the 2-bit saturating
> counters, but it is sort of a partial mystery why (for mainstream
> processors) more complex lookup schemes and 2 bit state, was preferable
> to a simpler lookup scheme and 5-bit state.
In 1991 Mike Shebanow, Tse-Yu Yeh, and I tried out a Correlation predictor
where strings of {T, !T}** were pattern matched to create a prediction.
While it was somewhat competitive with Global History Table, it ultimately
failed.
I am now working on predictors for a 6-wide My 66000 machine--which is a bit
different.
a) VEC-LOOP loops do not alter the branch prediction tables.
b) Predication clauses do not alter the BPTs.
c) Jump Through Table is not predicted through jump indirect table-like
prediction, what is predicted is the value (switch variable) and this
is used to index the table (early)
d) CMOV gets rid of another 8%
These strip out about 40% of branches from needing prediction, causing
the remaining branches to be harder to predict but having less total
latency in execution.
-----------------
> Not proven, but I suspect that an arbitrary 5 bit pattern within a 6 bit
> state might be impossible. Although there would be sufficient
> state-space for the looping 5-bit patterns, there may not be sufficient
> state-space to distinguish whether to move from a mismatched 4-bit
> pattern to a 3 or 5 bit pattern. Whereas, at least with 4-bit, any
> mismatch of the 4-bit pattern can always decay to a 3-bit pattern, etc.
> One needs to be able to express decay both to shorter patterns and to
> longer patterns, and I suspect at this point, the pattern breaks down
> (but can't easily confirm; it is either this or the pattern extends
> indefinitely, I don't know...).
Tried some of these (1991) mostly with little to no success.
Be my guest and try again.
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-02-08 10:24 -0500 |
| Subject | Re: branch splitting |
| Message-ID | <10mb613$2brnl$2@dont-email.me> |
| In reply to | #113963 |
On 11/5/25 3:43 PM, MitchAlsup wrote: [snip] > I am now working on predictors for a 6-wide My 66000 machine--which is a bit > different. > a) VEC-LOOP loops do not alter the branch prediction tables. > b) Predication clauses do not alter the BPTs. Not recording the history of predicates may have a negative effect on global history predictors. (I do not know if anyone has studied this, but it has been mentioned — e.g., "[predication] has a negative side-effect because the removal of branches eliminates useful correlation information necessary for conventional branch predictors" from "Improving Branch Prediction and Predicated Execution in Out-of-Order Processors", Eduardo Quiñones et al., 2007.) Predicate prediction can also be useful when the availability of the predicate is delayed. Similarly, selective eager execution might be worthwhile when the predicate is delayed; the selection is likely to be predictive (resource use might be a basis for selection but even estimating that might be predictive). With predication of all short forward branches in order to avoid fetch bubbles, the impact of delayed predicate availability and missing information for branch prediction may be greater than for more selective predication. There may also be some short forward branches that are 99% taken such that converting to a longer branch with a jump back may be a better option. With trace-cache-like optimization, such branched over code could be removed from fetch even when the compiler used a short branch. Dynamic code organization has the advantage of being able to use dynamically available information (and the disadvantage of gathering the information and making a decision dynamically). Something like a branch target cache could store extracted instructions. This might facilitate stitching such instructions back into the instruction stream with limited overhead. Since this would only work for usually taken hammock branches, it would probably not be worthwhile. For if-then-else constructs, one might place both paths in separate entries in such a target cache and always stitch in one of them, but that seems wonky. I rather doubt the benefits of such would justify the added complexity — almost certainly not in a first or second implementation of an architecture — but I would not want to reject future possible adoption of such techniques. My guess would be that most short forward branches would not use an extracted code cache either because they are generally not taken so there is no fetch advantage or because the branch direction in unpredictable such that predication likely makes more sense and fetching from two structures just adds complexity. For highly unlikely code, an extracted cache might have higher latency (from placement, from deferred access to use better prediction, or from more complex retrieval). Stalling renaming when a longer-latency insertion is predicted seems undesirable (though it may have negligible performance harm), but including just enough dataflow information in the quicker accessed caches to support out-of-order fetch seems complicated.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-02-09 19:20 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <1770664801-5857@newsgrouper.org> |
| In reply to | #114879 |
Paul Clayton <paaronclayton@gmail.com> posted: > On 11/5/25 3:43 PM, MitchAlsup wrote: > [snip] > > I am now working on predictors for a 6-wide My 66000 machine--which is a bit > > different. > > a) VEC-LOOP loops do not alter the branch prediction tables. > > b) Predication clauses do not alter the BPTs. > > Not recording the history of predicates may have a negative > effect on global history predictors. (I do not know if anyone > has studied this, but it has been mentioned — e.g., > "[predication] has a negative side-effect because the removal > of branches eliminates useful correlation information > necessary for conventional branch predictors" from "Improving > Branch Prediction and Predicated Execution in Out-of-Order > Processors", Eduardo Quiñones et al., 2007.) It depends on where you are looking! If you think branch prediction alters where FETCH is Fetching, then MY 66000 predication does not do predication prediction--predication is used when the join point will have already been fetched by the time the condition is known. Then, either the then clause or the else clause will be nullified without backup (i.e., branch prediction repair). DECODE is still able to predict then-clause versus else-clause and maintain the no-backup property, as long as both sides are issued into the execution window. > Predicate prediction can also be useful when the availability > of the predicate is delayed. Similarly, selective eager > execution might be worthwhile when the predicate is delayed; > the selection is likely to be predictive (resource use might > be a basis for selection but even estimating that might be > predictive). The difference is that predication prediction never needs branch prediction repair.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-04-05 06:49 +0000 |
| Subject | Re: branch splitting |
| Message-ID | <10qt0ks$185o3$1@dont-email.me> |
| In reply to | #114891 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > > Paul Clayton <paaronclayton@gmail.com> posted: > >> On 11/5/25 3:43 PM, MitchAlsup wrote: >> [snip] >> > I am now working on predictors for a 6-wide My 66000 machine--which is a bit >> > different. >> > a) VEC-LOOP loops do not alter the branch prediction tables. >> > b) Predication clauses do not alter the BPTs. >> >> Not recording the history of predicates may have a negative >> effect on global history predictors. (I do not know if anyone >> has studied this, but it has been mentioned — e.g., >> "[predication] has a negative side-effect because the removal >> of branches eliminates useful correlation information >> necessary for conventional branch predictors" from "Improving >> Branch Prediction and Predicated Execution in Out-of-Order >> Processors", Eduardo Quiñones et al., 2007.) > > It depends on where you are looking! If you think branch prediction > alters where FETCH is Fetching, then MY 66000 predication does not > do predication prediction--predication is used when the join point > will have already been fetched by the time the condition is known. > Then, either the then clause or the else clause will be nullified > without backup (i.e., branch prediction repair). > > DECODE is still able to predict then-clause versus else-clause > and maintain the no-backup property, as long as both sides are > issued into the execution window. > >> Predicate prediction can also be useful when the availability >> of the predicate is delayed. Similarly, selective eager >> execution might be worthwhile when the predicate is delayed; >> the selection is likely to be predictive (resource use might >> be a basis for selection but even estimating that might be >> predictive). > > The difference is that predication prediction never needs branch > prediction repair. What happens to the instructions after the predicate? Let's say we have [...] peq0 r1,tf mov r2,#24 mov r2,#48 ldd r3,[r4,r2,0] [...] can the ldd be speculatively executed or not? And what happens if the prediction was wrong? -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
Page 37 of 46 — ← Prev page 1 … 35 36 [37] 38 39 … 46 Next page →
Back to top | Article view | comp.arch
csiph-web