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 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-11-07 18:01 +0000 |
| Subject | Re: Register windows |
| Message-ID | <2026Nov7.190141@mips.complang.tuwien.ac.at> |
| In reply to | #119067 |
antispam@fricas.org (Waldek Hebisch) writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> In a modern >> (post-1995, with a few exceptions, most of which have died out in the >> meantime) processor the front end predicts the return from the >> processor-internal return stack and often starts fetching from there >> before the load-store unit sees the load of the return address. The >> return address is then used to validate the branch prediction and >> retire the return instruction. > >It must be more complex. Silly fibonacci benchmark shows average >performance of function call per 2 clocks. Without inlining? On what hardware? What I see on a Rocket Lake with a Fibonacci program compiled by the Rust 1.89 compiler is 3.6 cycles per return (i.e., also per call, with 2.3 branches per return). I have not looked at the code to see if there is any inlining, but given that a regular fibonacci call includes a call, a conditional branch, and a return (with any recursive call accounted separately), showing 2.3 branches indicates that there is at least some inlining going on here. >Given length of >the pipeline return address is pushed too late to use it for >fetching intructions after return. In other words, return >must be predicted before the call starts executing. Certainly. Modern branch predictors have to trigger on addresses, not on the results of fetches. But if a microarchitecture really does a non-inlined fibonacci program at two cycles per call, even more prediction has to be done: In the base case (half of the calls) the push to the return address stack is followed by a pull from the return address stack, and all of that and the prediction based on the return address must happen in two cycles. Or maybe there is some special fast path for such cases. What the microarchitects do in the branch predictors is certainly amazing. - 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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-11-08 04:37 +0000 |
| Subject | Re: Register windows |
| Message-ID | <11couac$3eeoe$1@paganini.bofh.team> |
| In reply to | #119071 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> In a modern
>>> (post-1995, with a few exceptions, most of which have died out in the
>>> meantime) processor the front end predicts the return from the
>>> processor-internal return stack and often starts fetching from there
>>> before the load-store unit sees the load of the return address. The
>>> return address is then used to validate the branch prediction and
>>> retire the return instruction.
>>
>>It must be more complex. Silly fibonacci benchmark shows average
>>performance of function call per 2 clocks.
>
> Without inlining? On what hardware?
>
> What I see on a Rocket Lake with a Fibonacci program compiled by the
> Rust 1.89 compiler is 3.6 cycles per return (i.e., also per call, with
> 2.3 branches per return). I have not looked at the code to see if
> there is any inlining, but given that a regular fibonacci call
> includes a call, a conditional branch, and a return (with any
> recursive call accounted separately), showing 2.3 branches indicates
> that there is at least some inlining going on here.
A little correction. This is on AMD Ryzen 9 7900 with claims
3.0 GHz clock. But perf says that benchmark run at 5.310 GHz,
so number of clocks is larger. I used two versions, one produced
by gcc -O which in assembly is:
fib:
movq %rdi, %rax
cmpq $1, %rdi
jle .L5
pushq %rbp
pushq %rbx
subq $8, %rsp
movq %rdi, %rbx
leaq -1(%rdi), %rdi
call fib
movq %rax, %rbp
leaq -2(%rbx), %rdi
call fib
So performs all expected calls. This one needs 4.6 cycles
per call. The other is generated by the perl program below.
Generated code contains only calls and returns, for each
n there is separate function. Call structure is exactly the
same as when computing fibonacci. This one needs 4.01
cycles per call. For comparison, version which replaces
final call and ret by jump (corresponding to tail call
elimination) needs 2.43 clocks per "call".
-----------<cut here>---------------
print << 'EOD1';
.file "fib3c.pl"
EOD1
my($j);
for($j = 2; $j < 50; $j++) {
my($k) = $j - 1;
my($l) = $j - 2;
print << "EOD2";
.globl fib$j
.type fib$j, \@function
fib$j:
call fib$k
call fib$l
ret
.size fib$j, .-fib$j
EOD2
}
-----------<cut here>---------------
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-11-08 04:49 +0000 |
| Subject | Re: Register windows |
| Message-ID | <11cov08$21f3$2@dont-email.me> |
| In reply to | #119081 |
On Sun, 8 Nov 2026 04:37:34 -0000 (UTC), Waldek Hebisch wrote:
> for($j = 2; $j < 50; $j++) {
> my($k) = $j - 1;
> my($l) = $j - 2;
> print << "EOD2";
> .globl fib$j
> .type fib$j, \@function
> fib$j:
> call fib$k
> call fib$l
Shouldn’t there be a “fib0” somewhere?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-11-08 14:19 +0000 |
| Subject | Re: Register windows |
| Message-ID | <11cq0dq$3g8kd$1@paganini.bofh.team> |
| In reply to | #119082 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 8 Nov 2026 04:37:34 -0000 (UTC), Waldek Hebisch wrote:
>
>> for($j = 2; $j < 50; $j++) {
>> my($k) = $j - 1;
>> my($l) = $j - 2;
>> print << "EOD2";
>> .globl fib$j
>> .type fib$j, \@function
>> fib$j:
>> call fib$k
>> call fib$l
>
> Shouldn’t there be a “fib0” somewhere?
Yes, you need 'fib0' and 'fib1'. You can add them as Anton did,
or at assembly level just take single 'ret'.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-11-08 06:33 +0000 |
| Subject | call and return speed (was: Register windows) |
| Message-ID | <2026Nov8.073301@mips.complang.tuwien.ac.at> |
| In reply to | #119081 |
antispam@fricas.org (Waldek Hebisch) writes:
>The other is generated by the perl program below.
>Generated code contains only calls and returns
Which reminded me that I also have a microbenchmark that performs
calls to empty functions: 9 such calls to 5 different empty functions
in a row, and then a call to a function that does a little more than
nothing (including a conditional branch), then a jump back. The
overall instruction count is 2.7 per call on AMD64. And I have
results for that for a variety of microarchitectures. You find the
results at the first column of
<https://www.complang.tuwien.ac.at/forth/threading/>. See below for
your code.
In terms of cycles, Lion Cove (Core Ultra 225 P-core) is remarkable:
it takes just one cycle per call-return pair. Here the
microarchitecture clearly is doing miraculous things; maybe inlining
in the microcode cache?
Next, we have the Cortex-A76 with 2.24 cycles per call. Given the
clock rate of the Cortex-A76, it is plausible that it manages to push
something on the return-address stack in one cycle and pull it from
the return-address stack and use it for prediction in the next cycle.
Next, we have the Goldmont (predecessor to the present Intel E-cores)
with 2.88 cycles per call. Similar considerations apply as for the
Cortex-A76. What is interesting here is that the next
microarchitecture in this family, the Goldmont+, shows a much worse
result for this microbenchmark; this continues with further family
members Tremont and Gracemont, until finally Skymont gets down to 3.51
cycles. My guess is that a big redesign of the branch predictor
happened in the Goldmont+ (compare also the, e.g., direct columns for
these processors), and the case "return from a very recent call"
became a victim of the redesign, and was only optimized again in
Skymont.
>-----------<cut here>---------------
>print << 'EOD1';
> .file "fib3c.pl"
>
>EOD1
>
>my($j);
>
>for($j = 2; $j < 50; $j++) {
> my($k) = $j - 1;
> my($l) = $j - 2;
>print << "EOD2";
> .globl fib$j
> .type fib$j, \@function
>fib$j:
> call fib$k
> call fib$l
> ret
> .size fib$j, .-fib$j
>EOD2
>}
>-----------<cut here>---------------
I completed this as follows:
A C program fib.c with the following source code:
----------------
extern void fib49();
int main()
{
fib49();
return 0;
}
void fib1()
{
}
void fib0()
{
}
--------------------
And build and run the whole thing as follows:
perl fib3c.pl >fib.s
gcc -Wall -O fib.c fib.s -o fib
taskset -c 1 perf stat -c cycles:u -e instructions:u fib
fib benchmark executes 50_345_190_769 instructions, i.e., about
25_172_595_384 calls.
The Lion Cove takes 61_452_053_514 cycles, i.e., 2.44 cycles per call.
If half of the calls take 1 cycle (as seen in the subroutine
microbenchmark), the other half (which contains a call) take 3.88
cycles on average. Or maybe the limited depth of the return-address
stack plays a role. There are 6_448_145 branch mispredictions
reported, which are likely the result of the limited depth of the
return-address stack. These mispredictions would typically account
for ~130M cycles, i.e, only 0.2% of the total cycles. So the major
aspect seems to be how fast the handling of the return-address stack
works, and possible limitations of the optimization that produced the
miraculous 1 cycle/call on subroutine.
The Skymont takes 376_693_549_679 cycles, i.e., 14.96 cycles per call.
This is high, whatever the explanation is. The number of branch
mispredictions is reported as 7_511, so either the return-address
stack is more than 40 or so deep or mispredictions from returns are
not counted on Skymont.
In any case, fib3 tests things that subroutine does not test.
- 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 | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-10-30 00:10 +0000 |
| Message-ID | <6ae3df9b.3463531@news.eternal-september.org> |
| In reply to | #118873 |
On Tue, 27 Oct 2026 16:58:12 GMT, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >So iffy that essentially nobody does register windows anymore. Even I think that register windows are too crazy to consider! I have banks of 128 registers, but the choice is to use them all or ignore them. Of course, there's one register-window-like scheme that I could *remotely consider* using, even though it is also dangerously flawed. Give the computer an internal high-speed memory that's only 64K in size... and copy the Texas Instruments 9900 scheme. That's a little different from a "window", although in a way it's essentially the same thing. At least here save and restore don't mean copying the window contents into memory, but instead saving a copy of the pointer. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-30 00:33 +0000 |
| Message-ID | <1793320398-5857@newsgrouper.org> |
| In reply to | #118952 |
quadibloc@invalid.com (John Savard) posted: > On Tue, 27 Oct 2026 16:58:12 GMT, MitchAlsup > <user5857@newsgrouper.org.invalid> wrote: > > >So iffy that essentially nobody does register windows anymore. > > Even I think that register windows are too crazy to consider! > > I have banks of 128 registers, but the choice is to use them all or > ignore them. > > Of course, there's one register-window-like scheme that I could > *remotely consider* using, even though it is also dangerously flawed. > Give the computer an internal high-speed memory that's only 64K in > size... and copy the Texas Instruments 9900 scheme. That's a little > different from a "window", although in a way it's essentially the same > thing. At least here save and restore don't mean copying the window > contents into memory, but instead saving a copy of the pointer. My 66000's memory-based Thread-state is similar to 9900--except HW treats them like a write-back-cache. In the 9900 sense, one can change a pointer and one has a new register file--but one also has a new memory map, and everything else in a Thread-State. > John Savard
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-24 22:20 +0000 |
| Message-ID | <11bjav5$340l8$2@dont-email.me> |
| In reply to | #118811 |
On Sat, 24 Oct 2026 19:28:02 GMT, MitchAlsup wrote: > The commercial success of VAX delayed Alpha--no doubt about that. > So, I contend, DEC misplayed that card. But DEC did bring out their first Unix-based RISC product in 1989 -- the MIPS-based DECstation. But there was still internal feuding between the “Unix Is Snake Oil” camp (led by Ken Olsen himself) and the “Customers Want An Open OS” camp, which prevented the company committing wholesale to the latter viewpoint. The holdouts were not completely neutralized until Ken Olsen’s time as CEO came to an end.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-24 23:33 +0000 |
| Message-ID | <1792884789-5857@newsgrouper.org> |
| In reply to | #118816 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > On Sat, 24 Oct 2026 19:28:02 GMT, MitchAlsup wrote: > > > The commercial success of VAX delayed Alpha--no doubt about that. > > So, I contend, DEC misplayed that card. > > But DEC did bring out their first Unix-based RISC product in 1989 -- > the MIPS-based DECstation. But there was still internal feuding > between the “Unix Is Snake Oil” camp (led by Ken Olsen himself) and > the “Customers Want An Open OS” camp, which prevented the company > committing wholesale to the latter viewpoint. > > The holdouts were not completely neutralized until Ken Olsen’s time as > CEO came to an end. Faced the same war at Motorola where the factory and 68K design team (150+ people) waged war on 88K design team (22) with the same conclusion:: Moto is no longer in the CPU game.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-10-25 12:56 -0400 |
| Message-ID | <JzqDS.43458$3dP4.30034@fx18.iad> |
| In reply to | #118811 |
On 2026-Oct-24 15:28, MitchAlsup wrote: > quadibloc@invalid.com (John Savard) posted: > >> /ERROR "unexpected byte sequence starting at index 348: '\xE2'" while decoding/: >> >> On Sat, 1 Mar 2025 08:09:35 -0000 (UTC), Lawrence D'Oliveiro >> <ldo@nz.invalid> wrote: >> >>> The VAX project started roughly around the time the first RISC >>> concepts were being researched. > > I remember walking by a CS conference room 1973-ish and listening to > a bunch of people (including Bill Wolfe and Aho) at Carnegie Mellon. > The discussion was about a follow on to the PDP-11 architectures > and what additional address modes should go in or not. > > So, my memory is that VAX was being fleshed out at least 7 years > before RISC got started. According to one of Gordon Bell's web pages the VAX project was officially started on 1-Apr-1975. The VAX 780 product was introduced in Oct 1977. Recall my prior post of the article from Electronics about memory prices circa 1973 being about 10 cents per byte (in 1973 cents) as that would strongly influence any architecture and ISA design decisions. Also in 1975 DEC introduced the LSI-11 product built from a 3 chip set MCP-1600 from Western Digital in 7u NMOS process at 3.3MHz (300ns microcycle). https://simh.trailing-edge.com/semi/lsi11.html https://en.wikipedia.org/wiki/PDP-11#LSI-11_integrated_circuits https://en.wikipedia.org/wiki/MCP-1600 So circa 1975 DEC had access to NMOS chip technology similar to 8080 if they had chosen to use it for a risc-VAX. >>> RISC architecture to begin with? > > Not with the players involved. Now, if Thronton or Seymore was at CMU > then maybe. > >> Because not doing so meant that, just >>> over a decade later, RISC architectures took over the âreal computerâ >>> market and wiped the floor with DECâs flagship architecture, >>> performance-wise. >>> >>> The answer was no, the VAX could not have been done as a RISC >>> architecture. RISC wasnât actually price-performance competitive until >>> the latter 1980s: I disagree. As I mentioned above, the 1975 price of memory would be a strong consideration. Compared to a variable length ISA of 2.5 to 3 bytes average, a fixed length 4-byte ISA would waste 1 to 1.5 bytes per instruction. I believe one could build a variable length instruction fetch/parse using standard 1975 TTL parts that can sustain 1 clock per instruction at 5 MHz. After that, just keep the instructions simple like risc so they decode easily. That gives one the compact instruction size similar to cisc, with the uArch design simplicity a risc decode and execute, and performance of a pipelined processor. You need to also consider R&D cost and time to market. - IIRC I read someplace that VAX-780 design cost 300 man-years over 3 years. - Looking at Hennessy's project notes for the Stanford MIPS, and filtering out tool developments costs, MIPS-1 design cost about 2 engineers working for 6 months. > Once compilers made significant growth in optimization, and sufficient > silicon area became available. By 1982 DEC research showed that VAX compilers only used 50 to 60 of its 304 instructions and 3 or 4 of its address modes. See "A Case Study of VAX-11 Instruction Set Usage For Compiler Execution", 1982. So compilers were already emitting risc-ish code. >> Shall we then conclude that DEC did everything right, because later on >> after the VAX, DEC came up with the Alpha, which was RISC, and which >> was the highest-performing chip of its day? > > The commercial success of VAX delayed Alpha--no doubt about that. So, I > contend, DEC misplayed that card. During the 1980's DEC had multiple proposals and projects floating around internally but failed to capitalize on any of them. There was the risc-ish Titan project circa 1982. Titan System Manual 1986 WRL-86-1 https://www.bitsavers.org/pdf/dec/tech_reports/WRL-86-1.pdf "The Titan project was begun as the initial project of the Western Research Laboratory in April of 1982. The most obvious milestones were the following: Apr 1982 Project begins Mar 1983 CPU logic simulation Oct 1984 CPU executing with toy memory system May 1985 CPU executing with real memory system Jun 1985 I/O starts working Dec 1985 Complete system with all I/O running Unix" "The first implementation of Titan is in 100K ECL, with a 45 nanosecond cycle time and 13 cycle cache miss penalty. The central processor has a four-stage pipeline with a peak instruction issue rate of one per cycle. Due to cache misses and pipeline stalls, a new instruction is typically issued every 1.5 cycles." There were internal proposals to switch to an internal risc engine: VOR: VAX on a RISC. Internal memo, Digital Systems Research Center, December 1984 https://bwlampson.site/35a-VOR/35a-VORAbstract.html Ideas for a simple fast VAX. Internal memo, Digital Systems Research Center, October 1985 https://bwlampson.site/35b-IdeasFastVAX/35b-IdeasFastVAXAbstract.html DEC PRISM (Parallel Reduced Instruction Set Machine) was circa 1988 https://en.wikipedia.org/wiki/DEC_PRISM > >> Well, not everything. The Alpha was so expensive as to be a dismal >> failure in the market. However, it was either good enough, or >> well-documented enough, for some Chinese efforts at home-grown >> computer design to have copied it. >> >> John Savard
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-10-25 18:42 +0000 |
| Message-ID | <11blihu$bvm$1@gal.iecc.com> |
| In reply to | #118822 |
According to EricP <ThatWouldBeTelling@thevillage.com>: >Recall my prior post of the article from Electronics about memory prices >circa 1973 being about 10 cents per byte (in 1973 cents) as that would >strongly influence any architecture and ISA design decisions. Yes, they guessed wrong about the trajectory of memory prices. I think they also had an implicit assumption that ROM would always be faster than RAM so the cost of interpreting microcode would be low. And they totally missed that people would stop writing systems code in assembler and switch to higher level languages like C or PL/S or BLISS or Burroughs Algol. The IBM 801 project was going on at the same time, with the compiler and the computer developed together. The 801 was a RISC largely because that was the code that the PL.8 compiler generated. I recall reading somwhere that when they wrote a S/360 code generator for PL.8, its code ran much faster than the regular PL/I compilers because it mostly used a RISC-ish subset of the 360 instruction set that ran fast. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-25 20:03 +0000 |
| Message-ID | <11blna2$3u9ff$1@dont-email.me> |
| In reply to | #118824 |
John Levine <johnl@taugh.com> schrieb: > The 801 was a RISC largely because that was the > code that the PL.8 compiler generated. They chose the RISC design based on their studies of generated code, and then co-developed the ISA and the compiler together. What I particularly liked is the way they simulated their machine. Apparently, they had a /370 at their disposal and replaced the 801 instructions, on the fly, with equivalend 32-bit instructions for the /370, which made for much faster execution than pure emulation. > I recall reading somwhere that when they wrote a S/360 code generator > for PL.8, its code ran much faster than the regular PL/I compilers because > it mostly used a RISC-ish subset of the 360 instruction set that ran fast. Graph coloring for register allocation also played a large role, from what I read. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-10-25 23:36 -0400 |
| Message-ID | <jwvmrs1f89d.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118822 |
EricP [2026-10-25 12:56:55] wrote: > On 2026-Oct-24 15:28, MitchAlsup wrote: >> Once compilers made significant growth in optimization, and sufficient >> silicon area became available. [...] > So compilers were already emitting risc-ish code. Yeah, IIUC the need to have better compilers wasn't because compiler-generated RISC code would not be competitive with compiler-generated CISC code, but because CISC assembler was supposed to be comfortable whereas RISC assembler was supposed to be painful to use, so RISC would be palatable only if exposure to assembler was reduced (hence the need for better compilers). The old "semantic gap" argument. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-26 18:46 +0000 |
| Message-ID | <2026Oct26.194612@mips.complang.tuwien.ac.at> |
| In reply to | #118835 |
Stefan Monnier <monnier@iro.umontreal.ca> writes: >Yeah, IIUC the need to have better compilers wasn't because >compiler-generated RISC code would not be competitive with >compiler-generated CISC code, but because CISC assembler was supposed to >be comfortable whereas RISC assembler was supposed to be painful to use, >so RISC would be palatable only if exposure to assembler was reduced >(hence the need for better compilers). RISC assembly languages are not painful; on the contrary, they are relatively easy. I can imagine that assembly programmers resented the devaluing of their skill of making good use of the addressing modes, and CISCy features of an instruction set. Instead, delay slots meant that a new skill had to be learned for some assembly languages. The MIPS assembler took care of the delay slots, however. Anyway, as memories grew, high-level languages gained relevance. RISCs have a performance advantage over VAX-11/780 in assembly language, with simple compilers, and with optimizing compilers, thanks to pipelining (and the 11/780's high CPI). The memory consumption with simple compilers may have resulted in bad code density for a RISCy VAX, and that would have delayed the moved to high-level languages by a short while, but I still think that a RISCy VAX would have been better for DEC and their customers. - 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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-26 14:29 -0700 |
| Message-ID | <11bogob$vugm$1@dont-email.me> |
| In reply to | #118847 |
On 10/26/2026 11:46 AM, Anton Ertl wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Yeah, IIUC the need to have better compilers wasn't because >> compiler-generated RISC code would not be competitive with >> compiler-generated CISC code, but because CISC assembler was supposed to >> be comfortable whereas RISC assembler was supposed to be painful to use, >> so RISC would be palatable only if exposure to assembler was reduced >> (hence the need for better compilers). > > RISC assembly languages are not painful; on the contrary, they are > relatively easy. I can imagine that assembly programmers resented the > devaluing of their skill of making good use of the addressing modes, > and CISCy features of an instruction set. Instead, delay slots meant > that a new skill had to be learned for some assembly languages. The > MIPS assembler took care of the delay slots, however. Fwiw, never put a MEMBAR instruction in a delay slot on SPARC. > > Anyway, as memories grew, high-level languages gained relevance. > RISCs have a performance advantage over VAX-11/780 in assembly > language, with simple compilers, and with optimizing compilers, thanks > to pipelining (and the 11/780's high CPI). The memory consumption > with simple compilers may have resulted in bad code density for a > RISCy VAX, and that would have delayed the moved to high-level > languages by a short while, but I still think that a RISCy VAX would > have been better for DEC and their customers. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-26 18:19 +0000 |
| Message-ID | <2026Oct26.191923@mips.complang.tuwien.ac.at> |
| In reply to | #118811 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: >quadibloc@invalid.com (John Savard) posted: >> Could the VAX have been designed as a >> >RISC architecture to begin with? > >Not with the players involved. Now, if Thronton or Seymore was at CMU >then maybe. The 801 was designed at around the same time as the VAX 11/780, and the CDC6600 had been designed more than a decade earlier. EricP has reported on his design of a RISC with the kind of technology that the VAX was built from. It's pretty obvious that it was possible, and it is even more obvious that the VAX architects did not do it. >Once compilers made significant growth in optimization, and sufficient >silicon area became available. RISCs are already faster without additional compiler optimization. Good register allocation is necessary to avoid a large code size penalty, however, and that was an issue when the VAX started. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-27 16:41 +0000 |
| Message-ID | <1793119295-5857@newsgrouper.org> |
| In reply to | #118844 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >quadibloc@invalid.com (John Savard) posted: > >> Could the VAX have been designed as a > >> >RISC architecture to begin with? > > > >Not with the players involved. Now, if Thronton or Seymore was at CMU > >then maybe. > > The 801 was designed at around the same time as the VAX 11/780, and > the CDC6600 had been designed more than a decade earlier. EricP has > reported on his design of a RISC with the kind of technology that the > VAX was built from. It's pretty obvious that it was possible, and it > is even more obvious that the VAX architects did not do it. > > >Once compilers made significant growth in optimization, and sufficient > >silicon area became available. > > RISCs are already faster without additional compiler optimization. If 1983 compilers were still at the -O1 level, RISC may have failed. Luckily they were at -O2 at that time, and did. > Good register allocation is necessary to avoid a large code size > penalty, however, and that was an issue when the VAX started. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-27 18:16 +0000 |
| Message-ID | <2026Oct27.191641@mips.complang.tuwien.ac.at> |
| In reply to | #118871 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> RISCs are already faster without additional compiler optimization. > >If 1983 compilers were still at the -O1 level, RISC may have failed. >Luckily they were at -O2 at that time, and did. The -O1 and -O2 of what compiler do you have in mind? Gcc was released in 1987; it did have a -O option (IIRC no -O2 yet), and gcc beat HP's C compiler on HP/UX (probably PCC-based, i.e., far less optimization that gcc -O) by a wide margin; yet HP with their not so great compiler saw good speedups with their C compiler from their HPPA RISC architecture (introduced 1986) compared to their 68K-based and HP FOCUS based systems. And that's against the 68030 (when I was at HP in 1988), which already had a better CPI than the CPI=10 of the VAX 11/780. The VAX 11/780 CPI is so abysmally high that even if a VAX instruction would expand into load load operate store on a RISC, the RISC would still beat it easily (on early RISCs this sequence takes 5 cycles, while a typical VAX instruction takes 10 cycles). You may want to argue cache for the load and the store, but 1) wrt compilers, those memory accesses that compilers can register-allocate away are cache hits. 2) wrt VAX 11/780, it will miss the cache for the same memory accesses as the RISC, so cache misses won't help the VAX. Compilers with better register allocation certainly helped, but they also helped the CISCs (maybe not as much, but still). - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-27 21:01 +0000 |
| Message-ID | <1793134896-5857@newsgrouper.org> |
| In reply to | #118883 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> RISCs are already faster without additional compiler optimization. > > > >If 1983 compilers were still at the -O1 level, RISC may have failed. > >Luckily they were at -O2 at that time, and did. > > The -O1 and -O2 of what compiler do you have in mind? Green Hills circa 1985. > Gcc was released in 1987; it did have a -O option (IIRC no -O2 yet), > and gcc beat HP's C compiler on HP/UX (probably PCC-based, i.e., far > less optimization that gcc -O) by a wide margin; yet HP with their not > so great compiler saw good speedups with their C compiler from their > HPPA RISC architecture (introduced 1986) compared to their 68K-based > and HP FOCUS based systems. And that's against the 68030 (when I was > at HP in 1988), which already had a better CPI than the CPI=10 of the > VAX 11/780. > > The VAX 11/780 CPI is so abysmally high that even if a VAX instruction > would expand into > > load > load > operate > store > > on a RISC, the RISC would still beat it easily (on early RISCs this > sequence takes 5 cycles, while a typical VAX instruction takes 10 > cycles). You may want to argue cache for the load and the store, but > > 1) wrt compilers, those memory accesses that compilers can > register-allocate away are cache hits. > > 2) wrt VAX 11/780, it will miss the cache for the same memory accesses > as the RISC, so cache misses won't help the VAX. > > Compilers with better register allocation certainly helped, but they > also helped the CISCs (maybe not as much, but still). > > - anton
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-27 21:14 +0000 |
| Message-ID | <Ju8ES.54738$MmU5.22300@fx44.iad> |
| In reply to | #118898 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> >> RISCs are already faster without additional compiler optimization. >> > >> >If 1983 compilers were still at the -O1 level, RISC may have failed. >> >Luckily they were at -O2 at that time, and did. >> >> The -O1 and -O2 of what compiler do you have in mind? > >Green Hills circa 1985. When we started using the 88100 in 1989, we were given the m88k version of PCC[*] from the Motorola group in the Chicago area. It wasn't until the next year that we had access to the Green Hills (and later Diab Data) 88k compilers. [*] For which I had to patch the register allocator to support the crazy expressions generated by cfront.
[toc] | [prev] | [next] | [standalone]
Page 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
Back to top | Article view | comp.arch
csiph-web