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 24 of 46 — ← Prev page 1 … 22 23 [24] 25 26 … 46 Next page →
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-03-01 05:39 -0600 |
| Subject | Re: IA-64 |
| Message-ID | <10o18rn$6c0j$1@dont-email.me> |
| In reply to | #115166 |
On 2/28/2026 9:48 AM, Terje Mathisen wrote:
> BGB wrote:
>> On 2/24/2026 5:25 AM, Anton Ertl wrote:
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>>> On 2/21/2026 8:18 AM, Anton Ertl wrote:
>>>>
>>>> big snip
>>>>
>>>>> Otherwise what kind of common code do we have that is
>>>>> memory-dominated? Tree searching and binary search in arrays come to
>>>>> mind, but are they really common, apart from programming classes?
>>>>
>>>> It is probably useful to distinguish between latency bound and
>>>> bandwidth
>>>> bound.
>>>
>>> If a problem is bandwidth-bound, then differences between conventional
>>> architectures and EPIC play no role, and microarchitectural
>>> differences in the core play no role, either; they all have to wait
>>> for memory.
>>>
>>> For latency various forms of prefetching (by hardware or software) can
>>> help.
>>>
>>>> Many occur in commercial (i.e. non scientific) programs, such as
>>>> database systems. For example, imagine a company employee file
>>>> (table),
>>>> with a (say 300 byte) record for each of its many thousands of
>>>> employees
>>>> each containing typical employee stuff). Now suppose someone wants to
>>>> know "What is the total salary of all the employees in the "Sales"
>>>> department. With no index on "department", but it is at a fixed
>>>> displacement within each record, the code looks at each record, does a
>>>> trivial test on it, perhaps adds to a register, then goes to the next
>>>> record. This it almost certainly memory latency bound.
>>>
>>> If the records are stored sequentially, either because the programming
>>> language supports that arrangement and the programmer made use of
>>> that, or because the allocation happened in a way that resulted in
>>> such an arrangement, stride-based prefetching will prefetch the
>>> accessed fields and reduce the latency to the one due to bandwidth
>>> limits.
>>>
>>> If the records are stored randomly, but are pointed to by an array,
>>> one can prefetch the relevant fields easily, again turning the problem
>>> into a latency-bound problem. If, OTOH, the records are stored
>>> randomly and are in a linked list, this problem is a case of
>>> pointer-chasing and is indeed latency-bound.
>>>
>>> BTW, thousands of employee records, each with 300 bytes, fit in the L2
>>> or L3 cache of modern processors.
>>>
>>
>> FWIW:
>>
>> IME, code with fairly random access patterns to memory, and lots of
>> cache misses, is inherently slow; even on big/fancy OoO chips.
>> Seemingly about the only real hope the CPU has is to have a large
>> cache and just hope that the data happens to be in the cache (and has
>> been accessed previously or sufficiently recently) else it is just
>> kinda SOL.
>>
>> If there is some way that CPU's can guess what memory they need in
>> advance and fetch it beforehand, I have not seen much evidence of this
>> personally.
>>
>> Rather, as can be noted, memory access patterns can often make a
>> fairly large impact on the performance of some algorithms.
>>
>>
>> Like, for example, decoding a PNG like format vs a JPG like format:
>> PNG decoding typically processes the image as several major phases:
>> Decompress the Deflate-compressed buffer into memory;
>> Walk over the image, running scanline filters,
>> copying scanlines into a new (output) buffer.
>
> Could you have a secondary thread that started as soon as one (or a
> small number of) scanline(s) were available, taking advantage of any
> shared $L3 cache to grab the data before it is blown away?
>
It is possible to make it piecewise and incremental, but making the
inflater incremental (and fast) is more complexity and difficulty than
making a JPEG-like format that is both fast and lossless.
Though, zlib supports incremental decoding of the type that would be
useful here, but using zlib this way isn't particularly fast.
Ironically, if not for cache misses, PNG (and JPEG 2000) would likely be
some of the faster image codecs around. But, both PNG and JP2K suffer
from some similar issues here.
Though, if you stick a Haar of CDF5/3 wavelet in a small fixed-size
block, it works well (and is faster than if applied over larger
raster-ordered planes).
Though, if designing a new codec to optimize for this, could make sense
to increase the block size from 8x8 to 16x16; with the effective
macroblock size increased to 32x32.
Mostly because this is still small enough to probably fit in the L1
cache on most CPU (assuming one isn't wasting too much memory on the
entropy coder or similar).
Though, likely 32x32 blocks would be too big, and would push the decoder
outside of "mostly fits in L1 cache" territory.
My UPIC format stayed with 8x8 blocks though:
8x8 blocks, 16x16 macroblocks (still 16x16 for 4:4:4).
When there are four 8x8 blocks, they are encoded in Hilbert order.
Used:
STF+AdRice
Z3V5 VLN's
Encoded similar to Deflate distances,
zigzag sign-folding for values.
Block Transforms (as layered 1D transforms):
BHT: Block Haar.
CDF 5/3
WHT (does poorly on average)
DCT (lossy only)
Colorspaces:
RCT
YCoCg-R
YCbCr (Approx, Lossy Only)
At lossless and high quality:
BHT and CDF5/3 dominate;
RCT and YCoCg dominate.
Where, DCT and YCbCr mostly pull ahead at medium to low quality levels
and for photo-like images.
For lossy compression of cartoon-like graphics, CDF 5/3 often wins.
Have noted:
Is competitive with T.81 JPEG for compression ratio;
Is slightly faster for decompression;
For many lossless images,
tends to beat PNG for both compression and speed.
Though for many "very artificial" images:
Such as for UI graphics,
PNG still wins for compression.
Compared with PNG, it has a relative weakness in that it isn't as
effective with repeating patterns and large flat-colored areas. Both of
these can benefit more from LZ compression. Though, partly QOI shares
the same issue.
>>
>> Even if the parts, taken in isolation, should be fast:
>> The image buffers are frequently too large to fit in cache;
>> Cache misses tend to make PNG decoding painfully slow,
>> even when using faster filters.
>> If using the Paeth filter though, this adds extra slowness,
>> due to branch-predictor misses.
>> On targets like x86,
>> the filter is frequently implemented using branches;
>> The branch miss rate is very high.
>> So, a naive branching version, performs like dog crap.
>
> This reminds me of CABAC decoding in h264, where the output of the
> arithmetic decoder is single bits that by definition cannot be
> predictable, but the codec typically uses that bit to branch.
>
Yeah.
Making arithmetic and range coders fast is also hard.
I don't often use them as much because I am not aware of a good way to
make them fast.
This is part of why I had often ended up going for STF+AdRice or
similar, which, while not the best in terms of compression, can be one
of the faster options in many cases.
Theoretically, table-driven Huffman could be faster, but likewise often
suffers from cache misses (cycles lost to cache misses can outweigh the
cost of the more complex logic of an AdRice coder).
Huffman speed can be improved by reducing maximum symbol length and
table size, but then this can lose much its compression advantage.
Say, max symbol length:
10/11: Too short, limits effectiveness.
12: OK, leans faster;
13: OK, leans better compression;
14: Intermediate
15: Slower still (Deflate is here)
16: Slower (T.81 JPEG is here)
Where, for 12/13 bits, the fastest strategy is typically to use a single
big lookup table for the entropy decoder.
For 15 or 16 bits, it is often faster to have a separate fast-path and
slow path. Say, fast path matches on the first 9 or 10 bits, and then
the slow path falls back to a linear search (over the longer symbols).
In this case, the relative slowness of falling back to a linear search
being less than that of the cost of the L1 misses from a bigger lookup
table.
The relative loss of Huffman coding efficiency between a 13 bit limit
and 15 bit limit is fairly modest.
Where, say:
AdRice:
+ Can be made reasonably fast and cheap.
+ Low memory footprint;
+ Cheap setup cost;
- Often weaker than Huffman in terms of compression.
- Pure AdRice Only deals with certain distributions
(Requires STF or similar to mimic Huffman's generality).
Static Huffman:
+ More optimal in terms of coding efficiency;
- Speed requires initializing bulky lookup tables;
- High overhead and ineffective for small payloads.
Range Coding
+ Good for maximizing compression
+ Deals well with small payloads
- Slow.
For small data though in some use cases, the relative gains of entropy
coding relative to raw bytes can become small though.
Huffman falls first:
Constant overheads of the Huffman tables themselves become the dominant
part of the overhead.
AdRice falls second:
At a certain limit, it can become ineffective.
Range falls third:
Usually the best, but initial adaptation time becomes the bottleneck
(needs a minimum number of symbols to actually adapt to anything).
Had noted recently that AdRice's effectiveness can be improved slightly
at a fairly modest speed cost by slowing the adaptation speed (say, by
adjusting by a fraction of a bit each time).
Say, typical:
Q=0: Decrement K (if K>0)
Q=1: Leave K as-is
Q>=2: Increment K
Where K is the number of fixed bits following the unary-coded prefix (Q).
The tweak being to instead adapt a scaled K, say S, then define K=S>>4
or similar (so, it effectively needs multiple symbols before the value
of K updates, but increases how often symbols are encoded at the optimal
value of K).
As for STF (swap towards front):
Usual strategy still to swap symbols with whatever is at (15*I/16) or
similar.
There are other schemes, but this one has most often ended up winning
out IME.
>>
>> So, net result: Despite its conceptual simplicity, PNG's decode-time
>> performance typically sucks.
>>
>> Contrast, a decoder for a JPEG like format can be made to process one
>> block at a time and go all the way to final output. So, JPEG is often
>> faster despite the more complex process (with transform stages and a
>> colorspace transform).
>>
>>
>> The Paeth filter slowness does seem a little odd though:
>> Theoretically, a CPU could turn a short forward branch into predication;
>> But, this doesn't tend to be the case.
>>
>> It then is faster to turn the filter into some convoluted mess of
>> arithmetic and masking in an attempt to reduce the branch mispredict
>> costs.
>
> I would look for a way to handle multiple pixels at once, with SIMD
> code: There the masking/combining is typically the easiest way to
> implement short branches.
>
> (I might take a look a png decoding at some point)
>
#if 0 //naive version, pays a lot for branch penalties
int BGBBTJ_BufPNG_Paeth(int a, int b, int c)
{
int p, pa, pb, pc;
p=a+b-c;
pa=(p>a)?(p-a):(a-p);
pb=(p>b)?(p-b):(b-p);
pc=(p>c)?(p-c):(c-p);
p=(pa<=pb)?((pa<=pc)?a:c):((pb<=pc)?b:c);
return(p);
}
#endif
#if 1 //avoid branch penalties
int BGBBTJ_BufPNG_Paeth(int a, int b, int c)
{
int p, pa, pb, pc;
int ma, mb, mc;
p=a+b-c;
pa=p-a; pb=p-b; pc=p-c;
ma=pa>>31; mb=pb>>31; mc=pc>>31;
pa=pa^ma; pb=pb^mb; pc=pc^mc;
ma=pb-pa; mb=pc-pb; mc=pc-pa;
ma=ma>>31; mb=mb>>31; mc=mc>>31;
p=(ma&((mb&c)|((~mb)&b))) | ((~ma)&((mc&c)|((~mc)&a)));
return(p);
}
#endif
Where, the Paeth filter is typically the most heavily used filter in PNG
decoding (because it tends to be the most accurate), but also the slowest.
Could in theory be SIMD'ed to maybe work on RGB or RGBA in parallel.
If someone were designing a new PNG like format, one option could be, say:
p=(3*a+3*b-2*c)>>2;
//maybe: clamp p to 0..255 or similar
Which is "similar, but cheaper".
Otherwise, could be possible to have a faster PNG like format if the
format were structured to allow doing everything in a single pass (with
no separate LZ stage).
If I were designing it, might also be tempted to use AdRice rather than
Huffman.
...
Otherwise:
Meanwhile, I am mostly starting to question if one might ironically need
to add a restriction clause to MIT-0 to preserve freedom, say, something
like:
This code may not be used in jurisdictions where usage would violate the
terms of the No Warranty clause or where use of the code would be in
violation of the laws within that jurisdiction.
Since as-is, the existing language doesn't offer sufficient protection
from liability in cases where users use code in violation of laws and
where said laws hold the vendors or copyright holders liable for
violation of local laws (say, because the code does not actively prevent
users from using it in a way which is illegal within their laws, and
which would be applied to parties outside of the jurisdiction in question).
While MIT-0 allows for re-licensing, this would shift liability to the
user of the code for using it in a way that violates local laws.
Should offer protection except in cases where it could be argued that
the developers had intended for users to use the code in ways which
violated laws (which would be harder to prove except in cases where it
could be argued that the sole intended purpose of the code was to be
used in a way which violated a law; rather than otherwise benign code
that was used in a way which violated the law).
Well, at least in theory.
> Terje
>
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-03-01 19:02 +0100 |
| Subject | Re: IA-64 |
| Message-ID | <10o1uva$ep56$1@dont-email.me> |
| In reply to | #115172 |
BGB wrote:
> On 2/28/2026 9:48 AM, Terje Mathisen wrote:
>> This reminds me of CABAC decoding in h264, where the output of the
>> arithmetic decoder is single bits that by definition cannot be
>> predictable, but the codec typically uses that bit to branch.
>>
>
> Yeah.
>
> Making arithmetic and range coders fast is also hard.
>
> I don't often use them as much because I am not aware of a good way to
> make them fast.
>
>
>
> This is part of why I had often ended up going for STF+AdRice or
> similar, which, while not the best in terms of compression, can be one
> of the faster options in many cases.
>
> Theoretically, table-driven Huffman could be faster, but likewise often
> suffers from cache misses (cycles lost to cache misses can outweigh the
> cost of the more complex logic of an AdRice coder).
>
> Huffman speed can be improved by reducing maximum symbol length and
> table size, but then this can lose much its compression advantage.
>
> Say, max symbol length:
> 10/11: Too short, limits effectiveness.
> 12: OK, leans faster;
> 13: OK, leans better compression;
> 14: Intermediate
> 15: Slower still (Deflate is here)
> 16: Slower (T.81 JPEG is here)
>
>
> Where, for 12/13 bits, the fastest strategy is typically to use a single
> big lookup table for the entropy decoder.
>
> For 15 or 16 bits, it is often faster to have a separate fast-path and
> slow path. Say, fast path matches on the first 9 or 10 bits, and then
> the slow path falls back to a linear search (over the longer symbols).
I have looked at multi-level table lookups, where the symbol either is
the one you want (short codes) or an index into a list of secondary
tables to be used on the remaining bits.
When you have many really short codes (think Morse!) , then you can
profitably decode multiple in a single iteration.
>
> In this case, the relative slowness of falling back to a linear search
> being less than that of the cost of the L1 misses from a bigger lookup
> table.
>
> The relative loss of Huffman coding efficiency between a 13 bit limit
> and 15 bit limit is fairly modest.
Yeah.
>> I would look for a way to handle multiple pixels at once, with SIMD
>> code: There the masking/combining is typically the easiest way to
>> implement short branches.
>>
>> (I might take a look a png decoding at some point)
>>
>
>
> #if 0 //naive version, pays a lot for branch penalties
> int BGBBTJ_BufPNG_Paeth(int a, int b, int c)
> {
> int p, pa, pb, pc;
>
> p=a+b-c;
> pa=(p>a)?(p-a):(a-p);
> pb=(p>b)?(p-b):(b-p);
> pc=(p>c)?(p-c):(c-p);
>
> p=(pa<=pb)?((pa<=pc)?a:c):((pb<=pc)?b:c);
> return(p);
> }
> #endif
>
> #if 1 //avoid branch penalties
> int BGBBTJ_BufPNG_Paeth(int a, int b, int c)
> {
> int p, pa, pb, pc;
> int ma, mb, mc;
> p=a+b-c;
> pa=p-a; pb=p-b; pc=p-c;
> ma=pa>>31; mb=pb>>31; mc=pc>>31;
> pa=pa^ma; pb=pb^mb; pc=pc^mc;
> ma=pb-pa; mb=pc-pb; mc=pc-pa;
> ma=ma>>31; mb=mb>>31; mc=mc>>31;
> p=(ma&((mb&c)|((~mb)&b))) | ((~ma)&((mc&c)|((~mc)&a)));
> return(p);
> }
> #endif
>
> Where, the Paeth filter is typically the most heavily used filter in PNG
> decoding (because it tends to be the most accurate), but also the slowest.
>
> Could in theory be SIMD'ed to maybe work on RGB or RGBA in parallel.
OK
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-03-01 18:05 -0600 |
| Subject | Re: IA-64 |
| Message-ID | <10o2kiq$mcbq$1@dont-email.me> |
| In reply to | #115176 |
On 3/1/2026 12:02 PM, Terje Mathisen wrote:
> BGB wrote:
>> On 2/28/2026 9:48 AM, Terje Mathisen wrote:
>>> This reminds me of CABAC decoding in h264, where the output of the
>>> arithmetic decoder is single bits that by definition cannot be
>>> predictable, but the codec typically uses that bit to branch.
>>>
>>
>> Yeah.
>>
>> Making arithmetic and range coders fast is also hard.
>>
>> I don't often use them as much because I am not aware of a good way to
>> make them fast.
>>
>>
>>
>> This is part of why I had often ended up going for STF+AdRice or
>> similar, which, while not the best in terms of compression, can be one
>> of the faster options in many cases.
>>
>> Theoretically, table-driven Huffman could be faster, but likewise
>> often suffers from cache misses (cycles lost to cache misses can
>> outweigh the cost of the more complex logic of an AdRice coder).
>>
>> Huffman speed can be improved by reducing maximum symbol length and
>> table size, but then this can lose much its compression advantage.
>>
>> Say, max symbol length:
>> 10/11: Too short, limits effectiveness.
>> 12: OK, leans faster;
>> 13: OK, leans better compression;
>> 14: Intermediate
>> 15: Slower still (Deflate is here)
>> 16: Slower (T.81 JPEG is here)
>>
>>
>> Where, for 12/13 bits, the fastest strategy is typically to use a
>> single big lookup table for the entropy decoder.
>>
>> For 15 or 16 bits, it is often faster to have a separate fast-path and
>> slow path. Say, fast path matches on the first 9 or 10 bits, and then
>> the slow path falls back to a linear search (over the longer symbols).
>
> I have looked at multi-level table lookups, where the symbol either is
> the one you want (short codes) or an index into a list of secondary
> tables to be used on the remaining bits.
>
Can work OK if one assumes all of the longer codes are prefixed by a
longish series of 1s, which is usually but not necessarily true.
Probably more true of a Deflate style table though, where sending the
table as an array of symbol lengths does limit the configurations it can
take.
> When you have many really short codes (think Morse!) , then you can
> profitably decode multiple in a single iteration.
>
Typical in my case of both shorter length-limited Huffman, and of Rice
coding.
In the case of Rice, it can often make sense to use a lookup table to
decode the Q prefix.
Say (pseudocode):
b=PeekBits()
q=qtab[b&255];
if(q>=8)
{ skb=16; v=(b>>8)&255; }
else
{ skb=q+k+1; v=(q<<k)|((b>>(q+1))&((1<<k)-1)); }
SkipBits(skb);
>>
>> In this case, the relative slowness of falling back to a linear search
>> being less than that of the cost of the L1 misses from a bigger lookup
>> table.
>>
>> The relative loss of Huffman coding efficiency between a 13 bit limit
>> and 15 bit limit is fairly modest.
>
> Yeah.
>
Some of my designs where I stuck with Huffman had ended up going over to
a 13 bit limit partly for this reason, as in this case, the lookup table
fitting in the L1 cache ends up as a win.
Though, a factor is the number of tables in use; something more like
JPEG where one has 4 of them (Y-DC, Y-AC, UV-DC, UV-AC); this still
isn't going to fit in the L1 cache.
So, errm, partial win here for STF+AdRice.
Though, one could argue:
Why use Rice for encoding the coefficient values as VLNs vs just
encoding the values directly as Rice? Well, simple answer is mostly that
this sucks.
As noted, one might want to encode symbols that encode both a zero run
and a value. JPEG had used Z4V4, with the value directly encoding the
number of bits. The scheme used by JPEG was comparably space-inefficient
though; and the general scheme used by Deflate was more space-efficient.
So:
JPEG scheme:
Read V bits;
Sign extend these bits for the full coefficient.
val=ReadBits(v);
sh=31-v;
val=((s32)((val)<<sh))>>sh;
Deflate Inspired:
if(v>=4)
{ h=(v>>1)-1; val=((2|(v&1))<<h)|ReadBits(h); }
else
{ val=v; }
val=(val>>1)^(((s32)(val<<31))>>31);
where, value table (unsigned) looks sorta like:
pfx extra value
0/1 0 0 / 1
2/3 0 2 / 3
4/5 1 4.. 7
6/7 2 8..15
8/9 3 16..31
...
With the LSB then encoding the sign, so:
0, -1, 1, -2, 2, ...
Though, as can be noted, the loss of one bit for Z means that the
maximum run of zeroes per symbol is shorter.
The main difference is mostly that the JPEG scheme costs roughly 1 bit
more per VLN (typical), or 2 bits more for small values (-1 and 1 need 2
extra with the JPEG scheme).
Though, despite the more efficient VLN scheme, UPIC does lose some
entropic efficiency with its use of STF+AdRice here rather than Huffman.
>>> I would look for a way to handle multiple pixels at once, with SIMD
>>> code: There the masking/combining is typically the easiest way to
>>> implement short branches.
>>>
>>> (I might take a look a png decoding at some point)
>>>
>>
>>
>> #if 0 //naive version, pays a lot for branch penalties
>> int BGBBTJ_BufPNG_Paeth(int a, int b, int c)
>> {
>> int p, pa, pb, pc;
>>
>> p=a+b-c;
>> pa=(p>a)?(p-a):(a-p);
>> pb=(p>b)?(p-b):(b-p);
>> pc=(p>c)?(p-c):(c-p);
>>
>> p=(pa<=pb)?((pa<=pc)?a:c):((pb<=pc)?b:c);
>> return(p);
>> }
>> #endif
>>
>> #if 1 //avoid branch penalties
>> int BGBBTJ_BufPNG_Paeth(int a, int b, int c)
>> {
>> int p, pa, pb, pc;
>> int ma, mb, mc;
>> p=a+b-c;
>> pa=p-a; pb=p-b; pc=p-c;
>> ma=pa>>31; mb=pb>>31; mc=pc>>31;
>> pa=pa^ma; pb=pb^mb; pc=pc^mc;
>> ma=pb-pa; mb=pc-pb; mc=pc-pa;
>> ma=ma>>31; mb=mb>>31; mc=mc>>31;
>> p=(ma&((mb&c)|((~mb)&b))) | ((~ma)&((mc&c)|((~mc)&a)));
>> return(p);
>> }
>> #endif
>>
>> Where, the Paeth filter is typically the most heavily used filter in
>> PNG decoding (because it tends to be the most accurate), but also the
>> slowest.
>>
>> Could in theory be SIMD'ed to maybe work on RGB or RGBA in parallel.
>
> OK
>
As an idle thought for a format "sorta PNG-like", but meant to be faster
to decode (though, aiming to be closer to PNG than, say, QOI).
Tag symbols encode commands, say:
01..0F: 1..15 pixels, Delta per Pixel, useoffset=0;
11..1F: 1..15 pixels, Delta per pixel, useOffset=1;
21..2F: 1..15 pixels, Delta is 0, useOffset=0;
30..3F: 1..15 pixels, Delta is 0, useOffset=1;
41..4F: 1..15 pixels, Single Delta, Applied Every Pixel
51..5F: 1..15 pixels, Single Delta, Applied One Pixel
00/10/20/30/40/50: 16+ pixels
Length follows, encoded as a VLN.
Otherwise behaves the same as the corresponding 1-15 case.
60..6F: -
70..7F: -
80..8F: -
90..9F: -
A0..AF: Single Delta of a given Type, useOffset=0;
B0..BF: Single Delta of a given Type, useOffset=1;
C0..CF: Set Predictor Function, useOffset=0;
D0..DF: -
E0..FF: Set Predictor Offset, useOffset=1;
So, in this case:
useOffset==0:
Predict pixel values in a similar way to PNG.
Adjacent pixels are used with predictor.
useOffset==1:
The Offset gives at a previous location in the image
Deltas relative to the pixels at this offset.
Offset is in raster space, must point within image.
Encoded in a similar way to a Deflate distance.
Always relative to the current position in raster space.
The offset pixel is used as the prediction.
So, setting an offset and then doing a run of delta==0 pixels
effectively just copies the prior pixels. Otherwise, deltas are applied
relative to those pixels.
As in PNG, the deltas would likely be mod-256.
Each delta point would be encoded as a symbol.
Predictor functions:
0: Special, restore last predictor
1: Last Value
2: Left
3: Up
4: Average of Left and Up
6: (3*A+3*B-2*C)/4
7: Paeth (Possible, but slower option)
Delta Types:
0: Special, last delta type
1: dY, dR=dG=dB=dY, dA=0
2: dRGB, dA=0
3: dRGBA
4: dYUV, dA=0 (encodes dRGB as RCT)
5: dYUVA
Would likely have STF+AdRice contexts for:
Tag/Command Bytes
Delta Bytes
Length VLN prefix values.
Downsides:
This design as-is in not particularly elegant;
Would exist awkwardly in a part of the design space between PNG and QOI;
Would have a comparably more complex encoder.
Would be considered as failing if:
Compression is significantly worse than PNG;
Fails to beat PNG at decode speed.
The more complex stream representation is partly to compensate for not
having an LZ stage.
...
Would likely make sense to have the various configurations as function
pointers, but this is not ideal (both due to code bulk and
function-pointer overheads). But, function pointers are likely to be
faster than decision trees in this case.
Then again, might just be better to figure out some effective way to
have an incremental stream-decoded inflater...
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-03-02 02:03 +0000 |
| Subject | Re: IA-64 |
| Message-ID | <1772416990-5857@newsgrouper.org> |
| In reply to | #115185 |
BGB <cr88192@gmail.com> posted: > On 3/1/2026 12:02 PM, Terje Mathisen wrote: > > BGB wrote: > >> On 2/28/2026 9:48 AM, Terje Mathisen wrote: > >>> This reminds me of CABAC decoding in h264, where the output of the > >>> arithmetic decoder is single bits that by definition cannot be > >>> predictable, but the codec typically uses that bit to branch. > >>> > >> > >> Yeah. > >> > >> Making arithmetic and range coders fast is also hard. > >> > >> I don't often use them as much because I am not aware of a good way to > >> make them fast. > >> > >> > >> > >> This is part of why I had often ended up going for STF+AdRice or > >> similar, which, while not the best in terms of compression, can be one > >> of the faster options in many cases. > >> > >> Theoretically, table-driven Huffman could be faster, but likewise > >> often suffers from cache misses (cycles lost to cache misses can > >> outweigh the cost of the more complex logic of an AdRice coder). > >> > >> Huffman speed can be improved by reducing maximum symbol length and > >> table size, but then this can lose much its compression advantage. > >> > >> Say, max symbol length: > >> 10/11: Too short, limits effectiveness. > >> 12: OK, leans faster; > >> 13: OK, leans better compression; > >> 14: Intermediate > >> 15: Slower still (Deflate is here) > >> 16: Slower (T.81 JPEG is here) > >> > >> > >> Where, for 12/13 bits, the fastest strategy is typically to use a > >> single big lookup table for the entropy decoder. > >> > >> For 15 or 16 bits, it is often faster to have a separate fast-path and > >> slow path. Say, fast path matches on the first 9 or 10 bits, and then > >> the slow path falls back to a linear search (over the longer symbols). > > > > I have looked at multi-level table lookups, where the symbol either is > > the one you want (short codes) or an index into a list of secondary > > tables to be used on the remaining bits. > > > > Can work OK if one assumes all of the longer codes are prefixed by a > longish series of 1s, which is usually but not necessarily true. In HW any pattern can be used. In SW only patterns that are almost satisfied by the current ISA can be considered. Big difference.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-03-03 04:24 -0600 |
| Subject | Re: IA-64 |
| Message-ID | <10o6d75$1u34a$1@dont-email.me> |
| In reply to | #115186 |
On 3/1/2026 8:03 PM, MitchAlsup wrote: > > BGB <cr88192@gmail.com> posted: > >> On 3/1/2026 12:02 PM, Terje Mathisen wrote: >>> BGB wrote: >>>> On 2/28/2026 9:48 AM, Terje Mathisen wrote: >>>>> This reminds me of CABAC decoding in h264, where the output of the >>>>> arithmetic decoder is single bits that by definition cannot be >>>>> predictable, but the codec typically uses that bit to branch. >>>>> >>>> >>>> Yeah. >>>> >>>> Making arithmetic and range coders fast is also hard. >>>> >>>> I don't often use them as much because I am not aware of a good way to >>>> make them fast. >>>> >>>> >>>> >>>> This is part of why I had often ended up going for STF+AdRice or >>>> similar, which, while not the best in terms of compression, can be one >>>> of the faster options in many cases. >>>> >>>> Theoretically, table-driven Huffman could be faster, but likewise >>>> often suffers from cache misses (cycles lost to cache misses can >>>> outweigh the cost of the more complex logic of an AdRice coder). >>>> >>>> Huffman speed can be improved by reducing maximum symbol length and >>>> table size, but then this can lose much its compression advantage. >>>> >>>> Say, max symbol length: >>>> 10/11: Too short, limits effectiveness. >>>> 12: OK, leans faster; >>>> 13: OK, leans better compression; >>>> 14: Intermediate >>>> 15: Slower still (Deflate is here) >>>> 16: Slower (T.81 JPEG is here) >>>> >>>> >>>> Where, for 12/13 bits, the fastest strategy is typically to use a >>>> single big lookup table for the entropy decoder. >>>> >>>> For 15 or 16 bits, it is often faster to have a separate fast-path and >>>> slow path. Say, fast path matches on the first 9 or 10 bits, and then >>>> the slow path falls back to a linear search (over the longer symbols). >>> >>> I have looked at multi-level table lookups, where the symbol either is >>> the one you want (short codes) or an index into a list of secondary >>> tables to be used on the remaining bits. >>> >> >> Can work OK if one assumes all of the longer codes are prefixed by a >> longish series of 1s, which is usually but not necessarily true. > > In HW any pattern can be used. In SW only patterns that are almost > satisfied by the current ISA can be considered. Big difference. I guess it is possible someone could define hardware logic to support Huffman coding, but then again, it would be even easier to define hardware support for Rice coding. Though, this could range from more generic, like a CTNZ instruction (Count Trailing Non-Zero) to maybe more specialized instructions. Big downside for Huffman in HW is that almost invariably it would require big lookup tables, wheres Rice coding could mostly be done with fixed logic (and/or more generic instructions). Like, often the main lookup table used for Rice-decoding is just to do the equivalent of a CTNZ operation. Could integrate things more, but this would likely get into the territory of needing instructions with multiple destination registers or similar (and/or some sort of state-containing architectural feature). ... Meanwhile, did a quick mock-up of the Rice-coded vaguely PNG-like format mentioned a previously (calling it UNG for now), but thus far it is kinda looking like a turd. Comparing a few formats (with a photo-like image, 1024x688, lossless or max quality; speeds on my desktop PC): UPIC: 488K, 41.5 Mpix/s UNG : 1060K, 21.6 Mpix/s JPG : 410K, 25.3 Mpix/s (Q=100, inexact) PNG : 795K, 12.7 Mpix/s QOI : 1036K, 76.2 Mpix/s So, UPIC gives nearly JPEG-like compression while being lossless and faster than either JPEG or PNG. QOI wins for speed, but not compression (it is a byte-oriented format). It is fast, but in my own testing its compression still often loses to PNG (despite claims that it beats PNG). And, my UNG test was kind of a fail thus far, having a QOI-like file-size with closer to PNG-like speeds. Well, and the use of entropy coding is not necessarily a win though, if the design still turns out to be kinda a turd... UNG could maybe be improved with more fiddling, but thus far this is not a good start. It looks like UPIC is still in the lead here. Initially, it was mostly just focused on speed (and ability to support a lossless mode) but turned out to also be pretty solid for compression as well. Also maybe ironic that the Block Haar Transform is both faster than DCT and also still fairly effective as a block transform (and lossless). Not sure why Block-Haar is not more popular. Note that both UPIC and JPG see a pretty big speed boost when used lossy compression here (and, among the formats tested, JPG is the closest direct analog to UPIC among the mainline formats). Then again, maybe I need to test with highly-compressible synthetic images (like UI graphics), as this is typically where PNG holds a strong lead. And, I didn't really come up with the UNG design with photos in mind (even if they make sense as an initial test case). Would likely be a worse option for texture-maps than UPIC. Likely has no real advantage over indexed-color BMP for the use-cases where indexed-color BMP makes sense (and thus far the best compression method for indexed-color graphics seems to be to use LZ compression over the indexed color graphics). Still kinda annoying sometimes that it seems like stuff like this can be a bit hit or miss, one doesn't always know in advance whether something will work well or turn out to just kinda suck (well, and sometimes things that seem to suck initially can pull ahead with some more polishing). ...
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-03-08 17:53 +0000 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <memo.20260308175313.20100L@jgd.cix.co.uk> |
| In reply to | #115071 |
In article <2026Feb21.171811@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > IA-64 certainly had significantly larger code sizes than others, > but I think that they expected it and found it acceptable. The code size would have been better had they obtained the hoped-for ILP. Too much was riding on that. Also, bulky code is hard on memory bandwidth and cache size, and IA-64 needed more of those than its competitors. > And a software-pipelined loop on IA-64 is probably smaller than an > auto-vectorized loop on AMD64+AVX The code I was working on at the time (and still do) didn't _have_ many loops that the compiler could software-pipeline, or that can be auto- vectorised now. It's pretty branchy and does a lot of pointer-chasing. Making it reliable and extending its functionality has always been higher priority than redesigning its many algorithms for vectorisation. It is largely memory-bound. > Actually, other architectures also added prefetching instructions > for dealing with that problem. All I have read about that was that > there were many disappointments when using these instructions. > I don't know if there were any successes, and how frequent they > were compared to the disappointments. I have never encountered any successes, and given how keen Intel were on their x86 version of this, and my employers' relationship with them at the time, I would expect to have heard about them. My own experience was disappointing, with minor speedups and slowdowns. My best hypothesis was that the larger code size worsened cache effects enough to cancel out any gains from the prefetches. > So I don't see that IA-64 was any different from other architectures > in that respect. Two points on that: Prefetches were a fundamental architectural feature of IA-64, and Intel professed to believe in their effectiveness. Further, they came into registers, rather than cache. The loading into registers was part of an architectural bug with prefetches of floating-point values. If you did a floating-point advance into a callee-save register, then called a function which actually did save that register, the sequence of event could easily come out as: Advance floating-point load into Rn. ... Call function. Function pushes Rn. ... Advance load arrives, possibly messing up the function. ... Function pops Rn. Function returns. ... Check the floating-point load. The ALAT says it has happened, which is true. However, the value has been lost. The "fix" adopted was to re-issue all outstanding floating-point loads after each function call and return. That bulked out the code still more. > OoO helps in several ways: it will do some work in the shadow of the > load (although the utilization will still be abysmal even with > present-day schedulers and ROBs [1]); but more importantly, it can > dispatch additional loads that may also miss the cache, resulting in > more memory-level parallelism. Yup. > They wanted to do it (and did it) in the compiler; the corresponding > architectural feature is IIRC the advanced load. And it failed, comprehensively. > Having so many registers may have mad it harder than otherwise, but > SPARC also used many registers Not really on the same scale, surely? > The issue is that speculative execution and OoO makes all the > EPIC features of IA-64 unnecessary, so if they cannot do > a fast in-order implementation of IA-64 (and they could not), they > should just give up and switch to an architecture without these > features, such as AMD64. And Intel did, after a few years of > denying. Yes. They claimed at the time they would bring IA-64 back, when the fab technology was better. I don't think anyone believed them at the time, but an Intel marketing person I talked to a few years later was quite shocked at the idea that everyone knew this was nonsense, and they were just being humoured because arguing was pointless. > In a world where we see convergence on fewer and fewer architecture > styles and on fewer and fewer architectures, you only see the > investment necessary for high-performance implementations of a new > architecture if there is a very good reason not to use one of the > established architectures (for ARM T32 and ARM A64 the smartphone > market was that reason). It may be that politics will provide that > reason for another architecture, but even then it's hard. But > RISC-V seems to have the most mindshare among the alternatives, > so if any architecture will catch up, it looks like the best bet. I was expecting the old tradition of "We have better computers, come and buy them" to have some effect, but it doesn't seem to be happening for RISC-V. There are at least two companies that were trying to design high-performance RISC-V cores, in MIPS, who have been taken over and seem to be focused on other things now, and Ahead Computing, who haven't done much visible since they were formed. John
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-03-08 21:15 +0000 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <1773004557-5857@newsgrouper.org> |
| In reply to | #115258 |
jgd@cix.co.uk (John Dallman) posted: > In article <2026Feb21.171811@mips.complang.tuwien.ac.at>, > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >--------------------- > > > Actually, other architectures also added prefetching instructions > > for dealing with that problem. All I have read about that was that > > there were many disappointments when using these instructions. > > I don't know if there were any successes, and how frequent they > > were compared to the disappointments. > > I have never encountered any successes, and given how keen Intel were on > their x86 version of this, and my employers' relationship with them at > the time, I would expect to have heard about them. My own experience was > disappointing, with minor speedups and slowdowns. My best hypothesis was > that the larger code size worsened cache effects enough to cancel out any > gains from the prefetches. > > > So I don't see that IA-64 was any different from other architectures > > in that respect. > > Two points on that: > While I have, personally, added prefetch SW instructions and HW prefetchers, these tend to add performance rather sporadically, and seldom add "enough" performance to justify taking up 'that much' of ISA or designer time.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-03-08 16:43 -0500 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <10okqsk$2p6o6$2@dont-email.me> |
| In reply to | #115269 |
On 3/8/2026 4:15 PM, MitchAlsup wrote: > > jgd@cix.co.uk (John Dallman) posted: > >> In article <2026Feb21.171811@mips.complang.tuwien.ac.at>, >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >> --------------------- >> >>> Actually, other architectures also added prefetching instructions >>> for dealing with that problem. All I have read about that was that >>> there were many disappointments when using these instructions. >>> I don't know if there were any successes, and how frequent they >>> were compared to the disappointments. >> >> I have never encountered any successes, and given how keen Intel were on >> their x86 version of this, and my employers' relationship with them at >> the time, I would expect to have heard about them. My own experience was >> disappointing, with minor speedups and slowdowns. My best hypothesis was >> that the larger code size worsened cache effects enough to cancel out any >> gains from the prefetches. >> >>> So I don't see that IA-64 was any different from other architectures >>> in that respect. >> >> Two points on that: >> > > While I have, personally, added prefetch SW instructions and HW prefetchers, > these tend to add performance rather sporadically, and seldom add "enough" > performance to justify taking up 'that much' of ISA or designer time. Yeah... This area seems to be a lost cause, as cache misses seem to be a rather inescapable cost IME.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-03-09 13:14 -0400 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <qeDrR.81290$wcP9.29931@fx24.iad> |
| In reply to | #115269 |
MitchAlsup wrote: > jgd@cix.co.uk (John Dallman) posted: > >> In article <2026Feb21.171811@mips.complang.tuwien.ac.at>, >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >> --------------------- >> >>> Actually, other architectures also added prefetching instructions >>> for dealing with that problem. All I have read about that was that >>> there were many disappointments when using these instructions. >>> I don't know if there were any successes, and how frequent they >>> were compared to the disappointments. >> I have never encountered any successes, and given how keen Intel were on >> their x86 version of this, and my employers' relationship with them at >> the time, I would expect to have heard about them. My own experience was >> disappointing, with minor speedups and slowdowns. My best hypothesis was >> that the larger code size worsened cache effects enough to cancel out any >> gains from the prefetches. >> >>> So I don't see that IA-64 was any different from other architectures >>> in that respect. >> Two points on that: >> > > While I have, personally, added prefetch SW instructions and HW prefetchers, > these tend to add performance rather sporadically, and seldom add "enough" > performance to justify taking up 'that much' of ISA or designer time. One area I think might be a benefit is to prefetch VA translations for instructions and data. These can be prefetched just into cache, or into I- and D- TLB's. I had the idea in 2010 while looking at locking and hardware transactions. If a memory section is guarded by a mutex, I don't want to prefetch the data as that could yank ownership away from the current mutex holder. What I might do is prefetch the translation PTE's for the data locations so that when I am granted mutex ownership that I minimize the time it is held by not waiting for cold memory table walks. I also optionally might like to be able to trigger advance page faults on data but without actually touching the data page such that it moves cache line ownership. This could save me from taking a page fault on a shared memory section while holding the guard mutex. Prefetching the VA translates for instructions could be a good tradeoff for alternate paths and just load the PTE's into cache, as opposed to loading the alternate code into cache. The VA translate prefetch instructions would need options to control which cache and I- and D- TLB level the PTE's are prefetched into.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-03-09 19:30 +0000 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <1773084628-5857@newsgrouper.org> |
| In reply to | #115283 |
EricP <ThatWouldBeTelling@thevillage.com> posted:
> MitchAlsup wrote:
> > jgd@cix.co.uk (John Dallman) posted:
> >
> >> In article <2026Feb21.171811@mips.complang.tuwien.ac.at>,
> >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >> ---------------------
> >>
> >>> Actually, other architectures also added prefetching instructions
> >>> for dealing with that problem. All I have read about that was that
> >>> there were many disappointments when using these instructions.
> >>> I don't know if there were any successes, and how frequent they
> >>> were compared to the disappointments.
> >> I have never encountered any successes, and given how keen Intel were on
> >> their x86 version of this, and my employers' relationship with them at
> >> the time, I would expect to have heard about them. My own experience was
> >> disappointing, with minor speedups and slowdowns. My best hypothesis was
> >> that the larger code size worsened cache effects enough to cancel out any
> >> gains from the prefetches.
> >>
> >>> So I don't see that IA-64 was any different from other architectures
> >>> in that respect.
> >> Two points on that:
> >>
> >
> > While I have, personally, added prefetch SW instructions and HW prefetchers,
> > these tend to add performance rather sporadically, and seldom add "enough"
> > performance to justify taking up 'that much' of ISA or designer time.
>
> One area I think might be a benefit is to prefetch VA translations
> for instructions and data. These can be prefetched just into cache,
> or into I- and D- TLB's.
>
> I had the idea in 2010 while looking at locking and hardware transactions.
> If a memory section is guarded by a mutex, I don't want to prefetch
> the data as that could yank ownership away from the current mutex holder.
Then you need a LD instruction that can fail and the status tested by
some other instruction. That is: code performs a LD; LD takes a miss
and leaves the CPU. Access finds cache line in modified or exclusive
state, and instead of returning the value and making line stale, it
fails. {with whatever definition you want for fail}. Since MOESI uses
3-bits, you can use an unused MOESI state to record that a failed access
has transpired--then use this to optimize downstream-cache behavior.
> What I might do is prefetch the translation PTE's for the data locations
> so that when I am granted mutex ownership that I minimize the time
> it is held by not waiting for cold memory table walks.
This is what table-walk accelerators are for.
> I also optionally might like to be able to trigger advance page faults
> on data but without actually touching the data page such that it moves
> cache line ownership. This could save me from taking a page fault on a
> shared memory section while holding the guard mutex.
>
> Prefetching the VA translates for instructions could be a good
> tradeoff for alternate paths and just load the PTE's into cache,
> as opposed to loading the alternate code into cache.
>
> The VA translate prefetch instructions would need options to control
> which cache and I- and D- TLB level the PTE's are prefetched into.
I use 5-bits for this (although in practice 3 would have been sufficient)
{PRE, PUSH}×{{RWX}+{Cc}}}
where Cc tells which cache layer the data is fetched up into orpushed
back down into.
PUSH {{010}+{--}} is simple invalidate and throw away modifications.
>
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-03-10 13:04 -0400 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <ZaYrR.92413$mngd.34055@fx16.iad> |
| In reply to | #115284 |
MitchAlsup wrote:
> EricP <ThatWouldBeTelling@thevillage.com> posted:
>
>> MitchAlsup wrote:
>>> jgd@cix.co.uk (John Dallman) posted:
>>>
>>>> In article <2026Feb21.171811@mips.complang.tuwien.ac.at>,
>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>>> ---------------------
>>>>
>>>>> Actually, other architectures also added prefetching instructions
>>>>> for dealing with that problem. All I have read about that was that
>>>>> there were many disappointments when using these instructions.
>>>>> I don't know if there were any successes, and how frequent they
>>>>> were compared to the disappointments.
>>>> I have never encountered any successes, and given how keen Intel were on
>>>> their x86 version of this, and my employers' relationship with them at
>>>> the time, I would expect to have heard about them. My own experience was
>>>> disappointing, with minor speedups and slowdowns. My best hypothesis was
>>>> that the larger code size worsened cache effects enough to cancel out any
>>>> gains from the prefetches.
>>>>
>>>>> So I don't see that IA-64 was any different from other architectures
>>>>> in that respect.
>>>> Two points on that:
>>>>
>>> While I have, personally, added prefetch SW instructions and HW prefetchers,
>>> these tend to add performance rather sporadically, and seldom add "enough"
>>> performance to justify taking up 'that much' of ISA or designer time.
>> One area I think might be a benefit is to prefetch VA translations
>> for instructions and data. These can be prefetched just into cache,
>> or into I- and D- TLB's.
>>
>> I had the idea in 2010 while looking at locking and hardware transactions.
>> If a memory section is guarded by a mutex, I don't want to prefetch
>> the data as that could yank ownership away from the current mutex holder.
>
> Then you need a LD instruction that can fail and the status tested by
> some other instruction. That is: code performs a LD; LD takes a miss
> and leaves the CPU. Access finds cache line in modified or exclusive
> state, and instead of returning the value and making line stale, it
> fails. {with whatever definition you want for fail}. Since MOESI uses
> 3-bits, you can use an unused MOESI state to record that a failed access
> has transpired--then use this to optimize downstream-cache behavior.
Interesting - a load conditional on the cache line being either
- cached locally in an MOES state
- cached remotely in an S state
- uncached
Does your ESM use this approach?
>> What I might do is prefetch the translation PTE's for the data locations
>> so that when I am granted mutex ownership that I minimize the time
>> it is held by not waiting for cold memory table walks.
>
> This is what table-walk accelerators are for.
If by table walk accelerator you mean caching the interior level PTE's
on the downward walk, and if there is a PTE miss checking them in a
bottom-up table walk, then that mechanism is still there and
my PTE prefetch would make use of it.
>> I also optionally might like to be able to trigger advance page faults
>> on data but without actually touching the data page such that it moves
>> cache line ownership. This could save me from taking a page fault on a
>> shared memory section while holding the guard mutex.
>>
>> Prefetching the VA translates for instructions could be a good
>> tradeoff for alternate paths and just load the PTE's into cache,
>> as opposed to loading the alternate code into cache.
>>
>> The VA translate prefetch instructions would need options to control
>> which cache and I- and D- TLB level the PTE's are prefetched into.
>
> I use 5-bits for this (although in practice 3 would have been sufficient)
> {PRE, PUSH}×{{RWX}+{Cc}}}
> where Cc tells which cache layer the data is fetched up into orpushed
> back down into.
> PUSH {{010}+{--}} is simple invalidate and throw away modifications.
I would also have 2 or 3 cache control bits on all levels of PTE's
but I would have separate lookup tables for interior and leaf PTE's.
The tables map the cache control bits to the kind of caching the
for that table level.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-03-10 18:28 +0000 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <1773167287-5857@newsgrouper.org> |
| In reply to | #115290 |
EricP <ThatWouldBeTelling@thevillage.com> posted:
------------------------------
> >> I had the idea in 2010 while looking at locking and hardware transactions.
> >> If a memory section is guarded by a mutex, I don't want to prefetch
> >> the data as that could yank ownership away from the current mutex holder.
> >
> > Then you need a LD instruction that can fail and the status tested by
> > some other instruction. That is: code performs a LD; LD takes a miss
> > and leaves the CPU. Access finds cache line in modified or exclusive
> > state, and instead of returning the value and making line stale, it
> > fails. {with whatever definition you want for fail}. Since MOESI uses
> > 3-bits, you can use an unused MOESI state to record that a failed access
> > has transpired--then use this to optimize downstream-cache behavior.
>
> Interesting - a load conditional on the cache line being either
> - cached locally in an MOES state
> - cached remotely in an S state
> - uncached
>
> Does your ESM use this approach?
ESM solves the case where one CAN have more than 1 cache line in an
ATOMIC state {I've got it and you can't get at it}; which has nothing
to do with MEOSI.
> >> What I might do is prefetch the translation PTE's for the data locations
> >> so that when I am granted mutex ownership that I minimize the time
> >> it is held by not waiting for cold memory table walks.
> >
> > This is what table-walk accelerators are for.
>
> If by table walk accelerator you mean caching the interior level PTE's
> on the downward walk, and if there is a PTE miss checking them in a
> bottom-up table walk, then that mechanism is still there and
> my PTE prefetch would make use of it.
TWA allows for any and all of that--whatever stores fit the needs.
The Ross HyperSPARC's had a TWA consisting of comparitors spanning VA
fields, so the hit also conveyed what level (down from top).
> >> I also optionally might like to be able to trigger advance page faults
> >> on data but without actually touching the data page such that it moves
> >> cache line ownership. This could save me from taking a page fault on a
> >> shared memory section while holding the guard mutex.
> >>
> >> Prefetching the VA translates for instructions could be a good
> >> tradeoff for alternate paths and just load the PTE's into cache,
> >> as opposed to loading the alternate code into cache.
> >>
> >> The VA translate prefetch instructions would need options to control
> >> which cache and I- and D- TLB level the PTE's are prefetched into.
> >
> > I use 5-bits for this (although in practice 3 would have been sufficient)
> > {PRE, PUSH}×{{RWX}+{Cc}}}
> > where Cc tells which cache layer the data is fetched up into orpushed
> > back down into.
> > PUSH {{010}+{--}} is simple invalidate and throw away modifications.
>
> I would also have 2 or 3 cache control bits on all levels of PTE's
> but I would have separate lookup tables for interior and leaf PTE's.
> The tables map the cache control bits to the kind of caching the
> for that table level.
>
>
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-03-11 12:14 -0400 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <YxgsR.132509$WJU1.22392@fx21.iad> |
| In reply to | #115291 |
MitchAlsup wrote: > EricP <ThatWouldBeTelling@thevillage.com> posted: > >>>> What I might do is prefetch the translation PTE's for the data locations >>>> so that when I am granted mutex ownership that I minimize the time >>>> it is held by not waiting for cold memory table walks. >>> This is what table-walk accelerators are for. >> If by table walk accelerator you mean caching the interior level PTE's >> on the downward walk, and if there is a PTE miss checking them in a >> bottom-up table walk, then that mechanism is still there and >> my PTE prefetch would make use of it. > > TWA allows for any and all of that--whatever stores fit the needs. > > The Ross HyperSPARC's had a TWA consisting of comparitors spanning VA > fields, so the hit also conveyed what level (down from top). Yes, this is the bottom-up walker I referred to. The difference is whether one checks multiple levels at once, or at higher levels only after missing at the lowest. On x86 VA translate can look at 4kB TLB first and on a miss then check 2MB and then 1GB level TLB's (the bottom-up walk), or a "table walk accelerator" can look at all 3 levels at once, consuming more power but allowing a single lookup to check all 3 table levels or page sizes at once.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-03-11 21:37 +0000 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <1773265074-5857@newsgrouper.org> |
| In reply to | #115300 |
EricP <ThatWouldBeTelling@thevillage.com> posted:
> MitchAlsup wrote:
> > EricP <ThatWouldBeTelling@thevillage.com> posted:
> >
> >>>> What I might do is prefetch the translation PTE's for the data locations
> >>>> so that when I am granted mutex ownership that I minimize the time
> >>>> it is held by not waiting for cold memory table walks.
> >>> This is what table-walk accelerators are for.
> >> If by table walk accelerator you mean caching the interior level PTE's
> >> on the downward walk, and if there is a PTE miss checking them in a
> >> bottom-up table walk, then that mechanism is still there and
> >> my PTE prefetch would make use of it.
> >
> > TWA allows for any and all of that--whatever stores fit the needs.
> >
> > The Ross HyperSPARC's had a TWA consisting of comparitors spanning VA
> > fields, so the hit also conveyed what level (down from top).
>
> Yes, this is the bottom-up walker I referred to.
> The difference is whether one checks multiple levels at once,
> or at higher levels only after missing at the lowest.
We had 6 comparators: 4 for L3, 1 for L2 and 1 for L1 (down from top)
L3 had 3 8-ish bit comparison fields,
L2 had 2 comparison fields,
L1 had 1 comparison field;
Each had a cache line of PTP data attached--
Each invalidated on ASID change (although we could have done better).
> On x86 VA translate can look at 4kB TLB first and on a miss then check
> 2MB and then 1GB level TLB's (the bottom-up walk), or a "table walk
> accelerator" can look at all 3 levels at once, consuming more power but
> allowing a single lookup to check all 3 table levels or page sizes at once.
x86 has the problem that is has 32-bit PTP/Es with 10-bit fields
and 64-bit PTP/Es with 9-bit fields. Merging both into a single
TLB is "not fun" not is it any "fun" in the TWAs {probably easier
to just build 2 TWAs}.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-03-12 10:56 -0400 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <cwAsR.12488$1n3.7863@fx04.iad> |
| In reply to | #115302 |
MitchAlsup wrote:
> EricP <ThatWouldBeTelling@thevillage.com> posted:
>
>> MitchAlsup wrote:
>>> EricP <ThatWouldBeTelling@thevillage.com> posted:
>>>
>>>>>> What I might do is prefetch the translation PTE's for the data locations
>>>>>> so that when I am granted mutex ownership that I minimize the time
>>>>>> it is held by not waiting for cold memory table walks.
>>>>> This is what table-walk accelerators are for.
>>>> If by table walk accelerator you mean caching the interior level PTE's
>>>> on the downward walk, and if there is a PTE miss checking them in a
>>>> bottom-up table walk, then that mechanism is still there and
>>>> my PTE prefetch would make use of it.
>>> TWA allows for any and all of that--whatever stores fit the needs.
>>>
>>> The Ross HyperSPARC's had a TWA consisting of comparitors spanning VA
>>> fields, so the hit also conveyed what level (down from top).
>> Yes, this is the bottom-up walker I referred to.
>> The difference is whether one checks multiple levels at once,
>> or at higher levels only after missing at the lowest.
>
> We had 6 comparators: 4 for L3, 1 for L2 and 1 for L1 (down from top)
> L3 had 3 8-ish bit comparison fields,
> L2 had 2 comparison fields,
> L1 had 1 comparison field;
> Each had a cache line of PTP data attached--
> Each invalidated on ASID change (although we could have done better).
>
>> On x86 VA translate can look at 4kB TLB first and on a miss then check
>> 2MB and then 1GB level TLB's (the bottom-up walk), or a "table walk
>> accelerator" can look at all 3 levels at once, consuming more power but
>> allowing a single lookup to check all 3 table levels or page sizes at once.
>
> x86 has the problem that is has 32-bit PTP/Es with 10-bit fields
> and 64-bit PTP/Es with 9-bit fields. Merging both into a single
> TLB is "not fun" not is it any "fun" in the TWAs {probably easier
> to just build 2 TWAs}.
There is a different way to do this that VAX used which is well suited
to associative TLB's, as opposed to CAM's, which I'll describe as some
folks here are designing TLB's for FPGA's, which don't do CAM's easily
but do do assoc. caches.
(This description is a simplified variation on VAX approach).
The basic idea was to locate the multiple page table levels at
*virtual base addresses*. This allows all the levels of the radix tree
table to be stored in a single assoc. cache. A bottom-up table walk is
accomplished by recursively looking up virtual addresses in the same TLB.
A virtual address (VA) is composed of two parts, Virtual Page Number (VPN)
and a byte offset. A physical address is composed of two parts,
the Physical Frame Number (PFN) and a byte offset.
MMU looks up a VA in the TLB and misses, then it takes the VPN of the VA and
uses that as an index into the virtual address of the level 1 page table.
That gives a VA of the level-1 PTE which is looked up.
If that hits then that is the level-2 PTE for the level-1 PTE and contains
the PFN of the frame containing the L1-PTE. MMU reads the L1-PTE,
and if Valid inserts it into the TLB at the L1-PTE's VA.
It then uses the L1-PTE PFN to access the code/data.
If its a miss then MMU takes the VPN of the L1-PTE VA, indexes into the
virtual address of the level-2 table to get the VA of the L3-PTE.
MMU looks up the VPN of that VA, which if it hits gives the L3-PTE
containing the PFN of the frame containing the L2-PTE.
At the top of this bottom-up tree walk is a single register containing
the physical address of the top level frame, to be used if all the
lower level TLB lookups miss.
By choosing "nice" virtual addresses for the different page table levels,
all the above does not require arithmetic to index into the tables,
just shifting and inserting low order bits into an address field.
The above MMU table walker has a simple hardware loop with simple decisions
at each step, which is particularly nice when working in TTL where things
like 32-bit adders get expensive real quick. It allows a single assoc cache
to hold all the multiple levels of the page table.
There is more to it that this as it requires some hardware-software
co-design with the OS virtual memory subsystem. For example, one can
have separate TLB's for system address space and process space so
OS can switch processes easily without having to scan the assoc. TLB
to invalidate P-space entries for the old process.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-03-12 18:15 +0000 |
| Subject | Re: IA-64 (was: Tonights Tradeoff) |
| Message-ID | <2026Mar12.191545@mips.complang.tuwien.ac.at> |
| In reply to | #115300 |
EricP <ThatWouldBeTelling@thevillage.com> writes: >On x86 VA translate can look at 4kB TLB first and on a miss then check >2MB and then 1GB level TLB's (the bottom-up walk), or a "table walk >accelerator" can look at all 3 levels at once, consuming more power but >allowing a single lookup to check all 3 table levels or page sizes at once. Looking in (as an example) Section 2.7.1 of "Software Optimization Guide for the AMD Zen4 Microarchitecture", it says: |The processor contains a fully-associative L1 instruction TLB (ITLB) |with 64 entries that can hold 4-Kbyte, 2-Mbyte, or 1-Gbyte page |entries. | |The fully-associative L1 data TLB (DTLB) provides 72 entries that hold |4-Kbyte, 16-Kbyte, 2-Mbyte, or 1-Gbyte page entries And AFAIK other implementations similarly check for small and huge pages at the same time. I remember seeing some info about an implementation where there are separate L1 DTLBs for small and for huge pages, but even for those, they are checked at the same time AFAIK. - 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 | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-02-21 23:51 -0500 |
| Message-ID | <10nik1c$3cpi9$2@dont-email.me> |
| In reply to | #115052 |
On 2/19/26 6:10 PM, John Dallman wrote: [snip] >On 2/19/26 6:04 PM, BGB wrote: >> In a way, it showed that they screwed up the design pretty hard >> that x86-64 ended up being the faster and more efficient option... > > They did. They really did. > >> I guess one question is if they had any other particular drawbacks >> other than, say: >> Their code density was one of the worst around; >> 128 registers is a little excessive; >> 128 predicate register bits is a bit WTF; > > Those huge register files had a lot to do with the low code density. They > had two much bigger problems, though. The large register count seems to have been a result of both the integer-side register stack idea — if one is going to lazily save registers one might as well be able to use those registers within a single function — and the rejection of pipeline- dependent binaries where a result does not use a register name until the result is produced (Itanium code was defined to be executable by single stepping through operations). The hidden pipeline architectural choice also seems to have meant that operations using the results of non-single-cycle operations have to check for availability. Since the register number does not communicate the latency, all register sources would have to check a scoreboard-like structure (I think). (The Mill at least recognized that compiling a distribution format to work on the specific pipeline makes sense for static scheduling.) Loop unrolling combined with software pipelining presumably also motivated larger register files. The lack of base+immediate addressing — to avoid address generation latency when not necessary — also hurt code density even though one could sometimes use post-increment addressing to generate a later-used address. This probably also tended to increase register use as two parallel address computations would have to have different destination registers. The template system also seems to have bloated the code, introducing unnecessary nops. This is also a consequence of not exposing the pipeline; with an exposed microarchitecture the encoding of instruction routing could be simplified. > They'd correctly understood that the low speed of affordable dynamic RAM > as compared to CPUs running at hundreds of MHz was the biggest barrier to > making code run fast. Their solution was have the compiler schedule loads > well in advance. They assumed, without evidence, that a compiler with > plenty of time to think could schedule loads better than hardware doing > it dynamically. It's an appealing idea, but it's wrong. They had 'evidence'. From the Oral history of Robert P. Colwell: | He said, well that's true we don't have a compiler yet, so I | hand assembled my simulations. I asked "How did you do | thousands of line of code that way?" He said “No, I did 30 | lines of code”. Flabbergasted, I said, "You're predicting the | entire future of this architecture on 30 lines of hand | generated code?" That oral history has a lot of pieces that pointed to major organizational issues (e.g., the two people with VLIW experience at Intel were not involved in the project, not even for initial consultation). One implementation flaw (in my opinion) for Itanium 2 was the use of peak register file ports. With in-order execution and a decent compiler there should be (I suspect/feel) very few cases where ILP is hurt by substantially reducing the register file port count (relying on forwarding, immediates, etc. to reduce demand for register reads). For the FP-side, the architecture already implied two-wide banking for load-pair which were required to be even/odd pairs even with rotation. Even without expensive optimization, register file banking might have reduced port demand for such wide execution without much if any ILP loss. (I admit my feeling about register file ports is just a feeling, but it would have been fairly easy to test whether much existing code suffered lower ILP from having, e.g., only 8 read ports instead of 12.) I suspect an exposed pipeline architecture might also allow a compiler to schedule result forwarding such that a full all-to- all network might be avoided. > It might be possible to do that effectively in a single-core, > single-thread, single-task system that isn't taking many (if any) > interrupts. In a multi-core system, running a complex operating system, > several multi-threaded applications, and taking frequent interrupts and > context switches, it is _not possible_. There is no knowledge of any of > the interrupts, context switches or other applications at compile time, > so the compiler has no idea what is in cache and what isn't. I don't > understand why HP and Intel didn't realise this. It took me years, but I > am no CPU designer. For simple interrupts, the 16 "banked" GPRs (similar to ARM's fast interrupt limited register set) might have been enough to avoid having to save the context for most interrupts. I would have guessed that 32 GPRs, to match the static (not rotating/stacked) GPRs would have been better, particularly with the 3D register file mechanism to hide the area cost under the wires of a highly ported register file, which mechanism was used for the multithreaded Itanium. On the other hand, to use so many registers for interrupt handling, it might have been necessary to provide a static-only calling convention. I suspect context switches were expected to be rare. If one is chasing ILP to the maximum extent, Thread-Level Parallelism may be ignored. Even at a low bandwidth 32-bytes per cycle, a context swap would take (I think) less than 150 cycles; with 1 GHz frequency and 1 ms OS time slice this would be 0.015% of a time slice used by context switch overhead. If the extra state allowed the program to run even a tiny bit faster, that overhead would not be significant. System calls that cannot be run entirely in the banked registers might be more frequent than time slice thread switches, and blocking system calls would result in more thread switches. Yet it is not obvious to me that the context switch overhead was necessarily a major roadblock to system performance. There are other reasons (besides code density) to keep the most active set of data small, e.g., storage area and access power. > Speculative execution addresses that problem quite effectively. We don't > have a better way, almost thirty years after Itanium design decisions > were taken. They didn't want to do speculative execution, and they close > an instruction format and register set that made adding it later hard. If > it was ever tried, nothing was released that had it AFAIK. > > The other problem was that they had three (or six, or twelve) in-order > pipelines running in parallel. That meant the compilers had to provide > enough ILP to keep those pipelines fed, or they'd just eat cache capacity > and memory bandwidth executing no-ops ... in a very bulky instruction set. > They didn't have a general way to extract enough ILP. Nobody does, even > now. They just assumed that with an army of developers they'd find enough > heuristics to make it work well enough. They didn't. > > There was also an architectural misfeature with floating-point advance > loads that could make them disappear entirely if there was a call > instruction between an advance-load instruction and the corresponding > check-load instruction. Was this really architectural in terms of initial design intent or a "won't fix" bug that became a de facto architectural feature? Based on the special case nature and your calling it a bug, I am guessing the latter (which I would tend to view as worse). By the way, the Mill has, in my opinion, a better design for hoisted loads. The loads are not speculative (though they can return a not-a-thing result) and the state is saved on function calls. The variable latency loads do require a second load commit operation, but a "fixed" latency load could be, e.g., two cycles after a function call return (which is a highly variable actual latency). I think a better design is possible when targeting out-of-order execution. A hoisted load can be automatically reissued so the hardware does not have to track all of the "active" loads. If I recall correctly, Itanium required holding the destination register unused for the duration of the load operation (so very long hoisting of many loads would be expensive). Itanium also did not distinguish between thread-local load speculation (which could ignore cache snooping traffic) and speculation across threads. (If Itanium had been designed for TLP, it might have included transactional memory.) > That cost me a couple of weeks working out and > reporting the bug, which was unfixable. The only work-around was to > re-issue all outstanding all floating-point advance-load instruction > after each call returned. The effective code density went down further, > and there were lots of extra read instructions issued. > >> I guess it is more of an open question of what would have happened, >> say, if Intel had gone for an ISA design more like ARM64 or RISC-V >> or something. > > ARM64 seems to me to be the product of a lot more experience with > speculatively-executing processors than was available in 1998. ARM64 is a little conservative/traditional (e.g., no variable- length encoding), but it was also a product of experience and some familiarity with compilers and hardware design. Since it is intended for in-order cores as well, it is not explicitly designed for speculative execution or even superscalar execution. > RISC-V has > not demonstrated really high performance yet, and it's been around long > enough that I'm starting to doubt it ever will. I do not think there is anything technically preventing RISC-V from having a high performance implementation; it is in some ways substantially more sane than x86. However, high performance processor design is expensive. Look at how slow ARM is in gaining server market share even for cloud computing dominated by open source software. If it was not for Apple, one might well doubt that a fast ARM implementation was possible. I get the impression that ARM, the company, emphasizes design flexibility over design efficiency. I doubt a pipeline can be optimized to support, e.g., 32 KiB and 64 KiB L1 caches. I do not know how much efficiency AMD sacrifices with its shrunk low-frequency cores; perhaps the tools are good enough that almost all of the optimization opportunities are automated. I *guess* it is more the case that the savings from reduced frequency targets are so large that even a 10% loss of efficiency would not be problematic.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-28 19:19 +0000 |
| Message-ID | <1769627946-5857@newsgrouper.org> |
| In reply to | #114781 |
Paul Clayton <paaronclayton@gmail.com> posted:
> On 11/13/25 5:13 PM, MitchAlsup wrote:
> >
> > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> [snip]
> >> What I wanted to write was "And assembly language is
> >> architecture-specific".
> >
> > I have worked on a single machine with several different ASM "compilers".
> > Believe me, one asm can be different than another asm.
> >
> > But it is absolutely true that asm is architecture specific.
>
> Is that really *absolutely* true? Architecture usually includes binary
> encoding (and memory order model and perhaps other non-assembly details).
If/when you use an instruction in a more modern implementation,
that you HAVE made this program incompatible with prior implementations.
> I do not know if being able to have an interrupt in the middle of an
> assembly instruction is a violation of the assembly contract. (In
> theory, a few special cases might be handled such that the assembly
> instruction that breaks into more than one machine instruction is
> handled similarly to breaking instructions into µops.) There might not
> be any practical case where all the sub-instructions of an assembly
> instruction are also assembly instructions (especially not if
> retaining instruction size compatibility, which would be difficult
> with such assembly instruction fission anyway).
The real question is whether you support multiple memory instructions
Since we all seem to be supporting multiple data instructions (Vector
and SIMD).
In My 66000 case, Memory to Memory move is performed using indexing
from starting points {From and To}, Program status cache line maintains
the index when a MM is interrupted, so we can restart in the middle.
{Essentially no different than VAX except its an index instead of a
set of pointers}
> Self-modifying assembly obviously breaks with different encodings (as
> would using instruction encodings as data).
>
> If the assembly instructions were different sizes, control flow
> instructions could be broken if addresses or explicit displacements
> were used rather than abstract labels (which might not be allowed or
> merely considered bad practice). Jump tables would also be affected
> (such could also be fixed automatically if the jump table location and
> format is known).
In My 66000, jump tables are PIC.
> Obviously, one could also do the equivalent of complete binary
> recopmilation, which would usually not be considered the role of an
> assembler.
>
> I _feel_ that if only the opcode encoding is changed (a very tiny
> difference that would only affect using code as data) that one could
> rightly state that the new architecture uses the same assembly. I
> doubt there could be any economic justification for only changing the
> opcode encoding, but theoretically such could have multiple
> architectures with the same assembly.
>
> If one allows changing the placement of constants, register
> specifiers, and opcodes (without changing the machine code size of any
> assembly instruction) to still be the same assembly language (which I
> consider reasonable), the benefit of a new encoding might be
> measurable (albeit tiny and not worthwhile).
>
> If one allows assembly instructions to change in size as well as
> encoding (but retain even interrupt semantics), the assembler could
> still be very simple (which might justify still calling it an assembler).
In My 66000, compiler produces an abstract address. After linking when
the address/offset/displacement is manifest, Linker determines the size
of the instruction.
> If the assembly language includes macros (single assembly instruction
> that is assembled into multiple machine instructions), interrupt
> granularity should not be considered part of compatibility, in my
> opinion. Yes, behavior would change because some uninterruptable
> assembly instructions would become interruptable, but the mapping was
> already not simple.
I do not think anyone would think that converting macros into multiple
instructions in any way prevents interrupts from happening anywhere.
> If one allows pipeline reorganization in the assembler (as I think was
> considered a possibility for handling explicit pipelines that
> changed), then size changes would be allowed in which case substantial
> encoding changes should be allowed.
S/substantial/moderate/
> I do not think assembly language considered the possible effects of
> memory order model. (Have all x86 implementations been compatible? I
> think the specification changed, but I do not know if compatibility
> was broken.)
Agree with previous responder: programmer programs to memory model
not ASM.
> Upward compatibility is also a factor. Since one could say that adding
> assembly instructions to an assembly language does not change the
> language (like adding machine instructions does not change the
> architecture in terms of name (upwardly compatible family?)), one
> could argue that increasing the number of registers could maintain the
> same "assembly language' as well as increasing the size of registers.
But the use of said addition, prevent this program from running on
previous implementations.
> In addition to the definition for "assembly language" one also needs
> to define "architecture". In a very strict sense, x86-64 is not a
> single architecture — every different set of machine instructions
> would constitute a different architecture. Intel has sold incompatible
> architectures within the same design by fusing off functionality and
> has even had different application cores in the same chip have
> different instruction support (though that seems to have bit Intel).
The ISA is less than 1/3rd of an architecture:: you have
a) Memory management
b) exception management
c) interrupt management
d) system check management
e) PCIe Root Complex management
f) peripheral management
g) power management
h) frequency management
i) virtualization
j) Boot considerations
...
>
> AMD and Intel also differ slightly in architecture for one or two
> application-level instructions (as well as virtualization
> differences), but are considered the same architecture.
Requiring different builds for any sense of compatible performance.
> Architecture seems to be used in the fuzzy sense rather than the
> strict sense of 100% timing-independent compatibility,
You are only considering 1/3rd of what architecture IS.
> so it seems
> reasonable to have a fuzzier sense of assembly language to include at
> least encoding changes. It seems reasonable to me for "assembly
> language" to mean the preferred language for simple mapping to machine
> instructions (which can include idioms — different spellings of the
> same machine instruction — and macros).
The modern sense of ASM is that it is an ASCII version of binary.
The old sense where ASM was a language that could do anything and
everything (via Macros) has slipped into the past.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-01-29 07:13 +0000 |
| Message-ID | <10lf1ad$13kcf$1@dont-email.me> |
| In reply to | #114787 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > In My 66000, compiler produces an abstract address. After linking when > the address/offset/displacement is manifest, Linker determines the size > of the instruction. Maybe eventually. Right now, the assembler adjust sizes when it has the information (including the size of jump tables, for example). Unresolved symbols are left in a size according to the memory model specified to the assembler. A linker *can* do linker relaxation, the RISC-V toolchain does so. However, they have opened a huge can of worms with this, for several reasons, for example changing debug tables in the linker and bugs for corner cases where special alignment was needed, which is not uncommon on embedded systems (I believe). Perhaps the RISC-V binutils team are simply incompetent, but I think it is far more likely that linker relaxation is simply a very difficult task to get right, and the problem lies mainly with the specification, not with those tasked with implementing it. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-01-29 12:30 -0500 |
| Message-ID | <jwvcy2s5o2x.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #114791 |
Thomas Koenig [2026-01-29 07:13:17] wrote: > Perhaps the RISC-V binutils team are simply incompetent, but > I think it is far more likely that linker relaxation is simply > a very difficult task to get right, and the problem lies mainly > with the specification, not with those tasked with implementing it. My gut feeling is that adjusting instruction sizes after you generated the machine code is just a bad idea. In theory it can be done, but I'd expect there's always a better solution to the problem it's trying to solve (e.g. delay the generation of the machine code, or just use pessimistically-sized instructions). === Stefan
[toc] | [prev] | [next] | [standalone]
Page 24 of 46 — ← Prev page 1 … 22 23 [24] 25 26 … 46 Next page →
Back to top | Article view | comp.arch
csiph-web