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 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-05 01:28 +0200 |
| Message-ID | <20250305012818.00007386@yahoo.com> |
| In reply to | #110958 |
On Tue, 04 Mar 2025 16:32:42 -0500 George Neuner <gneuner2@comcast.net> wrote: > On Mon, 3 Mar 2025 19:53:12 +0200, Michael S > <already5chosen@yahoo.com> wrote: > > >On Mon, 03 Mar 2025 17:21:32 GMT > >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > > >Digital sold solid PCs in the 1990s. Some under brand DECpc, others > >under brand DEC Station. > > Was there an Intel based DECstation? > The only ones I ever saw were MIPS based. > > <searches> > > Ahh! Wikipedia says there were 3 different DECstation lines: one based > on PDP-8, annother based on MIPS, and yet another based on Intel. > Naturally one has to scan/read the entire article to find the Intel > references. The name I dug out of 1994 Byte issue are DEC Celebris desktop and HiNote laptop. But that's not the names I had in mind.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-05 00:05 +0000 |
| Message-ID | <vq84g9$23f55$3@dont-email.me> |
| In reply to | #110961 |
On Wed, 5 Mar 2025 01:28:18 +0200, Michael S wrote: > On Tue, 04 Mar 2025 16:32:42 -0500 George Neuner <gneuner2@comcast.net> > wrote: > >> Ahh! Wikipedia says there were 3 different DECstation lines: one based >> on PDP-8, annother based on MIPS, and yet another based on Intel. >> Naturally one has to scan/read the entire article to find the Intel >> references. > > The name I dug out of 1994 Byte issue are DEC Celebris desktop and > HiNote laptop. But that's not the names I had in mind. Entirely different decades.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-05 15:07 +0200 |
| Message-ID | <20250305150703.000035ab@yahoo.com> |
| In reply to | #110963 |
On Wed, 5 Mar 2025 00:05:30 -0000 (UTC) Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Wed, 5 Mar 2025 01:28:18 +0200, Michael S wrote: > > > On Tue, 04 Mar 2025 16:32:42 -0500 George Neuner > > <gneuner2@comcast.net> wrote: > > > >> Ahh! Wikipedia says there were 3 different DECstation lines: one > >> based on PDP-8, annother based on MIPS, and yet another based on > >> Intel. Naturally one has to scan/read the entire article to find > >> the Intel references. > > > > The name I dug out of 1994 Byte issue are DEC Celebris desktop and > > HiNote laptop. But that's not the names I had in mind. > > Entirely different decades. You are not obliged to take part in discussion you aren't able to follow.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-03 23:32 +0000 |
| Message-ID | <vq5e5n$1h3mg$8@dont-email.me> |
| In reply to | #110930 |
On Mon, 3 Mar 2025 16:34:35 +0100, Terje Mathisen wrote: > ... while the guy who hired me kept his belowed DEC Rainbow which he > felt had the better architecture: I only had a brief exposure to them, but I think they were beautiful machines, too. > For one thing they did not break Intel's rules about where to place the > interrupt vectors. In hindsight this was a bad decision since 100% > compatibility with Microsoft Flight Simulator was an absolute > requirement at the time. This is why I refer to “Microsoft-compatible”, rather than “IBM- compatible”, PCs. Because it was Microsoft that very quickly took over the mantle of arbiter of “compatibility” from IBM. > Anton Ertl wrote: >> >> They did not succeed. Maybe that's the decisive difference from HP: >> They did succeed in the PC market. Bell mentions that: DEC tried to set a standard (a reasonable thing to try in 1982), and failed. They should have quickly pivoted to embracing the actual standard that won, but they did not.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-02 21:56 +0000 |
| Message-ID | <vq2k5o$v1q6$9@dont-email.me> |
| In reply to | #110883 |
On Sat, 1 Mar 2025 16:29:27 -0600, BGB wrote: > It almost seems like they could have tried making a PDP-11 based PC. They did. In 1982, DEC already had, not one, but three different lines of PCs, based on the PDP-11 (the “Professional” line), the PDP-8 (“DECmate”), and a dual-processor Z80/8088 machine (the “Rainbow”). This last one could run 3 OSes: CP/M-80, CP/M-86, and MS-DOS. But only one at a time. So you’d think they had their bases covered on the PC front, quite early on.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-02 00:16 +0000 |
| Message-ID | <vq0805$etiq$1@dont-email.me> |
| In reply to | #110877 |
On Sat, 01 Mar 2025 11:58:17 GMT, Anton Ertl wrote: > Like other USA-based computer architects, Bell ignores ARM, which > outperformed the VAX without using caches and was much easier to design. While those ARM chips were legendary for their low power consumption (and low transistor count), those Archimedes machines were not exactly low- cost, as I recall. Without caches, did they have to use faster (and therefore more expensive) memory? Or did they fall back on the classic “wait states”?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-02 12:10 +0000 |
| Message-ID | <2025Mar2.131042@mips.complang.tuwien.ac.at> |
| In reply to | #110889 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Sat, 01 Mar 2025 11:58:17 GMT, Anton Ertl wrote:
>
>> Like other USA-based computer architects, Bell ignores ARM, which
>> outperformed the VAX without using caches and was much easier to design.
>
>While those ARM chips were legendary for their low power consumption (and
>low transistor count), those Archimedes machines were not exactly low-
>cost, as I recall.
Compared to what? Compared to an 8-bit or 16-bit home computer: no.
Compared to PCs at the time: yes. Compared to a contemporary VAX: by
a lot.
USD GBP Year Model
149 1985 C64 (64KB RAM)
699 499 1987 Amiga 500 (512KB RAM)
799 1987 ARM Archimedes 305 (512KB RAM)
3500 1989 ARM R140 (4MB RAM, 60MB HDD, RISC iX, no ethernet)
1995 1990 ARM R225 (8MB RAM, RISC iX)
3995 1990 ARM R260 (8MB RAM, 100MB HDD, RISC iX)
6499 1986 Compaq DeskPro 386 Model 40 (1MB RAM, 40MB HDD)
3769 1987 MacIntosh II (1MB RAM, no HDD for this price)
5000 1987? MicroVAX II KA620 (1MB RAM)
81000 1989 MicroVAX 3800
120200 1989 MicroVax 3900
The MicroVAX II KA620 seems to be a special model ("a single-board
MicroVAX II designed for automatic test equipment and manufacturing
applications which only ran DEC's real-time VAXELN operating system"
<https://alchetron.com/MicroVAX>; all VAX prices are from that site).
The question of performance came up:
<https://en.wikipedia.org/wiki/File:Archimedes_performance.svg> shows
that the Acorn Archimedes using ARM2 without cache ran Dhrystone at
2.8 times the speed of a VAX-11/780, and the ARM3 with 4KB cache ran
DhryStone at 10.5-15.1 times the speed of the VAX-11/780. The graph
also shows the competition in the home computer and PC space, and
gives sources for the numbers.
>Without caches, did they have to use faster (and therefore more expensive)
>memory?
The ARM Archimedes used a 32-bit memory interface which was apparently
a lot more expensive than the 8-bit memory interface of the C64 and
the 16-bit memory interface of the Amiga 500. Other than that, I
don't think there was much in the way of DRAM speed grades at the
time. Marketing high-speed DRAM to the gullible seems to be a rather
recent development.
>Or did they fall back on the classic “wait states”?
Wait states make no sense is the CPU has no chance to do other work
during the wait states (as for the ARM2), so I doubt that. I expect
that what they did was to just use the clock that the RAM supported.
They used an 8MHz clock.
- 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 | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-05 15:28 -0500 |
| Message-ID | <jwv34fr442b.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #110877 |
Anton Ertl [2025-03-01 11:58:17] wrote:
> Bottom line: If you sent, e.g., me and the needed documents back in
> time to the start of the VAX project, and gave me a magic wand that
> would convince the DEC management and workforce that I know how to
> design their next architecture, and how to compiler for it, I would
> give the implementation team RV32GC as architecture to implement, and
> that they should use pipelining for that, and of course also give that
> to the software people.
I wonder if an RV32GC would be competitive if implemented in the
technology available back in 1977 (when the VAX-11/780 came out,
according to Wikipedia).
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-05 21:15 +0000 |
| Message-ID | <vqaeu0$2j9k5$1@dont-email.me> |
| In reply to | #110970 |
Stefan Monnier <monnier@iro.umontreal.ca> schrieb: > Anton Ertl [2025-03-01 11:58:17] wrote: >> Bottom line: If you sent, e.g., me and the needed documents back in >> time to the start of the VAX project, and gave me a magic wand that >> would convince the DEC management and workforce that I know how to >> design their next architecture, and how to compiler for it, I would >> give the implementation team RV32GC as architecture to implement, and >> that they should use pipelining for that, and of course also give that >> to the software people. > > I wonder if an RV32GC would be competitive if implemented in the > technology available back in 1977 (when the VAX-11/780 came out, > according to Wikipedia). RISC in general could have been - the 801 (although it was implemented in ECL), HP's first HP-PA, implemented in TTL, and ARM show that.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-01 14:40 -0500 |
| Message-ID | <8qJwP.64143$2zn8.32753@fx15.iad> |
| In reply to | #110876 |
Lawrence D'Oliveiro wrote: > Found this paper > <https://gordonbell.azurewebsites.net/Digital/Bell_Retrospective_PDP11_paper_c1998.htm> > at Gordon Bell’s website. Talking about the VAX, which was designed as > the ultimate “kitchen-sink” architecture, with every conceivable > feature to make it easy for compilers (and humans) to generate code, > he explains: > > The VAX was designed to run programs using the same amount of > memory as they occupied in a PDP-11. The VAX-11/780 memory range > was 256 Kbytes to 2 Mbytes. Thus, the pressure on the design was > to have very efficient encoding of programs. Very efficient > encoding of programs was achieved by having a large number of > instructions, including those for decimal arithmetic, string > handling, queue manipulation, and procedure calls. In essence, any > frequent operation, such as the instruction address calculations, > was put into the instruction-set. VAX became known as the > ultimate, Complex (Complete) Instruction Set Computer. The Intel > x86 architecture followed a similar evolution through various > address sizes and architectural fads. > > 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: > > RISC didn’t cross over CISC until 1985. This occurred with the > availability of large SRAMs that could be used for caches. It > should be noted at the time the VAX-11/780 was introduced, DRAMs > were 4 Kbits and the 8 Kbyte cache used 1 Kbits SRAMs. Memory > sizes continued to improve following Moore’s Law, but it wasn’t > till 1985, that Reduced Instruction Set Computers could be built > in a cost-effective fashion using SRAM caches. In essence RISC > traded off cache memories built from SRAMs for the considerably > faster, and less expensive Read Only Memories that held the more > complex instructions of VAX (Bell, 1986). If you look at the VAX 8800 or NVAX uArch you see that even in 1990 it was still taking multiple clocks to serially decode each instruction and that basically stalls away any benefits a pipeline might have given. If they had just only put in *the things they actually use* (as show by DEC's own instruction usage stats from 1982), and left out all the things that they rarely or never use, it would have had 50 or so opcodes instead of 305, at most one operand that addressed memory on arithmetic and logic opcodes with 3 address modes (register, register address, register offset address) instead of 0 to 5 variable length operands with 13 address modes each (most combinations of which are either silly, redundant, or illegal). Then they would have be able to parse instructions in one clock, which makes pipelining a possible consideration, and simplifies the uArch so now it can all fit on one chip, which allows it to complete with RISC. The reason it was designed the way it was, was because DEC had microcode and microprogramming on the brain. In this 1975 paper Bell and Strecher say it over and over and over. They were looking at the cpu design as one large parsing machine and not as a set of parallel hardware tasks. This was their mental mindset just before they started the VAX design: What Have We Learned From PDP11, Bell Strecker, 1975 https://gordonbell.azurewebsites.net/Digital/Bell_Strecker_What_we%20_learned_fm_PDP-11c%207511.pdf
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-01 22:30 +0000 |
| Message-ID | <a7558b1767c6cb23070ccc4b0a3fc47b@www.novabbs.org> |
| In reply to | #110880 |
On Sat, 1 Mar 2025 19:40:55 +0000, EricP wrote:
> Lawrence D'Oliveiro wrote:
>> Found this paper
>> <https://gordonbell.azurewebsites.net/Digital/Bell_Retrospective_PDP11_paper_c1998.htm>
>> at Gordon Bell’s website. Talking about the VAX, which was designed as
>> the ultimate “kitchen-sink” architecture, with every conceivable
>> feature to make it easy for compilers (and humans) to generate code,
>> he explains:
>>
>> The VAX was designed to run programs using the same amount of
>> memory as they occupied in a PDP-11. The VAX-11/780 memory range
>> was 256 Kbytes to 2 Mbytes. Thus, the pressure on the design was
>> to have very efficient encoding of programs. Very efficient
>> encoding of programs was achieved by having a large number of
>> instructions, including those for decimal arithmetic, string
>> handling, queue manipulation, and procedure calls. In essence, any
>> frequent operation, such as the instruction address calculations,
>> was put into the instruction-set. VAX became known as the
>> ultimate, Complex (Complete) Instruction Set Computer. The Intel
>> x86 architecture followed a similar evolution through various
>> address sizes and architectural fads.
>>
>> 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:
>>
>> RISC didn’t cross over CISC until 1985. This occurred with the
>> availability of large SRAMs that could be used for caches. It
>> should be noted at the time the VAX-11/780 was introduced, DRAMs
>> were 4 Kbits and the 8 Kbyte cache used 1 Kbits SRAMs. Memory
>> sizes continued to improve following Moore’s Law, but it wasn’t
>> till 1985, that Reduced Instruction Set Computers could be built
>> in a cost-effective fashion using SRAM caches. In essence RISC
>> traded off cache memories built from SRAMs for the considerably
>> faster, and less expensive Read Only Memories that held the more
>> complex instructions of VAX (Bell, 1986).
>
> If you look at the VAX 8800 or NVAX uArch you see that even in 1990 it
> was
> still taking multiple clocks to serially decode each instruction and
> that basically stalls away any benefits a pipeline might have given.
>
> If they had just only put in *the things they actually use*
> (as show by DEC's own instruction usage stats from 1982),
> and left out all the things that they rarely or never use,
> it would have had 50 or so opcodes instead of 305,
> at most one operand that addressed memory on arithmetic and logic
> opcodes
> with 3 address modes (register, register address, register offset
> address)
> instead of 0 to 5 variable length operands with 13 address modes each
> (most combinations of which are either silly, redundant, or illegal).
Excepting for the 1 memory operand per instruction, the above para-
graph accurately describes My 66000 ISA.
> Then they would have be able to parse instructions in one clock,
> which makes pipelining a possible consideration,
> and simplifies the uArch so now it can all fit on one chip,
> which allows it to complete with RISC.
If VAX had stuck with PDP-11 address modes and simply added the
{Byte, Half, Word, Double} accesses it would have been a lot easier
to pipeline.
> The reason it was designed the way it was, was because DEC had
> microcode and microprogramming on the brain.
As did most of academia at the time.
> In this 1975 paper Bell and Strecher say it over and over and over.
> They were looking at the cpu design as one large parsing machine
> and not as a set of parallel hardware tasks.
Orthogonality, Regularity, Expressibility, ...
> This was their mental mindset just before they started the VAX design:
>
> What Have We Learned From PDP11, Bell Strecker, 1975
> https://gordonbell.azurewebsites.net/Digital/Bell_Strecker_What_we%20_learned_fm_PDP-11c%207511.pdf
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-01 23:19 +0000 |
| Message-ID | <vq04ls$e6sd$6@dont-email.me> |
| In reply to | #110880 |
On Sat, 01 Mar 2025 14:40:55 -0500, EricP wrote: > If you look at the VAX 8800 or NVAX uArch you see that even in 1990 it > was still taking multiple clocks to serially decode each instruction and > that basically stalls away any benefits a pipeline might have given. How many clocks did Alpha take to process each instruction? Because I recall the initial chips had clock speeds several times that of the RISC competition, but performance, while competitive, was not several times greater.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-01 17:45 -0600 |
| Message-ID | <vq0677$dq4s$2@dont-email.me> |
| In reply to | #110885 |
On 3/1/2025 5:19 PM, Lawrence D'Oliveiro wrote: > On Sat, 01 Mar 2025 14:40:55 -0500, EricP wrote: > >> If you look at the VAX 8800 or NVAX uArch you see that even in 1990 it >> was still taking multiple clocks to serially decode each instruction and >> that basically stalls away any benefits a pipeline might have given. > > How many clocks did Alpha take to process each instruction? Because I > recall the initial chips had clock speeds several times that of the RISC > competition, but performance, while competitive, was not several times > greater. AFAIK, issue was partly a case of: What clock speed giveth, large instruction counts taketh away... If reading an 8/16/32 bit value from memory takes a multi-instruction sequence, and writing such a value back to memory also requires another multi-instruction sequence (to fake the insertion in software). Well, this can't be good for performance... Seemingly, it was designed to prioritize clock speed above all else, but more instructions don't necessarily help if the added overheads exceed the relative gains in clock speed. Such is the issue. On the other side, one may get better performance at a lower clock speed if one needs fewer instructions for a given task, and those instructions have a lower average case latency. Though, admittedly, in my project, the typical 2/3 cycle latency values on most instructions are higher than 1/2 cycle latency on many other CPUs. But, at the same time, the latency hurts less if one has fewer and shorter chains of directly-dependent instructions. Not a great situation for running RISC-V though, which has a more obvious detrimental impact from things like 2-cycle ADD or SLL (mostly as direct multi-instruction register-dependent chains are common and GCC emits a lot of them). Not sure about what instruction scheduling was like on the Alpha, this would likely have a big impact on how it would perform in the face of multi-cycle ALU ops (and, off hand, I don't know if the Alpha had single or multi-cycle latency on ALU ops). Though, AFAIK, 2-cycle ALU was common on PowerPC and POWER variants. ...
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-01 17:45 -0600 |
| Message-ID | <vq067u$el2n$1@dont-email.me> |
| In reply to | #110885 |
On 3/1/2025 5:19 PM, Lawrence D'Oliveiro wrote: > On Sat, 01 Mar 2025 14:40:55 -0500, EricP wrote: > >> If you look at the VAX 8800 or NVAX uArch you see that even in 1990 it >> was still taking multiple clocks to serially decode each instruction and >> that basically stalls away any benefits a pipeline might have given. > > How many clocks did Alpha take to process each instruction? Because I > recall the initial chips had clock speeds several times that of the RISC > competition, but performance, while competitive, was not several times > greater. AFAIK, issue was partly a case of: What clock speed giveth, large instruction counts taketh away... If reading an 8/16/32 bit value from memory takes a multi-instruction sequence, and writing such a value back to memory also requires another multi-instruction sequence (to fake the insertion in software). Well, this can't be good for performance... Seemingly, it was designed to prioritize clock speed above all else, but more instructions don't necessarily help if the added overheads exceed the relative gains in clock speed. Such is the issue. On the other side, one may get better performance at a lower clock speed if one needs fewer instructions for a given task, and those instructions have a lower average case latency. Though, admittedly, in my project, the typical 2/3 cycle latency values on most instructions are higher than 1/2 cycle latency on many other CPUs. But, at the same time, the latency hurts less if one has fewer and shorter chains of directly-dependent instructions. Not a great situation for running RISC-V though, which has a more obvious detrimental impact from things like 2-cycle ADD or SLL (mostly as direct multi-instruction register-dependent chains are common and GCC emits a lot of them). Not sure about what instruction scheduling was like on the Alpha, this would likely have a big impact on how it would perform in the face of multi-cycle ALU ops (and, off hand, I don't know if the Alpha had single or multi-cycle latency on ALU ops). Though, AFAIK, 2-cycle ALU was common on PowerPC and POWER variants. ...
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-02 16:33 +0200 |
| Message-ID | <20250302163331.00000e23@yahoo.com> |
| In reply to | #110888 |
On Sat, 1 Mar 2025 17:45:58 -0600 BGB <cr88192@gmail.com> wrote: > > Not sure about what instruction scheduling was like on the Alpha, DEC shipped 4 generations of Alpha CPUs with 3 quite different core microarchitectures.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-02 12:03 +0000 |
| Message-ID | <2025Mar2.130358@mips.complang.tuwien.ac.at> |
| In reply to | #110885 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >How many clocks did Alpha take to process each instruction? For the 21064 see slide 15 of <https://people.eecs.berkeley.edu/~randy/Courses/CS252.S96/Lecture19.pdf> I.e., about 1 CPI for Ear, and about 4.3 CPI for TCP-B, with other benchmarks in between. Theoretical bottom CPI (peak performance) of the 21064 is 0.5. - 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@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-02 21:35 +0000 |
| Message-ID | <85c3cd7ad115dec5c18cadac8e91bbd2@www.novabbs.org> |
| In reply to | #110897 |
On Sun, 2 Mar 2025 12:03:58 +0000, Anton Ertl wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>How many clocks did Alpha take to process each instruction? > > For the 21064 see slide 15 of > <https://people.eecs.berkeley.edu/~randy/Courses/CS252.S96/Lecture19.pdf> Well, that was fun. Thanks. > I.e., about 1 CPI for Ear, and about 4.3 CPI for TCP-B, with other > benchmarks in between. > > Theoretical bottom CPI (peak performance) of the 21064 is 0.5. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-02 21:50 +0000 |
| Message-ID | <c9a971ef6330fa51710b7a18f8aba35a@www.novabbs.org> |
| In reply to | #110880 |
On Sat, 1 Mar 2025 19:40:55 +0000, EricP wrote:
> Lawrence D'Oliveiro wrote:
>> Found this paper
>> <https://gordonbell.azurewebsites.net/Digital/Bell_Retrospective_PDP11_paper_c1998.htm>
>> at Gordon Bell’s website. Talking about the VAX, which was designed as
>> the ultimate “kitchen-sink” architecture, with every conceivable
>> feature to make it easy for compilers (and humans) to generate code,
>> he explains:
>>
>> The VAX was designed to run programs using the same amount of
>> memory as they occupied in a PDP-11. The VAX-11/780 memory range
>> was 256 Kbytes to 2 Mbytes. Thus, the pressure on the design was
>> to have very efficient encoding of programs. Very efficient
>> encoding of programs was achieved by having a large number of
>> instructions, including those for decimal arithmetic, string
>> handling, queue manipulation, and procedure calls. In essence, any
>> frequent operation, such as the instruction address calculations,
>> was put into the instruction-set. VAX became known as the
>> ultimate, Complex (Complete) Instruction Set Computer. The Intel
>> x86 architecture followed a similar evolution through various
>> address sizes and architectural fads.
>>
>> 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?
Not with the people involved in VAX at both DEC and in academia.
With some other group of individuals who worked under any of
{Thornton, Cray, Smith, Cooke} and latched onto the things those
people preached and performed.
> 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.
Remember, VAX was envisioned to be the 32-bit PDP-11.
>> 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:
In a rough sense, that statement is true; and add in the fact that
people building computers at the inception of VAX were still beholden
to Wilkes (i.e., microcode.)
> If you look at the VAX 8800 or NVAX uArch you see that even in 1990 it
> was
> still taking multiple clocks to serially decode each instruction and
> that basically stalls away any benefits a pipeline might have given.
When compilers spit out code so each VAX instruction contains
a memory reference (anything from a displacement to an immediate
to a real memory reference), serial decode is what lands on the
table.
> If they had just only put in *the things they actually use*
The problem was that they (the VAX compiler people) emit code
using all the address modes, and VAX had a problem in not having
enough registers ~12 compared to ~29 for R2000, so all use once
memory references used address modes.
> (as show by DEC's own instruction usage stats from 1982),
> and left out all the things that they rarely or never use,
> it would have had 50 or so opcodes instead of 305,
IMHO::: VAX should have 50-60 instructions and not have had the
polynomial instructions, the queue handling instructions, and
the editing instructions, CALLS, RET, Decimal arithmetic, two
kinds of FP, (and a bunch more I can't think of).
> at most one operand that addressed memory on arithmetic and logic
> opcodes
> with 3 address modes (register, register address, register offset
> address)
> instead of 0 to 5 variable length operands with 13 address modes each
> (most combinations of which are either silly, redundant, or illegal).
DEC literally jumped the shark. No instruction should have more
than 3 or 4 operands.
> The reason it was designed the way it was, was because DEC had
> microcode and microprogramming on the brain.
Yes, exactly, and it was the safe choice when VAX started.
> In this 1975 paper Bell and Strecher say it over and over and over.
> They were looking at the cpu design as one large parsing machine
> and not as a set of parallel hardware tasks.
We were in the era where you typical instructions took 5-cycles
to execute, heading to the era where the typical instruction
takes 3 cycles to execute.
RISC shows up at 1.4 cycles per instruction heading to 0.5 today.
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2025-03-05 11:58 +0000 |
| Message-ID | <ZFe*A8G8z@news.chiark.greenend.org.uk> |
| In reply to | #110876 |
Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > 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: > > RISC didn’t cross over CISC until 1985. This occurred with the > availability of large SRAMs that could be used for caches. It > should be noted at the time the VAX-11/780 was introduced, DRAMs > were 4 Kbits and the 8 Kbyte cache used 1 Kbits SRAMs. Memory > sizes continued to improve following Moore’s Law, but it wasn’t > till 1985, that Reduced Instruction Set Computers could be built > in a cost-effective fashion using SRAM caches. In essence RISC > traded off cache memories built from SRAMs for the considerably > faster, and less expensive Read Only Memories that held the more > complex instructions of VAX (Bell, 1986). ARM2 had no caches, but was still table-topping in its era. The thing often missed in the CISC v RISC debate is the cost of main memory. In the 1970s DRAM (or discrete SRAM) was very expensive. So you want a very tight instruction encoding that is maximally expressive - resulting in complex microcode and many-cycle instructions. Effectively the microcode was a table of library functions and the assembly was more like a series of API calls. In the mid 1980s (~1984) the Japanese had entered the DRAM market which caused the price of DRAMs to fall dramatically. That meant you could have a RISC CPU which was more profligate with its instruction encoding but could have a much simplified pipeline and so much better IPC. You didn't need to have the microcode library any more, you could just let the compiler do it. Also memory bandwidth had improved, allowing better feeding of a more profligate CPU (and compilers had got better too) In the late 1980s process improvements meant that on-die caches had become more affordable, which assisted memory bandwidth and latency further. Theo
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-06 00:28 +0000 |
| Message-ID | <vqaq7i$2lg6a$3@dont-email.me> |
| In reply to | #110966 |
On 05 Mar 2025 11:58:35 +0000 (GMT), Theo wrote: > ARM2 had no caches, but was still table-topping in its era. Table-topping in the PC market, perhaps, and less so if you look at price/ performance as opposed to performance. Was it table-topping in the workstation market? Somehow it never seems to have been considered seriously for that.
[toc] | [prev] | [next] | [standalone]
Page 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web