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 1 of 17 [1] 2 3 … 17 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-01 08:09 +0000 |
| Subject | Why VAX Was the Ultimate CISC and Not RISC |
| Message-ID | <vpufbv$4qc5$1@dont-email.me> |
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).
[toc] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-01 11:58 +0000 |
| Message-ID | <2025Mar1.125817@mips.complang.tuwien.ac.at> |
| In reply to | #110876 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >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. Like other USA-based computer architects, Bell ignores ARM, which outperformed the VAX without using caches and was much easier to design. As for code size, we see significantly smaller code for RISC instruction sets with 16/32-bit encodings such as ARM T32/A32 and RV64GC than for all CISCs, including AMD64, i386, and S390x <2024Jan4.101941@mips.complang.tuwien.ac.at>. I doubt that VAX fares so much better in this respect that its code is significantly smaller than for these CPUs. 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. As a result, DEC would have had an architecture that would have given them superior performance, they would not have suffered from the infighting of VAX9000 vs. PRISM etc. (and not from the wrong decision to actually build the VAX9000), and might still be going strong to this day. They would have been able to extend RV32GC to RV64GC without problems, and produce superscalar and OoO implementations. OTOH, DEC had great success with the VAX for a while, and their demise may have been unavoidable given their market position: Their customers (especially the business customers of VAXen) went to them instead of IBM, because they wanted something less costly, and they continued onwards to PCs running Linux when they provided something less costly. So DEC would also have needed to outcompete Intel and the PC market to succeed (and IBM eventually got out of that market). - 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-01 18:03 +0000 |
| Message-ID | <dde4cf4961bc821b99d96fc830ad53bd@www.novabbs.org> |
| In reply to | #110877 |
On Sat, 1 Mar 2025 11:58:17 +0000, Anton Ertl wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>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. > > Like other USA-based computer architects, Bell ignores ARM, which > outperformed the VAX without using caches and was much easier to > design. Was ARM around when VAX was being designed (~1973) ?? "The Case for the Reduced Instruction Set Computer" was after 1980 as a point of temporal reference. > As for code size, we see significantly smaller code for RISC > instruction sets with 16/32-bit encodings such as ARM T32/A32 and > RV64GC than for all CISCs, including AMD64, i386, and S390x > <2024Jan4.101941@mips.complang.tuwien.ac.at>. I doubt that VAX fares > so much better in this respect that its code is significantly smaller > than for these CPUs. VAX's advantage was it executed fewer instructions (VAX only executed 65% of the number of instructions R2000 executed.) My 66000 only needs 70% of the instructions RISC-V requires. Thus it is within spitting distance of VAX instruction count while still being almost a RISC architecture. > 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 You would also have to convince the Computer Science department at CMU; Where a lot of VAX ideas were dreamed up based on the success of the PDP-11. > 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. A pipelined machine in 1978 would have had 50% to 100% more circuit boards than VAX 11/780, making it a lot more expensive. > As a result, DEC would have had an architecture that would have given > them superior performance, they would not have suffered from the > infighting of VAX9000 vs. PRISM etc. (and not from the wrong decision > to actually build the VAX9000), and might still be going strong to > this day. They would have been able to extend RV32GC to RV64GC > without problems, and produce superscalar and OoO implementations. The design point you target for the original VAX would have taken significantly longer to design, debug, and ship. > OTOH, DEC had great success with the VAX for a while, and their demise > may have been unavoidable given their market position: Their customers > (especially the business customers of VAXen) went to them instead of > IBM, because they wanted something less costly, and they continued > onwards to PCs running Linux when they provided something less costly. > So DEC would also have needed to outcompete Intel and the PC market to > succeed (and IBM eventually got out of that market). Unclear. > - anton
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-01 20:01 +0000 |
| Message-ID | <vpvp1t$caef$1@dont-email.me> |
| In reply to | #110878 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: > On Sat, 1 Mar 2025 11:58:17 +0000, 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. > > Was ARM around when VAX was being designed (~1973) ?? ARM was designed starting in 1983, if Wikipedia is to be believed. The only ones experimenting (successfully) with RISC at the time the VAX was designed were IBM with the 801, and they were kept from realizing their full potential by IBM's desire to not hurt their /370 business.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-02 09:34 +0000 |
| Message-ID | <2025Mar2.103437@mips.complang.tuwien.ac.at> |
| In reply to | #110878 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Sat, 1 Mar 2025 11:58:17 +0000, Anton Ertl wrote: >> As for code size, we see significantly smaller code for RISC >> instruction sets with 16/32-bit encodings such as ARM T32/A32 and >> RV64GC than for all CISCs, including AMD64, i386, and S390x >> <2024Jan4.101941@mips.complang.tuwien.ac.at>. I doubt that VAX fares >> so much better in this respect that its code is significantly smaller >> than for these CPUs. > >VAX's advantage was it executed fewer instructions (VAX only executed >65% of the number of instructions R2000 executed.) This agrees with my estimate that a CPU with 3 RV32GC MIPS would have the same performance as a CPU with 2 VAX MIPS. >> 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 > >You would also have to convince the Computer Science department at >CMU; Where a lot of VAX ideas were dreamed up based on the success >of the PDP-11. Yes, include that in my magic wand. >A pipelined machine in 1978 would have had 50% to 100% more circuit >boards than VAX 11/780, making it a lot more expensive. What makes you think that a pipelined single-issue RV32GC would take more circuit boards than VAX11/780? I have no data about discrete implementations, but if we look at integrated ones and assume that the number of transistors or the area corresponds to the number of circuit boards in discrete implementations, the evidence goes in the opposite direction: Transistors area proc CPU 125,000 74.82 3um MicroVAX 78032 (integer-only, some instructions missing) 68,000 44 3.5um 68,000 (integer-only, no MMU) 45,000 58.52 2um ROMP (integer-only, no MMU, three pipeline stages) 25,000 50 3um ARM1 (integer-only, no MMU, pipelined) 110,000 ? 1.2um SPARC MB86900 (integer-only, pipelined) 110,000 80 2um MIPS R2000 (integer-only, pipelined) It seems that the MMU cost a lot of transistors, while the pipelining did not, as especially the ARM1 shows. >The design point you target for the original VAX would have taken >significantly longer to design, debug, and ship. What makes you think so? A major selling point of RISC especially compared to the VAX was that the reduced instruction-set complexity reduces the implementation effort. And the fact that the students of Berkeley and Stanford could produce their prototypes in a short time lends credibility to the claim. We also have some timelines we can compare: <https://en.wikipedia.org/wiki/PA-RISC> says: |In early 1982, work on the Precision Architecture began at HP |Laboratories, defining the instruction set and virtual memory |system. Development of the first TTL implementation started in April |1983. With simulation of the processor having completed in 1983, a |final processor design was delivered to software developers in July |1984. Systems prototyping followed, with "lab prototypes" being |produced in 1985 and product prototypes in 1986.[7] | |The first processors were introduced in products during 1986. <https://www.hpmuseum.net/display_item.php?hw=836> writes: |The 3000/930 and 3000/950 were both announced in March of 1986 but did |not ship until the second half of 1987. So here we actually have a discrete implementation of a RISC. You write that VAX work began in 1973; it was introduced in 1977 (but when where machines shipped to customers?), which would mean that development also took 4 years. According to <https://en.wikipedia.org/wiki/VAX-11>, development began in 1976, but that is hard to believe, especially given the CISC-based problems such as having to keep many pages in physical memory at the same time. <https://people.computing.clemson.edu/~mark/330/eagle.html#timeline> says about the Data General Eclipse MV/8000: |spring 1978 - Eagle project starts |summer 1978 - recruiting of Hardy Boys and Microkids ||April 1979 - projected Eagle completion date (missed) |June 1979 - West presents Eagle at Product Board Meeting |mid-1979 - Eagle supporter and VP of Engineering Carl Carmen leaves DG |October 1979 - Gallifrey Eagle moved to software department |November 1979 - Tom West transferred |2H79 and early 1980 - difficulties with PAL supplier; | hardware debugging and software development continue |April 1980 - public announcement of MV/8000 |fall 1980 - Eclipse group reorganized It's not clear when the MV/8000 was delivered to the customers. The same timeline also contains Data General's Plan A (Eagle was Plan B), the more ambitious FHP which makes the writable control store available to third-party software, i.e., it's in a way a further step in the thinking that led to CISC: |July 1975 - FHP project starts |September 1977 - EGO vs. FHP meeting; FHP version promised in a year |early 1979 - news that FHP will miss deadline "by a huge margin" |November 1981 - FHP demo BTW, the existence of writable control stores before the release of the VAX is further counterevidence to the claim that at the time of the VAX, microcode ROM was so much faster and that fast SRAM was not an option: The DEC PDP-10 KL10 (1975) has 80*1280bits (12.5KB) or 80*2K bits (20KB) of WCS, depending on the model, and they were the machines that the VAX-11/780 was going to replace. So not only did RISCs not need cache to perform better than a VAX-11/780, for a machine in the price class of the VAX-11/780 you could also have cache to gain even more speed; the 2KB of the VAX-11/780 itself would help, but bigger caches were possible and could help more. <https://en.wikipedia.org/wiki/I386> says: |Development of i386 technology began in 1982 under the internal name |of P3.[4] The tape-out of the 80386 development was finalized in July |1985.[4] The 80386 was introduced as pre-production samples for |software development workstations in October 1985.[5] Manufacturing |of the chips in significant quantities commenced in June 1986 ... The |first personal computer to make use of the 80386 was the Deskpro 386. The Compaq DeskPro 386 was released on September 9, 1986. But the i386 was a single chip, not a discrete implementation, which may have had an influence on development time. IBM took until July 1987 to introduce their first computer with an i386. - 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 | Robert Swindells <rjs@fdy2.co.uk> |
|---|---|
| Date | 2025-03-02 15:42 +0000 |
| Message-ID | <vq1u9t$r2pe$1@dont-email.me> |
| In reply to | #110895 |
On Sun, 02 Mar 2025 09:34:37 GMT, Anton Ertl wrote: > mitchalsup@aol.com (MitchAlsup1) writes: > >>A pipelined machine in 1978 would have had 50% to 100% more circuit >>boards than VAX 11/780, making it a lot more expensive. > > What makes you think that a pipelined single-issue RV32GC would take > more circuit boards than VAX11/780? I have no data about discrete > implementations, but if we look at integrated ones and assume that the > number of transistors or the area corresponds to the number of circuit > boards in discrete implementations, the evidence goes in the opposite > direction: You could look at the MIT Lisp Machine, it used basically the same chips as a VAX 11/780 but was a pipelined load/store architecture internally.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-02 18:30 +0000 |
| Message-ID | <2025Mar2.193024@mips.complang.tuwien.ac.at> |
| In reply to | #110901 |
Robert Swindells <rjs@fdy2.co.uk> writes: >On Sun, 02 Mar 2025 09:34:37 GMT, Anton Ertl wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: >> >>>A pipelined machine in 1978 would have had 50% to 100% more circuit >>>boards than VAX 11/780, making it a lot more expensive. ... >You could look at the MIT Lisp Machine, it used basically the same chips >as a VAX 11/780 but was a pipelined load/store architecture internally. And what was the effect on the number of circuit boards? What effect did the load/store architecture have, and what effect did the pipelining have? It's been a number of years since I read about Lisp Machines and Symbolics. My impression was that they were both based on CISCy ideas; it's about closing the semantic gap, no? Load/store would surprise me. And when the RISC revolution came, they could not compete. The RISCy way to Lisp implementation was explored in SPUR (and Smalltalk in SOAR) (one of which counts as RISC-III and the other as RISC-IV, I don't remember which), and commercialized in SPARC's instructions with support for tags (not used in the Lisp system that a former comp.arch regular contributed to). - 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 | Robert Swindells <rjs@fdy2.co.uk> |
|---|---|
| Date | 2025-03-05 15:01 +0000 |
| Message-ID | <vq9ovn$2etk9$1@dont-email.me> |
| In reply to | #110902 |
On Sun, 02 Mar 2025 18:30:24 GMT, Anton Ertl wrote: > Robert Swindells <rjs@fdy2.co.uk> writes: >>On Sun, 02 Mar 2025 09:34:37 GMT, Anton Ertl wrote: >> >>> mitchalsup@aol.com (MitchAlsup1) writes: >>> >>>>A pipelined machine in 1978 would have had 50% to 100% more circuit >>>>boards than VAX 11/780, making it a lot more expensive. > ... >>You could look at the MIT Lisp Machine, it used basically the same chips >>as a VAX 11/780 but was a pipelined load/store architecture internally. > > And what was the effect on the number of circuit boards? What effect > did the load/store architecture have, and what effect did the pipelining > have? > > It's been a number of years since I read about Lisp Machines and > Symbolics. My impression was that they were both based on CISCy ideas; > it's about closing the semantic gap, no? Load/store would surprise me. I don't know the internal architecture of Symbolics machines well enough to comment on it, only the MIT/LMI/TI ones. The MIT Lisp Machine was described as microcoded but this is more like a simple RTOS combined with an interpreter for the 16-bit instructions of the higher level emulated stack machine. The "micro" instruction set is three address, load/store, even has delay slots. There are a lot of registers so the instruction word is wide at 56 bits, there is 16kw of SRAM to hold this code. Code written in this looks like typical RISC assembler to me, I have added TFTP support to it, there was also an option to compile Lisp down to the real instruction set. Built using a 74181+74182 ALU with other 74 series logic same as a VAX 11/780. The pipeline is two instructions deep. The design documentation is available online, someone could go through that to get the exact number of boards used. The purchase price was lower than a VAX though, even with a high-resolution display. > And when the RISC revolution came, they could not compete. The RISCy > way to Lisp implementation was explored in SPUR (and Smalltalk in SOAR) > (one of which counts as RISC-III and the other as RISC-IV, I don't > remember which), and commercialized in SPARC's instructions with support > for tags (not used in the Lisp system that a former comp.arch regular > contributed to). SOAR was before SPUR. The tags support on SPARC(32) only helps in Lisp for integer operations inline, like using a number as an array offset. The same word layout of using the "free" lower bits for tags when you know that objects are aligned to larger boundaries is still used in most Lisp systems today, just without any hardware support, you need to generate instructions to shift down an integer value before using it.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-06 00:24 +0000 |
| Message-ID | <vqapvp$2lg6a$2@dont-email.me> |
| In reply to | #110968 |
On Wed, 5 Mar 2025 15:01:11 -0000 (UTC), Robert Swindells wrote: > The same word layout of using the "free" lower bits for tags when > you know that objects are aligned to larger boundaries is still used > in most Lisp systems today, just without any hardware support, you > need to generate instructions to shift down an integer value before > using it. *Lightbulb moment* How much would it cost in hardware to add support for ignoring some bottommost N bits (N fixed? configurable?) for most accesses? This ties in with my idea that it would have been useful to reserve the bottom 3 bits for a bit offset, albeit ignored (or even MBZ) by normal load/store instructions.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-06 01:01 +0000 |
| Message-ID | <5bd5128615b4b17e14377b58b8f42a6b@www.novabbs.org> |
| In reply to | #110974 |
On Thu, 6 Mar 2025 0:24:25 +0000, Lawrence D'Oliveiro wrote: > On Wed, 5 Mar 2025 15:01:11 -0000 (UTC), Robert Swindells wrote: > >> The same word layout of using the "free" lower bits for tags when >> you know that objects are aligned to larger boundaries is still used >> in most Lisp systems today, just without any hardware support, you >> need to generate instructions to shift down an integer value before >> using it. > > *Lightbulb moment* > > How much would it cost in hardware to add support for ignoring some > bottommost N bits (N fixed? configurable?) for most accesses? The gates used to query and control whether that functionality is present or absent will be 50× larger than the gates to ignore any misalignment. > This ties in with my idea that it would have been useful to reserve the > bottom 3 bits for a bit offset, albeit ignored (or even MBZ) by normal > load/store instructions.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-03-02 09:03 -1000 |
| Message-ID | <87wmd7dzl2.fsf@localhost> |
| In reply to | #110901 |
Robert Swindells <rjs@fdy2.co.uk> writes:
> You could look at the MIT Lisp Machine, it used basically the same chips
> as a VAX 11/780 but was a pipelined load/store architecture internally.
from long ago and far away:
Date: 79/07/11 11:00:03
To: wheeler
i heard a funny story: seems the MIT LISP machine people proposed that
IBM furnish them with an 801 to be the engine for their prototype.
B.O. Evans considered their request, and turned them down.. offered them
an 8100 instead! (I hope they told him properly what they thought of
that)
... snip ...
... trivia: Evans had asked my wife to review/audit 8100 (had really
slow, anemic processor) and shortly later it was canceled
("decomitted").
--
virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-02 13:51 -0500 |
| Message-ID | <GN1xP.50850$SZca.2573@fx13.iad> |
| In reply to | #110895 |
Anton Ertl wrote: > mitchalsup@aol.com (MitchAlsup1) writes: > >> A pipelined machine in 1978 would have had 50% to 100% more circuit >> boards than VAX 11/780, making it a lot more expensive. > > What makes you think that a pipelined single-issue RV32GC would take > more circuit boards than VAX11/780? I have no data about discrete > implementations, but if we look at integrated ones and assume that the > number of transistors or the area corresponds to the number of circuit > boards in discrete implementations, the evidence goes in the opposite > direction: The first article in this Mar-1987 HP Journal is about the HP 9000 MODEL 840 and HP 3000 Series 930 implementing the HP PA ISA. The cpu is 5 boards, 6 with FPU, built with standard and FAST TTL. Implementation started in Apr-1983, prototype ready early 1984. "[3 stage] pipeline fetches and executes an instruction every 125 ns, a 4096-entry translation lookaside buffer (TLB) for high-speed address translation, and 128K bytes of cache memory." "The measured MIPS rate for the Model 840 varies from about 3.5 to 8 MIPS with an average of 4.5 to 5." which at 125 ns, 8 MHz clock is an IPC of 0.43 to 1.0, avg 0.625. https://archive.org/download/Hewlett-Packard_Journal_Vol._38_No._3_1987-03_Hewlett-Packard/Hewlett-Packard_Journal_Vol._38_No._3_1987-03_Hewlett-Packard.pdf
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-03 18:05 +0000 |
| Message-ID | <2025Mar3.190527@mips.complang.tuwien.ac.at> |
| In reply to | #110903 |
EricP <ThatWouldBeTelling@thevillage.com> writes: >Anton Ertl wrote: >> mitchalsup@aol.com (MitchAlsup1) writes: >> >>> A pipelined machine in 1978 would have had 50% to 100% more circuit >>> boards than VAX 11/780, making it a lot more expensive. >> >> What makes you think that a pipelined single-issue RV32GC would take >> more circuit boards than VAX11/780? I have no data about discrete >> implementations, but if we look at integrated ones and assume that the >> number of transistors or the area corresponds to the number of circuit >> boards in discrete implementations, the evidence goes in the opposite >> direction: > >The first article in this Mar-1987 HP Journal is about the >HP 9000 MODEL 840 and HP 3000 Series 930 implementing the HP PA ISA. >The cpu is 5 boards, 6 with FPU, built with standard and FAST TTL. >Implementation started in Apr-1983, prototype ready early 1984. <https://people.csail.mit.edu/emer/media/papers/1999.06.retrospective.vax.pdf> says: |the VAX 11/780 CPU spanned about 20 boards. Have TTL chips advanced between the VAX and the first HP-PA implementation? I don't think so. Are the boards of a different size? If the answers to both questions are "no", this would be counterevidence to Mitch Alsup's claim. >"[3 stage] pipeline fetches and executes an instruction every 125 ns, >a 4096-entry translation lookaside buffer (TLB) for high-speed address >translation, and 128K bytes of cache memory." > >"The measured MIPS rate for the Model 840 varies from >about 3.5 to 8 MIPS with an average of 4.5 to 5." > >which at 125 ns, 8 MHz clock is an IPC of 0.43 to 1.0, avg 0.625. It's interesting that this HP machine needed a cache at 8MHz, while the contemporary ARM2 could run from DRAM at the same speed. But then, the HP machine supports bigger memories, and includes an MMU, both of which slow things down. >https://archive.org/download/Hewlett-Packard_Journal_Vol._38_No._3_1987-03_Hewlett-Packard/Hewlett-Packard_Journal_Vol._38_No._3_1987-03_Hewlett-Packard.pdf - 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 | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-03 19:24 +0000 |
| Message-ID | <vq4vlh$1eqlm$1@dont-email.me> |
| In reply to | #110939 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > Have TTL chips advanced between the VAX and the first HP-PA > implementation? I don't think so. Oh yes, they did; there were nine years between the launch of the VAX and the launch of HP-PA. According to https://www.openpa.net/pa-risc_processor_pa-early.html#ts-1 the first HP-PA CPU was introduced in 1986, and you can see pictures at https://computermuseum.informatik.uni-stuttgart.de/dev_en/hp9000_840/ For example, you could buy state machines programmable by FPGA in 1986, which was not available in 1977. (No idea if HP used them or not).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-03 20:04 +0000 |
| Message-ID | <rXnxP.4433$8rz3.3059@fx37.iad> |
| In reply to | #110940 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > >> Have TTL chips advanced between the VAX and the first HP-PA >> implementation? I don't think so. > >Oh yes, they did; there were nine years between the launch of the >VAX and the launch of HP-PA. > >According to https://www.openpa.net/pa-risc_processor_pa-early.html#ts-1 >the first HP-PA CPU was introduced in 1986, and you can see pictures >at https://computermuseum.informatik.uni-stuttgart.de/dev_en/hp9000_840/ > > >For example, you could buy state machines programmable by FPGA in 1986, >which was not available in 1977. (No idea if HP used them or not). I don't believe that HP used FPGAs for the first PA/HP3000 processor; the hp journal article posted earlier says that they were standard TTL SSI logic chips (which allowed them to build several hundred prototypes to use for software development). The VAX-11 design _shipped_ in 1978, so the logic family used was selected several years prior. We were designing a new mainframe using ECL gate-arrays in 1986.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-03 22:41 +0000 |
| Message-ID | <2025Mar3.234146@mips.complang.tuwien.ac.at> |
| In reply to | #110940 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > >> Have TTL chips advanced between the VAX and the first HP-PA >> implementation? I don't think so. > >Oh yes, they did; there were nine years between the launch of the >VAX and the launch of HP-PA. So what? >and you can see pictures >at https://computermuseum.informatik.uni-stuttgart.de/dev_en/hp9000_840/ Nice! The pictures are pretty good. I can read the markings on the chip. The first chip I looked at was marked 74AS181. TI introduced the 74xx series of TTL chips starting in 1964, and when I read TTL, I expected to see 74xx chips. The 74181 was introduced in February 1970, and I expected it to be in the HP-PA CPU, as well as in the VAX 11/780. <https://en.wikipedia.org/wiki/74181> confirms my expectation for the VAX, and the photo confirms my expectation for the first HP-PA CPU. The AS family was only introduced in 1980, so there was some advances between the VAX and this HP-PA CPU indeed. However, as far as the number of boards is concerned, a 74AS181 takes as much space as a plain 74181, so that difference is irrelevant for that aspect. I leave it to you to point out a chip on the HP-PA CPU that did not have a same-sized variant avalable in, say, 1975. - 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 | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-05 18:08 +0000 |
| Message-ID | <vqa3u1$2hamd$1@dont-email.me> |
| In reply to | #110944 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > Thomas Koenig <tkoenig@netcologne.de> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >> >>> Have TTL chips advanced between the VAX and the first HP-PA >>> implementation? I don't think so. >> >>Oh yes, they did; there were nine years between the launch of the >>VAX and the launch of HP-PA. > > So what? > >>and you can see pictures >>at https://computermuseum.informatik.uni-stuttgart.de/dev_en/hp9000_840/ > > Nice! The pictures are pretty good. I can read the markings on the > chip. The first chip I looked at was marked 74AS181. TI introduced > the 74xx series of TTL chips starting in 1964, and when I read TTL, I > expected to see 74xx chips. The 74181 was introduced in February > 1970, and I expected it to be in the HP-PA CPU, as well as in the VAX > 11/780. <https://en.wikipedia.org/wiki/74181> confirms my expectation > for the VAX, and the photo confirms my expectation for the first HP-PA > CPU. > > The AS family was only introduced in 1980, so there was some advances > between the VAX and this HP-PA CPU indeed. However, as far as the > number of boards is concerned, a 74AS181 takes as much space as a > plain 74181, so that difference is irrelevant for that aspect. > > I leave it to you to point out a chip on the HP-PA CPU that did not > have a same-sized variant avalable in, say, 1975. What I found intruiging are the chips that have numbers on paper on them, like 09740-81710. That chip has a MMI logo still sticking out. This is the logo of Monolithic Memories, Inc. which developed the PAL chips of "Soul of a New Machine" and Eclipse MV 8000 fame. At https://en.wikipedia.org/wiki/Programmable_Array_Logic you can see the logo of the company. PALs were not available for the VAX development, and they certainly made implemting logic far less cumbersome, and they took up far less space than their equivalent in logic gates (again, as described in "The Soul of a New Machine", where Tom West gambled the development on MMI getting its act togetther). Given a (very rough) estimate that each PAL replaced four standard logic chips of simlar size, my guess would be that it saved them toe equivalent of two to three circuit boards, not bad. Another striking thing is how densely the circuit boards are packed, compared to the VAX boards one finds. I suspect they had access to more layers of printed circuit board than DEC ten years earlier.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-05 19:04 -0500 |
| Message-ID | <hE5yP.151667$BrX.27518@fx12.iad> |
| In reply to | #110969 |
Thomas Koenig wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >> Thomas Koenig <tkoenig@netcologne.de> writes: >>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >>> >>>> Have TTL chips advanced between the VAX and the first HP-PA >>>> implementation? I don't think so. >>> Oh yes, they did; there were nine years between the launch of the >>> VAX and the launch of HP-PA. >> So what? >> >>> and you can see pictures >>> at https://computermuseum.informatik.uni-stuttgart.de/dev_en/hp9000_840/ >> Nice! The pictures are pretty good. I can read the markings on the >> chip. The first chip I looked at was marked 74AS181. TI introduced >> the 74xx series of TTL chips starting in 1964, and when I read TTL, I >> expected to see 74xx chips. The 74181 was introduced in February >> 1970, and I expected it to be in the HP-PA CPU, as well as in the VAX >> 11/780. <https://en.wikipedia.org/wiki/74181> confirms my expectation >> for the VAX, and the photo confirms my expectation for the first HP-PA >> CPU. >> >> The AS family was only introduced in 1980, so there was some advances >> between the VAX and this HP-PA CPU indeed. However, as far as the >> number of boards is concerned, a 74AS181 takes as much space as a >> plain 74181, so that difference is irrelevant for that aspect. >> >> I leave it to you to point out a chip on the HP-PA CPU that did not >> have a same-sized variant avalable in, say, 1975. > > What I found intruiging are the chips that have numbers on paper > on them, like 09740-81710. That chip has a MMI logo still sticking > out. This is the logo of Monolithic Memories, Inc. which developed > the PAL chips of "Soul of a New Machine" and Eclipse MV 8000 fame. > At https://en.wikipedia.org/wiki/Programmable_Array_Logic you can > see the logo of the company. > > PALs were not available for the VAX development, and they certainly > made implemting logic far less cumbersome, and they took up far less > space than their equivalent in logic gates (again, as described in > "The Soul of a New Machine", where Tom West gambled the development > on MMI getting its act togetther). > > Given a (very rough) estimate that each PAL replaced four standard > logic chips of simlar size, my guess would be that it saved > them toe equivalent of two to three circuit boards, not bad. > > Another striking thing is how densely the circuit boards are packed, > compared to the VAX boards one finds. I suspect they had access > to more layers of printed circuit board than DEC ten years earlier. MMI's PAL Programmable Array Logic is a subset of a Programmable Logic Array. PAL has programmable AND matrix but a fixed OR matrix. PLA has both AND and OR matrix programmable. Mask programmed PLA's were available since 1970, and field programmable FPLA's available in 1976 from a number of suppliers (e.g. Signetics). https://en.wikipedia.org/wiki/Programmable_logic_array If one was building a RISC style ISA cpu in 1975 they could be used for decoding and state machines for fetch, load/store, page table walker. I don't know the price.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-06 06:53 +0000 |
| Message-ID | <vqbgp3$2s8lp$1@dont-email.me> |
| In reply to | #110973 |
EricP <ThatWouldBeTelling@thevillage.com> schrieb: >> Given a (very rough) estimate that each PAL replaced four standard >> logic chips of simlar size, my guess would be that it saved >> them toe equivalent of two to three circuit boards, not bad. >> >> Another striking thing is how densely the circuit boards are packed, >> compared to the VAX boards one finds. I suspect they had access >> to more layers of printed circuit board than DEC ten years earlier. > > MMI's PAL Programmable Array Logic is a subset of a Programmable Logic Array. > PAL has programmable AND matrix but a fixed OR matrix. > PLA has both AND and OR matrix programmable. > > Mask programmed PLA's were available since 1970, and field programmable > FPLA's available in 1976 from a number of suppliers (e.g. Signetics). > https://en.wikipedia.org/wiki/Programmable_logic_array I read somewhere that these were not used much because, in the beginning, they were slow, big, expensive and difficult to program. This is probably why they were not considered as a replacement for the PAL chips for the MV/8000, had MMI failed - they were not up to the job. > If one was building a RISC style ISA cpu in 1975 they could be used > for decoding and state machines for fetch, load/store, page table walker. > I don't know the price. They could have been used for the same things on the VAX 11/780. Does anybody know if they were?
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-07 14:26 -0500 |
| Message-ID | <BMHyP.418532$2zn8.34844@fx15.iad> |
| In reply to | #110978 |
Thomas Koenig wrote: > EricP <ThatWouldBeTelling@thevillage.com> schrieb: > >>> Given a (very rough) estimate that each PAL replaced four standard >>> logic chips of simlar size, my guess would be that it saved >>> them toe equivalent of two to three circuit boards, not bad. >>> >>> Another striking thing is how densely the circuit boards are packed, >>> compared to the VAX boards one finds. I suspect they had access >>> to more layers of printed circuit board than DEC ten years earlier. >> MMI's PAL Programmable Array Logic is a subset of a Programmable Logic Array. >> PAL has programmable AND matrix but a fixed OR matrix. >> PLA has both AND and OR matrix programmable. >> >> Mask programmed PLA's were available since 1970, and field programmable >> FPLA's available in 1976 from a number of suppliers (e.g. Signetics). >> https://en.wikipedia.org/wiki/Programmable_logic_array > > I read somewhere that these were not used much because, in the > beginning, they were slow, big, expensive and difficult to program. Looking at the Signetics 82S100 in 1976 has max access of 50 ns, 600 mw in a 28 pins dip. That seems like a lot but I looked up what it would take if you built the same out of discrete 2-input NOR and and 8-input NAND and its basically about the same delay but a lot more parts and board space. > This is probably why they were not considered as a replacement for > the PAL chips for the MV/8000, had MMI failed - they were not up > to the job. > >> If one was building a RISC style ISA cpu in 1975 they could be used >> for decoding and state machines for fetch, load/store, page table walker. >> I don't know the price. > > They could have been used for the same things on the VAX 11/780. Does > anybody know if they were? PLA's are useful when you have don't care bits or have different bit-wise layout formats to parse, exactly like RISC ISA's do. VAX opcode was 1 or two whole bytes so PLA would have been a waste. The operand specifier did have a varying format but was simple so was decoded with discrete logic. The VAX 780 decoder used 2k * 12 ROM's to look up the starting uAddress. I haven't checked if it actually did this but a microsequencer might execute a multiway microsubroutine call by jamming that ROM output into the low address bits of the next address field while pushing the return uAddr on a hardware stack. If anyone is interested the VAX 780 hardware designs are available but you have to know how to read TTL and have old hardware manuals to look up part numbers. CPU Assembly http://www.bitsavers.org/pdf/dec/vax/780/MP00496_KA780_197911.pdf Data Path Description http://www.bitsavers.org/pdf/dec/vax/780/AA-H307-TE_VAX-11_780_Data_Path_Description_197902.pdf
[toc] | [prev] | [next] | [standalone]
Page 1 of 17 [1] 2 3 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web