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 3 of 17 — ← Prev page 1 2 [3] 4 5 … 17 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-02 13:19 +0000 |
| Message-ID | <2025Mar2.141932@mips.complang.tuwien.ac.at> |
| In reply to | #110892 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >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 Sure, more cache is better than less cache, all other things being equal, but as the ARM2 without cache demonstrates, a RISC running out of RAM can outperform the VAX-11/780 with 2KB (or is it 8KB? see below) cache. And as the ARM3 with 4KB cache demonstrates, that performance advantage increases by a lot with even a 4KB cache. >and hence their contribution to the >cost. Interestingly, <http://bitsavers.informatik.uni-stuttgart.de/pdf/datapro/datapro_reports_70s-90s/DEC/M11-384-40_8402_DEC_VAX-11.pdf> reports VAX-11/780 cache as having 8KB (4KB for the /750). It also gives a delivery date of Jan. 1978 for the VAX-11/780. So that cost was obviously acceptable for the VAX-11/780, and, as the ARM3 performance results show, is not too small to be beneficial to performance. MIPS used 64KB caches for the R2000? Because they could, in 1986. Motorola used 16KB caches for the 88000? Obviously 64KB is not all that necessary. Acorn used a 4KB shared cache for ARM3? Because it allowed them to do it on a single chip; it still gives good benefits. My impression is that Bell was just grasping at straws to justify their wrong choices. He looked at other differences (rather than the instruction set) between the MIPS R2000 and the VAX, and if it represented something that was not available at acceptable cost in 1977 (in particular, 64KB caches), he used it as justification for the VAX. - 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 21:48 +0000 |
| Message-ID | <vq2jnk$v1q6$7@dont-email.me> |
| In reply to | #110899 |
On Sun, 02 Mar 2025 13:19:32 GMT, Anton Ertl wrote: > My impression is that Bell was just grasping at straws to justify their > wrong choices. My impression was not. Note that the “big bang” arrival of RISC in the latter 1980s is pretty much in agreement with his timeline.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-03 17:57 +0000 |
| Message-ID | <2025Mar3.185737@mips.complang.tuwien.ac.at> |
| In reply to | #110910 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >Note that the “big bang” arrival of RISC in the >latter 1980s is pretty much in agreement with his timeline. Correlation does not prove causation. And when the facts (performance of cacheless and small-cache RISCs) are counterevidence of his explanation, his explanation is obviously wrong. - 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-03 23:27 +0000 |
| Message-ID | <vq5dts$1h3mg$7@dont-email.me> |
| In reply to | #110938 |
On Mon, 03 Mar 2025 17:57:37 GMT, Anton Ertl wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> Note that the “big bang” arrival of RISC in the latter 1980s is pretty >> much in agreement with his timeline. > > Correlation does not prove causation. Back atcha. Your attempt at drawing correlations (or lack thereof) between Bell’s claims and reality is no more valid than mine.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-02 22:00 +0000 |
| Message-ID | <f28e7114320af8493e7c18655e1ec458@www.novabbs.org> |
| In reply to | #110899 |
On Sun, 2 Mar 2025 13:19:32 +0000, Anton Ertl wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > > MIPS used 64KB caches for the R2000? Because they could, in 1986. > Motorola used 16KB caches for the 88000? Obviously 64KB is not all > that necessary. Acorn used a 4KB shared cache for ARM3? Because it > allowed them to do it on a single chip; it still gives good benefits. MIPS used SRAM external to the chip and sent out addresses 1 on the high phase of the clock and 1 on the low phase of the clock and violating the timing of the SRAM specs themselves. I was told that later MIPS had a tester setup to sort SRAMs into those that met its needs and those that did not. Mc88100 was not allowed to use an interface twice per cycle (the test guys objected) so we had to use 2 interfaces 1 for I$ 1 for D$. We put FP on die and migrated the TLB to the Caches which were 4-way set instead of direct mapped unified. As to ARM's 4KB cache:: 68020 had a 256 byte cache, with a hit rate just good enough (70%) to separate Instructions accesses from data accesses at the pins. ARM's cache would have been big enough for there to be unused cycles on its external interface. > My impression is that Bell was just grasping at straws to justify > their wrong choices. Likely, but looking at it from the originating time perspective, VAX would have lost PDP-11 compatibility if it were more RISC- like. I put the mistakes up to hoping the other guys don't advance the start of the art as much as what actually happened. > He looked at other differences (rather than the > instruction set) between the MIPS R2000 and the VAX, and if it > represented something that was not available at acceptable cost in > 1977 (in particular, 64KB caches), he used it as justification for the > VAX. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-03 14:56 +0000 |
| Message-ID | <hqjxP.120703$_N6e.81599@fx17.iad> |
| In reply to | #110916 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Sun, 2 Mar 2025 13:19:32 +0000, Anton Ertl wrote: > >> My impression is that Bell was just grasping at straws to justify >> their wrong choices. > >Likely, but looking at it from the originating time perspective, >VAX would have lost PDP-11 compatibility if it were more RISC- >like. In fact, that PDP-11 compatibility provided early market opportunities for the VAX as until VMS 2.0, many of the utility programs and vax commands were from RSX-11M running in compatibility mode (e.g. PIP).
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-03-01 18:29 -1000 |
| Message-ID | <871pvgukap.fsf@localhost> |
| In reply to | #110886 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> 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.
ROMP originally for DISPLAYWRITER follow-on ... running CP.r operating
system and PL.8 programming language. ROMP was minimal 801, didn't have
supervisor/problem mode ... at the time their claim was PL.8 would only
generate correct code and CP.r would only load/execute correct programs.
They claimed 40bit addressing ... 32 bit addresses ... but top four bits
selected 16 "segment registers" that contained 12bit
segment-identifiers. ... aka 28bit segment displacement and 12bit
segment-ids (40bits) .... and any inline code could change segment
register value ... as easily as could load any general register.
When follow-on to DISPLAYWRITER was canceled, they pivoted to UNIX
workstation market and got the company that had done AT&T unix port to
IBM/PC for PC/IX ... to do AIX. Now ROMP needed supervisor/problem mode
and inline code could no longer change segment register values
... needed to have supervisor call.
Folklore is they also had 200 PL.8 programmers and needed something for
them to do, so they gen'ed a abstract virtual machine system ("VRM")
(implemented in PL.8) and had AIX port be done to the abstract virtual
machine definition (instead of real hardware) .... claiming that the
combined effort would be less (total effort) than having the outside
company do the AIX port to the real hardware (also putting in a lot of
IBM SNA communication support).
The IBM Palo Alto group had been working on UCB BSD port to 370, but was
redirected to do it instead to bare ROMP hardware ... doing it in
enormously significantly less resources than the VRM+AIX+SNA effort.
Move to RS/6000 & RIOS (large multi-chip) doubled the 12bit segment-id
to 24bit segment-id (and some left-over description talked about it
being 52bit addressing) and eliminated the VRM ... and adding in some
amount of BSDisms.
AWD had done their own cards for PC/RT (16bit AT) bus, including a 4mbit
token-ring card. Then for RS/6000 microchannel, AWD was told they
couldn't do their own card, but had to do PS2 microchannel cards. The
communication group was fiercely fighting off client/server and
distributed computing and had seriously performance knee-capped PS2
cards, including ($800) 16mbit token-ring card (the PS2 microchannel
which had lower card throughput than the PC/RT 4mbit TR card). There
was joke that PC/RT 4mbit TR server having higher throughput than
RS/6000 16mbit TR server. There was also joke that the RS6000/730 with
VMEbus was a work around corporate politics and being able to install
high-performance workstation cards
We got the HA/6000 project in 1988 (approved by Nick Donofrio),
originally for NYTimes to move their newspaper system off VAXCluster to
RS/6000. I rename it HA/CMP.
https://en.wikipedia.org/wiki/IBM_High_Availability_Cluster_Multiprocessing
when I start doing technical/scientific cluster scale-up with national
labs (LLNL, LANL, NCAR, etc) and commercial cluster scale-up with RDBMS
vendors (Oracle, Sybase, Ingres, Informix that had vaxcluster support in
same source base with unix). The S/88 product administrator then starts
taking us around to their customers and also has me do a section for the
corporate continuous availability strategy document ... it gets pulled
when both Rochester/AS400 and POK/(high-end mainframe) complain they
couldn't meet the requirements.
Early Jan1992 have a meeting with Oracle CEO and IBM/AWD Hester tells
Ellison we would have 16-system clusters by mid92 and 128-system
clusters by ye92. Then late Jan92, cluster scale-up is transferred for
announce as IBM Supercomputer (for technical/scientific *ONLY*) and we
are told we can't work on anything with more than four processors (we
leave IBM a few months later). Contributing was the mainframe DB2 DBMS
group were complaining if we were allowed to coninue, it would be at
least five years ahead of them.
Neither ROMP or RIOS supported bus/cache consistency for multiprocessor
operation. The executive we reported to, went over to head up ("AIM" -
Apple, IBM, Motorola) Somerset for single chip 801/risc ... but also
adopts Motorola 88k bus enabling multiprocessor configurations. He later
leaves Somerset for president of (SGI owned) MIPS.
trivia: I also had HSDT project (started in early 80s), T1 and faster
computer links, both terrestrial and satellite ... which included custom
designed TDMA satellite system done on the other side of the pacific
... and put in 3-node system. two 4.5M dishes, one in San Jose and one
in Yorktown Research (hdqtrs, east coast) and a 7M dish in Austin (where
much of the RIOS design was going on). San Jose also got an EVE, a
superfast hardware VLSI logic simulator (scores of times faster than
existing simultion) ... and it was claimed that Austin being able to use
the EVE in San Jose, helped bring RIOS in a year early.
--
virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-03-02 20:02 +0000 |
| Message-ID | <vq2dfr$2skk$1@gal.iecc.com> |
| In reply to | #110886 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>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. Oh, OK. How was the code density? I know ARM was pretty good but VAX was fantastic since they sacrified everything else to compact instructions. The pages were only 512B, they really thought memory was expensive even though the trend lines were clear. >IBM tried to commercialize it in the ROMP in the IBM RT PC; ... >... 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)." I was there, designing AIX. IBM couldn't decide what they wanted, and they didn't understand Unix, but they wanted it yesterday, so they had an elaborate and slow "virtual resource manager" with the operating systems running on top. It turned out that the only operating system was AIX, with the VRM just extra overhead. We wasted a lot of time explaining why we weren't going to do random IBM stuff of which the most memorable was user labels in the inodes (well, OS DASD has them.) It did not help that I naively believed their initial schedule so we based AIX on 4.1BSD rather than the recently released 4.2 and it didn't have dynamic shared libraries and other 4.2 stuff. Someone else did a 4.2 port that ran way faster than AIX did. -- 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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-02 21:50 +0000 |
| Message-ID | <vq2jqn$v1q6$8@dont-email.me> |
| In reply to | #110905 |
On Sun, 2 Mar 2025 20:02:03 -0000 (UTC), John Levine wrote: > We wasted a lot of time explaining why we weren't going to do random > IBM stuff of which the most memorable was user labels in the inodes > (well, OS DASD has them.) Sounds like an early form of Linux-style extended attributes? <https://manpages.debian.org/xattr(7)>
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-02 22:40 +0000 |
| Message-ID | <2025Mar2.234011@mips.complang.tuwien.ac.at> |
| In reply to | #110905 |
John Levine <johnl@taugh.com> writes: >According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>>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. > >How was the code density? I have no data on that. Interestingly, unlike the 68k, which was outcompeted by RISCs at around the same time, the VAX did not have an afterlife of hobbyists who produced Linux and Debian ports, so I cannot easily make a comparison. >I know ARM was pretty good but VAX >was fantastic since they sacrified everything else to compact instructions. I don't think they did. They spent encoding space on instructions that were very rare, and AFAIK instructions can be encoded that do not work (e.g., a consant as destination). The major idea seems to have been orthogonality, not compactness. They did take choices for compactness (e.g., the call instructions that includes a bitmask for the registers to be saved), but overall other ideas were more important. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-03-03 02:58 +0000 |
| Message-ID | <vq35t1$cbc$1@gal.iecc.com> |
| In reply to | #110919 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>I know ARM was pretty good but VAX >>was fantastic since they sacrified everything else to compact instructions. > >I don't think they did. They spent encoding space on instructions >that were very rare, and AFAIK instructions can be encoded that do not >work (e.g., a consant as destination). The major idea seems to have >been orthogonality, not compactness. It certainly was orthogonal. I was thinking that they had one-, two-, and four- byte offset versions of all of the relative addressing modes, which made the code smaller at the cost of forcing operands to be decoded one at a time since you couldn't tell where the N+1st operand was until you'd looked at the Nth. Nearly all opcodes were one byte other than the extended format floating point instructions so it's hard to see how they could have made that much smaller without making it a lot more complicated. On the other hand, we can compare it to the S/360 instruction set which was fairly compact but a lot easier to decode, e.g., you could tell from the high bits of the first opcode byte how long each instruction was and where the operands were so you could decode the rest and do address calculations in parallel. -- 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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-03 03:36 +0000 |
| Message-ID | <vq3834$168la$1@dont-email.me> |
| In reply to | #110922 |
On Mon, 3 Mar 2025 02:58:41 -0000 (UTC), John Levine wrote: > Nearly all opcodes were one byte other than the extended format floating > point instructions so it's hard to see how they could have made that > much smaller without making it a lot more complicated. Bell points that VAX code gets close to the code density of equivalent PDP-11 code. That was a major design goal.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-03 07:39 +0000 |
| Message-ID | <2025Mar3.083903@mips.complang.tuwien.ac.at> |
| In reply to | #110922 |
John Levine <johnl@taugh.com> writes: >Nearly all opcodes were one byte other than the extended format floating point >instructions so it's hard to see how they could have made that much smaller >without making it a lot more complicated. One can look at IA-32 and compare the instruction lengths for frequent instructions like "add %reg1,%reg2", "add const,%reg", "mov (%reg1), %reg2", and "mov %reg1, (%reg2)" are. I expect that they are shorter than on the VAX (exception: if the constant fits in 16 bits, but not in 8). Of course there is a difference: VAX has 16 GPRs and IA-32 has only 8. AMD64 has 16 GPRs, and needs a REX prefix byte, but only if one of the additional registers is used (or 64-bit operation is needed), so for the frequent cases it probably still has shorter encodings on average than the VAX, especially if compilers prefer using the first 8 registers. For three-operand addition, IA-32/AMD64 has lea, and other three-operand instructions are not that common. IA-32 has even shorter encodings for some operations on %eax (stemming from the need for compactness on the 8080 and the 8086, and the fact that assembly-language programmers are good at exploiting such things). One can use this to make the code even shorter by trying to get the compiler to use %eax for instructions where such encodings exist. Alternatively, one could reassign this encoding space for some other purpose, e.g., avoiding the REX prefix in some cases. Another opportunity for shorter instructions is that IA-32/AMD64 supports byte-width register-to-register operations. These encodings are unnecessary and can be reused for better purposes. Another opportunity for making code shorter is that IA-32/AMD64 has redundant encodings for register-to-register operations: e.g., "sub %ecx, %edx" can be encoded with the first byte bein 0x29 or 0x2b (they make a difference if one of the operands is in memory). These encodings can be reused; one possibility would be to support only load-and-op instructions, not read-modify-write instructions; the the first byte 29 (for sub, and similar for the other operations) can be used for a different purpose, e.g., avoiding the need for a REX prefix. One idea I have had is that many instructions encode for a source register the same register as the target register of the previous instruction. One could just refer to the target of the previous instruction and thus save encoding space. The downside is that such instructions no longer are complete, but need the previous instruction to be decoded, which complicates interrupts and various tools. Bottom line: IA-32 is probably more compact than VAX, and even for IA-32 one can think of various ways to possibly make it even more compact. And looking at my latest code size measurements <2024Jan4.101941@mips.complang.tuwien.ac.at>, both armhf (ARM T32) and riscv64 (RV64GC) result in shorter code than IA-32 and AMD64: bash grep gzip 595204 107636 46744 armhf 599832 101102 46898 riscv64 796501 144926 57729 amd64 853892 152068 61124 i386 Apparently the additional registers of AMD64 (or maybe the different calling convention) result in smaller code than IA-32 despite having to use REX prefixes not only if the additional registers are used, but also if 64-bit width is required. The 16-bit wide encodings of ARM T32 and the RISC-V C extension apparently catch many common cases. These load/store architectures avoids the encoding waste of having several operation widths[1], and redundant encodings for register-to-register operations. However, in those cases where load-and-op instructions are useful, they need to encode an intermediate register, twice. In those cases where read-modify-write instructions are useful, they need to encode an intermediate register, 4 times, and the memory operand a second time; but obviously on the balance these instruction sets are more compact. [1] RV64G includes 32-bit wide register-register ops that I consider unnecessary: Usually the top 32 bits of 32-bit operations are not used, and then one can just use the 64-bit version. In the few cases where they are used, a 64-bit operation followed by a sign extension will produce the same result. But maybe the RISC-V architects have data that shows that the top 32 bits are used more often than I expect; maybe in C code with int variables that are used for indexing arrays (in that case we can thank the people who decided to go with I32LP64 (rather than ILP64) for that). - 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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-03 14:45 +0200 |
| Message-ID | <20250303144537.00007442@yahoo.com> |
| In reply to | #110925 |
On Mon, 03 Mar 2025 07:39:03 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > And looking at my latest code size measurements > <2024Jan4.101941@mips.complang.tuwien.ac.at>, both armhf (ARM T32) and > riscv64 (RV64GC) result in shorter code than IA-32 and AMD64: > > bash grep gzip > 595204 107636 46744 armhf > 599832 101102 46898 riscv64 > 796501 144926 57729 amd64 > 853892 152068 61124 i386 > I never measured size of gnu utilities, but my measurements of few of my own embedded projects and of some microbenchmarks always gave very different ratios. That is, in my measurements T32 was also a champion among extant 32b/64b architectures (extinct nanoMIPS was better), but i386 was MUCH closer than in your figures above. Up to twice closer, actually. It seems, newer gcc is much worse than older versions at generation of compact i386 code. Also in my measurement T32 was significantly denser than RV64GC, although in case of RV I only did microbenchmarks. One of my early measurements that I have bookmarked. https://www.realworldtech.com/forum/?threadid=86001&curpostid=86094
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-03 17:32 +0000 |
| Message-ID | <2025Mar3.183209@mips.complang.tuwien.ac.at> |
| In reply to | #110927 |
Michael S <already5chosen@yahoo.com> writes: >It seems, newer gcc is much worse than older versions at generation of >compact i386 code. Yes, a weakness of my measurement method is that if the compiler does not care much about code size (and compilers usually do what gives good benchmark timings, not the smallest code), it can easily make the code a lot bigger in ways that have nothing to do with encoding size, e.g., by loop unrolling or padding before branch targets, - 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-03 23:26 +0000 |
| Message-ID | <vq5dqb$1h3mg$6@dont-email.me> |
| In reply to | #110925 |
On Mon, 03 Mar 2025 07:39:03 GMT, Anton Ertl wrote: > ... VAX has 16 GPRs ... Technically only 13.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-03 07:24 +0000 |
| Message-ID | <vq3lg9$18525$1@dont-email.me> |
| In reply to | #110919 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > John Levine <johnl@taugh.com> writes: >>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>>>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. >> >>How was the code density? > > I have no data on that. Interestingly, unlike the 68k, which was > outcompeted by RISCs at around the same time, the VAX did not have an > afterlife of hobbyists who produced Linux and Debian ports, so I > cannot easily make a comparison. The VAX is still supported with gcc and binutils, with newlib as its C library, so building up a tool chain for assembly/disassembly should be doable with a few (CPU) hours; you can then compare sizes.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-03 08:06 +0000 |
| Message-ID | <2025Mar3.090608@mips.complang.tuwien.ac.at> |
| In reply to | #110924 |
Thomas Koenig <tkoenig@netcologne.de> writes: >The VAX is still supported with gcc and binutils, with newlib as >its C library, so building up a tool chain for assembly/disassembly >should be doable with a few (CPU) hours; you can then compare >sizes. Good. While the CPU hours are not the problem, I cannot spare the human hours for such a project. - 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 | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-03 16:41 -0600 |
| Message-ID | <vq5b96$1gjnc$1@dont-email.me> |
| In reply to | #110926 |
On 3/3/2025 2:06 AM, Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> The VAX is still supported with gcc and binutils, with newlib as
>> its C library, so building up a tool chain for assembly/disassembly
>> should be doable with a few (CPU) hours; you can then compare
>> sizes.
>
> Good. While the CPU hours are not the problem, I cannot spare the
> human hours for such a project.
>
Similar for why I am not doing full comparisons...
Can note in my case, a few targets for Dhrystone (".text" size):
x86-64, GCC : 3.3K (dynamically linked)
SH-4, GCC : 90.5K (static linked, old binary, TestKern)
XG2, BGBCC : 71.3K (static linked, TestKern)
RV64G. GCC : 144.9K (static linked, TestKern)
Doom:
x86-64, GCC : 244.2K (dynamically linked)
XG2, BGBCC : 296.4K (static linked, TestKern)
RV64G. GCC : 460.6K (static linked, TestKern)
Doom ("-Os"):
x86-64, GCC : 174.2K (dynamically linked)
RV64GC. GCC : 352.1K (static linked, TestKern)
Can't directly compare against Thumb2 at the moment, in past tests, it
was the leader, but for accurate results would require it to also use
the same C library (similar issues at present with comparing against x86
or x86-64). Also, being 32-bit, they aren't really in the same category.
Though, XG2 isn't doing too badly vs x86-64, given the x86-64 versions
are dynamically linked.
Though, it would appear so much in my own testing that it isn't so much
that XG2 gets amazing code density, but that RISC-V output tends to be
bulkier than some seem to claim (and neither "-Os" nor RV64GC seem to
make all that drastic of a difference to the final ".text" size).
So, RV64GC gets around 370K instead (or 352K with RV64GC + "-Os"), still
doesn't put it in the lead.
The "-Os" option seems to make a much bigger difference with x86-64 though.
Generally, I am counting ".text" specifically, rather than the overall
size of the binary (can note that generally, ELF objects burn a
considerable amount of space on metadata).
I am also leaving out MSVC output at the moment, as it tends to be an
outlier in terms of bloated ".text" sections (Doom with VS2022 gives a
size of roughly 1MB).
In many cases, doesn't make a huge difference, except when trying to
shoe-horn stuff into ROMs, or annoyance about large code/data wasting
RAM or increasing loading times (or both: the RV64G+ELF binaries combine
the powers of bulkier code, bloated metadata, and being uncompressed; to
give much worse loading times in the Verilog simulations...).
> - anton
[toc] | [prev] | [next] | [standalone]
| From | MarkC <usenet@em-ess-see-twenty-seven.me.uk> |
|---|---|
| Date | 2025-03-03 12:43 +0000 |
| Message-ID | <5pkg9l-kipt.ln1@msc27.me.uk> |
| In reply to | #110919 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >John Levine <johnl@taugh.com> writes: >>How was the code density? > >I have no data on that. Interestingly, unlike the 68k, which was >outcompeted by RISCs at around the same time, the VAX did not have an >afterlife of hobbyists who produced Linux and Debian ports, so I >cannot easily make a comparison. NetBSD still has a VAX port, so the sizes of pre-built packages from there might be informative.
[toc] | [prev] | [next] | [standalone]
Page 3 of 17 — ← Prev page 1 2 [3] 4 5 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web