Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #110876 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2025-03-01 08:09 +0000 |
| Last post | 2026-10-26 22:13 +0000 |
| Articles | 20 on this page of 321 — 35 participants |
Back to article view | Back to comp.arch
Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-01 08:09 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-01 11:58 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-01 18:03 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-01 20:01 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-02 09:34 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Robert Swindells <rjs@fdy2.co.uk> - 2025-03-02 15:42 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-02 18:30 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Robert Swindells <rjs@fdy2.co.uk> - 2025-03-05 15:01 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-06 00:24 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-06 01:01 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lynn Wheeler <lynn@garlic.com> - 2025-03-02 09:03 -1000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-02 13:51 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-03 18:05 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-03 19:24 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2025-03-03 20:04 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-03 22:41 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-05 18:08 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-05 19:04 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-06 06:53 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-07 14:26 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-08 10:52 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-08 13:03 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-08 19:42 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-09 10:13 -0400
Re: Why VAX Was the Ultimate CISC and Not RISC Torbjorn Lindgren <tl@none.invalid> - 2025-03-09 01:27 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-09 01:46 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-09 07:02 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-09 10:15 -0400
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-03 20:12 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-04 10:09 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-02 21:26 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-02 21:57 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-02 23:43 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-03 02:08 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-02 16:35 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-01 17:59 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-01 17:42 -0800
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-01 20:46 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-01 22:25 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-02 02:40 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-02 13:19 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-02 21:48 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-03 17:57 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-03 23:27 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-02 22:00 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2025-03-03 14:56 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lynn Wheeler <lynn@garlic.com> - 2025-03-01 18:29 -1000
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-02 20:02 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-02 21:50 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-02 22:40 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-03 02:58 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-03 03:36 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-03 07:39 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2025-03-03 14:45 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-03 17:32 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-03 23:26 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-03 07:24 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-03 08:06 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-03 16:41 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC MarkC <usenet@em-ess-see-twenty-seven.me.uk> - 2025-03-03 12:43 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-03 16:44 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-03 17:53 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-03 23:23 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-04 03:04 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-04 10:04 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-04 23:27 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-05 07:36 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-06 02:30 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lynn Wheeler <lynn@garlic.com> - 2025-03-06 16:11 -1000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-08 07:27 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC antispam@fricas.org (Waldek Hebisch) - 2025-03-07 02:27 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-07 04:09 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-07 05:08 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-07 17:34 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Robert Finch <robfi680@gmail.com> - 2025-03-07 13:27 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-07 20:07 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-07 15:00 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-07 22:51 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Robert Finch <robfi680@gmail.com> - 2025-03-07 18:40 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-07 20:49 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-08 03:28 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-09 02:55 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-10 17:40 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-10 23:17 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-10 19:30 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-11 00:53 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Robert Finch <robfi680@gmail.com> - 2025-03-10 22:49 -0400
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-11 01:14 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-11 18:00 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2025-03-11 21:29 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-11 22:41 +0100
Re: Why VAX Was the Ultimate CISC and Not RISC David Schultz <david.schultz@earthlink.net> - 2025-03-11 16:57 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-11 22:40 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-12 08:57 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-12 21:35 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-11 17:44 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-11 11:15 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-11 18:56 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-11 13:46 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-11 22:43 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-11 18:52 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-12 00:34 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-11 18:48 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC moi <findlaybill@blueyonder.co.uk> - 2025-03-11 19:07 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-11 13:39 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-11 22:44 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-11 18:58 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-12 00:37 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-11 19:28 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-12 00:51 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-12 01:24 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2025-03-12 14:14 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-12 17:08 +0100
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-12 00:36 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-12 09:07 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-12 23:55 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC moi <findlaybill@blueyonder.co.uk> - 2025-03-12 00:27 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-12 00:37 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC moi <findlaybill@blueyonder.co.uk> - 2025-03-12 00:43 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2025-03-11 21:26 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-12 00:26 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-12 00:38 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-12 04:02 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-12 09:14 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-11 22:42 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-12 00:42 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-12 08:02 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-12 23:58 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-13 12:08 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2025-03-11 21:18 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-10 23:49 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-11 17:57 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-11 16:20 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-12 00:33 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-12 01:09 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-07 20:48 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2025-03-07 22:25 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-07 22:45 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2025-03-08 14:36 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-08 17:57 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-07 17:19 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC Robert Finch <robfi680@gmail.com> - 2025-03-07 13:03 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-07 16:57 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-08 01:02 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-08 02:08 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-07 17:35 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-07 18:52 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-08 01:00 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-08 00:57 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-07 14:59 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-07 20:25 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC antispam@fricas.org (Waldek Hebisch) - 2025-03-11 22:15 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-11 22:48 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-12 00:46 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-12 08:42 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2025-03-12 11:48 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-12 11:28 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2025-03-12 14:09 +0200
rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-12 16:46 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-12 17:44 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-13 00:03 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 00:49 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-13 02:34 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-13 01:48 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove Robert Finch <robfi680@gmail.com> - 2025-03-13 05:10 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 16:15 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-13 16:29 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 16:19 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 16:10 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 09:40 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-13 16:23 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 16:24 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 12:43 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:35 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 15:53 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 20:59 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 17:44 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:24 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove jgd@cix.co.uk (John Dallman) - 2025-03-16 14:27 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-13 22:55 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:42 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 17:48 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:25 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 00:19 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 14:35 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 21:08 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 01:30 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 22:20 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-14 00:16 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:27 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-14 12:10 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-14 11:15 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 00:18 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-14 12:06 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-14 12:25 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 14:38 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-14 12:52 +0100
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-14 14:00 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-14 13:18 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-14 16:20 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 14:46 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Michael S <already5chosen@yahoo.com> - 2025-03-14 16:51 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 15:39 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 17:38 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 14:44 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-14 16:37 -0400
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 22:23 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..) Michael S <already5chosen@yahoo.com> - 2025-03-13 23:06 +0200
Re: rep movsb vs. simpler instructions for memcpy/memmove mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 22:07 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-14 12:43 +0000
Re: rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..) George Neuner <gneuner2@comcast.net> - 2025-03-16 01:22 -0400
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-13 00:03 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-13 00:01 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2025-03-07 13:57 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-07 15:23 +0100
Re: Why VAX Was the Ultimate CISC and Not RISC Robert Swindells <rjs@fdy2.co.uk> - 2025-03-03 22:15 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-04 08:39 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-01 16:29 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-02 01:02 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-02 02:56 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-02 11:46 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-02 14:39 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-03-02 13:16 -0800
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-02 22:00 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-02 22:27 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC "Brian G. Lucas" <bagel99@gmail.com> - 2025-03-03 11:04 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-04 02:09 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC "Brian G. Lucas" <bagel99@gmail.com> - 2025-03-04 11:46 -0500
Re: PC/IX, not, Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-04 21:00 +0000
Re: PC/IX, not, Why VAX Was the Ultimate CISC and Not RISC "Brian G. Lucas" <bagel99@gmail.com> - 2025-03-04 17:51 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC jgd@cix.co.uk (John Dallman) - 2025-03-04 16:53 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-04 23:29 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC jgd@cix.co.uk (John Dallman) - 2025-03-05 09:16 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC George Neuner <gneuner2@comcast.net> - 2025-03-07 06:03 -0500
Re: PC/IX, Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2025-03-08 01:13 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-03 16:34 +0100
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-03 17:21 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-03 18:51 +0100
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2025-03-03 19:53 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC George Neuner <gneuner2@comcast.net> - 2025-03-04 16:32 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2025-03-05 01:28 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-05 00:05 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2025-03-05 15:07 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-03 23:32 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-02 21:56 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-02 00:16 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-02 12:10 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-05 15:28 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2025-03-05 21:15 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-01 14:40 -0500
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-01 22:30 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-01 23:19 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-01 17:45 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC BGB <cr88192@gmail.com> - 2025-03-01 17:45 -0600
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2025-03-02 16:33 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-03-02 12:03 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-02 21:35 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC mitchalsup@aol.com (MitchAlsup1) - 2025-03-02 21:50 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Theo <theom+news@chiark.greenend.org.uk> - 2025-03-05 11:58 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-06 00:28 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC quadibloc@invalid.com (John Savard) - 2026-10-24 00:05 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-24 19:28 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2026-10-24 20:42 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-26 18:33 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2026-10-26 19:56 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2026-10-27 06:31 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 16:58 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2026-10-27 20:43 +0000
Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-29 16:11 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-29 17:54 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-29 18:09 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-29 20:31 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-30 07:06 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-30 18:34 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-31 08:13 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-31 18:22 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-31 19:15 +0000
Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-31 20:44 +0000
Re: Register windows Paul Clayton <paaronclayton@gmail.com> - 2026-11-04 22:45 -0500
Re: Register windows antispam@fricas.org (Waldek Hebisch) - 2026-11-07 16:21 +0000
Re: Register windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-07 18:01 +0000
Re: Register windows antispam@fricas.org (Waldek Hebisch) - 2026-11-08 04:37 +0000
Re: Register windows Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-08 04:49 +0000
Re: Register windows antispam@fricas.org (Waldek Hebisch) - 2026-11-08 14:19 +0000
call and return speed (was: Register windows) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-08 06:33 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC quadibloc@invalid.com (John Savard) - 2026-10-30 00:10 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-30 00:33 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-24 22:20 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-24 23:33 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-25 12:56 -0400
Re: Why VAX Was the Ultimate CISC and Not RISC John Levine <johnl@taugh.com> - 2026-10-25 18:42 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Thomas Koenig <tkoenig@netcologne.de> - 2026-10-25 20:03 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-25 23:36 -0400
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-26 18:46 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:29 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-26 18:19 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 16:41 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-27 18:16 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 21:01 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2026-10-27 21:14 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-26 18:06 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC scott@slp53.sl.home (Scott Lurndal) - 2026-10-26 18:53 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:30 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:32 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-26 22:16 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC John Ames <commodorejohn@gmail.com> - 2026-10-27 10:04 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC Peter Flass <Peter@Iron-Spring.com> - 2026-10-27 12:44 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC John Ames <commodorejohn@gmail.com> - 2026-10-27 13:03 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC Roman Belenov <no@spam.please> - 2026-10-27 20:22 +0300
Re: Why VAX Was the Ultimate CISC and Not RISC cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-27 18:05 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2026-10-27 20:15 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-27 18:50 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2026-10-27 21:16 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC Peter Flass <Peter@Iron-Spring.com> - 2026-10-27 12:46 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC Michael S <already5chosen@yahoo.com> - 2026-10-27 22:00 +0200
Re: Why VAX Was the Ultimate CISC and Not RISC Dave Yeo <dave.r.yeo@gmail.com> - 2026-10-27 11:14 -0700
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-27 22:19 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC jgd@cix.co.uk (John Dallman) - 2026-10-27 08:18 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-27 22:32 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC jgd@cix.co.uk (John Dallman) - 2026-10-28 08:08 +0000
Re: Why VAX Was the Ultimate CISC and Not RISC Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-26 22:13 +0000
Page 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
| From | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-10-24 00:05 +0000 |
| Message-ID | <6adbf597.9767671@news.eternal-september.org> |
| In reply to | #110876 |
On Sat, 1 Mar 2025 08:09:35 -0000 (UTC), Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >The VAX project started roughly around the time the first RISC >concepts were being researched. Could the VAX have been designed as a >RISC architecture to begin with? Because not doing so meant that, just >over a decade later, RISC architectures took over the “real computer” >market and wiped the floor with DEC’s flagship architecture, >performance-wise. > >The answer was no, the VAX could not have been done as a RISC >architecture. RISC wasn’t actually price-performance competitive until >the latter 1980s: Shall we then conclude that DEC did everything right, because later on after the VAX, DEC came up with the Alpha, which was RISC, and which was the highest-performing chip of its day? Well, not everything. The Alpha was so expensive as to be a dismal failure in the market. However, it was either good enough, or well-documented enough, for some Chinese efforts at home-grown computer design to have copied it. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-24 19:28 +0000 |
| Message-ID | <1792870082-5857@newsgrouper.org> |
| In reply to | #118803 |
quadibloc@invalid.com (John Savard) posted: > /ERROR "unexpected byte sequence starting at index 348: '\xE2'" while decoding/: > > On Sat, 1 Mar 2025 08:09:35 -0000 (UTC), Lawrence D'Oliveiro > <ldo@nz.invalid> wrote: > > >The VAX project started roughly around the time the first RISC > >concepts were being researched. I remember walking by a CS conference room 1973-ish and listening to a bunch of people (including Bill Wolfe and Aho) at Carnegie Mellon. The discussion was about a follow on to the PDP-11 architectures and what additional address modes should go in or not. So, my memory is that VAX was being fleshed out at least 7 years before RISC got started. > Could the VAX have been designed as a > >RISC architecture to begin with? Not with the players involved. Now, if Thronton or Seymore was at CMU then maybe. > Because not doing so meant that, just > >over a decade later, RISC architectures took over the âreal computerâ > >market and wiped the floor with DECâs flagship architecture, > >performance-wise. > > > >The answer was no, the VAX could not have been done as a RISC > >architecture. RISC wasnât actually price-performance competitive until > >the latter 1980s: Once compilers made significant growth in optimization, and sufficient silicon area became available. > Shall we then conclude that DEC did everything right, because later on > after the VAX, DEC came up with the Alpha, which was RISC, and which > was the highest-performing chip of its day? The commercial success of VAX delayed Alpha--no doubt about that. So, I contend, DEC misplayed that card. > Well, not everything. The Alpha was so expensive as to be a dismal > failure in the market. However, it was either good enough, or > well-documented enough, for some Chinese efforts at home-grown > computer design to have copied it. > > John Savard
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-24 20:42 +0000 |
| Message-ID | <11bj58a$327li$1@dont-email.me> |
| In reply to | #118811 |
On 2026-10-24, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > quadibloc@invalid.com (John Savard) posted: > >> /ERROR "unexpected byte sequence starting at index 348: '\xE2'" while decoding/: >> >> On Sat, 1 Mar 2025 08:09:35 -0000 (UTC), Lawrence D'Oliveiro >> <ldo@nz.invalid> wrote: >> >> >The VAX project started roughly around the time the first RISC >> >concepts were being researched. > > I remember walking by a CS conference room 1973-ish and listening to > a bunch of people (including Bill Wolfe and Aho) at Carnegie Mellon. > The discussion was about a follow on to the PDP-11 architectures > and what additional address modes should go in or not. > > So, my memory is that VAX was being fleshed out at least 7 years > before RISC got started. The 801 certainly counts, but it was certainly not mainstream at the time. > >> Could the VAX have been designed as a >> >RISC architecture to begin with? > > Not with the players involved. Now, if Thronton or Seymore was at CMU > then maybe. > >> Because not doing so meant that, just >> >over a decade later, RISC architectures took over the ??????real computer?????? >> >market and wiped the floor with DEC??????s flagship architecture, >> >performance-wise. >> > >> >The answer was no, the VAX could not have been done as a RISC >> >architecture. RISC wasn??????t actually price-performance competitive until >> >the latter 1980s: > > Once compilers made significant growth in optimization, and sufficient > silicon area became available. Again, the 801 proved that it could be done. I think they also invented graph coloring for register allocation, or if they did not invent it, they certainly used 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-26 18:33 +0000 |
| Message-ID | <2026Oct26.193309@mips.complang.tuwien.ac.at> |
| In reply to | #118814 |
Thomas Koenig <tkoenig@netcologne.de> writes:
>Again, the 801 proved that it could be done. I think they also
>invented graph coloring for register allocation, or if they did
>not invent it, they certainly used it.
Graph coloring register allocation was indeed developed in connection
with the 801 project (note that John Cocke coauthored the paper
[chaitin+81]).
However, graph coloring register allocation is not necessary for a
RISC to outperform the VAX 11/780, pipelining is enough. The Berkeley
RISC people were a hardware group and did not do optimizing compilers.
HPPA originally used some PCC variant (no graph coloring register
allocation or any other sophisticated optimization) as C compiler, and
gcc outperformed HP's compiler by a wide margin when it appeared. Yet
HPPA outperformed HP's CISC offerings by a wide margin, too.
The only groups that did much with compilers in early RISC history are
the IBM 801 group and the Stanford MIPS group.
@Article{chaitin+81,
author = "Gregory J. Chaitin and Marc A. Auslander and Ashok K.
Chandra and John Cocke and Martin E. Hopkins and
Peter W. Markstein",
title = "Register Allocation via Coloring",
journal = complang,
year = "1981",
volume = "6",
number = "1",
pages = "45--57",
note = "Reprinted in \cite{stallings90}",
annote = "The seminal paper on coloring register allocation.
The spill code generation differs much from Chaitins
later paper and reminds me of hierarchical graph
coloring."
}
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-10-26 19:56 +0000 |
| Message-ID | <11bob96$3af$2@gal.iecc.com> |
| In reply to | #118845 |
It appears that Anton Ertl <anton@mips.complang.tuwien.ac.at> said: >However, graph coloring register allocation is not necessary for a >RISC to outperform the VAX 11/780, pipelining is enough. The Berkeley >RISC people were a hardware group and did not do optimizing compilers. They sure didn't. They invented register windows because PCC's register allocator saved and restored lots of registers around every call, and the windows made that faster. On the 801, they just saved what they needed to so they didn't even have load or store multiple. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-27 06:31 +0000 |
| Message-ID | <11bpggu$1961c$1@dont-email.me> |
| In reply to | #118849 |
John Levine <johnl@taugh.com> schrieb: > It appears that Anton Ertl <anton@mips.complang.tuwien.ac.at> said: >>However, graph coloring register allocation is not necessary for a >>RISC to outperform the VAX 11/780, pipelining is enough. The Berkeley >>RISC people were a hardware group and did not do optimizing compilers. > > They sure didn't. They invented register windows because PCC's > register allocator saved and restored lots of registers around > every call, and the windows made that faster. On the 801, they > just saved what they needed to so they didn't even have load or > store multiple. They had subroutines for register save and restore, which of course helps code density, but is a bit... iffy. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-27 16:58 +0000 |
| Message-ID | <1793120292-5857@newsgrouper.org> |
| In reply to | #118865 |
Thomas Koenig <tkoenig@netcologne.de> posted:
> John Levine <johnl@taugh.com> schrieb:
> > It appears that Anton Ertl <anton@mips.complang.tuwien.ac.at> said:
> >>However, graph coloring register allocation is not necessary for a
> >>RISC to outperform the VAX 11/780, pipelining is enough. The Berkeley
> >>RISC people were a hardware group and did not do optimizing compilers.
> >
> > They sure didn't. They invented register windows because PCC's
> > register allocator saved and restored lots of registers around
> > every call, and the windows made that faster. On the 801, they
> > just saved what they needed to so they didn't even have load or
> > store multiple.
>
> They had subroutines for register save and restore, which of course
> helps code density, but is a bit... iffy.
So iffy that essentially nobody does register windows anymore.
The compiler is at least as good at it as an exception-called
save/restore machine. {Both V8 and V9}
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-27 20:43 +0000 |
| Message-ID | <11br2e3$1sc25$1@dont-email.me> |
| In reply to | #118873 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> posted:
>
>> John Levine <johnl@taugh.com> schrieb:
>> > It appears that Anton Ertl <anton@mips.complang.tuwien.ac.at> said:
>> >>However, graph coloring register allocation is not necessary for a
>> >>RISC to outperform the VAX 11/780, pipelining is enough. The Berkeley
>> >>RISC people were a hardware group and did not do optimizing compilers.
>> >
>> > They sure didn't. They invented register windows because PCC's
>> > register allocator saved and restored lots of registers around
>> > every call, and the windows made that faster. On the 801, they
>> > just saved what they needed to so they didn't even have load or
>> > store multiple.
>>
>> They had subroutines for register save and restore, which of course
>> helps code density, but is a bit... iffy.
>
> So iffy that essentially nobody does register windows anymore.
> The compiler is at least as good at it as an exception-called
> save/restore machine. {Both V8 and V9}
The 801 didn't do register windows.
They called a routine to save x registers (in their calling
convention) and to restore them on return. Like enter/exit,
but with a subroutine call.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-29 16:11 +0000 |
| Subject | Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <2026Oct29.171118@mips.complang.tuwien.ac.at> |
| In reply to | #118873 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>Thomas Koenig <tkoenig@netcologne.de> posted:
>
>> John Levine <johnl@taugh.com> schrieb:
[IBM 801]
>> They had subroutines for register save and restore, which of course
>> helps code density, but is a bit... iffy.
>
>So iffy that essentially nobody does register windows anymore.
The IBM 801 did not do register windows, either.
>The compiler is at least as good at it as an exception-called
>save/restore machine. {Both V8 and V9}
If we stay with in-order machines, the SPARC register windows have two
disadvantages that are not necessary:
1) Every window has a fixed 16 registers, resulting in less utilization
of a given number of registers (and more need for saving/restoring
to memory) and possibly extra spilling needed for functions with
particularly high register pressure, compared to a more flexible
scheme.
2) Using exceptions for the saving and restoring gives away some of
the potential speed advantage of register windows. That does not
affect user space, so getting rid of that should have been not that
hard, but AFAIK it did not happen for SPARC, so maybe it was hard
(cf. the IA-64 problems).
The AMD 29K and IA-64 deal with 1) by being more flexible. IA-64 was
intended to deal with 2) with its hardware stack engine, but according
to John Dallman they botched it, and fell back to exceptions as a
recourse. Apparently it is not an easy feature to implement, which is
somewhat surprising given that OoO seems conceptually more complex,
and the microarchitects have managed to get it right pretty much every
time.
There is a third issue: Do you pass arguments in the register windows,
or in what SPARC calls global registers? AFAIK SPARC chose to pass
them in windows, but that means that a call sequence like
int foo(a,b)
{
...
bar(a,b);
...
}
has to copy a and b between in and out, while using globals for
arguments would avoid that (but would require saving the arguments in
some way if they are used after the call, the same as without register
windows).
Once we consider OoO, the potential advantages of register windows
become even smaller:
1) OoO can make the stores and loads around calls and returns cheaper:
If the front end runs far ahead of the execution engine (the usual
case), the stores can start as soon as the values are ready (and if
they are ready late, the store waits without delaying anything
else), and independent loads can start early. So ideally they
don't get into the way of the useful instructions.
2) On recent designs, zero-cycle store-to-load forwarding means that
even storing and loading around short function calls may have little
or no latency penalty.
And register windows tend to cost more in OoO implementations: the
register address table (for implementations with a separate renamer)
becomes larger.
My memory says that the OoO implementations of HAL/Fujitsu used the
minimum number of register windows allowed, probably due to a
combination of the cost and the smaller benefits. However, the number
of exceptions would increase.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-29 17:54 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <1793296454-5857@newsgrouper.org> |
| In reply to | #118942 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >Thomas Koenig <tkoenig@netcologne.de> posted:
> >
> >> John Levine <johnl@taugh.com> schrieb:
> [IBM 801]
> >> They had subroutines for register save and restore, which of course
> >> helps code density, but is a bit... iffy.
> >
> >So iffy that essentially nobody does register windows anymore.
-----------snip----------
> There is a third issue: Do you pass arguments in the register windows,
> or in what SPARC calls global registers? AFAIK SPARC chose to pass
> them in windows, but that means that a call sequence like
>
> int foo(a,b)
> {
> ...
> bar(a,b);
> ...
> }
It gets worse when::
type foo( a, b ){
...
return bar( a, b );
...
}
Now you have to copy forward foo->bar and copy bar's return back
as foo's return. Whereas a flat register file has neither MOV.
> has to copy a and b between in and out, while using globals for
> arguments would avoid that (but would require saving the arguments in
> some way if they are used after the call, the same as without register
> windows).
>
> Once we consider OoO, the potential advantages of register windows
> become even smaller:
>
> 1) OoO can make the stores and loads around calls and returns cheaper:
> If the front end runs far ahead of the execution engine (the usual
> case), the stores can start as soon as the values are ready (and if
> they are ready late, the store waits without delaying anything
> else), and independent loads can start early. So ideally they
> don't get into the way of the useful instructions.
My 66000 takes advantage of this by LDing the Ret Addr first, and then
reLDing the rest of the file, so by the time that is done, FETCH already
has instructions for DECODE>
> 2) On recent designs, zero-cycle store-to-load forwarding means that
> even storing and loading around short function calls may have little
> or no latency penalty.
When prologue and epilogue are 'structured' there are times when one
can elide the stores entirely as the memory location already has the
bit pattern the <yet to be performed> ST will write. These happen
when an EXIT runs into a CALL->ENTER while EXIT is still moving data.
> And register windows tend to cost more in OoO implementations: the
> register address table (for implementations with a separate renamer)
> becomes larger.
Slower RF, makes the pipeline at least 1/2 cycle longer.
> My memory says that the OoO implementations of HAL/Fujitsu used the
> minimum number of register windows allowed, probably due to a
> combination of the cost and the smaller benefits. However, the number
> of exceptions would increase.
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-29 18:09 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <2026Oct29.190945@mips.complang.tuwien.ac.at> |
| In reply to | #118946 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>> There is a third issue: Do you pass arguments in the register windows,
>> or in what SPARC calls global registers? AFAIK SPARC chose to pass
>> them in windows, but that means that a call sequence like
>>
>> int foo(a,b)
>> {
>> ...
>> bar(a,b);
>> ...
>> }
>
>It gets worse when::
>
> type foo( a, b ){
> ...
> return bar( a, b );
> ...
> }
>
>Now you have to copy forward foo->bar and copy bar's return back
>as foo's return.
No, it's a tail-call. You just jump to bar without saving or
restoring a register window.
>My 66000 takes advantage of this by LDing the Ret Addr first, and then
>reLDing the rest of the file, so by the time that is done, FETCH already
>has instructions for DECODE>
I get the impression that My 66000 lives in 1994. In a modern
(post-1995, with a few exceptions, most of which have died out in the
meantime) processor the front end predicts the return from the
processor-internal return stack and often starts fetching from there
before the load-store unit sees the load of the return address. The
return address is then used to validate the branch prediction and
retire the return instruction.
>> And register windows tend to cost more in OoO implementations: the
>> register address table (for implementations with a separate renamer)
>> becomes larger.
>
>Slower RF, makes the pipeline at least 1/2 cycle longer.
Given register file sizes like 416 physical GPRs on the Qualcomm
Oryon, making the pipeline longer seems to be something CPU designers
can handle these days; with 416 physical GPRs, taking 72 (or however
many architectural registers Fujitsu used) rather than 32 for
architected registers is probably not a big thing, but sure, now there
are 40 fewer registers that can be used for renaming. Still the
growth of the RAT is probably a bigger issue.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-29 20:31 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <1793305885-5857@newsgrouper.org> |
| In reply to | #118947 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
--------------------
> >My 66000 takes advantage of this by LDing the Ret Addr first, and then
> >reLDing the rest of the file, so by the time that is done, FETCH already
> >has instructions for DECODE>
>
> I get the impression that My 66000 lives in 1994. In a modern
> (post-1995, with a few exceptions, most of which have died out in the
> meantime) processor the front end predicts the return from the
> processor-internal return stack and often starts fetching from there
> before the load-store unit sees the load of the return address. The
> return address is then used to validate the branch prediction and
> retire the return instruction.
You can't predict until you are within <about> 2-fetch cycles of the
instruction you are going to make a prediction about {RET here}.
When RET is 16-odd instructions (all LDDs) from the current INSERT
point, you aren't at the point you can make a prediction (by couple
of cycles).
The thing is that there may be 16 register loads between the point where
the compiler knows a return is going to happen and the RET instruction
itself (in whatever guise). Given that each takes an instruction, then
we get to the point where moving those 16 register loads through DECODE
prevents FETCH/PREDICT from seeing the RET for several cycles. But the
EXIT instruction itself makes DECODE know that a bunch of register LDs
will happen and a RET will also happen, so it arranged that RA is fetched
first and then used to fetch instructions at RA and feed DECODE while all
the LDs are transpiring.
Yes, it is easy to predict RET and to fetch instructions there. So, let's
say we predict the RET and we also "predict" <in some manner> the sub-
sequent call. So, while we are still LDing registers, we now need to ST
a bunch of registers {new epilogue} onto the same memory currently being
LDed.
The predictive mechanics to determine that the new epilogue is storing
bit patterns that are already in those memory locations is "non trivial"
for RISC-V but trivial for EXIT-CALL-ENTER. {For most leaf functions;
there is only RET with no preserved register restoration and no EXIT}.
There are cases where one has an EXIT-CALL-ENTER where both {EXIT LDDs
and ENTER STs} are elided, since the return from this CALL will perform
those restores--but only to the overlapping set of registers.
In no way am I preventing predictors from predicting {although I am
reducing the number of <hard> cases they have to sift through.} I am
realistic about when a prediction may transpire. Generally current IP
and some HASHing bits are used to access predictor(s) in cycle k,
and are available in cycle k=1 to make a FETCH prediction for cycle
k+2.
So, the question, here, boils down to: "How many cycles does it take
DECODE to 'process' 16-LDDs in a row". Even a 10-wide machine may only
have 4 LD/MEM FUs, so it would take 4-odd cycles to push LDDs through
DECODE, and at cycle 2 one could be able to predict RET--whereas My
66000 can predict {with 100% confidence} 2-cycles earlier.
It is this "push through DECODE" notion I have been struggling with
for a "while". Once I saw 42-instructions in a row out of the compiler
all targeting the FMAC FU--I knew I needed a way to move instructions
through DECODE faster than the targeted FU can process them. Prologues
and epilogues are just more of this same problem.
I suspect others have found similar "push through DECODE" issues, too.
> >> And register windows tend to cost more in OoO implementations: the
> >> register address table (for implementations with a separate renamer)
> >> becomes larger.
> >
> >Slower RF, makes the pipeline at least 1/2 cycle longer.
>
> Given register file sizes like 416 physical GPRs on the Qualcomm
> Oryon, making the pipeline longer seems to be something CPU designers
> can handle these days; with 416 physical GPRs, taking 72 (or however
> many architectural registers Fujitsu used) rather than 32 for
> architected registers is probably not a big thing, but sure, now there
> are 40 fewer registers that can be used for renaming. Still the
> growth of the RAT is probably a bigger issue.
The RAT _was_ a big problem for K9 {with 22 ports per cycle}, its only
saving grace was that it was only 8-bits wide {instead of 64+}.
> - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-30 07:06 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <2026Oct30.080654@mips.complang.tuwien.ac.at> |
| In reply to | #118949 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>> In a modern
>> (post-1995, with a few exceptions, most of which have died out in the
>> meantime) processor the front end predicts the return from the
>> processor-internal return stack and often starts fetching from there
>> before the load-store unit sees the load of the return address. The
>> return address is then used to validate the branch prediction and
>> retire the return instruction.
>
>You can't predict until you are within <about> 2-fetch cycles of the
>instruction you are going to make a prediction about {RET here}.
Predictors can make predictions about anything. But given that it is
only useful to make predictions that are actually used, they will only
predict the next few I-cache lines to be fetched, so yes, predicting a
few fetch lines ahead could be common.
How many? Depends on the latency of the I-cache. Given that it is
typically similar in size to the D-cache, it's latency will also be
similar, i.e., around 4 cycles.
How many cache lines are fetched per cycle? With a 10-wide front end,
you probably do not want to underutilize the rest of the front end if
there is a taken branch or there is a branch to a target less than 10
instructions from the end of the cache line, so better fetch two cache
lines per cycle.
So there might be about 8 cache lines fetched between the prediction
of the line that includes the return instructions and the actual fetch
of the return instruction. The predictor has to predict the target of
the return as the next prediction.
Now if you want to wait for the result of the return-address load, you
have to contend not just with the latency of the I-cache fetch of this
load, but also the decoding, renaming, scheduling, and execution
(D-cache latency) of this load, typically 10-20 cycles total. So you
would have to fetch this load 10-20 cycles (and thus 10-20 cycles
worth of instructions, i.e. 100-200 instructions on a 10-wide machine)
to have its result ready for using it to fetch the cache line after
the return instruction (but of course that does not consider that in
such a predictorless design, the return instruction also takes its
time to decode etc.).
Anyway, thanks to branch prediction and speculative execution, that's
not necessary.
>When RET is 16-odd instructions (all LDDs) from the current INSERT
>point, you aren't at the point you can make a prediction (by couple
>of cycles).
>
>The thing is that there may be 16 register loads between the point where
>the compiler knows a return is going to happen and the RET instruction
>itself (in whatever guise). Given that each takes an instruction, then
>we get to the point where moving those 16 register loads through DECODE
>prevents FETCH/PREDICT from seeing the RET for several cycles.
Concerning the 16 loads, I don't think I have ever seen a compiler
generate that many in front of a return. It would require that the
calling convention has at least 16 callee-saved registers, and that
they are all being used.
But anyway, even assuming there is this bunch of loads, and the
pipeline from the renamer to the scheduler(s) of the load/store units
is narrow and there is no buffering capacity in between, there is no
reason why the predictor would not predict the return. It does not
need to decode the return instruction to predict it, it just needs to
predict that there will be a return, and then use the hardware return
stack to make the prediction.
Of course, with a design that suffers from congestion between the
renamer and the schedulers, the congestion will eventually clog the
front end back to the instruction fetcher, and then even having a
preduction early will not help. If this is a common occurence, the
microarchitecture is obviously badly balanced for the workloads it
uses.
BTW, what is the INSERT point?
>But the
>EXIT instruction itself makes DECODE know that a bunch of register LDs
>will happen and a RET will also happen, so it arranged that RA is fetched
>first and then used to fetch instructions at RA and feed DECODE while all
>the LDs are transpiring.
Ok, so you are assuming that the congestion has not clogged the
decoder. In that case, a design with a predictor will happily fetch
the target of the return and feed it into the decoders.
>Yes, it is easy to predict RET and to fetch instructions there. So, let's
>say we predict the RET and we also "predict" <in some manner> the sub-
>sequent call. So, while we are still LDing registers, we now need to ST
>a bunch of registers {new epilogue} onto the same memory currently being
>LDed.
I assume you mean "{new prologue}".
And you assume that the next call also makes use of many callee-saved
registers.
>The predictive mechanics to determine that the new epilogue is storing
>bit patterns that are already in those memory locations is "non trivial"
>for RISC-V but trivial for EXIT-CALL-ENTER.
Are the same registers saved to the same places? If that is a common
occurence (I don't think so), recognizing and optimizing it in
hardware (probably in the renamer) looks doable.
>{For most leaf functions;
>there is only RET with no preserved register restoration and no EXIT}.
If you need so many registers that you also use callee-saved
registers, the callee also saves them when the callee is a leaf
function. Of course, for values that do not live across a call
(i.e. all values in a leaf function), caller-saved registers are the
first pick.
>So, the question, here, boils down to: "How many cycles does it take
>DECODE to 'process' 16-LDDs in a row". Even a 10-wide machine may only
>have 4 LD/MEM FUs, so it would take 4-odd cycles to push LDDs through
>DECODE
I would not know why a 10-wide decoder would not decode 10 loads per
cycle. Likewise for the renamer. Then the schedulers may be more
limited, but if so, and having loads and stores in large bunches is
common, a competent designer will insert some buffering capacity to
avoid congesting the front end.
>and at cycle 2 one could be able to predict RET--whereas My
>66000 can predict {with 100% confidence} 2-cycles earlier.
You mean, it can resolve the prediction two cycles earlier. Given
that return stack prediction is very accurate, the benefit might be
that one can use a smaller ROB, if the prediction of return was the
only reason for having a large ROB. But I think that other reasons
for having a large ROB (such as conditional branches, or cache misses)
stull persist and are actually more important.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-30 18:34 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <1793385253-5857@newsgrouper.org> |
| In reply to | #118959 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >> In a modern
> >> (post-1995, with a few exceptions, most of which have died out in the
> >> meantime) processor the front end predicts the return from the
> >> processor-internal return stack and often starts fetching from there
> >> before the load-store unit sees the load of the return address. The
> >> return address is then used to validate the branch prediction and
> >> retire the return instruction.
> >
> >You can't predict until you are within <about> 2-fetch cycles of the
> >instruction you are going to make a prediction about {RET here}.
>
> Predictors can make predictions about anything. But given that it is
> only useful to make predictions that are actually used, they will only
> predict the next few I-cache lines to be fetched, so yes, predicting a
> few fetch lines ahead could be common.
>
> How many? Depends on the latency of the I-cache. Given that it is
> typically similar in size to the D-cache, it's latency will also be
> similar, i.e., around 4 cycles.
>
> How many cache lines are fetched per cycle? With a 10-wide front end,
> you probably do not want to underutilize the rest of the front end if
> there is a taken branch or there is a branch to a target less than 10
> instructions from the end of the cache line, so better fetch two cache
> lines per cycle.
A cache line contains 16 instructions, so one would assume a partial
line is held over (to the next decode cycle) and one makes 1 fetch
in the sequential direction and 1 fetch to another predicted address.
2-fetches per cycle giving almost 3 lines of instructions for decode.
> So there might be about 8 cache lines fetched between the prediction
> of the line that includes the return instructions and the actual fetch
> of the return instruction. The predictor has to predict the target of
> the return as the next prediction.
>
> Now if you want to wait for the result of the return-address load, you
> have to contend not just with the latency of the I-cache fetch of this
> load, but also the decoding, renaming, scheduling, and execution
> (D-cache latency) of this load, typically 10-20 cycles total.
That is the latency of verification of the prediction.
> So you
> would have to fetch this load 10-20 cycles (and thus 10-20 cycles
> worth of instructions, i.e. 100-200 instructions on a 10-wide machine)
> to have its result ready for using it to fetch the cache line after
> the return instruction (but of course that does not consider that in
> such a predictorless design, the return instruction also takes its
> time to decode etc.).
>
> Anyway, thanks to branch prediction and speculative execution, that's
> not necessary.
>
> >When RET is 16-odd instructions (all LDDs) from the current INSERT
> >point, you aren't at the point you can make a prediction (by couple
> >of cycles).
> >
> >The thing is that there may be 16 register loads between the point where
> >the compiler knows a return is going to happen and the RET instruction
> >itself (in whatever guise). Given that each takes an instruction, then
> >we get to the point where moving those 16 register loads through DECODE
> >prevents FETCH/PREDICT from seeing the RET for several cycles.
>
> Concerning the 16 loads, I don't think I have ever seen a compiler
> generate that many in front of a return. It would require that the
> calling convention has at least 16 callee-saved registers, and that
> they are all being used.
I have numerous examples of RISC-V (LLVM -O3) having 13 STs in prologue
and 13 LDs in epilogue. The distribution (excepting for leaf functions
(0 saved) and director functions (1 saved) is basically a Bell Curve
from 2->13.)
> But anyway, even assuming there is this bunch of loads, and the
> pipeline from the renamer to the scheduler(s) of the load/store units
> is narrow and there is no buffering capacity in between, there is no
> reason why the predictor would not predict the return. It does not
> need to decode the return instruction to predict it, it just needs to
> predict that there will be a return, and then use the hardware return
> stack to make the prediction.
Maybe predictors have gotten that good. We always verified that there
was a flow-control instruction as a qualification to the predictor.
> Of course, with a design that suffers from congestion between the
> renamer and the schedulers, the congestion will eventually clog the
> front end back to the instruction fetcher, and then even having a
> preduction early will not help. If this is a common occurence, the
> microarchitecture is obviously badly balanced for the workloads it
> uses.
Key point: DECODE needs a mechanism that "smoothly" deals with FU
overcommitment.
> BTW, what is the INSERT point?
It is where the instruction is far enough into the pipe that natural
FU scheduling runs it to completion {This is mostly when the Inst is
written into Reservation Station.}
> >But the
> >EXIT instruction itself makes DECODE know that a bunch of register LDs
> >will happen and a RET will also happen, so it arranged that RA is fetched
> >first and then used to fetch instructions at RA and feed DECODE while all
> >the LDs are transpiring.
>
> Ok, so you are assuming that the congestion has not clogged the
> decoder. In that case, a design with a predictor will happily fetch
> the target of the return and feed it into the decoders.
ENTER and EXIT invent the STs and LDs needed in a way easy for DECODE to
digest. EXIT in particular {with inst<3>==0} will return; and even if
there are a lot of LDs to be performed <via EXIT>, RA can be sent to
FETCH far earlier, ...
> >Yes, it is easy to predict RET and to fetch instructions there. So, let's
> >say we predict the RET and we also "predict" <in some manner> the sub-
> >sequent call. So, while we are still LDing registers, we now need to ST
> >a bunch of registers {new epilogue} onto the same memory currently being
> >LDed.
>
> I assume you mean "{new prologue}". -- YES YES
>
> And you assume that the next call also makes use of many callee-saved
> registers.
Sure, setting up the scenario.
> >The predictive mechanics to determine that the new epilogue is storing
> >bit patterns that are already in those memory locations is "non trivial"
> >for RISC-V but trivial for EXIT-CALL-ENTER.
>
> Are the same registers saved to the same places? If that is a common
> occurence (I don't think so), recognizing and optimizing it in
> hardware (probably in the renamer) looks doable.
My 66000 ABI (and SBI) both operate that way. ENTER saves registers
where higher register numbers are stored at higher memory locations.
> >{For most leaf functions;
> >there is only RET with no preserved register restoration and no EXIT}.
>
> If you need so many registers that you also use callee-saved
> registers, the callee also saves them when the callee is a leaf
> function.
No, of course not. Leaf functions (93%) save no registers at all as they
perform their duties in the freely-available temporary registers R0..15
> Of course, for values that do not live across a call
> (i.e. all values in a leaf function), caller-saved registers are the
> first pick.
>
> >So, the question, here, boils down to: "How many cycles does it take
> >DECODE to 'process' 16-LDDs in a row". Even a 10-wide machine may only
> >have 4 LD/MEM FUs, so it would take 4-odd cycles to push LDDs through
> >DECODE
>
> I would not know why a 10-wide decoder would not decode 10 loads per
> cycle. Likewise for the renamer. Then the schedulers may be more
> limited, but if so, and having loads and stores in large bunches is
> common, a competent designer will insert some buffering capacity to
> avoid congesting the front end.
>
> >and at cycle 2 one could be able to predict RET--whereas My
> >66000 can predict {with 100% confidence} 2-cycles earlier.
>
> You mean, it can resolve the prediction two cycles earlier. Given
> that return stack prediction is very accurate, the benefit might be
> that one can use a smaller ROB, if the prediction of return was the
> only reason for having a large ROB. But I think that other reasons
> for having a large ROB (such as conditional branches, or cache misses)
> stull persist and are actually more important.
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-31 08:13 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <2026Oct31.091342@mips.complang.tuwien.ac.at> |
| In reply to | #118965 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>
>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>> >> In a modern
>> >> (post-1995, with a few exceptions, most of which have died out in the
>> >> meantime) processor the front end predicts the return from the
>> >> processor-internal return stack and often starts fetching from there
>> >> before the load-store unit sees the load of the return address. The
>> >> return address is then used to validate the branch prediction and
>> >> retire the return instruction.
>> >
>> >You can't predict until you are within <about> 2-fetch cycles of the
>> >instruction you are going to make a prediction about {RET here}.
>>
>> Predictors can make predictions about anything. But given that it is
>> only useful to make predictions that are actually used, they will only
>> predict the next few I-cache lines to be fetched, so yes, predicting a
>> few fetch lines ahead could be common.
>>
>> How many? Depends on the latency of the I-cache. Given that it is
>> typically similar in size to the D-cache, it's latency will also be
>> similar, i.e., around 4 cycles.
>>
>> How many cache lines are fetched per cycle? With a 10-wide front end,
>> you probably do not want to underutilize the rest of the front end if
>> there is a taken branch or there is a branch to a target less than 10
>> instructions from the end of the cache line, so better fetch two cache
>> lines per cycle.
>
>A cache line contains 16 instructions, so one would assume a partial
>line is held over (to the next decode cycle) and one makes 1 fetch
>in the sequential direction and 1 fetch to another predicted address.
With this design the rest of the front end would not be fully utilized
if there are is more than on taken branch per n instructions (where n
is the decode width). With 10-wide designs, that's restrictive. I
have programs here that have more than 1 taken branch on 10
instructions:
perf stat -e instructions:u -e br_inst_retired.near_taken:u ./magichex 3 2
...
143280237 instructions:u
16156505 br_inst_retired.near_taken:u
That's 8.9 instructions per taken branch.
perf stat -e instructions:u -e br_inst_retired.near_taken:u gforth-fast --no-dynamic onebench.fs
4249141031 instructions:u
661631554 br_inst_retired.near_taken:u
That's 6.4 instructions per taken branch.
Although, admittedly, in the last case if we take the "--no-dynamic"
away, this reduces the number of taken branches more than the number
of instructions, resulting in more than 10 instructions per taken
branch:
2026987196 instructions:u
175323098 br_inst_retired.near_taken:u
But it uses dynamic native-code generation, which you have poo-pooed
as "self-modifying code", so presumably My 66000 will have to fall
back to --no-dynamic and will have to take at least 661M cycles for
this benchmark if it can only deal with one taken branch per cycle,
whereas even a lowly Darkmont (Core Ultra 225 E-Core) can run this
benchmark on 440M cycles.
>I have numerous examples of RISC-V (LLVM -O3) having 13 STs in prologue
>and 13 LDs in epilogue. The distribution (excepting for leaf functions
>(0 saved) and director functions (1 saved) is basically a Bell Curve
>from 2->13.)
It's interesting that you have numerous examples of needing 13
callee-saved registers for non-leaf functions, but apparently the 16
caller-saved registers are enough for the leaf functions; i.e., there
is not a single leaf function that needs more than 16 registers (the
number of caller-saved registers in the RISC-V ABI).
>> It does not
>> need to decode the return instruction to predict it, it just needs to
>> predict that there will be a return, and then use the hardware return
>> stack to make the prediction.
>
>Maybe predictors have gotten that good.
They have to. You cannot afford to wait to decode a branch before
starting to predict it when you need to be able to deal with 1-2 taken
branches per cycle. If you wait for the fetch and the decode before
starting to predict, you will see at most 1 taken branch every n
cycles, where n=fetch_latency+decode_latency+predictor_latency, i.e.,
>5 cycles on a modern CPU, possibly more like 10 cycles. With one
taken branch every 10 instructions or so, this would limit your IPC to
1-2, and much of the 10-wide design would starve.
>No, of course not. Leaf functions (93%) save no registers at all as they
>perform their duties in the freely-available temporary registers R0..15
If a leaf function needs more GPRs, it use callee-saved registers, and
will save them in the prologue and load them in the epilogue.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-31 18:22 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <1793470952-5857@newsgrouper.org> |
| In reply to | #118979 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >
> >> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >> >> In a modern
> >> >> (post-1995, with a few exceptions, most of which have died out in the
> >> >> meantime) processor the front end predicts the return from the
> >> >> processor-internal return stack and often starts fetching from there
> >> >> before the load-store unit sees the load of the return address. The
> >> >> return address is then used to validate the branch prediction and
> >> >> retire the return instruction.
> >> >
> >> >You can't predict until you are within <about> 2-fetch cycles of the
> >> >instruction you are going to make a prediction about {RET here}.
> >>
> >> Predictors can make predictions about anything. But given that it is
> >> only useful to make predictions that are actually used, they will only
> >> predict the next few I-cache lines to be fetched, so yes, predicting a
> >> few fetch lines ahead could be common.
> >>
> >> How many? Depends on the latency of the I-cache. Given that it is
> >> typically similar in size to the D-cache, it's latency will also be
> >> similar, i.e., around 4 cycles.
> >>
> >> How many cache lines are fetched per cycle? With a 10-wide front end,
> >> you probably do not want to underutilize the rest of the front end if
> >> there is a taken branch or there is a branch to a target less than 10
> >> instructions from the end of the cache line, so better fetch two cache
> >> lines per cycle.
> >
> >A cache line contains 16 instructions, so one would assume a partial
> >line is held over (to the next decode cycle) and one makes 1 fetch
> >in the sequential direction and 1 fetch to another predicted address.
>
> With this design the rest of the front end would not be fully utilized
> if there are is more than on taken branch per n instructions (where n
> is the decode width). With 10-wide designs, that's restrictive.
Remember, I am only shooting at a 6-wide machine. and for 6-wide, 1-
prediction per cycle is not very restrictive. Also note: I have
conditional PREDicates which take 20% of front-end-redirects away.
K9 was 8-wide and we did have 2-predictions per cycle to deal with.
> I have programs here that have more than 1 taken branch on 10
> instructions:
>
> perf stat -e instructions:u -e br_inst_retired.near_taken:u ./magichex 3 2
> ...
> 143280237 instructions:u
> 16156505 br_inst_retired.near_taken:u
>
> That's 8.9 instructions per taken branch.
My statistics are low 9.x inst per taken branch.
> perf stat -e instructions:u -e br_inst_retired.near_taken:u gforth-fast --no-dynamic onebench.fs
> 4249141031 instructions:u
> 661631554 br_inst_retired.near_taken:u
>
> That's 6.4 instructions per taken branch.
>
> Although, admittedly, in the last case if we take the "--no-dynamic"
> away, this reduces the number of taken branches more than the number
> of instructions, resulting in more than 10 instructions per taken
> branch:
>
> 2026987196 instructions:u
> 175323098 br_inst_retired.near_taken:u
>
> But it uses dynamic native-code generation, which you have poo-pooed
> as "self-modifying code",
I have indeed.
> so presumably My 66000 will have to fall
> back to --no-dynamic and will have to take at least 661M cycles for
> this benchmark if it can only deal with one taken branch per cycle,
> whereas even a lowly Darkmont (Core Ultra 225 E-Core) can run this
> benchmark on 440M cycles.
If --no-dynamic has to do with dynamically loaded libraries, ABI
allows for them via GOT (without PLT saving a branch in the process).
> >I have numerous examples of RISC-V (LLVM -O3) having 13 STs in prologue
> >and 13 LDs in epilogue. The distribution (excepting for leaf functions
> >(0 saved) and director functions (1 saved) is basically a Bell Curve
> >from 2->13.)
>
> It's interesting that you have numerous examples of needing 13
> callee-saved registers for non-leaf functions, but apparently the 16
> caller-saved registers are enough for the leaf functions; i.e., there
> is not a single leaf function that needs more than 16 registers (the
> number of caller-saved registers in the RISC-V ABI).
There are leaf functions which need more than 16 registers--where did I
imply otherwise--there are "just not many".
> >> It does not
> >> need to decode the return instruction to predict it, it just needs to
> >> predict that there will be a return, and then use the hardware return
> >> stack to make the prediction.
> >
> >Maybe predictors have gotten that good.
>
> They have to. You cannot afford to wait to decode a branch before
> starting to predict it when you need to be able to deal with 1-2 taken
> branches per cycle.
Which is why we built the packet cache for Mc 88120 and a trace cache
for K9. Mc 88120 could take all conditional branches per cycle and 1
conditional branch per cycle. K9 could take all unconditional and 2
conditional branches per cycle.
> If you wait for the fetch and the decode before
> starting to predict, you will see at most 1 taken branch every n
> cycles, where n=fetch_latency+decode_latency+predictor_latency, i.e.,
I see fetch-latency running concurrently with predictor-latency.
I do not see DECODE-latency getting in the way.
> >5 cycles on a modern CPU, possibly more like 10 cycles. With one
> taken branch every 10 instructions or so, this would limit your IPC to
> 1-2, and much of the 10-wide design would starve.
Fetching as described above, and with annotation as above; I don't
see a problem feeding DECODE with 6-instructions per cycle. Remember
that 10-wide machine is only retiring 3 I/c.
> >No, of course not. Leaf functions (93%) save no registers at all as they
> >perform their duties in the freely-available temporary registers R0..15
>
> If a leaf function needs more GPRs, it use callee-saved registers, and
> will save them in the prologue and load them in the epilogue.
Captain Obvious strikes again.
> - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-31 19:15 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <2026Oct31.201546@mips.complang.tuwien.ac.at> |
| In reply to | #118991 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> if we take the "--no-dynamic" away ... >> But it uses dynamic native-code generation, which you have poo-pooed >> as "self-modifying code", > >I have indeed. >If --no-dynamic has to do with dynamically loaded libraries, ABI >allows for them via GOT (without PLT saving a branch in the process). No, --no-dynamic falls back to using a threaded-code interpreter, while --dynamic (default) uses native code generated at run-time (what you call "self-modifying code" and want to disable; other people call it "JIT compilation"). >There are leaf functions which need more than 16 registers--where did I >imply otherwise--there are "just not many". Here: >> >Leaf functions (93%) save no registers at all as they >> >perform their duties in the freely-available temporary registers R0..15 >Remember >that 10-wide machine is only retiring 3 I/c. I regularly see programs with >3IPC on 5-wide, 6-wide and 8-wide machines. E.g., for "gforth-fast onebench.fs" mentioned above on a Darkmont (Core Ultra 225 E-Core). 424_922_809 cpu_atom/cycles:u/ 2_044_802_828 cpu_atom/instructions:u/ # 4.81 insn per cycle A few weeks ago <2026Sep21.171615@mips.complang.tuwien.ac.at> I reported measuring 6.75 IPC on a Rocket Lake, which is usually considered to be 5-wide, and with reason (only 5 renamer slots etc.). Here we see 7 IPC in a loop because the loop contains two cmp+branch combinations, which consume only one slot in the path from the microcode cache through the renamer to the schedulers. Both branches are taken in the measured loop, i.e., 1 taken branch every 3.5 instructions. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-31 20:44 +0000 |
| Subject | Re: Register windows (was: Why VAX Was the Ultimate CISC and Not RISC) |
| Message-ID | <1793479457-5857@newsgrouper.org> |
| In reply to | #118996 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> if we take the "--no-dynamic" away > ... > >> But it uses dynamic native-code generation, which you have poo-pooed > >> as "self-modifying code", > > > >I have indeed. > > >If --no-dynamic has to do with dynamically loaded libraries, ABI > >allows for them via GOT (without PLT saving a branch in the process). > > No, --no-dynamic falls back to using a threaded-code interpreter, > while --dynamic (default) uses native code generated at run-time (what > you call "self-modifying code" and want to disable; other people call > it "JIT compilation"). > > >There are leaf functions which need more than 16 registers--where did I > >imply otherwise--there are "just not many". > > Here: > >> >Leaf functions (93%) save no registers at all as they > >> >perform their duties in the freely-available temporary registers R0..15 > > >Remember > >that 10-wide machine is only retiring 3 I/c. > > I regularly see programs with >3IPC on 5-wide, 6-wide and 8-wide > machines. E.g., for "gforth-fast onebench.fs" mentioned above on a > Darkmont (Core Ultra 225 E-Core). > > 424_922_809 cpu_atom/cycles:u/ > 2_044_802_828 cpu_atom/instructions:u/ # 4.81 insn per cycle > > A few weeks ago <2026Sep21.171615@mips.complang.tuwien.ac.at> I > reported measuring 6.75 IPC on a Rocket Lake, which is usually > considered to be 5-wide, and with reason (only 5 renamer slots etc.). > Here we see 7 IPC in a loop because the loop contains two cmp+branch > combinations, which consume only one slot in the path from the > microcode cache through the renamer to the schedulers. Both branches > are taken in the measured loop, i.e., 1 taken branch every 3.5 > instructions. I see similar (at a smaller scale) when my cores perform CoIssue (similar to instruction fusing, but designed to leverage RF ports across instructions. A CoIssued instruction requires no more RF ports or rename ports than any 'random' instruction can use. Since STs do not write to RF, STs can be CoIssued with any following calculation instruction (or branch instruction). Since conditional Branch instructions do not write RF, they can be CoIssued with previous calculation instruction. STs and <conditional> branches make up 30%-odd of instruction stream: so, the decoder looks to be processing 1.3 I/c in a 1-wide implementa- tion. There are other potentials--but since this is not close to RISC-V's instruction fusing, I had to use a different word. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-11-04 22:45 -0500 |
| Subject | Re: Register windows |
| Message-ID | <11clehe$2snva$1@dont-email.me> |
| In reply to | #118999 |
On 10/31/26 4:44 PM, MitchAlsup wrote: [snip] > I see similar (at a smaller scale) when my cores perform CoIssue > (similar to instruction fusing, but designed to leverage RF ports > across instructions. A CoIssued instruction requires no more RF > ports or rename ports than any 'random' instruction can use. I think I would view CoIssue as a limited form of superscalar execution that has fine-grained hazard detection. With support for worst-case execution of three-source, one- destination instructions (e.g., no source coming from the forwarding network) and wide fetch (reducing fetch energy), there would be more opportunities for two-wide execution in a nominally one-wide design. I would guess that even two-way register banking would expose even more opportunities for dual issue at the cost of more complex hazard detection. (A 50% chance of two-wide issue enabled when base CoIssue is prevented only from the two instructions each having a register destination. Clever register allocation could increase the frequency of two-wide execution.) Adding such execution opportunities might then incentivize increasing execution resources, pushing the design closer to a conventional two-wide superscalar. (Even wider register access support for load/store multiple operations — ENTER/EXIT, context switch, etc. — might sometimes effectively provide more register ports, though I would have guessed that banking would not have that much more overhead.) Supporting two register destinations would presumably complicate the forwarding; limited forwarding would introduce another hazard to detect and potentially extend such to single issue. Borrowing across cycles could also support wider execution. E.g., if two instructions cannot CoIssue because both instructions read two registers, the earlier instruction could CoIssue with a pseudo-instruction that moves one register source from the later instruction into a buffer. The next cycle the first instruction would have only one register source (and one buffer source), and so would have a better chance of being eligible for CoIssue. Stores may also tolerate delayed register read. An indexed store might normally be ineligible for CoIssue (having three register sources), but might be able to borrow a register read port from the next cycle. [I do wonder if it would be practical to detect/express that a result is only stored. A Decoupled Access/Execute architecture could simply use a register name to indicate result being sent to the store queue (execute-to-access queue). This effectively partially fuses a computation instruction and a potentially substantially later store instruction, removing the need for allocating a destination physical register and using a register write port and possibly a register read port for the store (the store data might be supplied by ordinary forwarding in a conventional design).] Dependent instructions would present opportunities for later wider execution as one register operand would be from the forwarding network and one or more register sources could be read earlier and buffered. Borrowing a register write might also be possible. With a memory-access stage before writeback (classic 5-stage pipeline), it might be possible for the register write slot from an immediately previous no-register-write execution to be borrowed (inserting the write into the second forwarding slot). Borrowing a write slot from the following execution cycle > Since STs do not write to RF, STs can be CoIssued with any following > calculation instruction (or branch instruction). Presumably excluding indexed loads, which read three register sources? With four register read ports, an indexed load could CoIssue with an immediate-using calculation instruction (or an instruction getting one source from the forwarding network), but I thought only three read ports were the design target. > Since conditional Branch instructions do not write RF, they can be > CoIssued with previous calculation instruction. Presumably this is not possible if the branch is dependent on the result of the calculation instruction. (A branch might also be CoIssued with a following calculation instruction if the calculation instruction can be annulled, which might not require much more hardware if predication is implemented by suppressing register writes when the predicate evaluation is delayed. This wastes some energy.) > STs and <conditional> branches make up 30%-odd of instruction stream: > so, the decoder looks to be processing 1.3 I/c in a 1-wide implementa- > tion. > > There are other potentials--but since this is not close to RISC-V's > instruction fusing, I had to use a different word. It is not clear to me that a separate term is needed. How is CoIssue distinct from superscalar execution with management of register read and write port hazards? Not having to look at the register names to determine potential CoIssue has some advantage, but a one-register source instruction could also CoIssue with a two-register source if two register destinations were supported without looking at the register names. If two-way banking was used only one bit from each instruction would have to be compared to enable two register writes. (The extra forwarding complexity to support two register writes might make more general superscalar execution a better choice.) If register port count is the primary constraint, a three-read, one-write register file could support a slightly broader set of instruction pairings. Two-read, one-write, and one-read/write could support even more diverse pairings, some detectable just from the opcode (two one register source instructions). Two-way banking presents even more two-wide execution opportunities. An instruction following an instruction with a register destination would have to check for a dependency, which would presumably delay register read or force instruction result nullification and instruction replay (wasting energy and adding some complexity). Since a branch can CoIssue with a previous calculation instruction, this case already needs to handle a potential dependency. A skewed or second-chance pipeline (skewed: address generation is one or more stages before execute; second-chance: branch and perhaps other instructions can execute in an earlier execute stage with address generation or a later stage) is another superscalar variation. (Counterflow pipelines [Robert F. Sproull et al., "Counterflow Pipeline Processor Architecture", 1994] are reminiscent of second-chance pipelines and cascaded execution.) 1.3 wide execution may be preferred over 1 wide or 1.9x wide (not allowing two memory access instructions, two multiplies, or two branches, but allowing most other instruction pairings); faster than 1 wide and simpler than 1.9x wide. Such would also be faster on integer code than early FPR+GPR superscalar. Not being a hardware designer, I do not have a feel for how much complexity (and delay) more flexible superscalar would add. *IF* register file port count is the _only_ significant constraint, more general two-wide execution seems reasonable. A lot of instructions use an immediate for one operand or get an operand from the forwarding network, and banking would increase the effective port count. Yet I must assume that CoIssue is a good design point, which indicates that hardware overheads (and not mere design complexity) make 1.5 wide execution excessively expensive.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-11-07 16:21 +0000 |
| Subject | Re: Register windows |
| Message-ID | <11cnj5a$36etq$1@paganini.bofh.team> |
| In reply to | #118947 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>> There is a third issue: Do you pass arguments in the register windows,
>>> or in what SPARC calls global registers? AFAIK SPARC chose to pass
>>> them in windows, but that means that a call sequence like
>>>
>>> int foo(a,b)
>>> {
>>> ...
>>> bar(a,b);
>>> ...
>>> }
>>
>>It gets worse when::
>>
>> type foo( a, b ){
>> ...
>> return bar( a, b );
>> ...
>> }
>>
>>Now you have to copy forward foo->bar and copy bar's return back
>>as foo's return.
>
> No, it's a tail-call. You just jump to bar without saving or
> restoring a register window.
>
>>My 66000 takes advantage of this by LDing the Ret Addr first, and then
>>reLDing the rest of the file, so by the time that is done, FETCH already
>>has instructions for DECODE>
>
> I get the impression that My 66000 lives in 1994. In a modern
> (post-1995, with a few exceptions, most of which have died out in the
> meantime) processor the front end predicts the return from the
> processor-internal return stack and often starts fetching from there
> before the load-store unit sees the load of the return address. The
> return address is then used to validate the branch prediction and
> retire the return instruction.
It must be more complex. Silly fibonacci benchmark shows average
performance of function call per 2 clocks. Given length of
the pipeline return address is pushed too late to use it for
fetching intructions after return. In other words, return
must be predicted before the call starts executing.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
Back to top | Article view | comp.arch
csiph-web