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 8 of 17 — ← Prev page 1 … 6 7 [8] 9 10 … 17 Next page →
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-07 17:19 -0600 |
| Message-ID | <vqfv0q$3oskp$2@dont-email.me> |
| In reply to | #110998 |
On 3/7/2025 4:25 PM, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>> On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote:
>>
>>> 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>
>
> Isn't that just 'bswap32' on x86, or REV32 on ARM64?
Technically yes, Or roughly BSWAPU.L in my ISA, or an older/dropped
SWAP.L (was later subsumed into PSHUF.B), ...
Where SWAP.L would reverse the 4 bytes in the low 32 bits, leaving the
high 32 bits as-is. This case largely got subsumed into PSHUF.B, which
can encode this pattern into the shuffle mask ("PSHUF.B Rm, 0x1B, Rn").
The newer BSWAPU.L instruction does similar, but also zero-extends the
result (with a BSWAP.Q instruction for a 64-bit swap).
This wasn't really the point though of this test...
I could have just as easily written:
lj[ 3: 0]=li[15:12];
lj[ 7: 4]=li[11: 8];
lj[11: 8]=li[ 7: 4];
lj[15:12]=li[ 3: 0];
Which doesn't map to an existing instruction...
Just, for sake of testing the feature, I wasn't being all that particular...
Only reason to stick to multiples of 4 bits here mostly to make it
easier to verify the results in a debug printf...
Ironically, have now spent far more time and energy writing about the
meta-issues with this test, than it took to write the test-case in the
first place (though, harder to rank it in terms of time/effort spent
debugging the feature in my compiler...). I guess, it would be funny if
the effort spent writing about the test for the feature ends up
exceeding the effort spent debugging the compiler output and similar for
said feature...
...
Which is kinda why I went for Verilog syntax rather than pattern
matching the ASTs. If I had gone the pattern-matching route, would
probably be still trying to debug it.
...
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-07 13:03 -0500 |
| Message-ID | <vqfce7$3lctl$1@dont-email.me> |
| In reply to | #110984 |
> 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). > I find these operations handy when dealing with I/O devices that have bitfields. It makes it easy to test bits and compiles to an extract instruction. inbyte = *irqport; if (inbyte[7]) <do something> Support for bitfield indexing (Verilog style) is in the Arpl compiler. I found there were enough differences from standard C I better call it a different name. > 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. >
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-07 16:57 -0600 |
| Message-ID | <vqftn5$3oskp$1@dont-email.me> |
| In reply to | #110989 |
On 3/7/2025 12:03 PM, Robert Finch wrote:
>> 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).
>>
> I find these operations handy when dealing with I/O devices that have
> bitfields. It makes it easy to test bits and compiles to an extract
> instruction.
>
> inbyte = *irqport;
> if (inbyte[7])
> <do something>
>
> Support for bitfield indexing (Verilog style) is in the Arpl compiler. I
> found there were enough differences from standard C I better call it a
> different name.
>
BGBCC mostly accepts standard C.
But, has some amount of potentially wacky non-standard extensions...
Though, it seems that the idea of bitfield instructions or gluing some
Verilog style functionality onto a C compiler isn't quite as crazy or
wacky as it may at first seem...
Then again, turns out even Thumb2 has bitfield instructions, so these
are not super rare (rarer though is having an explicit syntax for this
sort of stuff).
Likely, if it was "that" weird or obscure, they wouldn't have bothered
adding it.
Formally though, RISC-V still lacks them.
Apparently early forms of BitManip had considered them, but they were
dropped.
Like, bitfield helpers were too weird/obscure, but hard-coding parts of
the CRC or stuff related to DES encryption and similar into the ISA is
fine...
Like, it is kinda unbalanced:
Most "general use" features ended up being dropped, leaving most of it
(beyond Zba) as just sort of a grab-bag of very niche features, most of
which only being relevant to certain specific algorithms.
Like, it is a bit of a "stupid rebellion" if one ends up reviving
previously dropped instructions, like ADDWU, mostly because "ADD with
zero extension" is "something I actually have a use for...".
Well, and I guess because my design impetus is not to micro-optimize how
quickly the CPU can run specific benchmarks (say, adding or removing
instructions based on whether or not they benefit the CoreMark score...).
Granted, arguably, maybe tuning for Doom performance over weighs the
relative effect of register-indexed load/store and similar, but not
exactly like these are all that rare in non-Doom workloads.
...
>> 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.
>>
Apart from some special-case recognition logic, would have otherwise
needed 8 or 12...
Ended up adding special cases both for things like:
Both sides of the assignment is a bit vector;
And that the size matches up, etc.
Bit vector source/dest is a normal variable (common case).
If these fail, it falls back to more generic logic (and thus generating
more instructions in the final machine code).
Though, some of this is relevant for the "=" operator in general, which
has a whole lot of special-case pattern matching assigned to it.
Well, as dealing with assignment often isn't quite as simple as:
Compile RHS expression;
Store result value into LHS expression.
And, a "simple" solution like:
Take address of LHS;
Turn it into an operation on a pointer.
Wouldn't be acceptable as a general-case solution in most cases.
In many cases, taking the address of something results in adverse
penalties in other areas (requires it to exist in memory and then gets
aliasing pointer semantics involved, ...).
...
I kinda suspect there are no good simple/elegant solutions here, and
given how huge and complicated GCC is in these areas, I suspect they
mostly just went down the "brute force every scenario" path in most areas.
Like, every time you try to be "simple" in one place, it often pushes
the complexity somewhere else, so if anything it more turns into a game
of pushing it around and seeing what needs to deal with it (programmer,
compiler frontend, compiler backend, logic in the CPU, time itself, ...).
Like, seemingly, things like compiler logic are also subject to the laws
of entropy...
One could impose limits, but C has a long tradition of people being able
to do:
whatever=whatever;
With no real concern for the implicit entropy cost of having the ability
to do so...
Well, and seemingly the design of both compilers and CPU ISAs turning
into a problem of trying to twiddle stuff to reduce the implicit entropy
costs.
...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-08 01:02 +0000 |
| Message-ID | <vqg4v4$3q92q$3@dont-email.me> |
| In reply to | #111001 |
On Fri, 7 Mar 2025 16:57:31 -0600, BGB wrote: > Like, bitfield helpers were too weird/obscure, but hard-coding parts of > the CRC or stuff related to DES encryption and similar into the ISA is > fine... I blame C. The fact that C does not have built-in constructs to make convenient use of variable bitfields seems to be the main excuse for not supporting them in hardware instruction sets. And then in return, the lack of efficient support in hardware becomes an excuse for not having such constructs in the higher-level language.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-08 02:08 +0000 |
| Message-ID | <9383edc0934b8c8ef8d749004d1b6f35@www.novabbs.org> |
| In reply to | #111006 |
On Sat, 8 Mar 2025 1:02:29 +0000, Lawrence D'Oliveiro wrote: > On Fri, 7 Mar 2025 16:57:31 -0600, BGB wrote: > >> Like, bitfield helpers were too weird/obscure, but hard-coding parts of >> the CRC or stuff related to DES encryption and similar into the ISA is >> fine... > > I blame C. The fact that C does not have built-in constructs to make > convenient use of variable bitfields seems to be the main excuse for not > supporting them in hardware instruction sets. Way back in 1983, John Perry of Bell Northern Research convinced me to add the masker to the barrel shifter in Mc 88100, and I saw then and there that it was an advancement in the state of "shift instructions". C notwithstanding. > And then in return, the lack of efficient support in hardware becomes an > excuse for not having such constructs in the higher-level language. Same excuse as misaligned memory references--shortsightedness.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-07 17:35 +0000 |
| Message-ID | <b91f10d096ee24705d8ad4bcdcc831c8@www.novabbs.org> |
| In reply to | #110982 |
On Fri, 7 Mar 2025 4:09:13 +0000, 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. One could also say at that point in time that FORTRAN was not that high of a high level language.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-03-07 18:52 +0000 |
| Message-ID | <vqff9r$3m6kd$2@dont-email.me> |
| In reply to | #110987 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: > On Fri, 7 Mar 2025 4:09:13 +0000, 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. > > One could also say at that point in time that FORTRAN was not that high > of a high level language. It was high enough, right from the start, to abstract away a _lot_ of the machine, while still being quite efficient. "Since Fortran should virtually eliminate coding and debugging" was rather optimistic, though; programming tasks expanded too fast for that.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-08 01:00 +0000 |
| Message-ID | <vqg4qh$3q92q$2@dont-email.me> |
| In reply to | #110991 |
On Fri, 7 Mar 2025 18:52:43 -0000 (UTC), Thomas Koenig wrote: > [Fortran] was high enough, right from the start, to abstract away a > _lot_ of the machine, while still being quite efficient. John Backus described the techno-cultural milieu in which Fortran was born, in one of a collection of papers on the origins of historically- significant programming languages, that I read many decades ago. It was one of the first, if not the first, serious attempt at an optimizing compiler. He mentions the surprise people felt (including, of course, seasoned assembly-language programmers) at how far the generated code departed from a simple correspondence to the individual statements of the original source. As I recall, much of the competition at the time took the form of floating-point calculation engines with interpreted languages on top.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-08 00:57 +0000 |
| Message-ID | <vqg4l8$3q92q$1@dont-email.me> |
| In reply to | #110987 |
On Fri, 7 Mar 2025 17:35:57 +0000, MitchAlsup1 wrote: > On Fri, 7 Mar 2025 4:09:13 +0000, Lawrence D'Oliveiro wrote: > >> In a way, one could say that, in many ways, VAX machine language was a >> higher-level language than Fortran. > > One could also say at that point in time that FORTRAN was not that high > of a high level language. It was to most people of the time, particularly in the USA.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-07 14:59 -0500 |
| Message-ID | <UfIyP.154326$OrR5.25311@fx18.iad> |
| In reply to | #110982 |
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. How the VAX Lost Its POLY (and EMOD and ACB_floating too), 2011 https://simh.trailing-edge.com/docs/vax_poly.pdf > In a way, one could say that, in many ways, VAX machine language was a > higher-level language than Fortran. And the decimal instructions for COBOL (also on some PDP-11's). The only reason to add complex instructions like MOVC3, MOVC5 and others SKIPC, SPANC, etc is if hardware can do a better job than a software subroutine. And you only add those instructions when you know you can afford the hardware, not in anticipation that someday we might do a better job. The reason VAX and 8086 benefit from string instructions is because they are sequential processors. It allows them to do decode once and sit in a tight loop doing execute. But both still move byte-by-byte and do not attempt to optimize memory access operations. Also the sequencer is sequential so the loop counting and branch testing each take microcycles. So there is some benefit when comparing a VAX MOVc3 to a VAX subroutine, but not compared to a pipelined TTL RISC. If it is a pipelined RISC then decode is overlapped with execute so there is no advantage to these complex instructions vs a RISC subroutine doing the same in a loop. And the RISC subroutine might be faster because it can overlap the loop count and branch with memory access. In both cases the real advantage is when you can afford the HW to optimize bus accesses as this is where the majority of cycles are spent. When you can afford the HW optimizer then you add them.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-07 20:25 +0000 |
| Message-ID | <41edf61c50a92e9d029d69dd61a6fb5f@www.novabbs.org> |
| In reply to | #110993 |
On Fri, 7 Mar 2025 19:59:47 +0000, EricP wrote: > 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. > > How the VAX Lost Its POLY (and EMOD and ACB_floating too), 2011 > https://simh.trailing-edge.com/docs/vax_poly.pdf > >> In a way, one could say that, in many ways, VAX machine language was a >> higher-level language than Fortran. > > And the decimal instructions for COBOL (also on some PDP-11's). > > The only reason to add complex instructions like MOVC3, MOVC5 and > others SKIPC, SPANC, etc is if hardware can do a better job than a > software subroutine. And you only add those instructions when you > know you can afford the hardware, not in anticipation that someday > we might do a better job. > > The reason VAX and 8086 benefit from string instructions is because > they are sequential processors. It allows them to do decode once and > sit in a tight loop doing execute. But both still move byte-by-byte > and do not attempt to optimize memory access operations. > Also the sequencer is sequential so the loop counting and branch testing > each take microcycles. > > So there is some benefit when comparing a VAX MOVc3 to a VAX subroutine, > but not compared to a pipelined TTL RISC. > > If it is a pipelined RISC then decode is overlapped with execute > so there is no advantage to these complex instructions vs a RISC > subroutine doing the same in a loop. You forgot the word "sequentially" in the previous sentence. > And the RISC subroutine might be > faster because it can overlap the loop count and branch with memory > access. > > In both cases the real advantage is when you can afford the HW to > optimize bus accesses as this is where the majority of cycles are spent. > When you can afford the HW optimizer then you add them. As to MOVc3; once your cache supports wide access (in support of 64-bit misaligned access) you can get 128-bits read or written per cycle per port. So, there is very little added to the HW in order to support doing MOVc3 stuff at 64-bits per cycle:: in cycle 1 we read 128-bits, in cycle 2 we write 128-bits and increment the iterator. For startup and terminations, the incrementation of the iterator creates a mask shutting down the lanes byte by byte.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-03-11 22:15 +0000 |
| Message-ID | <vqqcm0$3l3i5$1@paganini.bofh.team> |
| In reply to | #110982 |
Lawrence D'Oliveiro <ldo@nz.invalid> 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.
Trouble is that such "common" operations have rather low
frequency compared to simple stuff. They are really library
functions. String copies, if done well in microcode could
give some measurable speed gain. Other probably not.
If they managed to make some simpler instruction faster,
there would be substantial gain. RISC folks understood
this, but it is not clear if VAX folks were aware of this.
Of course, it is possible that VAX designers understood
performace implications of their decisons (or rather
meager speed gain from complex instructions), but bet
that "nice" instruction set will tie programs to their
platform.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-11 22:48 +0000 |
| Message-ID | <vqqejh$273mt$5@dont-email.me> |
| In reply to | #111081 |
On Tue, 11 Mar 2025 22:15:30 -0000 (UTC), Waldek Hebisch wrote: > Trouble is that such "common" operations have rather low frequency > compared to simple stuff. They are really library functions. Inline library functions. And they did contribute to keeping the code compact, as Bell said. One thing, though, I don’t think the POLYx instruction was all that useful. It is typical, when computing functions approximated by polynomials, for the polynomial to actually be infinite. And so you have a loop that computes each term in turn, accumulates it to the result, works out an estimate of the remaining error, and stops only when this falls below some threshold. This cannot be expressed by some fixed-length table of coefficients, as the POLYx instruction expects.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-12 00:46 +0000 |
| Message-ID | <3216e6118d138022cbea52f2bacb2abb@www.novabbs.org> |
| In reply to | #111086 |
On Tue, 11 Mar 2025 22:48:17 +0000, Lawrence D'Oliveiro wrote: > On Tue, 11 Mar 2025 22:15:30 -0000 (UTC), Waldek Hebisch wrote: > >> Trouble is that such "common" operations have rather low frequency >> compared to simple stuff. They are really library functions. > > Inline library functions. And they did contribute to keeping the code > compact, as Bell said. > > One thing, though, I don’t think the POLYx instruction was all that > useful. It is typical, when computing functions approximated by > polynomials, for the polynomial to actually be infinite. And so you have > a > loop that computes each term in turn, accumulates it to the result, > works > out an estimate of the remaining error, and stops only when this falls > below some threshold. > > This cannot be expressed by some fixed-length table of coefficients, as > the POLYx instruction expects. People quit doing it that way because Chebyshev (and later Remez) coefficients can be sufficiently accurate whereas Taylor (or Maclaurin) cannot. By the time of the Cody and Waite Book the continue the poly until convergence was already old in the tooth.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-12 08:42 +0000 |
| Message-ID | <2025Mar12.094228@mips.complang.tuwien.ac.at> |
| In reply to | #111081 |
antispam@fricas.org (Waldek Hebisch) writes: >Of course, it is possible that VAX designers understood >performace implications of their decisons (or rather >meager speed gain from complex instructions), but bet >that "nice" instruction set will tie programs to their >platform. I don't think that they fully understood the performance implications, but I believe that creating an appealing environment for software developers was a major consideration of the architects: For the assembly-language programmers, provide orthogonality; that also makes it easy to write compilers (optimility in some form is a different story). The much-critized VAX CALL instruction is designed for a software ecosystem where various languages can call each other, there exists a common debugger for all of them, etc. I am sure that they were aware that this call instruction was expensive, but they expected that it was worth the cost, and also expected that implementors would reduce the cost to below what a sequence of simpler instructions would cost (looking at REP MOVSB in many generations of Intel and AMD CPUs, we see such expectations disappointed; I have not measured recent generations, though). - 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-12 11:48 +0200 |
| Message-ID | <20250312114828.00003e99@yahoo.com> |
| In reply to | #111106 |
On Wed, 12 Mar 2025 08:42:28 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > antispam@fricas.org (Waldek Hebisch) writes: > >Of course, it is possible that VAX designers understood > >performace implications of their decisons (or rather > >meager speed gain from complex instructions), but bet > >that "nice" instruction set will tie programs to their > >platform. > > I don't think that they fully understood the performance implications, > but I believe that creating an appealing environment for software > developers was a major consideration of the architects: For the > assembly-language programmers, provide orthogonality; that also makes > it easy to write compilers (optimility in some form is a different > story). The much-critized VAX CALL instruction is designed for a > software ecosystem where various languages can call each other, there > exists a common debugger for all of them, etc. I am sure that they > were aware that this call instruction was expensive, but they expected > that it was worth the cost, and also expected that implementors would > reduce the cost to below what a sequence of simpler instructions would > cost (looking at REP MOVSB in many generations of Intel and AMD CPUs, > we see such expectations disappointed; I have not measured recent > generations, though). > > - anton It depends on what your call "a sequence of simpler instructions". For R/E/CX above, say, dozen 'rep movsb' is faster than a simple non-unrolled loop of single-byte loads and stores on pretty much any Intel or AMD CPU since a down of time. If we are talking about this century, then, at least for Intel, I think that we can claim that the same is true even relatively to simple loop of 32-bit loads and stores. If we replace a dozen with hundred or three then it will become true for loop of 64-bit loads/stores as well. Or, may be, in your book 5KB of elaborate code that contains unrolled and non-unrolled loops of YMM, XMM, Rxx, Exx, and byte memory accesses still considered 'a sequence of simpler instructions' ? If it is a case then I am not going to argue.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-12 11:28 +0000 |
| Message-ID | <2025Mar12.122836@mips.complang.tuwien.ac.at> |
| In reply to | #111111 |
Michael S <already5chosen@yahoo.com> writes: >> I am sure that they >> were aware that this call instruction was expensive, but they expected >> that it was worth the cost, and also expected that implementors would >> reduce the cost to below what a sequence of simpler instructions would >> cost (looking at REP MOVSB in many generations of Intel and AMD CPUs, >> we see such expectations disappointed; I have not measured recent >> generations, though). ... >It depends on what your call "a sequence of simpler instructions". >For R/E/CX above, say, dozen 'rep movsb' is faster than a simple >non-unrolled loop of single-byte loads and stores on pretty much any >Intel or AMD CPU since a down of time. If we are talking about this >century, then, at least for Intel, I think that we can claim that the >same is true even relatively to simple loop of 32-bit loads and stores. >If we replace a dozen with hundred or three then it will become true >for loop of 64-bit loads/stores as well. > >Or, may be, in your book 5KB of elaborate code that contains unrolled >and non-unrolled loops of YMM, XMM, Rxx, Exx, and byte memory accesses >still considered 'a sequence of simpler instructions' ? >If it is a case then I am not going to argue. My experiments were with the code in <https://github.com/AntonErtl/move/>. I posted performance results in <2017Sep19.082137@mips.complang.tuwien.ac.at> <2017Sep20.184358@mips.complang.tuwien.ac.at> <2017Sep23.174313@mips.complang.tuwien.ac.at> My routines were generally faster than rep movsb, except for pretty large blocks (16KB). The longest of the routines is ssememmove at 275 bytes. I expect that an avx512memmove would be quite a bit smaller, thanks to predication, but I have not yet written that nor measured how that performs. - 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-12 14:09 +0200 |
| Message-ID | <20250312140915.000010a8@yahoo.com> |
| In reply to | #111112 |
On Wed, 12 Mar 2025 11:28:36 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Michael S <already5chosen@yahoo.com> writes: > >> I am sure that they > >> were aware that this call instruction was expensive, but they > >> expected that it was worth the cost, and also expected that > >> implementors would reduce the cost to below what a sequence of > >> simpler instructions would cost (looking at REP MOVSB in many > >> generations of Intel and AMD CPUs, we see such expectations > >> disappointed; I have not measured recent generations, though). > ... > >It depends on what your call "a sequence of simpler instructions". > >For R/E/CX above, say, dozen 'rep movsb' is faster than a simple > >non-unrolled loop of single-byte loads and stores on pretty much any > >Intel or AMD CPU since a down of time. If we are talking about this > >century, then, at least for Intel, I think that we can claim that the > >same is true even relatively to simple loop of 32-bit loads and > >stores. If we replace a dozen with hundred or three then it will > >become true for loop of 64-bit loads/stores as well. > > > >Or, may be, in your book 5KB of elaborate code that contains unrolled > >and non-unrolled loops of YMM, XMM, Rxx, Exx, and byte memory > >accesses still considered 'a sequence of simpler instructions' ? > >If it is a case then I am not going to argue. > > My experiments were with the code in > <https://github.com/AntonErtl/move/>. Non of those are simple loops that I mentioned above. > I posted performance results in > <2017Sep19.082137@mips.complang.tuwien.ac.at> > <2017Sep20.184358@mips.complang.tuwien.ac.at> > <2017Sep23.174313@mips.complang.tuwien.ac.at> > > My routines were generally faster than rep movsb, except for pretty > large blocks (16KB). > Idiots from corporate IT blocked http://al.howardknight.net/ Trying to argue is not totally futile, but almost so. So, link to google groups or, if posts are relatively recent, to https://www.novabbs.com/devel/thread.php?group=comp.arch would be helpful. > The longest of the routines is ssememmove at 275 bytes. > I don't know why gnu memcpy is huge. I don't even know if it is really *that* huge. But several KB is number that I had seen stated by other people. > I expect that an avx512memmove would be quite a bit smaller, thanks to > predication, but I have not yet written that nor measured how that > performs. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-12 16:46 +0000 |
| Subject | rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..) |
| Message-ID | <2025Mar12.174636@mips.complang.tuwien.ac.at> |
| In reply to | #111113 |
Michael S <already5chosen@yahoo.com> writes:
>On Wed, 12 Mar 2025 11:28:36 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> My experiments were with the code in
>> <https://github.com/AntonErtl/move/>.
>
>Non of those are simple loops that I mentioned above.
They are not. If you want short code, rep movsb is unbeatable (for
memmove(), you have to do a little more, however).
>> I posted performance results in
>> <2017Sep19.082137@mips.complang.tuwien.ac.at>
>> <2017Sep20.184358@mips.complang.tuwien.ac.at>
>> <2017Sep23.174313@mips.complang.tuwien.ac.at>
>>
>> My routines were generally faster than rep movsb, except for pretty
>> large blocks (16KB).
>>
>
>Idiots from corporate IT blocked http://al.howardknight.net/
I feel with you. In my workplace, Usenet is blocked (probably
unintentionally). I have to post from home.
>So, link to google groups
Sorry, I cannot provide that service. Trying to access
groups.google.com tells me:
|Couldn’t sign you in
|
|The browser you’re using doesn’t support JavaScript, or has JavaScript
|turned off.
|
|To keep your Google Account secure, try signing in on a browser that
|has JavaScript turned on.
I certainly won't turn on JavaScript for Google, and apparently Google
wants me to log in to a Google account to access groups.google.com. I
don't have a Google account and I don't want one.
But all I would do is try whether google groups finds the message-ids.
You can do that yourself.
>or, if posts are relatively recent, to
>https://www.novabbs.com/devel/thread.php?group=comp.arch
>would be helpful.
The posts are from 2017; these message-ids are not random-generated.
>I don't know why gnu memcpy is huge. I don't even know if it is
>really *that* huge. But several KB is number that I had seen
>stated by other people.
I stated in one of these messages that I have seen an 11KB memmove in
glibc. Let's see:
objdump -t /debian8/usr/lib/x86_64-linux-gnu/libc.a|grep .text|grep 'memmove'
00000000000001a0 g i .text 0000000000000047 __libc_memmove
0000000000000000 g F .text 000000000000019f __memmove_sse2
00000000000001a0 g i .text 0000000000000047 memmove
0000000000000000 g F .text.ssse3 0000000000000009 __memmove_chk_ssse3
0000000000000010 g F .text.ssse3 0000000000002b67 __memmove_ssse3
0000000000000000 g F .text.ssse3 0000000000000009 __memmove_chk_ssse3_back
0000000000000010 g F .text.ssse3 0000000000002b06 __memmove_ssse3_back
...
Yes, 11111 bytes for __memmove_ssse3. Debian 8 is one of the systems
I used at the time.
Let's see how it looks in Debian 12:
objdump -t /usr/lib/x86_64-linux-gnu/libc.a|grep .text|grep 'memmove'|grep -v wmemmove
0000000000000000 l F .text 00000000000000f6 __libc_memmove_ifunc
0000000000000000 g i .text 00000000000000f6 __libc_memmove
0000000000000000 g i .text 00000000000000f6 memmove
0000000000000010 g F .text.avx 000000000000002f __memmove_avx_unaligned
0000000000000080 g F .text.avx 00000000000006de __memmove_avx_unaligned_erms
0000000000000010 g F .text.avx.rtm 000000000000002d __memmove_avx_unaligned_rtm
0000000000000080 g F .text.avx.rtm 00000000000006df __memmove_avx_unaligned_erms_rtm
0000000000000020 g F .text.avx512 0000000000000009 __memmove_chk_avx512_no_vzeroupper
0000000000000030 g F .text.avx512 000000000000073b __memmove_avx512_no_vzeroupper
0000000000000010 g F .text.evex512 0000000000000037 __memmove_avx512_unaligned
0000000000000080 g F .text.evex512 00000000000007a0 __memmove_avx512_unaligned_erms
0000000000000020 g F .text 0000000000000009 __memmove_chk_erms
0000000000000030 g F .text 000000000000002d __memmove_erms
0000000000000010 g F .text.evex 0000000000000034 __memmove_evex_unaligned
0000000000000080 g F .text.evex 00000000000007bb __memmove_evex_unaligned_erms
0000000000000010 g F .text 0000000000000028 __memmove_sse2_unaligned
0000000000000080 g F .text 0000000000000552 __memmove_sse2_unaligned_erms
0000000000000040 g F .text.ssse3 0000000000000f3d __memmove_ssse3
0000000000000000 g F .text 000000000000000e __memmove_chk
So __memmove_ssse3 is no longer that big ("only" 3901 bytes); it's
still the biggest implementation, but many others are quite a bit
bigger than the 0x113=275 bytes of my ssememmove.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-12 17:44 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <a296144c60c9774898235f505bc4c370@www.novabbs.org> |
| In reply to | #111116 |
On Wed, 12 Mar 2025 16:46:36 +0000, Anton Ertl wrote:
>
> So __memmove_ssse3 is no longer that big ("only" 3901 bytes); it's
> still the biggest implementation, but many others are quite a bit
> bigger than the 0x113=275 bytes of my ssememmove.
Imagine that:: almost a page for memmove entry points.
My 66000 has MM memmove as an instruction (4-bytes) always
optimal, no checking required.
>
> - anton
[toc] | [prev] | [next] | [standalone]
Page 8 of 17 — ← Prev page 1 … 6 7 [8] 9 10 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web