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 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-13 00:03 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <vqt7d7$2se4a$5@dont-email.me> |
| In reply to | #111117 |
On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote: > My 66000 has MM memmove as an instruction (4-bytes) always optimal, no > checking required. Presumably interruptible and resumable ...
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-13 00:49 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <7139de3c292f37d70bc8086a904fb6e0@www.novabbs.org> |
| In reply to | #111123 |
On Thu, 13 Mar 2025 0:03:51 +0000, Lawrence D'Oliveiro wrote: > On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote: > >> My 66000 has MM memmove as an instruction (4-bytes) always optimal, no >> checking required. > > Presumably interruptible and resumable ... Yep; but also include able to take exceptions.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-13 02:34 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <vqtg73$2u4jc$1@dont-email.me> |
| In reply to | #111124 |
On Thu, 13 Mar 2025 00:49:47 +0000, MitchAlsup1 wrote: > On Thu, 13 Mar 2025 0:03:51 +0000, Lawrence D'Oliveiro wrote: > >> On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote: >> >>> My 66000 has MM memmove as an instruction (4-bytes) always optimal, no >>> checking required. >> >> Presumably interruptible and resumable ... > > Yep; but also include able to take exceptions. So you have a VAX-style “first part done” processor status bit? And you use architectural registers to save/restore the state of an instruction in progress at the time of an interrupt?
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-13 01:48 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <skuAP.50603$Sfe6.40543@fx35.iad> |
| In reply to | #111125 |
Lawrence D'Oliveiro wrote: > On Thu, 13 Mar 2025 00:49:47 +0000, MitchAlsup1 wrote: > >> On Thu, 13 Mar 2025 0:03:51 +0000, Lawrence D'Oliveiro wrote: >> >>> On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote: >>> >>>> My 66000 has MM memmove as an instruction (4-bytes) always optimal, no >>>> checking required. >>> Presumably interruptible and resumable ... >> Yep; but also include able to take exceptions. > > So you have a VAX-style “first part done” processor status bit? And you > use architectural registers to save/restore the state of an instruction in > progress at the time of an interrupt? A safe buffer move doesn't need a FPD flag (VAX) or direction (x86) as long as (a) you don't specify the order bytes are actually moved and (b) you only specify that at the end the length register will be 0 and the buffer address values are unspecified.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-13 05:10 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <vqu7ed$35t1p$1@dont-email.me> |
| In reply to | #111127 |
On 2025-03-13 1:48 a.m., EricP wrote: > Lawrence D'Oliveiro wrote: >> On Thu, 13 Mar 2025 00:49:47 +0000, MitchAlsup1 wrote: >> >>> On Thu, 13 Mar 2025 0:03:51 +0000, Lawrence D'Oliveiro wrote: >>> >>>> On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote: >>>> >>>>> My 66000 has MM memmove as an instruction (4-bytes) always optimal, no >>>>> checking required. >>>> Presumably interruptible and resumable ... >>> Yep; but also include able to take exceptions. >> >> So you have a VAX-style “first part done” processor status bit? And >> you use architectural registers to save/restore the state of an >> instruction in progress at the time of an interrupt? > > A safe buffer move doesn't need a FPD flag (VAX) or direction (x86) > as long as (a) you don't specify the order bytes are actually moved and > (b) you only specify that at the end the length register will be 0 > and the buffer address values are unspecified. > > If it executes in the background with its own local copy of registers it does not need to save state. It might need a means to suspend or cancel the operation though.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-13 16:15 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <c59ce33faeb5b62237d78e13f034358c@www.novabbs.org> |
| In reply to | #111128 |
On Thu, 13 Mar 2025 9:10:36 +0000, Robert Finch wrote:
> On 2025-03-13 1:48 a.m., EricP wrote:
>> Lawrence D'Oliveiro wrote:
>>> On Thu, 13 Mar 2025 00:49:47 +0000, MitchAlsup1 wrote:
>>>
>>>> On Thu, 13 Mar 2025 0:03:51 +0000, Lawrence D'Oliveiro wrote:
>>>>
>>>>> On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote:
>>>>>
>>>>>> My 66000 has MM memmove as an instruction (4-bytes) always optimal, no
>>>>>> checking required.
>>>>> Presumably interruptible and resumable ...
>>>> Yep; but also include able to take exceptions.
>>>
>>> So you have a VAX-style “first part done” processor status bit? And
>>> you use architectural registers to save/restore the state of an
>>> instruction in progress at the time of an interrupt?
>>
>> A safe buffer move doesn't need a FPD flag (VAX) or direction (x86)
>> as long as (a) you don't specify the order bytes are actually moved and
>> (b) you only specify that at the end the length register will be 0
>> and the buffer address values are unspecified.
>>
>>
> If it executes in the background with its own local copy of registers it
> does not need to save state. It might need a means to suspend or cancel
> the operation though.
MM is NOT MOV (Rt)+,(Rf)+
MM is MOV [Rt,µi<<width],[Rf,µi<<width]
ADD µi,µi,width
Where µi is not visible to the thread. Thus Rt and Rf are not modified.
Since the pointers are not modified, the whole MOV can be bundled up
and moved (sic) to whatever layer of the cache hierarchy appropriate.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-13 16:29 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250313162954.00003c2a@yahoo.com> |
| In reply to | #111125 |
On Thu, 13 Mar 2025 02:34:11 -0000 (UTC) Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Thu, 13 Mar 2025 00:49:47 +0000, MitchAlsup1 wrote: > > > On Thu, 13 Mar 2025 0:03:51 +0000, Lawrence D'Oliveiro wrote: > > > >> On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote: > >> > >>> My 66000 has MM memmove as an instruction (4-bytes) always > >>> optimal, no checking required. > >> > >> Presumably interruptible and resumable ... > > > > Yep; but also include able to take exceptions. > > So you have a VAX-style “first part done” processor status bit? And > you use architectural registers to save/restore the state of an > instruction in progress at the time of an interrupt? According to my understanding, no and no. Mitch has instruction that saves architectural+microarchitectural context in memory and any interrupt or exception has to use it. Architectural part of saved buffer is documented. Microarchitectural part, apart from its size, not so much. That is, according to my understanding. Take it with amount of salt you find appropriate.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-13 16:19 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <4f2cd53f94174031fe0b57ac281bd0be@www.novabbs.org> |
| In reply to | #111131 |
On Thu, 13 Mar 2025 14:29:54 +0000, Michael S wrote: > On Thu, 13 Mar 2025 02:34:11 -0000 (UTC) > Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > >> On Thu, 13 Mar 2025 00:49:47 +0000, MitchAlsup1 wrote: >> >>> On Thu, 13 Mar 2025 0:03:51 +0000, Lawrence D'Oliveiro wrote: >>> >>>> On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote: >>>> >>>>> My 66000 has MM memmove as an instruction (4-bytes) always >>>>> optimal, no checking required. >>>> >>>> Presumably interruptible and resumable ... >>> >>> Yep; but also include able to take exceptions. >> >> So you have a VAX-style “first part done” processor status bit? And >> you use architectural registers to save/restore the state of an >> instruction in progress at the time of an interrupt? > > According to my understanding, no and no. > Mitch has instruction s/instruction/hardware means/ > that saves architectural+microarchitectural > context in memory and any interrupt or exception has to use it. Technically, you don't have to use it; it happens automatically. In one instant you are executing thread[k] in core[j], the next instant you are executing thread[m] in core[j] without SW over- head. Thread[j] and [k] are not related and share no state. > Architectural part of saved buffer is documented. Microarchitectural > part, apart from its size, not so much. > That is, according to my understanding. Take it with amount of salt you > find appropriate.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-13 16:10 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <22a6fa61cef9ad862351a46d4d5d9bad@www.novabbs.org> |
| In reply to | #111125 |
On Thu, 13 Mar 2025 2:34:11 +0000, Lawrence D'Oliveiro wrote: > On Thu, 13 Mar 2025 00:49:47 +0000, MitchAlsup1 wrote: > >> On Thu, 13 Mar 2025 0:03:51 +0000, Lawrence D'Oliveiro wrote: >> >>> On Wed, 12 Mar 2025 17:44:11 +0000, MitchAlsup1 wrote: >>> >>>> My 66000 has MM memmove as an instruction (4-bytes) always optimal, no >>>> checking required. >>> >>> Presumably interruptible and resumable ... >> >> Yep; but also include able to take exceptions. > > So you have a VAX-style “first part done” processor status bit? In effect, yes; however it is a valid bit on a "remaining count" control register. > And you > use architectural registers to save/restore the state of an instruction > in progress at the time of an interrupt? Technically, registers are saved and reloaded as if the RF was 4 lines of write back cache--5 lines if you count the thread header.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-13 09:40 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <jwvy0x93vb5.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111117 |
>> 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.
What is different about MM compared to `rep movsb` that you can
confidently state that it will always be optimal?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-13 16:23 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250313162347.00005634@yahoo.com> |
| In reply to | #111129 |
On Thu, 13 Mar 2025 09:40:09 -0400
Stefan Monnier <monnier@iro.umontreal.ca> 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.
>
> What is different about MM compared to `rep movsb` that you can
> confidently state that it will always be optimal?
>
>
> Stefan
Paper is different from silicon. Far superior.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-13 16:24 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <61cab9791f342672dcbd5dfd539cc5cc@www.novabbs.org> |
| In reply to | #111129 |
On Thu, 13 Mar 2025 13:40:09 +0000, Stefan Monnier 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.
>
> What is different about MM compared to `rep movsb`
MM does not modify the pointers. MM keeps its current index,
thus the compiler can use the Rf pointer multiple times.
> that you can
> confidently state that it will always be optimal?
Compared to the explosion in memmove() subroutine, yes.
Compared to a device living on My 66000 interconnect, maybe.
Compared to executing instructions on a core, yes.
>
>
> Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-13 12:43 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <jwv7c4s3n4d.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111135 |
>> What is different about MM compared to `rep movsb`
> MM does not modify the pointers. MM keeps its current index,
> thus the compiler can use the Rf pointer multiple times.
>> that you can confidently state that it will always be optimal?
> Compared to the explosion in memmove() subroutine, yes.
Are you suggesting that what prevents Intel to make `rep movsb` optimal
is the fact that it modifies its pointers?
I have no experience implementing such an instruction, but I find it odd
that such a "cosmetic detail" would have such an profound impact on the
performance of an instruction. Can't they just "macroexpand" it during
decoding into two instructions (one which copies the bytes without
modifying the pointers, and then one which just adjusts the pointers)?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-13 19:35 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <3104c2ab707086659d698a0377450527@www.novabbs.org> |
| In reply to | #111137 |
On Thu, 13 Mar 2025 16:43:07 +0000, Stefan Monnier wrote:
>>> What is different about MM compared to `rep movsb`
>> MM does not modify the pointers. MM keeps its current index,
>> thus the compiler can use the Rf pointer multiple times.
>>> that you can confidently state that it will always be optimal?
>> Compared to the explosion in memmove() subroutine, yes.
>
> Are you suggesting that what prevents Intel to make `rep movsb` optimal
> is the fact that it modifies its pointers?
Certainly does not help.
But they never really "tried all that hard" to make them continuously
Optimal.
And they have "So Many" extra burdens, such as when from is MMI/O
space access and to is cache coherent, and all sorts of other self
imposed problems. Using MTRRs one can switch the kind of memory
to and from point in the middle of a REP MOVs. All of which do no-
thing to make optimality easier.
So, at a certain point in time, designers punt. If all competing
parties punt, nobody is put asunder.
> I have no experience implementing such an instruction, but I find it odd
> that such a "cosmetic detail" would have such an profound impact on the
> performance of an instruction. Can't they just "macroexpand" it during
> decoding into two instructions (one which copies the bytes without
> modifying the pointers, and then one which just adjusts the pointers)?
My 66000 happens to know that memory space changes will not happen
in the middle of these kinds of things (including vectorized Loops).
My compilers don't create such problems for HW to solve. {That is;
the truly horrific x86 optimality problems don't exist.}
You may choose differently.
>
> Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-13 15:53 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <jwvv7sc1zve.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111144 |
MitchAlsup1 [2025-03-13 19:35:33] wrote:
[...]
>>> On Thu, 13 Mar 2025 16:43:07 +0000, Stefan Monnier wrote:
>>>> What is different about MM compared to `rep movsb`
[...]
> But they never really "tried all that hard" to make them
> continuously Optimal.
But is there a reason to presume an implementer of My 66000 would have
the luxury of putting more efforts into making MM "optimal" than Intel put
into making `rep movsb`?
> And they have "So Many" extra burdens,
Ah, now you seem to be getting to the kind of answer I was looking for.
> such as when from is MMI/O space access and to is cache coherent, and
> all sorts of other self imposed problems. Using MTRRs one can switch
> the kind of memory to and from point in the middle of a REP MOVs.
> All of which do nothing to make optimality easier.
How does MM avoid those complexities?
> My 66000 happens to know that memory space changes will not happen
> in the middle of these kinds of things (including vectorized Loops).
How does it know? Is it because the ISA just says "don't do that" (I
guess MM would then signal an error if it happens?), or is there some
underlying difference to the way the semantics/cachability of memory
pages is specified which makes it impossible to specify a memory range
to MM where the semantics changes partways?
> My compilers don't create such problems for HW to solve. {That is;
> the truly horrific x86 optimality problems don't exist.}
How do compilers getting in the picture? I thought they were basically
ignorant of such subtleties of memory caching, as controlled by MTRRs.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-13 20:59 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <5d1811bcd643246db941630e2e87f29b@www.novabbs.org> |
| In reply to | #111145 |
On Thu, 13 Mar 2025 19:53:25 +0000, Stefan Monnier wrote:
> MitchAlsup1 [2025-03-13 19:35:33] wrote:
> [...]
>>>> On Thu, 13 Mar 2025 16:43:07 +0000, Stefan Monnier wrote:
>>>>> What is different about MM compared to `rep movsb`
> [...]
>> But they never really "tried all that hard" to make them
>> continuously Optimal.
>
> But is there a reason to presume an implementer of My 66000 would have
> the luxury of putting more efforts into making MM "optimal" than Intel
> put
> into making `rep movsb`?
In one place we worked, there was a life sized plastic turtle (1-ft
and 2 pounds). Any the engineer who made the least amount of forward
progress every week was assigned the turtle at the corner of his/her
cubicle.
We found this "motivating"
And then there would be "me" assessing their accomplishments and
making fast MM and MS a priority goal to "him".
>> And they have "So Many" extra burdens,
>
> Ah, now you seem to be getting to the kind of answer I was looking for.
>
>> such as when from is MMI/O space access and to is cache coherent, and
>> all sorts of other self imposed problems. Using MTRRs one can switch
>> the kind of memory to and from point in the middle of a REP MOVs.
>> All of which do nothing to make optimality easier.
>
> How does MM avoid those complexities?
Compiler only produces MM and MS where the memory is known to be
contiguous,
and My 66000 universal address space is 64-bits in width for each kind
of
address space, so no MM can cross such a boundary (unless the GuestOS
is aiming a gun at its feet mucking with the PTEs).
>> My 66000 happens to know that memory space changes will not happen
>> in the middle of these kinds of things (including vectorized Loops).
>
> How does it know?
4 × 64-bit PASs
1 × 64-bit VAS
And how the compiler selects using MM or MS.
So, the compiler and Guest OS have to both make different mistakes that
is then not caught by Hypervisor translation tables.
> Is it because the ISA just says "don't do that" (I
> guess MM would then signal an error if it happens?), or is there some
> underlying difference to the way the semantics/cachability of memory
> pages is specified which makes it impossible to specify a memory range
> to MM where the semantics changes partways?
>
>> My compilers don't create such problems for HW to solve. {That is;
>> the truly horrific x86 optimality problems don't exist.}
>
> How do compilers getting in the picture? I thought they were basically
> ignorant of such subtleties of memory caching, as controlled by MTRRs.
The compiler uses MM for copying one chunk of virtually contiguous
memory to another chunk of vcm.
Compiler would not do this if there is any non-contiguousness. So, from
VAS, the access is well defined and compactly described.
During the performance of MM, a change in address space can fault
the performance allowing somebody more privileged to investigate.
>
>
> Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-13 17:44 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <jwv8qp81urp.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111150 |
MitchAlsup1 [2025-03-13 20:59:26] wrote:
> On Thu, 13 Mar 2025 19:53:25 +0000, Stefan Monnier wrote:
>> How does MM avoid those complexities?
>
> Compiler only produces MM and MS where the memory is known to be
> contiguous, and My 66000 universal address space is 64-bits in width
> for each kind of address space, so no MM can cross such a boundary
> (unless the GuestOS is aiming a gun at its feet mucking with the
> PTEs).
What is `MS`?
Isn't it also the case in `rep movsb`?
At least assuming an OS like Linux?
>>> My 66000 happens to know that memory space changes will not happen
>>> in the middle of these kinds of things (including vectorized Loops).
>> How does it know?
> 4 × 64-bit PASs
> 1 × 64-bit VAS
Sorry, I think you went too fast, you lost me here. I'm just a poor
compiler guy with a side-interest in computer architecture.
Presumably the needs that MTRRs satisfy can also be satisfied in My
66000, so I guess what I'm missing here is how My 66000's solution is
different from the amd64/i386 one and how that ends up providing MM with
a guarantee that it doesn't need to care?
It seems to me, there might still be cases where a My 66000 system might
want to copy bytes between a network card buffer and DRAM, so while
I don't expect the cachability of either source or destination to change
in the middle of an MM operation (and I similarly would be fine with
a `rep movsb` that becomes slow if this ever happens), I do expect MM
operations to transfer data between areas that don't have the
same cachability.
> The compiler uses MM for copying one chunk of virtually contiguous
> memory to another chunk of vcm.
> Compiler would not do this if there is any non-contiguousness. So, from
> VAS, the access is well defined and compactly described.
In which way does this not also apply to `rep movsb`?
> During the performance of MM, a change in address space can fault
> the performance allowing somebody more privileged to investigate.
What do you mean by "change in address space"?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-13 23:24 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <nOJAP.403742$zz8b.11690@fx09.iad> |
| In reply to | #111150 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Thu, 13 Mar 2025 19:53:25 +0000, Stefan Monnier wrote: > >> MitchAlsup1 [2025-03-13 19:35:33] wrote: >> [...] >>>>> On Thu, 13 Mar 2025 16:43:07 +0000, Stefan Monnier wrote: >>>>>> What is different about MM compared to `rep movsb` >> [...] >>> But they never really "tried all that hard" to make them >>> continuously Optimal. >> >> But is there a reason to presume an implementer of My 66000 would have >> the luxury of putting more efforts into making MM "optimal" than Intel >> put >> into making `rep movsb`? > >In one place we worked, there was a life sized plastic turtle (1-ft >and 2 pounds). Any the engineer who made the least amount of forward >progress every week was assigned the turtle at the corner of his/her >cubicle. One place I worked, we serialized checkins using a rubber chicken, which was hung on the cube wall. > >We found this "motivating" We found the checkin chicken humorous.
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2025-03-16 14:27 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <memo.20250316142708.10568B@jgd.cix.co.uk> |
| In reply to | #111161 |
In article <nOJAP.403742$zz8b.11690@fx09.iad>, scott@slp53.sl.home (Scott Lurndal) wrote: > One place I worked, we serialized checkins using a rubber chicken, > which was hung on the cube wall. The VAX my employers started with, well before my time, could handle everyone editing and checking in/out, but could handle a maximum of two instances of the product in its test harness running simultaneously. There were two small flags, which you had to have one of you launched the test harness. John
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-13 22:55 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250313225516.00004206@yahoo.com> |
| In reply to | #111144 |
On Thu, 13 Mar 2025 19:35:33 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:
>
> And they have "So Many" extra burdens, such as when from is MMI/O
> space access and to is cache coherent, and all sorts of other self
> imposed problems.
This case is pretty useful in practice.
> Using MTRRs one can switch the kind of memory
> to and from point in the middle of a REP MOVs.
How exactly?
> All of which do no-
> thing to make optimality easier.
>
> So, at a certain point in time, designers punt. If all competing
> parties punt, nobody is put asunder.
>
> > I have no experience implementing such an instruction, but I find
> > it odd that such a "cosmetic detail" would have such an profound
> > impact on the performance of an instruction. Can't they just
> > "macroexpand" it during decoding into two instructions (one which
> > copies the bytes without modifying the pointers, and then one which
> > just adjusts the pointers)?
>
> My 66000 happens to know that memory space changes will not happen
> in the middle of these kinds of things (including vectorized Loops).
> My compilers don't create such problems for HW to solve. {That is;
> the truly horrific x86 optimality problems don't exist.}
>
How high are you aiming?
How many bytes per clock when source and destination do not overlap
and both reside in L1D$ ?
How many bytes when one side in L1D$ and another in L2$?
If the answer is less than 50 in the first case and less than 30 in the
2nd case then your are aiming uninterestingly low.
> You may choose differently.
> >
> > Stefan
[toc] | [prev] | [next] | [standalone]
Page 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web