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 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-03 16:44 +0000 |
| Message-ID | <2025Mar3.174417@mips.complang.tuwien.ac.at> |
| In reply to | #110928 |
MarkC <usenet@em-ess-see-twenty-seven.me.uk> writes:
>NetBSD still has a VAX port, so the sizes of pre-built packages from
>there might be informative.
Thanks. The NetBSD pkgsrc is not limited to NetBSD, and there is a
wide variety of prebuilt stuff there. I took those that sound like
architecture names (and probably belong to NetBSD): aarch64 alpha
amd64 earmv7hf i386 m68k mips64eb mipsel powerpc sparc sparc64 vax
Unfortunately, they do not seem to port to RISC-V in any form yet, and
their earmv7hf port uses ARM A32, not T32. So the NetBSD competition
is performed without entries for those two instruction set encodings
that showed the smallest code sizes on Debian. Anyway, here are the
results:
bash grep xz
710838 42236 m68k
748354 159304 40930 vax
829077 176836 42840 amd64
855400 164188 aarch64
877284 186924 48032 sparc
882847 187203 49866 i386
898532 179844 earmv7hf
962128 205776 54704 powerpc
1004864 192256 53632 sparc64
1025136 51160 mips64eb
1147664 232688 63456 alpha
1172692 mipsel
I did not find packages for everything on all architectures. In
particular, I did not find packages for gzip on vax, so I used xz
instead.
So VAX is indeed a leading architecture in terms of code size, at
least if ARM T32 and RISC-V C is not in play.
Here are the scripts I used:
for i in aarch64 alpha amd64 earmv7hf i386 m68k mips64eb mipsel powerpc sparc sparc64 vax; do mkdir -p $i/unpacked; (cd $i; for j in bash-5.2.37.tgz grep-3.11.tgz xz-5.6.2.tgz; do wget https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$i/10.1/All/$j; done); done
This did not get everything, because some packages are in other
version directories or have other version "numbers", so I manually
searched for and downloaded some of the packages. Next time I should
leave some of that to wget, see
<https://superuser.com/questions/1424700/wget-download-all-files-starting-with-a-specified-name>.
for i in aarch64 alpha amd64 earmv7hf m68k mips64eb mipsel powerpc sparc sparc64 vax; do echo $i; mkdir -p $i/unpacked; (cd $i; for j in *.tgz; do (cd unpacked; if gzip -t ../$j; then tar xfz ../$j 2>/dev/null; else tar xfJ ../$j 2>/dev/null; fi); done); done
for i in *; do (cd $i/unpacked/bin; for j in bash ggrep xz; do if test -f $j; then objdump -h $j|awk --non-decimal-data '/[.]text/ {printf("%8d ","0x"$3)}'; else echo -n " "; fi; done); echo $i; done|sort -n
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-03 17:53 +0000 |
| Message-ID | <vq4qav$1dksd$1@dont-email.me> |
| In reply to | #110932 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > MarkC <usenet@em-ess-see-twenty-seven.me.uk> writes: >>NetBSD still has a VAX port, so the sizes of pre-built packages from >>there might be informative. > > Thanks. The NetBSD pkgsrc is not limited to NetBSD, and there is a > wide variety of prebuilt stuff there. I took those that sound like > architecture names (and probably belong to NetBSD): aarch64 alpha > amd64 earmv7hf i386 m68k mips64eb mipsel powerpc sparc sparc64 vax > > Unfortunately, they do not seem to port to RISC-V in any form yet, and > their earmv7hf port uses ARM A32, not T32. So the NetBSD competition > is performed without entries for those two instruction set encodings > that showed the smallest code sizes on Debian. Anyway, here are the > results: > > bash grep xz > 710838 42236 m68k > 748354 159304 40930 vax > 829077 176836 42840 amd64 > 855400 164188 aarch64 > 877284 186924 48032 sparc > 882847 187203 49866 i386 > 898532 179844 earmv7hf > 962128 205776 54704 powerpc > 1004864 192256 53632 sparc64 > 1025136 51160 mips64eb > 1147664 232688 63456 alpha > 1172692 mipsel Utilities are often compiled with a medium to high level of optimizationo (like -O2), which can do loop unrolling, inlining and function cloning, all of which can increase code size. These decisions can also depend on the number of available register. If your aim is small code size, it is better to compare output compiled with -Os.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-03 23:23 +0000 |
| Message-ID | <vq5dm2$1h3mg$5@dont-email.me> |
| In reply to | #110936 |
On Mon, 3 Mar 2025 17:53:35 -0000 (UTC), Thomas Koenig wrote: > If your aim is small code size, it is better to compare output compiled > with -Os. Then it becomes an artificial benchmark, trying to minimize code size at the expense of real-world performance. Remember, VAX was built for real-world use, not for academic benchmarks.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-04 03:04 -0600 |
| Message-ID | <vq6fov$1pvq9$1@dont-email.me> |
| In reply to | #110945 |
On 3/3/2025 5:23 PM, Lawrence D'Oliveiro wrote:
> On Mon, 3 Mar 2025 17:53:35 -0000 (UTC), Thomas Koenig wrote:
>
>> If your aim is small code size, it is better to compare output compiled
>> with -Os.
>
> Then it becomes an artificial benchmark, trying to minimize code size at
> the expense of real-world performance.
>
> Remember, VAX was built for real-world use, not for academic benchmarks.
Yeah, they are not exactly the same...
FWIW:
In my own past testing, the general leaders in terms of code density
were Thumb2 and 32-bit i386.
People claim RV32GC matches Thumb2 here, my own experience seems to
disagree.
Though, while Thumb2 code is small, it isn't necessarily particularly fast.
Though, from what I can gather, it is pretty close performance-wise
between Thumb2 and RV32GC or similar.
Previously I had thought x86-64 was doing unreasonably bad with code
density, but have since realized it is partly a choice of compiler and
compiler options (and it can actually do pretty well here).
Though, can note:
-O3 vs -Os makes relatively little difference on RISC-V;
It makes a big difference for x86-64:
There is also a pretty notable speed difference between -O3 and -Os as
well with x86-64 ("-O3" tending to be a fair bit faster). Where, for
size-optimized x86-64 had used "-Os -ffunction-sections -fdata-sections
-Wl,-gc-sections".
For modern MSVC (mostly running VS 2022), code is bloated regardless of
settings ("/Os" exists but is seemingly mostly equivalent to "/O1").
Both are a little smaller than "/O2", but the generated code is still
quite large.
Seemingly, older versions (such as VS 2008) did much better here.
Though, the newer versions have other advantages:
C99 support;
Better performance for compiled code;
...
Though, I ended up going the opposite direction (making choices to try
to favor speed over code density) and seemingly have ended back at
having moderately good code density for XG2 and XG3 despite the lack of
16-bit instructions (they are primarily 32/64 rather than 16/32).
Theoretically, an "/Os" option exists for BGBCC, but doesn't actually
accomplish much with XG2 or XG3, as a lot of the settings it tweaked are
mostly N/A for these.
Well, main things it effects are mostly:
Cut-off point between inline memcpy and emitting a function call;
Whether to use a single or multiple conditional branches for a loop;
...
It would alter register allocation heuristics, say:
Low pressure:
Only enable R8..R14 for register allocation;
Medium Pressure:
Enable R24..R31;
High pressure:
Enable R40..R47 and R56..R63;
The optimization settings would adjust the cut-off points.
With XG1, register choice would effect needed instruction lengths in
many cases.
R8..R14: Accessible from 16-bit ops;
R24..R31: Accessible from 32-bit ops;
Others: May require 64-bit encodings.
This becomes N/A, as the newer ISA variants always use the same encoding
length regardless of register used.
But, yeah, rough code-density ranking (best to worst, with Doom ".text"
sizes in kB):
XG1 (263)
XG2 (296)
XG3 (324)
XG1_Fix32 (347, *1)
RV64G+Jx (359)
RV64GC (371)
RV64G (449)
*1: Note that XG1_Fix32 represents a common subset of XG1 and XG2,
lacking 16-bit ops, but also always needing to use jumbo prefixes to
encode R32..R63.
For reference, an x86-64 "-O3" build is 244K here, but may not count as
it is using a dynamically-linked C library. Also, x86-64 has a far more
complex instruction encoding scheme (vs either BJX2 or RISC-V).
If ranking in terms of performance (best to worst, Doom framerate):
XG2 (25 fps)
XG3 (23 fps)
XG1_Fix32 (21 fps)
RV64G+Jx (20 fps)
XG1 (18 fps)
RV64G (17 fps)
RV64GC (14 fps)
(Framerate given as the value at the start of E1M1).
In many cases, performance has ended up as a higher priority than code
density.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-04 10:04 +0000 |
| Message-ID | <2025Mar4.110420@mips.complang.tuwien.ac.at> |
| In reply to | #110945 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >On Mon, 3 Mar 2025 17:53:35 -0000 (UTC), Thomas Koenig wrote: > >> If your aim is small code size, it is better to compare output compiled >> with -Os. > >Then it becomes an artificial benchmark, trying to minimize code size at >the expense of real-world performance. > >Remember, VAX was built for real-world use, not for academic benchmarks. And supposedly the real-world constraints at the time made it necessary to minimize code size. In the current discussion we look at how RV32GC might have fared under this constraint. So compiling for small code size could be a way to find that out. Whether -Os really achives that is another question (some earlier things I have seen and discussed here make me doubt 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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-04 23:27 +0000 |
| Message-ID | <vq829a$232tl$6@dont-email.me> |
| In reply to | #110953 |
On Tue, 04 Mar 2025 10:04:20 GMT, Anton Ertl wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> >>On Mon, 3 Mar 2025 17:53:35 -0000 (UTC), Thomas Koenig wrote: >> >>> If your aim is small code size, it is better to compare output >>> compiled with -Os. >> >> Then it becomes an artificial benchmark, trying to minimize code size >> at the expense of real-world performance. >> >> Remember, VAX was built for real-world use, not for academic >> benchmarks. > > And supposedly the real-world constraints at the time made it necessary > to minimize code size. Remember, RAM was much more expensive back then. For comparison, when Data General started their “Eagle” project (as chronicled in Tracy Kidder’s book “The Soul Of A New Machine”), which finally shipped as the MV/8000, they decided that having a full 32-bit address, VAX-style, was unnecessary, so they used some of those bits--4, I think--to hold privilege levels. Overall, they managed to end up with a simpler architecture than VAX. But it ran out of address space a little bit sooner. > In the current discussion we look at how RV32GC might have fared under > this constraint. Sure. Except you need a much more complicated and resource-hungry compiler than would have been reasonable to run on a VAX back then.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-05 07:36 +0000 |
| Message-ID | <2025Mar5.083636@mips.complang.tuwien.ac.at> |
| In reply to | #110960 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> In the current discussion we look at how RV32GC might have fared under
>> this constraint.
>
>Sure. Except you need a much more complicated and resource-hungry compiler
>than would have been reasonable to run on a VAX back then.
Looking at compiler technology available in 1975 close to DEC
[wulf+75] (highly recommended), I don't think so. RISC-V code size
(as well as VAX code size) benefits from register allocation (existent
in that compiler, running on the PDP11). Instruction scheduling would
have been helpful for performance, but would not help code size, and
is not particularly complex or resource-hungry when done on the
basic-block level (good enough for single-issue RISCs).
By contrast, making good use of the complex instructions of VAX in a
compiler consumed significant resources (e.g., Figure 2 of
https://dl.acm.org/doi/pdf/10.1145/502874.502876 reports about a
factor 1.5 more code in the code generator for VAX than for RISC-II).
Compilers at the time did not use the CISCy features much, which is
one reason why the IBM 801 project and later the Berkeley RISC and
Stanford MIPS proposed replacing them with a load/store architecture.
I think that a lot of that is inherent, but a part of it may be due to
the state of the art in instruction selection at the time. So RISC
code comes easily out of compiler technology of the time, and for
smaller code, you just have to perform register allocation, which was
possible at the time, as demonstrated by Wulf et al.
@Book{wulf+75,
author = {William Wulf and Richard K. Johnsson and Charles
B. Weinstock and Steven O. Hobbs and Charles M. Geschke},
title = {The Design of an Optimizing Compiler},
publisher = {Elsvier},
year = {1975},
isbn = {0-444-0164-6},
annote = {Describes a complete Bliss/11 compiler for the
PDP-11. It uses some interesting techniques: it
uses a (hand-constructed) tree parsing automaton for
parts of the code selection (Section~3.4); it
optimizes the use of unary complement operators
(Section~3.3); it uses a smart scheme to represent
a conservative approximation of the lifetime of
variables in constant space and uses that for
register allocation (Sections~4.1.3 and~4.3).}
}
- 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-06 02:30 +0000 |
| Message-ID | <vqb1cv$vq5$1@gal.iecc.com> |
| In reply to | #110964 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >By contrast, making good use of the complex instructions of VAX in a >compiler consumed significant resources (e.g., Figure 2 of >https://dl.acm.org/doi/pdf/10.1145/502874.502876 reports about a >factor 1.5 more code in the code generator for VAX than for RISC-II). >Compilers at the time did not use the CISCy features much, which is >one reason why the IBM 801 project and later the Berkeley RISC and >Stanford MIPS proposed replacing them with a load/store architecture. I'm not so sure. The IBM Fortran H compiler used a lot of the 360's instruction set and it is my recollection that even the dmr C compiler would generate memory to memory instructions when appropriate. The PL.8 compiler generated code for 5 architectures including S/360 and 68K, and I think I read somewhere that its S/360 code was considrably better than the native PL/I compilers. I get the impression that they found that once you have a reasonable number of registers, like 16 or more, the benefit of complex instructions drops because you can make good use of the values in the registers. -- 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 | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-03-06 16:11 -1000 |
| Message-ID | <877c51mvy4.fsf@localhost> |
| In reply to | #110977 |
John Levine <johnl@taugh.com> writes: > I'm not so sure. The IBM Fortran H compiler used a lot of the 360's instruction > set and it is my recollection that even the dmr C compiler would generate memory > to memory instructions when appropriate. The PL.8 compiler generated code for 5 > architectures including S/360 and 68K, and I think I read somewhere that its > S/360 code was considrably better than the native PL/I compilers. > > I get the impression that they found that once you have a reasonable number of > registers, like 16 or more, the benefit of complex instructions drops because > you can make good use of the values in the registers. long ago and far away ... comparing pascal to pascal front-end with pl.8 back-end (3033 is 370 about 4.5MIPS) Date: 8 August 1981, 16:47:28 EDT To: wheeler the 801 group here has run a program under several different PASCAL "systems". The program was about 350 statements and basically "solved" SOMA (block puzzle..). Although this is only one test, and all of the usual caveats apply, I thought the numbers were interesting... The numbers given in each case are EXECUTION TIME ONLY (Virtual on 3033). 6m 30 secs PERQ (with PERQ's Pascal compiler, of course) 4m 55 secs 68000 with PASCAL/PL.8 compiler at OPT 2 0m 21.5 secs 3033 PASCAL/VS with Optimization 0m 10.5 secs 3033 with PASCAL/PL.8 at OPT 0 0m 5.9 secs 3033 with PASCAL/PL.8 at OPT 3 -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-08 07:27 +0000 |
| Message-ID | <vqgrhi$1o8f$1@dont-email.me> |
| In reply to | #110980 |
Lynn Wheeler <lynn@garlic.com> schrieb: > long ago and far away ... comparing pascal to pascal front-end with > pl.8 back-end (3033 is 370 about 4.5MIPS) > > Date: 8 August 1981, 16:47:28 EDT > To: wheeler > > the 801 group here has run a program under several different PASCAL > "systems". The program was about 350 statements and basically > "solved" SOMA (block puzzle..). Although this is only one test, and > all of the usual caveats apply, I thought the numbers were > interesting... The numbers given in each case are EXECUTION TIME ONLY > (Virtual on 3033). > > 6m 30 secs PERQ (with PERQ's Pascal compiler, of course) > 4m 55 secs 68000 with PASCAL/PL.8 compiler at OPT 2 > 0m 21.5 secs 3033 PASCAL/VS with Optimization > 0m 10.5 secs 3033 with PASCAL/PL.8 at OPT 0 > 0m 5.9 secs 3033 with PASCAL/PL.8 at OPT 3 Interesting figures. there is a factor of 50 of 68000 vs the 3033, which was in the ~1 MIPS range, with the same compiler technology.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-03-07 02:27 +0000 |
| Message-ID | <vqdljd$29f8f$2@paganini.bofh.team> |
| In reply to | #110964 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> By contrast, making good use of the complex instructions of VAX in a
> compiler consumed significant resources (e.g., Figure 2 of
> https://dl.acm.org/doi/pdf/10.1145/502874.502876 reports about a
> factor 1.5 more code in the code generator for VAX than for RISC-II).
> Compilers at the time did not use the CISCy features much, which is
> one reason why the IBM 801 project and later the Berkeley RISC and
> Stanford MIPS proposed replacing them with a load/store architecture.
VAX intstructions are very complex and much of that complexity
is hard to use in compilers. But even extremaly simple compiler
can generate load-op combinations decreasing number of instructions.
Rather simple hack is enough to combine additions in address
artihmetic into addressing mode. Also, operations with two or three
memory addresses are easy to generate from compiler. I think
that chains of pointer dereferences in C should be not hard to
convert to indirect addressing mode.
I think that state of chip technology was more important. For
example 486 has RISC-like pipeline with load-ops, but load-ops
take the same time as two separate instructions. Similarly,
operations on memory take the same time as load-op-store.
So there were no execution time gain from combined instructions
and clearly some complication compared to load/store
architecture. Main speed gain of RISC came from having
pipeline on a chip (multichip processors were pipelined,
but expensive, earlier single chip ones had no pipeline).
So load/store architecture (and no microcode) meant that
early RISC could offer good pipeline earlier.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-07 04:09 +0000 |
| Message-ID | <vqdrh9$3cdrc$1@dont-email.me> |
| In reply to | #110981 |
On Fri, 7 Mar 2025 02:27:59 -0000 (UTC), Waldek Hebisch wrote: > VAX intstructions are very complex and much of that complexity is hard > to use in compilers. A lot of them mapped directly to common high-level operations. E.g. MOVC3/ MOVC5 for string copying, and of course POLYx for direct evaluation of polynomial functions. In a way, one could say that, in many ways, VAX machine language was a higher-level language than Fortran.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-07 05:08 -0600 |
| Message-ID | <vqek6h$3fro6$1@dont-email.me> |
| In reply to | #110982 |
On 3/6/2025 10:09 PM, Lawrence D'Oliveiro wrote:
> On Fri, 7 Mar 2025 02:27:59 -0000 (UTC), Waldek Hebisch wrote:
>
>> VAX intstructions are very complex and much of that complexity is hard
>> to use in compilers.
>
> A lot of them mapped directly to common high-level operations. E.g. MOVC3/
> MOVC5 for string copying, and of course POLYx for direct evaluation of
> polynomial functions.
>
> In a way, one could say that, in many ways, VAX machine language was a
> higher-level language than Fortran.
In a lot of this, it is almost a mystery if one could get something
similar with a simpler/cheaper ISA by having a pseudo-instruction that
does, say:
Move two register inputs to fixed special registers;
Branch to a location within a table supplied in another SPR.
Say:
RTTCALL 27, R18, R20
Which does the functional equivalent of, say, in RV terms:
MV X10, X18
MV X11, X20
JALR X1, 108(RTT)
Where RTT is a dedicated "Runtime Table" register (that is hard-coded in
the decoder logic).
...
In other news, got around to implementing the BITMOV logic in BGBCC and
similar, and implementing support for Verilog style notation.
So, writing things like:
y[55:48]=x[19:12];
Is now technically possible in my C variant, and (if the BITMOV
instruction is enabled) be encoded in a single instruction.
Where:
y[55:48]=x[19:12];
Is 1 instruction, main requirement is that the source and destination
bitfield are the same width (widening will require multiple ops).
If the instruction is not enabled, the fallback path is 4 to 6
instructions (in BJX2), or around 12 to 16 instructions for RV64G. I
decided to also add support for BITMOV to the RV decoder via my
jumbo-extension encodings (though, with some limitations on the 128-bit
case due to it needing to fit into a 21 bit immediate).
And:
j=x[19:12];
Also a single instruction, or 2 or 3 in the fallback case (encoded as a
shift and mask).
It is possible I could add something to infer a BITMOV from
"(x>>SHL)&MASK", though inferring bitfield insert is likely to be too
difficult for now.
At present, XG3 and RV will have a slight advantage over XG1 and XG2 for
this instruction in that they have access to a zero register, which
as-is doing a bitfield extract via BITMOV will require having access to
0. I am half tempted to consider whether it may make sense to
special-case the decoding to interpret R1 on the Ro/Rp input as meaning
ZZR (well, or just live with the compiler needing to load 0 into a
register to use it as a bitfield extract, albeit slightly diminishing
its advantage over shift+mask in this case; though, statistically, 0 is
likely to have already been loaded into a register either way).
For a simple test:
lj[ 7: 0]=li[31:24];
lj[15: 8]=li[23:16];
lj[23:16]=li[15: 8];
lj[31:24]=li[ 7: 0];
Does seem to compile down to 4 instructions.
Though, looking at the compiler code, it would be subject to the "side
effects in lvalue may be applied twice" bug:
(*ct++)[19:12]=(*cs++)[15:8];
Will result in the 'ct++' part happening twice (this is a pesky bug that
is prone to reappear). Though, a lazy option could be, since this is a
weird extension anyways, to simply claim it as undefined if the lvalue
expression has side effects.
Maybe will add, say:
(_BitInt(N)) { x, y, z };
Some uncertainties remain for how to approach adding VL support to BGBCC:
How to best approach instantiating modules;
How to best deal with "always" blocks;
High-level control flow is very different in Verilog vs C;
How to best deal with 'case' and 'casez'.
They don't exactly match up 1:1 with a C switch block.
It may make sense to special-case some "case()" blocks into lookup
tables. In small cases, "casez" could be turned into a lookup table or a
generic switch, but other cases might require linear pattern matching,
which would be slow...
I have some ideas for special cases, not no idea for a good "generic
case" strategy that would be much faster than O(n) ...
Best I can come up with is:
Walk all patterns, generate a mask of used bits;
Generate a hash table of (bits&mask) pointing to a "guess" entry;
Iterating over every possible bit-pattern.
Only hitting for the first matching entry.
If guessed match fails, it falls back to a linear search.
Landing on the first possible match and then doing a linear search for
subsequent matches has usually worked in the past. Worst case is still a
linear search though. Since casez patterns are formally not allowed to
overlap, it should be possible to sort them into ascending order (which
may reduce the probability of adverse cases) but is debatable.
Either way, it is a lot more complicated than a normal "switch()".
For module instantiation:
Probably the module itself is compiled with each "always @*" block or
similar as a function;
Any "assign" statements can probably also be lumped together;
The module instance is itself turned into an object instance, with all
of its registers as object fields;
The blocks are then essentially virtual methods.
The most naive way to do this:
Each module has an implicit "Run()" methods, which runs all of the
always blocks, and selectively runs "posedge" or "negedge" blocks if the
selected clock has changed (afterwards, the new clock is assigned to a
variable holding the last-known value, so that the posedge/negedge only
triggers when the value changes).
But, I am starting to have doubts as to the sanity of trying to add
support for Verilog to BGBCC...
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-07 17:34 +0000 |
| Message-ID | <fe70b48cd6fef0aaf89278163d8b6322@www.novabbs.org> |
| In reply to | #110984 |
On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote: > On 3/6/2025 10:09 PM, Lawrence D'Oliveiro wrote: ---------------- > > So, writing things like: > y[55:48]=x[19:12]; 2 instructions in My 66000. One extract, one insert. > > And: > j=x[19:12]; > Also a single instruction, or 2 or 3 in the fallback case (encoded as a > shift and mask). 1 instruction--extract (SLL or SLA) ---------------------- > > For a simple test: > lj[ 7: 0]=li[31:24]; > lj[15: 8]=li[23:16]; > lj[23:16]=li[15: 8]; > lj[31:24]=li[ 7: 0]; > Does seem to compile down to 4 instructions. 1 innstruction:: BITR rd,rs1,<8> > Though, looking at the compiler code, it would be subject to the "side > effects in lvalue may be applied twice" bug: > (*ct++)[19:12]=(*cs++)[15:8]; 5 instructions:: LD, LD, EXT, INS, ST; with deferred ADD to Rcs and Rct.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-07 13:27 -0500 |
| Message-ID | <vqfdpr$3lctl$2@dont-email.me> |
| In reply to | #110988 |
On 2025-03-07 12:34 p.m., MitchAlsup1 wrote: > On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote: > >> On 3/6/2025 10:09 PM, Lawrence D'Oliveiro wrote: > ---------------- >> >> So, writing things like: >> y[55:48]=x[19:12]; > > 2 instructions in My 66000. One extract, one insert. Ibid for Q+. The logic for an extract and insert as one operation might add to the timing. Extract, sign/zero extend and copy back. Fields may be different sizes. > >> >> And: >> j=x[19:12]; >> Also a single instruction, or 2 or 3 in the fallback case (encoded as a >> shift and mask). > > 1 instruction--extract (SLL or SLA) Q+ has EXT/EXTU which is basically a SRL or SRA with mask applied afterwards. PowerPC has a rotate-left-and-mask instruction. In my opinion it makes more sense for extracts to be shifting right. Not sure yet how this will be handled in Q+2. SRLPAM (shift right pair and mask), but I ran out of opcode bits. There are only four bits available to represent the mask field, but a 15-bit wide field might be enough to be useful most of the time. Can always code more than one instruction to get beyond 15 bits. > > ---------------------- >> >> For a simple test: >> lj[ 7: 0]=li[31:24]; >> lj[15: 8]=li[23:16]; >> lj[23:16]=li[15: 8]; >> lj[31:24]=li[ 7: 0]; >> Does seem to compile down to 4 instructions. Some work in the peephole optimizer might be able to reduce this. > > 1 innstruction:: BITR rd,rs1,<8> > >> Though, looking at the compiler code, it would be subject to the "side >> effects in lvalue may be applied twice" bug: >> (*ct++)[19:12]=(*cs++)[15:8]; > > 5 instructions:: LD, LD, EXT, INS, ST; with deferred ADD to Rcs and Rct.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-07 20:07 +0000 |
| Message-ID | <a19b814f567a54ee19c1e3d2c41505a7@www.novabbs.org> |
| In reply to | #110990 |
On Fri, 7 Mar 2025 18:27:06 +0000, Robert Finch wrote: > On 2025-03-07 12:34 p.m., MitchAlsup1 wrote: >> On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote: >> >>> On 3/6/2025 10:09 PM, Lawrence D'Oliveiro wrote: >> ---------------- >>> >>> So, writing things like: >>> y[55:48]=x[19:12]; >> >> 2 instructions in My 66000. One extract, one insert. > > Ibid for Q+. The logic for an extract and insert as one operation might > add to the timing. Extract, sign/zero extend and copy back. Fields may > be different sizes. > >> >>> >>> And: >>> j=x[19:12]; >>> Also a single instruction, or 2 or 3 in the fallback case (encoded as a >>> shift and mask). >> >> 1 instruction--extract (SLL or SLA) > > Q+ has EXT/EXTU which is basically a SRL or SRA with mask applied > afterwards. PowerPC has a rotate-left-and-mask instruction. In my > opinion it makes more sense for extracts to be shifting right. Both SR and SL have both sign control and masking.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-07 15:00 -0600 |
| Message-ID | <vqfmr4$3npgk$1@dont-email.me> |
| In reply to | #110988 |
On 3/7/2025 11:34 AM, MitchAlsup1 wrote: > On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote: > >> On 3/6/2025 10:09 PM, Lawrence D'Oliveiro wrote: > ---------------- >> >> So, writing things like: >> y[55:48]=x[19:12]; > > 2 instructions in My 66000. One extract, one insert. > 1 instruction in this case... The 3 sub-fields being, 36, 48, and 56. The way I defined things does mean adding 1 to the high bit in the encoding, so 63:56 would be expressed as 64:56, which nominally uses 1 more bit of range. Though, if expressed in 6 bits, the behavior I had defined it as, effectively causes it to be modulo. Though, ironically, while I could have eliminated the "off by 1" for the high index encoding, this would also implicitly disallow the ability to express modulo (wrap around) bitfields. So, it seemed like a reasonable tradeoff (even if wraparound bitfields aren't really a thing). In the layout for my ISA, I had uses 8,8,8 because I had the bits, and this allows the same layout for both 64 and 128 bit operations. Though, 8,7,7 would have also worked. For RV+Jx, there weren't quite enough bits. So, it instead used 8,6,6,1; for the 64-bit case it functions as a modulo ring. For the 128-bit case there is some wonk: Hi>=Lo: Extra bit is added to high bit of both; Else: Extra bit is added to high bit of high. This leaves modulo wraparound as N/E for 128-bits, but likely wraparound is going to be a rare edge case. Within BGBCC, it internally uses 16.16.16 for the IR stage, but mostly because this allows for potentially large _BitInt vectors. Though, bit vectors larger than 128 bits, or bitfields larger than 64, wont be directly supported at the ISA level (and will need to be faked by the compiler). But, in Verilog, it is not uncommon to go well outside of the usual 64-bit limit that C typically imposes. But, "32kb" in a single bit-vector should probably be enough for anyone... >> >> And: >> j=x[19:12]; >> Also a single instruction, or 2 or 3 in the fallback case (encoded as a >> shift and mask). > > 1 instruction--extract (SLL or SLA) > BITMOV, parameters being -12, 0, 8. But, does require a register holding 0 as input at present for XG1 and XG2. Fallback cases: SHAD.Q Rm, -12, Rt AND Rt, 255, Rd And: SRLI Rt, Rm, 12 ANDI Rd, Rt, 255 > ---------------------- >> >> For a simple test: >> lj[ 7: 0]=li[31:24]; >> lj[15: 8]=li[23:16]; >> lj[23:16]=li[15: 8]; >> lj[31:24]=li[ 7: 0]; >> Does seem to compile down to 4 instructions. > > 1 innstruction:: BITR rd,rs1,<8> > In this particular case, there is also a SWAP.L instruction, but I was ignoring it for sake of this example, and my compiler isn't that clever. It was already an ugly chunk of code to get it to recognize the above cases as single-instruction encodings. I went the route of adding Verilog style syntax as for now, inferring all this from shifts and masks would be asking too much from my compiler... >> Though, looking at the compiler code, it would be subject to the "side >> effects in lvalue may be applied twice" bug: >> (*ct++)[19:12]=(*cs++)[15:8]; > > 5 instructions:: LD, LD, EXT, INS, ST; with deferred ADD to Rcs and Rct. Ideally, one would have: LD, LD, BITMOV, ST, ADD, ADD However, there is going to be an issue with the logic-structure in my compiler in this case: LD, ADD, LD, ADD, BITMOV, ST, ADD In the past, for operators like "+=" and similar, there was a workaround, effectively detecting the non-clean expression and compiling it as: tmp=&(*ct++); *tmp=*tmp+val; But, haven't yet added this special case for the bit handling. It is a pesky issue, that reappears readily... I am debating if it is worthwhile to deal with in this case, or if I should maybe just be lazy and do the "detect and issue a warning or error" thing instead (the proper workaround is fairly awkward, and this is likely a fairly obscure edge case). I mostly added this for sake of possible Verilog support, and this is an edge case that can't happen in Verilog. Unlike Verilog, in C mode it will currently require single-bit fetch to use a notation like x[17:17], but this is more because a person is much more likely to type "x[17]" by accident (such as by using the wrong variable, a missing '*', or ...). I am considering adding something to infer bitfield extract from "((x>>SHR)&MASK)". Will likely need to use a different sub-operator though, mostly because the type of the original expression would likely be "int" or similar, and at present the bit-extract operator will give a type of '_BitInt(N)' which is not quite the same. One uncertainty at present is whether register declarations with a non-zero low bit are actually a thing: reg[23: 8] wackyVar1; reg[11:-4] wackyVar2; It would simplify things a fair bit if I can just pretend these cases do not exist... (then everything can mostly just decay into the existing _BitInt type internally). Well, along with an open question of how much the compiler needs to distinguish reg/wire/input/output. Can maybe ignore "inout" as Verilator doesn't support it, and for this I mostly only care about supporting similar functionality to Verilator (so, tristate logic will probably not be a thing in most cases). Expressions like "16'h4zz6" will need to be able to remember it, current thinking is that these will be a special literal integer pair type, representing each bit as 2 bits, say: 00: 0, 01: 1, 10: Z, 11: X They will matter for "casez" or similar, but in other cases will just decay into just the value bits. Though, input/output distinction would be needed for module ports, so I may need something here. Could almost just repurpose signed _BitInt for output, except that (annoyingly) a semantic distinction between signed and unsigned values does exist in SystemVerilog. So, at a least, may need a new subtype of BitInt for "output". But could maybe get by with dropping the distinction between "reg"/"wire"/"input", like was the case in older versions of Verilator. These distinctions don't matter as much if running Verilog on a CPU. Well, and probably also working on fixing the "fast" mode for JX2VM (emulator performance hasn't been a particularly high priority here; but would matter a bit more if using it for Verilog simulation). Well, with the goal of it being hopefully possible to throw some sort of source-level debugging on this stuff. Debugging with Verilator is currently a problem, as trying to navigate through undocumented auto-generated C++ confetti in GDB isn't particularly workable. Like, if I could just do something like (in GDB): (break simulation via CTRL-C or similar) print top->cpu->regGpr->gprArrA[7] I would have much less reason to complain... Much less practical to dig through ~ 10MB of generated C++ to try to figure out how it has mangled the names and/or seemingly decomposed a lot of the modules to merge them all into some big mass of code. Say, if every module mapped 1:1 with a class, and every module instance was an object instance, would be less of an issue (and I would probably have less of a reason to bother). ...
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-07 22:51 +0000 |
| Message-ID | <dd54322f623ee8b0bfde844042747071@www.novabbs.org> |
| In reply to | #110997 |
On Fri, 7 Mar 2025 21:00:09 +0000, BGB wrote: > On 3/7/2025 11:34 AM, MitchAlsup1 wrote: >> On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote: >> >>> On 3/6/2025 10:09 PM, Lawrence D'Oliveiro wrote: >> ---------------- >>> >>> So, writing things like: >>> y[55:48]=x[19:12]; >> >> 2 instructions in My 66000. One extract, one insert. >> > > 1 instruction in this case... > > The 3 sub-fields being, 36, 48, and 56. > > The way I defined things does mean adding 1 to the high bit in the > encoding, so 63:56 would be expressed as 64:56, which nominally uses 1 > more bit of range. Though, if expressed in 6 bits, the behavior I had > defined it as, effectively causes it to be modulo. My 66000 uses the same trick, allowing both 64 and 0 to indicate 64-bits. >> ---------------------- >>> >>> For a simple test: >>> lj[ 7: 0]=li[31:24]; >>> lj[15: 8]=li[23:16]; >>> lj[23:16]=li[15: 8]; >>> lj[31:24]=li[ 7: 0]; >>> Does seem to compile down to 4 instructions. >> >> 1 innstruction:: BITR rd,rs1,<8> >> > > In this particular case, there is also a SWAP.L instruction, but I was > ignoring it for sake of this example, and my compiler isn't that clever. ------------ > > Unlike Verilog, in C mode it will currently require single-bit fetch to > use a notation like x[17:17], but this is more because a person is much > more likely to type "x[17]" by accident (such as by using the wrong > variable, a missing '*', or ...). I use <1,16> where the first is the length of the field, and the second is the offset from bit<0>.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-07 18:40 -0500 |
| Message-ID | <vqg04o$3p80h$1@dont-email.me> |
| In reply to | #110997 |
> But, in Verilog, it is not uncommon to go well outside of the usual 64- > bit limit that C typically imposes Yes, all kinds of hardware structures use bit vectors >64. They also tend to have a reasonable upper limit as muxing from a bit vector can be expensive. > > But, "32kb" in a single bit-vector should probably be enough for anyone... > I would be tempted to allow an 'int' (size_t?) to be used for the size. For software bit vectors could be larger than for hardware. For example, I used a bit-pair vector to hold a ternary value representing memory pages for something called a page-allocation-map (PAM) which tracks which pages are allocated or free, and the end of an allocation. There could be a lot of pages in a large memory system. Scanning the bit-pair vector could be done mostly a word-at-a-time. Same thing could be done for disk pages.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-07 20:49 -0600 |
| Message-ID | <vqgbao$3rbkh$1@dont-email.me> |
| In reply to | #111003 |
On 3/7/2025 5:40 PM, Robert Finch wrote:
>> But, in Verilog, it is not uncommon to go well outside of the usual
>> 64- bit limit that C typically imposes
>
> Yes, all kinds of hardware structures use bit vectors >64. They also
> tend to have a reasonable upper limit as muxing from a bit vector can be
> expensive.
>
In my own Verilog code, I rarely go over 128 bit, but a few 512 bit
vectors are used.
This leaves 512 or 1024 as the lower-end of a vector-size limit.
Something like 32kb is well over this.
The way types are encoded has an implicit limit of 4kb before it needs
to go to an overflow type.
Say:
(11: 0): Base Type
000..0FF: Primitive Types
100..FFF: Complex/Structure Types
(15:12): Pointer Indirection Level or Array/Ref Type.
(27:16): Array Size (also used for _BitInt size)
(31:28): Type-Type Tag
There is a type that has larger arrays (up to 1M elements), but only
supports a subset of the primitive types.
Some primitive types may appear multiple types, differing in terms of
things like alignment or volatile status.
Another variant has a larger type fields, but only supports small arrays
(this case mostly comes up once the compiler gets beyond 3840
struct/union/etc types; can actually happen in practice, though one big
offender here is "GL/gl.h" defining a crapton of function-pointer types...).
In other cases, the type is expressed as an index into an array of types
whose type could not be described in one of the 32 bit formats.
>>
>> But, "32kb" in a single bit-vector should probably be enough for
>> anyone...
>>
> I would be tempted to allow an 'int' (size_t?) to be used for the size.
>
I had a 64-bit value field intended to hold an immediate value for a 3AC
operator, so I divided it into 3 parts for this operator.
3x 16b made sense as it was easy to unpack into 3 signed values (for
"technical reasons" also needs to be able to express negative values).
If needed, could switch to 1M as a limit (64/3 is 21 bits).
Can note that BGBCC can express larger literals (such as 128-bit
integers) but generally does so by encoding them as lookup table indices
(broken up into 64-bit chunks).
To go much bigger, would likely need to use multi-level indirection (or
switch to a different strategy for expressing large constants).
The variable fields can also express values:
temp/argument/local/global:
24 bit ID
12b index + 12b version got locals
24-bit global-ID for globals
32 bit type
8 bit tag
string literals use a similar format
Just encoding an index into a string table.
integer literals:
32-bit payload, 16-bit type (12b base, 4b level)
long/double literal:
56 bit value
(values that don't fit here are encoded as lookup table indices)
...
But, as such, memory use is still an issue.
Say, don't want to use lookup tables when it can be avoided, as this
requires memory.
But, can't really go much bigger than 32-bits for types, or 64-bits for
variable IDs, as this would eat a significant amount of memory in a part
of the compilers that already eats lots of RAM.
Similarly, don't want to increase the size of the 3AC operation
structure, ...
> For software bit vectors could be larger than for hardware. For example,
> I used a bit-pair vector to hold a ternary value representing memory
> pages for something called a page-allocation-map (PAM) which tracks
> which pages are allocated or free, and the end of an allocation. There
> could be a lot of pages in a large memory system. Scanning the bit-pair
> vector could be done mostly a word-at-a-time. Same thing could be done
> for disk pages.
>
Possibly, but not necessarily imagining that Verilog or similar would
make sense as a generic software programming language.
And, the bitfield stuff as-is wouldn't make sense for large bit arrays
(which as-is, only allows for constant bit offsets; most bitmap
use-cases tending to use a variable bit index).
I guess, while a person could do something like (in C):
_BitInt(1048576) bmp;
_Boolean b;
...
b=(bmp>>i)&1; //*blarg* (shift here would be absurdly expensive)
This is liklely to be rare vs more traditional strategies, say:
uint64_t *bmp;
int b, i;
...
b=(bmp[i>>6]>>(i&63))&1;
As well as the traditional strategy being a whole lot more efficient in
this case...
I guess the case could be made for a generic dense bit array.
Though, an open question is how one would define it in a way that is
consistent with existing semantics rules.
Note that a traditional array in Verilog is more like:
reg bitArray[1023:0];
But, this represents something conceptually different from a large bit
vector:
reg[1023:0] bitVec;
Even if it still allows:
b=bitVec[idx];
Hmm...
[toc] | [prev] | [next] | [standalone]
Page 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web