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 6 of 17 — ← Prev page 1 … 4 5 [6] 7 8 … 17 Next page →
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-11 18:52 -0500 |
| Message-ID | <vqqieu$27vt2$2@dont-email.me> |
| In reply to | #111084 |
On 3/11/2025 5:43 PM, Lawrence D'Oliveiro wrote: > On Tue, 11 Mar 2025 13:46:24 -0700, Stephen Fuld wrote: > >> No software guy talks about "pipeline semantics" :-) > > Remember what pipes are in Unix, and how they can be used to construct > command pipelines. Putting the destination on the right is also fairly common in general in Unix style command notation: dosomething args infile outfile prog1 infile | prog2 > outfile ...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-12 00:34 +0000 |
| Message-ID | <vqqkq0$28fls$2@dont-email.me> |
| In reply to | #111088 |
On Tue, 11 Mar 2025 18:52:50 -0500, BGB wrote: > Putting the destination on the right is also fairly common in general in > Unix style command notation: > dosomething args infile outfile > > prog1 infile | prog2 > outfile True enough. Except that the diff command shows changes as additions to the file on the right, and deletions from the file on the left. So if I want to change the diff command to cp, to actually replace the old file with the new one, I have to remember to swap the file names around.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-11 18:48 -0500 |
| Message-ID | <vqqi66$27vt2$1@dont-email.me> |
| In reply to | #111071 |
On 3/11/2025 1:56 PM, MitchAlsup1 wrote:
> On Tue, 11 Mar 2025 18:15:06 +0000, Stephen Fuld wrote:
>
>> On 3/11/2025 10:44 AM, MitchAlsup1 wrote:
>>>>> When you do change names, can you spell LD and ST instead of MOV ??
>>>>
>>>> Yes, please LD / ST it is so much clearer what is going on. Less
>>>> trouble
>>>> getting confused by the placement of operands.
>>>>
>>>> I always put the memory operand second, which breaks the pattern of
>>>> having the destination operand first. Otherwise the destination is
>>>> first.
>>>>
>>>> I go cross-eyed reading code that is a whole lot of moves.
>>>
>>> I agree.
>>
>> I wonder if the different preferences is at least partially due to
>> whether the person has a hardware or a software background?
>
> Even when both LD and ST are written MOV there is a different OpCode
> for the inbound MOV versus the outbound MOV, so, in effect, they are
> really different instructions requiring different pipeline semantics.
>
> Only (O N L Y) when one has a memory to memory move instruction can
> the LDs and STs be MOVs. VAX had this, BJX* does not.
>
This gives me an idea:
BJXG-ISA
Presumably does not trigger Google, and also seems to not already be in
use for other stuff...
So, at least "slightly less bad"...
Granted, still contains an undesirable letter pair, so maybe still
subject to "Scunthorpe Effect" style content filtering.
Then again, maybe the letter pairing might be related to the relative
lack of search results. Well, and/or, people do actually avoid its use
in things like product or organization names, etc...
> One should argue that different pipeline semantics requires a different
> OpCode--and you already have said OpCode having different bit patterns
> and different signedness semantics different translation access rights
> , ... At the HW level about the only thing LD has in common with ST is
> the way the address is generated--although MIPS did something different.
>
Possibly true.
Main thing that is common is ASM syntax path:
BJX syntax derived from SH syntax;
SH syntax derived from M68K syntax (as did MSP430);
M68K syntax derived from PDP-11 or VAX syntax.
Looking at stuff, it seems likely (probably outside the range of random
chance) that some aspects of SuperH were influenced by VAX, and some
amount of this carried over into the design of BJX.
Granted, even if functionally, they are almost entirely different (and
functionally there is more in common with RISC-V, which seems more
derived from the MIPS lineage...).
Well, there is an obvious difference, in that where BJX uses:
(R8, R11)
VAX had used:
(R8)[R11]
But, this bit of syntax seemingly did not make it into the SH ASM syntax.
It looks like '@' in VAX also meant deferred/indirect addressing, which
was not a thing in SH, but SH ASM had still usually used '@' on memory
operands (which I had dropped, as the parenthesis seemed sufficient to
know that one was accessing memory).
Like, if one has:
@R4, @(R4), and (R4)
And, they all do basically the same thing, why not reduce to just:
(R4)
...
Though, the assembler will still accept @R4 if one wants to write it
that way.
The (R4)+ and -(R4) notations still sorta exist (as do @R4+ and @-R4 ),
but don't actually exist at the ISA level (they are broken apart into
multiple instructions). Though, this logic doesn't exist along the
RISC-V and XG3 paths (usage of these was mostly good and dead before I
got around to adding these; and the use of different ABIs does limit the
sharing of ASM between XG1/XG2 and RV/XG3).
If really needed, could add the boilerplate to crack these instructions
if one tries to do this in RISC-V mode...
But, other option being to migrate over to just using the native RISC-V
ASM syntax...
At present, BGBCC will run stats on the ASM to try to figure which ASM
variant is being used (this applies at the scope of an entire ASM blob,
so trying to mix/match ASM syntax is not likely to go well).
Well, also there is another difference that BGBCC uses MSVC/Borland
style inline ASM.
__asm {
LD X10, 8(X10)
};
Rather than GCC style:
__asm("ld x10, 8(x10)");
Currently, using RISC-V ASM syntax for XG1 or XG2 isn't really a thing
though...
>> The idea is
>> that when hardware guys see the instruction, they think in terms of
>> register ports (read versus write), what is required of the memory
>> system (somewhat different for loads versus stores), etc. However
>> software guys think of a language construct, e.g. X = Y, which is
>
> MARY and MARY2 used X = Y to mean the value in X is deposited into Y.
> Both were left to right only languages. This should surprise most !!
> {{Although to be fair, Mary used the =: operator to perform assign.}}
>
> It took me 40 years of writing specifications to get to the point where
> I can write a specification such that neither the uninformed benevolent
> reader nor the malicious engineer can misread that specification. MOV
> is one of those things that makes getting the specification perfect
> harder--and down the road, you too will figure out why I carry this
> torch ...
>
To me it seems like mostly a historical split.
Is mildly annoying for things like ASM parsing though, as there are
cases where things can be ambiguous, and the assembler getting things
like argument ordering wrong is not ideal.
>> logically a move. I don't know if this is right, but I think it is
>> interesting.
>>
>> A somewhat related question, if one wants to copy the contents of R3
>> into R2, is that a load or a store? :-)
>
> In several RISC ISAs it is an ADD #0 or OR #0, however, in My 66000
> we get a MOV instruction (reg-reg only) as a degenerate version of
> the CMOV instruction {Hey, fell out for free}
XG1/XG2 has "MOV Rm, Rn" as its own instruction.
For RV, it is "ADDI Xd, Xm, 0".
For XG3, I mostly went with "ADD Rm, ZZR, Rn" (or "ADD Xd, Xm, ZERO") as
canonical, with the decoder also recognizing this as a MOV-RR.
In both cases, a special-case recognizer is useful as MOV-RR is 1-cycle
whereas ADD is 2 cycle.
For XG3, the use of 2R or 2RI ops is demoted if a 3R or 3RI op can also
be used for the same purpose (the opposite of XG1 and XG2, which
prioritize the use or 2R or 2RI over 3R or 3RI when equivalent, except
in cases where the 2RI encodings have been deprecated due to being
redundant in XG2; so "ADD Rn, Rm, Rn" would be used in preference to
"ADD Rm, Rn" in XG2, but not in XG1 since the 2R form can potentially be
collapsed down to a 16-bit encoding).
Also most 2RI forms were effectively dropped in XG3.
...
[toc] | [prev] | [next] | [standalone]
| From | moi <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2025-03-11 19:07 +0000 |
| Message-ID | <m3bfusF9ocaU1@mid.individual.net> |
| In reply to | #111069 |
On 11/03/2025 18:15, Stephen Fuld wrote: > > I wonder if the different preferences is at least partially due to > whether the person has a hardware or a software background? The idea is > that when hardware guys see the instruction, they think in terms of > register ports (read versus write), what is required of the memory > system (somewhat different for loads versus stores), etc. However > software guys think of a language construct, e.g. X = Y, which is > logically a move. I don't know if this is right, but I think it is > interesting. No, it is logically a copy. -- Bill F.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-03-11 13:39 -0700 |
| Message-ID | <vqq72r$22et9$1@dont-email.me> |
| In reply to | #111072 |
On 3/11/2025 12:07 PM, moi wrote: > On 11/03/2025 18:15, Stephen Fuld wrote: > >> >> I wonder if the different preferences is at least partially due to >> whether the person has a hardware or a software background? The idea >> is that when hardware guys see the instruction, they think in terms of >> register ports (read versus write), what is required of the memory >> system (somewhat different for loads versus stores), etc. However >> software guys think of a language construct, e.g. X = Y, which is >> logically a move. I don't know if this is right, but I think it is >> interesting. > > No, it is logically a copy. While that is true, I don't think anyone is talking about a "copy" op code. :-) I had thought about mentioning in the software part of the argument that COBOL actually has a "move" verb to accomplish that, i.e. "Move A to B." even though you are technically right that it is a copy. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-11 22:44 +0000 |
| Message-ID | <vqqece$273mt$4@dont-email.me> |
| In reply to | #111073 |
On Tue, 11 Mar 2025 13:39:55 -0700, Stephen Fuld wrote: > On 3/11/2025 12:07 PM, moi wrote: >> >> No, it is logically a copy. > > While that is true, I don't think anyone is talking about a "copy" op > code. :-) I had thought about mentioning in the software part of the > argument that COBOL actually has a "move" verb to accomplish that, i.e. > "Move A to B." even though you are technically right that it is a copy. There is a language (C++) which has introduced reference operators that distinguish between “move semantics” versus “copy semantics”. No, I haven’t got my head around it either.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-11 18:58 -0500 |
| Message-ID | <vqqiov$27vt2$3@dont-email.me> |
| In reply to | #111085 |
On 3/11/2025 5:44 PM, Lawrence D'Oliveiro wrote: > On Tue, 11 Mar 2025 13:39:55 -0700, Stephen Fuld wrote: > >> On 3/11/2025 12:07 PM, moi wrote: >>> >>> No, it is logically a copy. >> >> While that is true, I don't think anyone is talking about a "copy" op >> code. :-) I had thought about mentioning in the software part of the >> argument that COBOL actually has a "move" verb to accomplish that, i.e. >> "Move A to B." even though you are technically right that it is a copy. > > There is a language (C++) which has introduced reference operators that > distinguish between “move semantics” versus “copy semantics”. > > No, I haven’t got my head around it either. I still haven't seen any good reason to move to C++. Uses C, it is effective... Some people (at the C people): use C++, it has features... Others (at the C++ people): Use Rust, it is less of a trash fire. Or, stick with C, and avoid both the trash-fire and its "solution". ...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-12 00:37 +0000 |
| Message-ID | <vqqkvp$28fls$3@dont-email.me> |
| In reply to | #111089 |
On Tue, 11 Mar 2025 18:58:11 -0500, BGB wrote: > I still haven't seen any good reason to move to C++. No disagreement here. ;) > Some people (at the C people): use C++, it has features... It appears the GNU C compiler itself is written in C++ now. > Others (at the C++ people): Use Rust, it is less of a trash fire. Google started a project called “Carbon” a little while back, kind of a C++ done right, with all the accumulated legacy crap removed. Wonder what happened to it ...
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-03-11 19:28 -0700 |
| Message-ID | <vqqrfv$27bbf$1@dont-email.me> |
| In reply to | #111094 |
On 3/11/2025 5:37 PM, Lawrence D'Oliveiro wrote: > On Tue, 11 Mar 2025 18:58:11 -0500, BGB wrote: > >> I still haven't seen any good reason to move to C++. > > No disagreement here. ;) > >> Some people (at the C people): use C++, it has features... > > It appears the GNU C compiler itself is written in C++ now. > >> Others (at the C++ people): Use Rust, it is less of a trash fire. > > Google started a project called “Carbon” a little while back, kind of a > C++ done right, with all the accumulated legacy crap removed. > > Wonder what happened to it ... Still being developed https://en.wikipedia.org/wiki/Carbon_(programming_language) -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-12 00:51 +0000 |
| Message-ID | <0f5c9c5b5826cc6b25b7b5051415fe79@www.novabbs.org> |
| In reply to | #111089 |
On Tue, 11 Mar 2025 23:58:11 +0000, BGB wrote: > On 3/11/2025 5:44 PM, Lawrence D'Oliveiro wrote: >> On Tue, 11 Mar 2025 13:39:55 -0700, Stephen Fuld wrote: >> >>> On 3/11/2025 12:07 PM, moi wrote: >>>> >>>> No, it is logically a copy. >>> >>> While that is true, I don't think anyone is talking about a "copy" op >>> code. :-) I had thought about mentioning in the software part of the >>> argument that COBOL actually has a "move" verb to accomplish that, i.e. >>> "Move A to B." even though you are technically right that it is a copy. >> >> There is a language (C++) which has introduced reference operators that >> distinguish between “move semantics” versus “copy semantics”. >> >> No, I haven’t got my head around it either. > > I still haven't seen any good reason to move to C++. C++ is for those situations where you want to write a small amount of code and have it compile into a vast string of instructions. C is for those situations where you want to write a small amount of code and have it compile into a small string of instructions.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-12 01:24 -0500 |
| Message-ID | <vqr9dh$2finh$2@dont-email.me> |
| In reply to | #111101 |
On 3/11/2025 7:51 PM, MitchAlsup1 wrote: > On Tue, 11 Mar 2025 23:58:11 +0000, BGB wrote: > >> On 3/11/2025 5:44 PM, Lawrence D'Oliveiro wrote: >>> On Tue, 11 Mar 2025 13:39:55 -0700, Stephen Fuld wrote: >>> >>>> On 3/11/2025 12:07 PM, moi wrote: >>>>> >>>>> No, it is logically a copy. >>>> >>>> While that is true, I don't think anyone is talking about a "copy" op >>>> code. :-) I had thought about mentioning in the software part of the >>>> argument that COBOL actually has a "move" verb to accomplish that, i.e. >>>> "Move A to B." even though you are technically right that it is a copy. >>> >>> There is a language (C++) which has introduced reference operators that >>> distinguish between “move semantics” versus “copy semantics”. >>> >>> No, I haven’t got my head around it either. >> >> I still haven't seen any good reason to move to C++. > > C++ is for those situations where you want to write a small amount of > code and have it compile into a vast string of instructions. > Yeah, one can use iostream and have a trivial "hello world" type program have build times and binary size like it was something quite substantial... > C is for those situations where you want to write a small amount of > code and have it compile into a small string of instructions. Yeah. With C, I can have my own compiler, and I can write my Boot ROM program in mostly plain C. Not that many other languages can manage this sort of thing... Granted, there are practical limits, like my compiler has some features that can't be used in something like the Boot ROM. This isn't a huge loss.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-12 14:14 +0000 |
| Message-ID | <2FgAP.508645$eNx6.257631@fx14.iad> |
| In reply to | #111104 |
BGB <cr88192@gmail.com> writes: >On 3/11/2025 7:51 PM, MitchAlsup1 wrote: >> On Tue, 11 Mar 2025 23:58:11 +0000, BGB wrote: >> >>> On 3/11/2025 5:44 PM, Lawrence D'Oliveiro wrote: >>>> On Tue, 11 Mar 2025 13:39:55 -0700, Stephen Fuld wrote: >>>> >>>>> On 3/11/2025 12:07 PM, moi wrote: >>>>>> >>>>>> No, it is logically a copy. >>>>> >>>>> While that is true, I don't think anyone is talking about a "copy" op >>>>> code. :-) I had thought about mentioning in the software part of the >>>>> argument that COBOL actually has a "move" verb to accomplish that, i.e. >>>>> "Move A to B." even though you are technically right that it is a copy. >>>> >>>> There is a language (C++) which has introduced reference operators that >>>> distinguish between “move semantics” versus “copy semantics”. >>>> >>>> No, I haven’t got my head around it either. >>> >>> I still haven't seen any good reason to move to C++. >> >> C++ is for those situations where you want to write a small amount of >> code and have it compile into a vast string of instructions. >> > >Yeah, one can use iostream and have a trivial "hello world" type program >have build times and binary size like it was something quite substantial... You don't have to use iostream. vsnprintf/snprintf/printf all work fine in C++ code and are far more efficient (and far less verbose). Use a subset of C++ (C with classes) and the resulting code is quite compact, but you still get data encapsulation and inheritance (with a minor perf hit for virtual functions).
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-03-12 17:08 +0100 |
| Message-ID | <vqsbij$2mg61$1@dont-email.me> |
| In reply to | #111114 |
Scott Lurndal wrote: > BGB <cr88192@gmail.com> writes: >> On 3/11/2025 7:51 PM, MitchAlsup1 wrote: >>> On Tue, 11 Mar 2025 23:58:11 +0000, BGB wrote: >>> >>>> On 3/11/2025 5:44 PM, Lawrence D'Oliveiro wrote: >>>>> On Tue, 11 Mar 2025 13:39:55 -0700, Stephen Fuld wrote: >>>>> >>>>>> On 3/11/2025 12:07 PM, moi wrote: >>>>>>> >>>>>>> No, it is logically a copy. >>>>>> >>>>>> While that is true, I don't think anyone is talking about a "copy" op >>>>>> code. :-) I had thought about mentioning in the software part of the >>>>>> argument that COBOL actually has a "move" verb to accomplish that, i.e. >>>>>> "Move A to B." even though you are technically right that it is a copy. >>>>> >>>>> There is a language (C++) which has introduced reference operators that >>>>> distinguish between “move semantics†versus “copy semanticsâ€. >>>>> >>>>> No, I haven’t got my head around it either. >>>> >>>> I still haven't seen any good reason to move to C++. >>> >>> C++ is for those situations where you want to write a small amount of >>> code and have it compile into a vast string of instructions. >>> >> >> Yeah, one can use iostream and have a trivial "hello world" type program >> have build times and binary size like it was something quite substantial... > > You don't have to use iostream. vsnprintf/snprintf/printf all work > fine in C++ code and are far more efficient (and far less verbose). > > Use a subset of C++ (C with classes) and the resulting code is > quite compact, but you still get data encapsulation and > inheritance (with a minor perf hit for virtual functions). This the "C+" language that I started to use several decades ago! Just getting access to local declarations and inline comments was sufficient back then. Now regular C has of course mostly caught up here, but it doesn't matter since I'm using Rust for anything time-critical. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-12 00:36 +0000 |
| Message-ID | <81282b4d4a64124fd21a25fc5b4caba3@www.novabbs.org> |
| In reply to | #111085 |
On Tue, 11 Mar 2025 22:44:31 +0000, Lawrence D'Oliveiro wrote: > On Tue, 11 Mar 2025 13:39:55 -0700, Stephen Fuld wrote: > >> On 3/11/2025 12:07 PM, moi wrote: >>> >>> No, it is logically a copy. >> >> While that is true, I don't think anyone is talking about a "copy" op >> code. :-) I had thought about mentioning in the software part of the >> argument that COBOL actually has a "move" verb to accomplish that, i.e. >> "Move A to B." even though you are technically right that it is a copy. > > There is a language (C++) which has introduced reference operators that > distinguish between “move semantics” versus “copy semantics”. Is the distinction between overlapping and non-overlapping memory to memory moves ?? Ala:: memcopy versus memmove ! > No, I haven’t got my head around it either.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-12 09:07 +0000 |
| Message-ID | <2025Mar12.100709@mips.complang.tuwien.ac.at> |
| In reply to | #111085 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >There is a language (C++) which has introduced reference operators that >distinguish between “move semantics” versus “copy semantics”. This is the first time I read about copy semantics; the thing that is not reference semantics is usually called value semantics. But a web search indeed turns up uses of "copy semantics". Interestingly, it also turns up a link to a web site from the C++ standards committee: https://isocpp.org/wiki/faq/value-vs-ref-semantics The title says: "value vs ref semantics", and while there are 11 occurences of "copy" on the page, "copy semantics" does not occur once. However, it does say |Value (or "copy") semantics so apparently "copy semantics" is a synonym for "value semantics". - 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-12 23:55 +0000 |
| Message-ID | <vqt6t2$2se4a$1@dont-email.me> |
| In reply to | #111109 |
On Wed, 12 Mar 2025 09:07:09 GMT, Anton Ertl wrote: > https://isocpp.org/wiki/faq/value-vs-ref-semantics What I was talking about was this <https://en.cppreference.com/w/cpp/language/reference> (described there as “lvalue” versus “rvalue” references).
[toc] | [prev] | [next] | [standalone]
| From | moi <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2025-03-12 00:27 +0000 |
| Message-ID | <m3c2neFcu2rU1@mid.individual.net> |
| In reply to | #111073 |
On 11/03/2025 20:39, Stephen Fuld wrote: > On 3/11/2025 12:07 PM, moi wrote: >> On 11/03/2025 18:15, Stephen Fuld wrote: >> >>> >>> I wonder if the different preferences is at least partially due to >>> whether the person has a hardware or a software background? The idea >>> is that when hardware guys see the instruction, they think in terms >>> of register ports (read versus write), what is required of the memory >>> system (somewhat different for loads versus stores), etc. However >>> software guys think of a language construct, e.g. X = Y, which is >>> logically a move. I don't know if this is right, but I think it is >>> interesting. >> >> No, it is logically a copy. > > While that is true, I don't think anyone is talking about a "copy" op > code. :-) I had thought about mentioning in the software part of the > argument that COBOL actually has a "move" verb to accomplish that, i.e. > "Move A to B." even though you are technically right that it is a copy. Being technically right is the best kind of right. 8-) -- Bill F.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-12 00:37 +0000 |
| Message-ID | <2730e60380057925095119c1b00366f8@www.novabbs.org> |
| In reply to | #111072 |
On Tue, 11 Mar 2025 19:07:08 +0000, moi wrote: > On 11/03/2025 18:15, Stephen Fuld wrote: > >> >> I wonder if the different preferences is at least partially due to >> whether the person has a hardware or a software background? The idea is >> that when hardware guys see the instruction, they think in terms of >> register ports (read versus write), what is required of the memory >> system (somewhat different for loads versus stores), etc. However >> software guys think of a language construct, e.g. X = Y, which is >> logically a move. I don't know if this is right, but I think it is >> interesting. > > No, it is logically a copy. But does it copy X into Y or copy Y into X ??
[toc] | [prev] | [next] | [standalone]
| From | moi <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2025-03-12 00:43 +0000 |
| Message-ID | <m3c3lcFcu2rU2@mid.individual.net> |
| In reply to | #111096 |
On 12/03/2025 00:37, MitchAlsup1 wrote: > On Tue, 11 Mar 2025 19:07:08 +0000, moi wrote: > >> On 11/03/2025 18:15, Stephen Fuld wrote: >> >>> >>> I wonder if the different preferences is at least partially due to >>> whether the person has a hardware or a software background? The idea is >>> that when hardware guys see the instruction, they think in terms of >>> register ports (read versus write), what is required of the memory >>> system (somewhat different for loads versus stores), etc. However >>> software guys think of a language construct, e.g. X = Y, which is >>> logically a move. I don't know if this is right, but I think it is >>> interesting. >> >> No, it is logically a copy. > > But does it copy X into Y or copy Y into X ?? Quite so. My preference is for: LD dest source - reads as load dest from source ST source dest - reads as store source in dest -- Bill F.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-11 21:26 +0000 |
| Message-ID | <XT1AP.458543$2zn8.23180@fx15.iad> |
| In reply to | #111069 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 3/11/2025 10:44 AM, MitchAlsup1 wrote:
>> On Tue, 11 Mar 2025 2:49:00 +0000, Robert Finch wrote:
>>> I always put the memory operand second, which breaks the pattern of
>>> having the destination operand first. Otherwise the destination is
>>> first.
>>>
>>> I go cross-eyed reading code that is a whole lot of moves.
>>
>> I agree.
>
>I wonder if the different preferences is at least partially due to
>whether the person has a hardware or a software background? The idea is
I think it may depend on first experiences with assembler language; in
mine first experiences (on VAX, Burroughs mainframes, AT&T Unix) the first
was always the source operand and the second operand was the destination
operand. The VAX and PDP-11 also followed this paradigm, as does
the AT&T style of x86 assembler (which I find vastly preferable than
the over-annotated microsoft/intel form).
Vax:
;++
; Initialize FAO buffer.
;--
movl #80,obuf
movab obuffer,obuf+4
;++
Burroughs:
MVN Source, Dest
ADD src1, src2, dest
[toc] | [prev] | [next] | [standalone]
Page 6 of 17 — ← Prev page 1 … 4 5 [6] 7 8 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web