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 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-08 10:52 +0000 |
| Message-ID | <2025Mar8.115236@mips.complang.tuwien.ac.at> |
| In reply to | #110992 |
EricP <ThatWouldBeTelling@thevillage.com> writes: >Looking at the Signetics 82S100 in 1976 has max access of 50 ns, 600 mw >in a 28 pins dip. The Commodore 64 used a 82S100 or compatible for various purposes, especially for producing various chip select and RAM control signals from the addresses produced by the CPU or the VIC (graphics chip). Thomas Giesel wrote a very detailed report <http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf> on the original PLAs and their behaviour, in order to replace it (apparently it's a chip that was failure-prone). He reports that the 82S100 generates the #CASRAM signal with a propagation delay of 35ns in one direction and 25ns in the other, and the #ROMH signal with a propagation delay of 25ns in both directions (table 3.4). I guess that the 50ns are the worst case of anything you can do with the 82S100. He reports a current consumption of 102mA for the 82S100 (table 3.3), which at 5V (the regular voltage at the time) is pretty close to the 600mW given in the data sheet. The rest of the board, including several chips with much more logic (CPU, VIC, SID (sound), 2xCIA (I/O)) , consumed at most 770mA in his measurements; most of the rest was NMOS, while the 82S100 was TTL. - 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 | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-08 13:03 -0500 |
| Message-ID | <aF%yP.23612$5e_1.5671@fx33.iad> |
| In reply to | #111013 |
Anton Ertl wrote: > EricP <ThatWouldBeTelling@thevillage.com> writes: >> Looking at the Signetics 82S100 in 1976 has max access of 50 ns, 600 mw >> in a 28 pins dip. > > The Commodore 64 used a 82S100 or compatible for various purposes, > especially for producing various chip select and RAM control signals > from the addresses produced by the CPU or the VIC (graphics chip). > Thomas Giesel wrote a very detailed report > <http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf> on > the original PLAs and their behaviour, in order to replace it > (apparently it's a chip that was failure-prone). It looks like the C64's circuit design was one culprit. Though I do remember back then hearing about failures over time with other fuse programmable devices like PROMs. Something about the sputter from the blown fuses. > He reports that the 82S100 generates the #CASRAM signal with a > propagation delay of 35ns in one direction and 25ns in the other, and > the #ROMH signal with a propagation delay of 25ns in both directions > (table 3.4). I guess that the 50ns are the worst case of anything you > can do with the 82S100. Yes, and it sounds like the circuit design depends on a race condition between two logic paths to work. Big no-no. > He reports a current consumption of 102mA for the 82S100 (table 3.3), > which at 5V (the regular voltage at the time) is pretty close to the > 600mW given in the data sheet. The rest of the board, including > several chips with much more logic (CPU, VIC, SID (sound), 2xCIA > (I/O)) , consumed at most 770mA in his measurements; most of the rest > was NMOS, while the 82S100 was TTL. > > - anton This is not a problem with the 82S100. Whoever designed that circuit didn't know what they were doing. One can't use any combinatorial logic circuit and expect exact timing. The manufacturer specs indicate a range of speeds which depend on things like variations in power supply voltage, load, temperature. In the case of the 82S100 it is 35 ns typical, 50 ns max. Also these are logic chains, so each gate adds its own variations. The circuit should be designed so it works across all timing variations which is what synchronization clocks and flip flops are for. And even then flip flops have their own timing variations.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-08 19:42 +0000 |
| Message-ID | <2774d61ff6ae87a5da08e0b0174bdf22@www.novabbs.org> |
| In reply to | #111018 |
On Sat, 8 Mar 2025 18:03:38 +0000, EricP wrote: > Anton Ertl wrote: >> EricP <ThatWouldBeTelling@thevillage.com> writes: >>> Looking at the Signetics 82S100 in 1976 has max access of 50 ns, 600 mw >>> in a 28 pins dip. >> >> The Commodore 64 used a 82S100 or compatible for various purposes, >> especially for producing various chip select and RAM control signals >> from the addresses produced by the CPU or the VIC (graphics chip). >> Thomas Giesel wrote a very detailed report >> <http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf> on >> the original PLAs and their behaviour, in order to replace it >> (apparently it's a chip that was failure-prone). > > It looks like the C64's circuit design was one culprit. > Though I do remember back then hearing about failures over time with > other fuse programmable devices like PROMs. > Something about the sputter from the blown fuses. A laser blasts a short wire so that there is no longer any connection. Then, in use, the electrical forces cause the still present aluminum wires to reconstruct themselves making contact and changing the state. The blowable wire is still immersed within an oxide layer, preventing the blown aluminum atoms from "really going anywhere" allowing small forces to reassemble the wire. >> He reports that the 82S100 generates the #CASRAM signal with a >> propagation delay of 35ns in one direction and 25ns in the other, and >> the #ROMH signal with a propagation delay of 25ns in both directions >> (table 3.4). I guess that the 50ns are the worst case of anything you >> can do with the 82S100. > > Yes, and it sounds like the circuit design depends on a race condition > between two logic paths to work. Big no-no. In general, all signals that interact with the data path, must be clocked and driven from the same edge of the data path. But even here, designers must be careful to load each select line evenly so that the line driving operand 1 forwarding has the same "cross data path" delay as the line driving every other data path select line. >> He reports a current consumption of 102mA for the 82S100 (table 3.3), >> which at 5V (the regular voltage at the time) is pretty close to the >> 600mW given in the data sheet. The rest of the board, including >> several chips with much more logic (CPU, VIC, SID (sound), 2xCIA >> (I/O)) , consumed at most 770mA in his measurements; most of the rest >> was NMOS, while the 82S100 was TTL. >> >> - anton > > This is not a problem with the 82S100. > Whoever designed that circuit didn't know what they were doing. > One can't use any combinatorial logic circuit and expect exact timing. > The manufacturer specs indicate a range of speeds which depend on > things like variations in power supply voltage, load, temperature. > In the case of the 82S100 it is 35 ns typical, 50 ns max. > Also these are logic chains, so each gate adds its own variations. > > The circuit should be designed so it works across all timing variations > which is what synchronization clocks and flip flops are for. > And even then flip flops have their own timing variations.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-09 10:13 -0400 |
| Message-ID | <XnhzP.150979$sbY2.134097@fx40.iad> |
| In reply to | #111019 |
MitchAlsup1 wrote: > On Sat, 8 Mar 2025 18:03:38 +0000, EricP wrote: > >> Anton Ertl wrote: >>> EricP <ThatWouldBeTelling@thevillage.com> writes: >>>> Looking at the Signetics 82S100 in 1976 has max access of 50 ns, 600 mw >>>> in a 28 pins dip. >>> >>> The Commodore 64 used a 82S100 or compatible for various purposes, >>> especially for producing various chip select and RAM control signals >>> from the addresses produced by the CPU or the VIC (graphics chip). >>> Thomas Giesel wrote a very detailed report >>> <http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf> on >>> the original PLAs and their behaviour, in order to replace it >>> (apparently it's a chip that was failure-prone). >> >> It looks like the C64's circuit design was one culprit. >> Though I do remember back then hearing about failures over time with >> other fuse programmable devices like PROMs. >> Something about the sputter from the blown fuses. > > A laser blasts a short wire so that there is no longer any connection. > Then, in use, the electrical forces cause the still present aluminum > wires to reconstruct themselves making contact and changing the state. > > The blowable wire is still immersed within an oxide layer, preventing > the blown aluminum atoms from "really going anywhere" allowing small > forces to reassemble the wire. I'm referring to the electrically programmable bipolar PROMs. The 1977 TI Bipolar Memory manual says theirs had titanium-tungsten fuses. These were programmed with a 10.5V pulse up to 750 mA for 1 us to 1 ms. This would create a metallic vapor cloud around the cell inside the chip. I can envision that perhaps over time the electric field on the cell might attract the debris to grow into dendrites that eventually short the cell and turn a 0 to 1. As these could only be programmed once and cost a bundle, they were soon replaced by ultraviolet light erasable EPROMs.
[toc] | [prev] | [next] | [standalone]
| From | Torbjorn Lindgren <tl@none.invalid> |
|---|---|
| Date | 2025-03-09 01:27 +0000 |
| Message-ID | <vqiqpn$d34q$1@dont-email.me> |
| In reply to | #111013 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >EricP <ThatWouldBeTelling@thevillage.com> writes: >>Looking at the Signetics 82S100 in 1976 has max access of 50 ns, 600 mw >>in a 28 pins dip. > >The Commodore 64 used a 82S100 or compatible for various purposes, >especially for producing various chip select and RAM control signals >from the addresses produced by the CPU or the VIC (graphics chip). >Thomas Giesel wrote a very detailed report ><http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf> on >the original PLAs and their behaviour, in order to replace it >(apparently it's a chip that was failure-prone). AFAIK the Signetics 82S100 isn't failure-prone in C64, the MOS Technology (IE Commodore) *clone* that they switched to due to cost reasons IS known to be failure prone. Those are the reason there's lots of PLA replacement projects. If you have any actual Signetics device in a C64 it'll very likely fine unless the power supply failed and fed everything too high voltages which is unfortunately a common failure mode on the C64 power brick. This PSU failure usually destroys most or all of the memory chips, the SID and one or more likely multiple of CPU, PLA and ROMs. Other things with known high failure rates are the MOS Technology 74xx clones and the MT memory. These failure also include MT branded memory chips of that specific type when used in non-Commodore items like PC clones so it's not just C64. Notice the common factor here - MT/Commodore was making a lot of "working but only barely" chips and Commodore used them internally to save money and also sold them to others which used them because, well, they were frequently the cheapest.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-09 01:46 +0000 |
| Message-ID | <722ff46f0aeaa4875d589fdc68750e08@www.novabbs.org> |
| In reply to | #111026 |
On Sun, 9 Mar 2025 1:27:19 +0000, Torbjorn Lindgren wrote: > > Notice the common factor here - MT/Commodore was making a lot of > "working but only barely" chips and Commodore used them internally to > save money and also sold them to others which used them because, well, > they were frequently the cheapest. Radio Shack TRS-80 would buy every Z80 that did not make 2MHz operating frequency. They used something around 1.87 MHz so the CPU clock and the TV clock were the same clock.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-09 07:02 +0000 |
| Message-ID | <vqjede$k5sa$1@dont-email.me> |
| In reply to | #111027 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: > On Sun, 9 Mar 2025 1:27:19 +0000, Torbjorn Lindgren wrote: > >> >> Notice the common factor here - MT/Commodore was making a lot of >> "working but only barely" chips and Commodore used them internally to >> save money and also sold them to others which used them because, well, >> they were frequently the cheapest. > > Radio Shack TRS-80 would buy every Z80 that did not make 2MHz > operating frequency. They used something around 1.87 MHz so the > CPU clock and the TV clock were the same clock. RaptorCS buys POWER 9 chips where a higher number of cores failed than permitted by IBM's specs, and then sells them as systems with a lower working number of cores. The main disadvantages are a) price and b) they are stuck with POWER 9 (due to the binary driver blob on Power 10, among other things).
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-09 10:15 -0400 |
| Message-ID | <XnhzP.150980$sbY2.28337@fx40.iad> |
| In reply to | #111026 |
Torbjorn Lindgren wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> EricP <ThatWouldBeTelling@thevillage.com> writes: >>> Looking at the Signetics 82S100 in 1976 has max access of 50 ns, 600 mw >>> in a 28 pins dip. >> The Commodore 64 used a 82S100 or compatible for various purposes, >> especially for producing various chip select and RAM control signals >>from the addresses produced by the CPU or the VIC (graphics chip). >> Thomas Giesel wrote a very detailed report >> <http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf> on >> the original PLAs and their behaviour, in order to replace it >> (apparently it's a chip that was failure-prone). > > AFAIK the Signetics 82S100 isn't failure-prone in C64, the MOS > Technology (IE Commodore) *clone* that they switched to due to cost > reasons IS known to be failure prone. Those are the reason there's > lots of PLA replacement projects. C64 could just as easily have failed if Signetics had rev'd the chip design to improve the yield. All the 82S100 spec says is that if any input changes then all the outputs will have settled after 50 ns. It makes no statement about the relative order that outputs will change for different input combinations. As it is NORMAL for many outputs of combinatorial circuits to glitch when changing state, it is wrong to depend on them not doing so. This is independent of failures of the MT clone which also could be true. > If you have any actual Signetics device in a C64 it'll very likely > fine unless the power supply failed and fed everything too high > voltages which is unfortunately a common failure mode on the C64 power > brick. This PSU failure usually destroys most or all of the memory > chips, the SID and one or more likely multiple of CPU, PLA and ROMs. Affordable switching power supplies were relatively new back then. IIRC there were two designs, the expensive one that used a transformer and failed safe to ground, and the cheap one that failed to line voltage. > Other things with known high failure rates are the MOS Technology 74xx > clones and the MT memory. These failure also include MT branded memory > chips of that specific type when used in non-Commodore items like PC > clones so it's not just C64. > > Notice the common factor here - MT/Commodore was making a lot of > "working but only barely" chips and Commodore used them internally to > save money and also sold them to others which used them because, well, > they were frequently the cheapest.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-03 20:12 -0500 |
| Message-ID | <1tsxP.151019$t84d.148731@fx11.iad> |
| In reply to | #110939 |
Anton Ertl wrote: > 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 ARM1 was launched 1985, ARM2 in 1986. I found an ARM2 manual and the short answer is that the chip drives the RAS and CAS signals to the dram directly. The chip's clock is adjustable from 100 kHz to 10 MHz and you match the cpu clock to your dram timing. There is no READY line on the memory bus. It does have one interesting feature that if the current address is sequential to the prior one it skips the RAS cycle. I looks like it takes 1 cycle to do a read but their timing diagrams are total crap. There are only two and they contradict each other. It looks like the RAS signal is changing state on 1/4 cycle for no reason. The Motorola Memory Book from 1979 shows MCM4027A 4kb*1 drams with 80 to 165 ns CAS access, 120 to 250 RAS access, 320 to 375 R/W cycle. Similar numbers for MCM4116A 16kb*1 R/W cycle of 500 ns. VAX probably used 4kb 500 ns drams.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-04 10:09 +0000 |
| Message-ID | <2025Mar4.110909@mips.complang.tuwien.ac.at> |
| In reply to | #110949 |
EricP <ThatWouldBeTelling@thevillage.com> writes: >I found an ARM2 manual and the short answer is that the chip >drives the RAS and CAS signals to the dram directly. >The chip's clock is adjustable from 100 kHz to 10 MHz >and you match the cpu clock to your dram timing. >There is no READY line on the memory bus. > >It does have one interesting feature that if the current address >is sequential to the prior one it skips the RAS cycle. Yes, my memory is returning: someone explained here a while ago that this allowed fast execution: Instructions are executed sequentially, so as long as the row does not change, ARM get the instructions quickly out of the DRAM. Every data access incurs a RAS cycle, so the architects added load/store-multiple in order to benefit from this sequential-access optimization also for block copies and for register spill and refill around calls. Maybe switch from RV32GC to ARM T32 for my better-VAX time-travel project:-) Might also help with the condition codes. >The Motorola Memory Book from 1979 shows MCM4027A 4kb*1 drams with >80 to 165 ns CAS access, 120 to 250 RAS access, 320 to 375 R/W cycle. >Similar numbers for MCM4116A 16kb*1 R/W cycle of 500 ns. > >VAX probably used 4kb 500 ns drams. But with the sequential-access optimization, 250ns cycles should be possible (with waiting on changing rows). - 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:26 +0000 |
| Message-ID | <443e8f6f3af6cfbd1c2d765fe970b791@www.novabbs.org> |
| In reply to | #110895 |
On Sun, 2 Mar 2025 9:34:37 +0000, Anton Ertl wrote:
> 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?
a) 68000, 010, 020 were latch based implementations using cross coupled
sense amps as the flop-part of the latch.
b) 88110 was a non-overlapping clock dual latch design.
~2/3rds of 68000 transistor count was in the 2 levels of ROM (it was
both microcoded and nano-coded.)
So, comparing the area of the 88100 integer unit to the 68020 integer
unit, and certain making adjustments, the pipeline integer unit took
a lot more area in the latching of operands and results.
Where 68020 would read an operand, run it though integer calculation
and write it back to the still asserted register select line, with
only staging (delay) latches in the loop. Now, the loop took 2
cycles, but an R2000 it took 4 (Decode, EX, Cache, writeback).
There are a lot more flip-flops in the pipelined path that in the
"use latches to create optimal delay" unpipelined path.
> 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)
huge portion of the transistor count was ROM
> 68,000 44 3.5um 68,000 (integer-only, no MMU)
2/3rds of the transistor count in ROM
So, here we are only using ~20K transistors for {address, data, pc, and
pins}. Now revisit your comparisons.
> 45,000 58.52 2um ROMP (integer-only, no MMU, three pipeline stages)
Twice the 68K data path transistor count.
> 25,000 50 3um ARM1 (integer-only, no MMU, pipelined)
This gives some credence that is can be done
> 110,000 ? 1.2um SPARC MB86900 (integer-only, pipelined)
> 110,000 80 2um MIPS R2000 (integer-only, pipelined)
These two counteract that credence, with 40K of those transistors
found in the windowed register file.
>
> 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.
Reduces the effort is you have a RISC ISA, it does not reduce the
effort as much if you have a VAX ISA with al of its decoding "stuff".
> And the fact that the students of
> Berkeley and Stanford could produce their prototypes in a short time
> lends credibility to the claim.
Student projects run in quanta of semesters, often building on the
work of the previous students in the previous semesters, guided
by professors with an overall direction moving forward. This is not
different than the VAX prototype designs at CMU.
But academic efforts do not result in industrial quality products.
So, the time lines in academia are fundamentally different than in
industry.
<snip>
>
> 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.
I remember walking by the 12 person conference room in the CS
part of CMU in 1973 and listening to the participants discuss
making a bigger-better PDP-11. The topics was quite advanced
at that moment, but I can vouch for the '73 date. I had been
using PDP-11 ISA for 6-months at that point and was significantly
impressed with it, more so that PDP-10, or IBM 360/67.
Another time I was walking by they were talking about how to
adjust BLISS so that it ran well on the "Bigger and better PDP-11".
Grayson, Bell, and Newell were at both meeting along with a host
of students.
<snip>
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-02 21:57 +0000 |
| Message-ID | <vq2k95$v1q6$10@dont-email.me> |
| In reply to | #110908 |
On Sun, 2 Mar 2025 21:26:34 +0000, MitchAlsup1 wrote: > But academic efforts do not result in industrial quality products. *Cough* Unix *cough*
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-02 23:43 +0000 |
| Message-ID | <c525e18c1e8343f617fd97489f0e023e@www.novabbs.org> |
| In reply to | #110914 |
On Sun, 2 Mar 2025 21:57:57 +0000, Lawrence D'Oliveiro wrote: > On Sun, 2 Mar 2025 21:26:34 +0000, MitchAlsup1 wrote: > >> But academic efforts do not result in industrial quality products. > > *Cough* Unix *cough* Not sure you can call Bell Labs academia.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-03 02:08 +0000 |
| Message-ID | <vq32ve$11gfj$6@dont-email.me> |
| In reply to | #110920 |
On Sun, 2 Mar 2025 23:43:58 +0000, MitchAlsup1 wrote: > On Sun, 2 Mar 2025 21:57:57 +0000, Lawrence D'Oliveiro wrote: > >> On Sun, 2 Mar 2025 21:26:34 +0000, MitchAlsup1 wrote: >> >>> But academic efforts do not result in industrial quality products. >> >> *Cough* Unix *cough* > > Not sure you can call Bell Labs academia. Berkeley!
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-02 16:35 -0600 |
| Message-ID | <vq2mg2$vnod$1@dont-email.me> |
| In reply to | #110895 |
On 3/2/2025 3:34 AM, Anton Ertl wrote:
> 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.
>
Quick test...
Running Dhrystone:
XG2, 90908
33.6 MIPs
51.74 VAX MIPS
RV64G, 68965 ("GCC -O3")
35.5 MIPs
39.25 VAX MIPS
Where, the theoretical claim is VAX MIPs is the Dhrystone score divided
by 1757.
So, in this case, both came out less than 1 DMIPS/MHz, but:
1.54 VAX MIPs per XG2 op;
1.11 VAX MIPs per RV64 op.
Comparing ".text" size in this case:
RV64G:
.text 145K
.rodata 9K
XG2:
.text 71K
.rodata 0K
Initially, ".text" was bigger for XG2, but then noted I was static
linking the whole kernel (it shrank a fair bit after switching to only
linking the C library).
That and switching back to performance-tuned compiler options (had
previously set slower options for debugging Quake, which is sharing the
same Makefile in this case).
The RISC-V build also static-links the same C library (a highly modified
PDPCLIB).
Note that GCC is set to prune unreachable code.
Not actually sure why there is a 2x size difference, nothing obvious
stands out in the instruction-use stats (most obvious XG2 exclusive
features are not seeing all that much use in Dhrystone).
Note that this is the uncompressed size (the LZ compressed binary size
being 50K in this case).
Note here that RV64GC would reduce ".text" to around 116K but also
reduces Dhrystone score to around 56K...
But, IMHO, RISC-V has kinda foot-gunned itself with the design of 'C'.
Both a dog-chewed mess and seemingly not particularly effective either
(though, my CPU core takes a performance penalty in this case, due to
needing to fall back to scalar operation to deal with 16-bit instructions).
>>> 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
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-01 17:59 +0000 |
| Message-ID | <2025Mar1.185951@mips.complang.tuwien.ac.at> |
| In reply to | #110877 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >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. There was also the question of PDP-11 compatibility. I would solve that by adding a PDP-11 decoder that produces RV32G instructions (or maybe the microcode that the RV32G decoder produces). Low-end models may get a dynamic binary translator instead. >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). OTOH, HP was also a big player in the mini and later workstation market, and they managed to survive, albeit by eventually splitting themselves into HPE for the big iron, and the other part for the PCs and printers. But it may be the exception that proves the rule. - 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-03-01 17:42 -0800 |
| Message-ID | <87jz98w6m8.fsf@nosuchdomain.example.com> |
| In reply to | #110879 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
[...]
> OTOH, HP was also a big player in the mini and later workstation
> market, and they managed to survive, albeit by eventually splitting
> themselves into HPE for the big iron, and the other part for the PCs
> and printers. But it may be the exception that proves the rule.
Exceptions don't prove rules. They refute them. (The existence of an
exception may prove the existence of a rule to which it is an
exception.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-03-01 20:46 +0000 |
| Message-ID | <vpvrn5$2hq0$1@gal.iecc.com> |
| In reply to | #110877 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>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. That's not a fair comparison. VAX design started in 1975 and shipped in 1978. The first ARM design started in 1983 with working silicon in 1985. It was a decade later. On the other hand, I think some things were shortsighted even at the time. As Bell's paper said, they knew about Moore's law but didn't believe it. If they believed it they could have made the instructions a little less dense and a lot easier to decode and pipeline. STRETCH did pipelining in the 1950s so they should have been aware of it and considered that future machines could use it. As someeone else noted, they had microcode on the brain and the VAX instruction set is clearly designed to be decoded by microcode one byte at a time. Address modes can have side-effects so you have to decode them serially or have a big honking hazard scheme. They probably also assumed that microcode ROM would be faster than RAM which even in 1975 was not particularly true. Rather than putting every possible instruction into microcode, have a fast subroutine call and make them subsroutines which can be cached and pipelined. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-01 22:25 +0000 |
| Message-ID | <2025Mar1.232526@mips.complang.tuwien.ac.at> |
| In reply to | #110882 |
John Levine <johnl@taugh.com> writes: >According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>>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. > >That's not a fair comparison. VAX design started in 1975 and shipped in 1978. >The first ARM design started in 1983 with working silicon in 1985. It was a >decade later. The point is that ARM outperformed VAX without using caches. DRAM with 800ns cycle time was available in 1971 (the Nova 800 used it). By 1977, when the VAX 11/780 was released, certainly faster DRAM was available. So I think that, for a VAX-11/780-priced machine, they could have had a pipelined RISC that reads instructions from two 32-bit-wide DRAM banks alternatingly, resulting in maybe 3-4 32-bits of instructions delivered per microsecond for straight-line code without loads or stores. And in RV32GC many instructions take only 16 bits, so these 3-4 32-bits contain maybe 5-6 instructions. So that might be 5-6 peak MIPS, maybe 3 average MIPS, compared to 0.5 VAX MIPS. Some VAX instructions have to be replaced with several RISC instructions, so let's say these 3 RISC MIPS correspond to 2 VAX MIPS. That would still be faster than the VAX 11/780, which reportedly had about 0.5 MIPS. The other thing is that the VAX 11/780 (released 1977) had a 2KB cache, so Bell's argument that caches were only available around 1985 does not hold water on that end, either. So my 1977 RISC project would have used that cache, too, increasing the performance of the result even more. Yes, commercial RISCs only happened in 1986 or so, but there is no technical reason for that, only that commercial architects did not believe in such things at the time. It took research projects from several sources until the concept had enough credibility to be taken seriously. That's why I asked for the magic wand for my time-travel project. It's interesting that this lack of credibility apparently includes IBM, whose research lab pioneered the concept. They produced the IBM 801 with 15MHz clock, probably around the time of the first VAX, but the IBM 801 had no MMU; not sure what RAM technology they used. IBM tried to commercialize it in the ROMP in the IBM RT PC; Wikipedia says: "The architectural work on the ROMP began in late spring of 1977, as a spin-off of IBM Research's 801 RISC processor ... The first examples became available in 1981, and it was first used commercially in the IBM RT PC announced in January 1986. ... The delay between the completion of the ROMP design, and introduction of the RT PC was caused by overly ambitious software plans for the RT PC and its operating system (OS)." And IBM then designed a new RISC, the RS/6000, which was released in 1990. - 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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-02 02:40 +0000 |
| Message-ID | <vq0gfd$g1o3$3@dont-email.me> |
| In reply to | #110886 |
On Sat, 01 Mar 2025 22:25:26 GMT, Anton Ertl wrote: > The other thing is that the VAX 11/780 (released 1977) had a 2KB cache, > so Bell's argument that caches were only available around 1985 does not > hold water on that end, either. It was about the sizes of the caches, and hence their contribution to the cost.
[toc] | [prev] | [next] | [standalone]
Page 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web