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 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-13 21:42 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <5jIAP.61128$Xq5f.38323@fx38.iad> |
| In reply to | #111148 |
Michael S <already5chosen@yahoo.com> writes: >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. Although mostly done with DMA controllers in these modern times to offload from the CPU. > >> Using MTRRs one can switch the kind of memory >> to and from point in the middle of a REP MOVs. > >How exactly? The REP MOV straddles the boundary between two MTRRs.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-13 17:48 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <jwv34fg1u29.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111156 |
Scott Lurndal [2025-03-13 21:42:25] wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Thu, 13 Mar 2025 19:35:33 +0000
>> mitchalsup@aol.com (MitchAlsup1) wrote:
>>> Using MTRRs one can switch the kind of memory
>>> to and from point in the middle of a REP MOVs.
>> How exactly?
> The REP MOV straddles the boundary between two MTRRs.
Why/when would this happen in practice?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-13 23:25 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <DPJAP.403743$zz8b.133824@fx09.iad> |
| In reply to | #111158 |
Stefan Monnier <monnier@iro.umontreal.ca> writes: >Scott Lurndal [2025-03-13 21:42:25] wrote: >> Michael S <already5chosen@yahoo.com> writes: >>> On Thu, 13 Mar 2025 19:35:33 +0000 >>> mitchalsup@aol.com (MitchAlsup1) wrote: >>>> Using MTRRs one can switch the kind of memory >>>> to and from point in the middle of a REP MOVs. >>> How exactly? >> The REP MOV straddles the boundary between two MTRRs. > >Why/when would this happen in practice? > Nobody said it was a good idea.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-14 00:19 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <b6290aa72d7561da394077b5c2839a84@www.novabbs.org> |
| In reply to | #111162 |
On Thu, 13 Mar 2025 23:25:23 +0000, Scott Lurndal wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >>Scott Lurndal [2025-03-13 21:42:25] wrote: >>> Michael S <already5chosen@yahoo.com> writes: >>>> On Thu, 13 Mar 2025 19:35:33 +0000 >>>> mitchalsup@aol.com (MitchAlsup1) wrote: >>>>> Using MTRRs one can switch the kind of memory >>>>> to and from point in the middle of a REP MOVs. >>>> How exactly? >>> The REP MOV straddles the boundary between two MTRRs. >> >>Why/when would this happen in practice? >> > Nobody said it was a good idea. I can envision an attack strategy using this to "confuse" someone in the higher privilege levels of the "system"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-14 14:35 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <B8XAP.584092$FVcd.556966@fx10.iad> |
| In reply to | #111168 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Thu, 13 Mar 2025 23:25:23 +0000, Scott Lurndal wrote: > >> Stefan Monnier <monnier@iro.umontreal.ca> writes: >>>Scott Lurndal [2025-03-13 21:42:25] wrote: >>>> Michael S <already5chosen@yahoo.com> writes: >>>>> On Thu, 13 Mar 2025 19:35:33 +0000 >>>>> mitchalsup@aol.com (MitchAlsup1) wrote: >>>>>> Using MTRRs one can switch the kind of memory >>>>>> to and from point in the middle of a REP MOVs. >>>>> How exactly? >>>> The REP MOV straddles the boundary between two MTRRs. >>> >>>Why/when would this happen in practice? >>> >> Nobody said it was a good idea. > >I can envision an attack strategy using this to "confuse" >someone in the higher privilege levels of the "system" generally the MTRR's control the cachability, not the privilege.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-13 21:08 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <jwvldt8zakm.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111162 |
>>> The REP MOV straddles the boundary between two MTRRs.
>> Why/when would this happen in practice?
> Nobody said it was a good idea.
But if it doesn't happen in normal cases, then it shouldn't be
significant to performance. So is the problem that just detecting the
occurrence of this situation is already too costly to make `rep
movsb` fast?
[ Of course, I still haven't understood either why it technically can
happen in amd64 but not in My 66000. ]
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-14 01:30 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <2db3b1e37183511df9a0a539c618f1c6@www.novabbs.org> |
| In reply to | #111169 |
On Fri, 14 Mar 2025 1:08:38 +0000, Stefan Monnier wrote: >>>> The REP MOV straddles the boundary between two MTRRs. >>> Why/when would this happen in practice? >> Nobody said it was a good idea. > > But if it doesn't happen in normal cases, then it shouldn't be > significant to performance. So is the problem that just detecting the > occurrence of this situation is already too costly to make `rep > movsb` fast? A camel's back is only so strong. Conjecture that there are 14-different kinds of memory on both source and destination. So we need a 14×14 check on where we are every cycle, or every time a boundary could be crossed. Now, µCode (or HW sequencer) needs to check certain things at certain boundaries, and switch optimal[DRAM,DRAM] to optimal[Streaming-store, PCIe-config-space] on a cycle's notice, while adjusting its memory model from "causal" to strongly ordered. > [ Of course, I still haven't understood either why it technically can > happen in amd64 but not in My 66000. ] The cartesian product is smaller, more amenable to buffering and caching, with more easily discovered (or eliminated) boundaries. > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-13 22:20 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <jwva59oz7ew.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111170 |
>> [ Of course, I still haven't understood either why it technically can
>> happen in amd64 but not in My 66000. ]
> The cartesian product is smaller, more amenable to buffering and
> caching, with more easily discovered (or eliminated) boundaries.
These are the parts I can guess. But the part I don't get is what makes
the factors of your cartesian product smaller, what makes your CPU
more amenable to buffering and caching, and what makes those boundaries
easier to discover or eliminate in My 66000 than in amd64.
From what I have gathered so far, the difference in optimizability
between `MM` and `rep movsb` is not due to the semantics of the
instruction, but in the rest of the CPU.
I guess part of my question is: would an `MM` instruction added to, say,
RISC-V or ARM be as easy to optimize as for My 66000 or would it be more
like for the amd64?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-14 00:16 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250314001619.000004fa@yahoo.com> |
| In reply to | #111156 |
On Thu, 13 Mar 2025 21:42:25 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >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. > > Although mostly done with DMA controllers in these modern times > to offload from the CPU. > For up to few hundreds bytes it would be slower. For few thousands byte it could be faster at transfer level, but data ends up in the wrong place in the memory hierarchy, too far away from the ultimate consumer, so still slower from the "full job done" perspective. And CPU time that you "saved" by offload is almost always just uselessly wasted in idle loop. > > > >> Using MTRRs one can switch the kind of memory > >> to and from point in the middle of a REP MOVs. > > > >How exactly? > > The REP MOV straddles the boundary between two MTRRs. > Crossing boundary that way can typically be predicted far in advance, so not really big problem. I think, Mitch had something less mundane in mind.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-13 23:27 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <oRJAP.403744$zz8b.33205@fx09.iad> |
| In reply to | #111160 |
Michael S <already5chosen@yahoo.com> writes: >On Thu, 13 Mar 2025 21:42:25 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >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. >> >> Although mostly done with DMA controllers in these modern times >> to offload from the CPU. >> > >For up to few hundreds bytes it would be slower. For few thousands byte >it could be faster at transfer level, but data ends up in the wrong >place in the memory hierarchy, too far away from the ultimate consumer, Most systems I work with have an 'allocate' attribute on inbound DMA operations that will allocate in a specified cache level (typically LLC). Most DMA's are far more a hundred bytes, and the application can be doing something else while the DMA is in process. >so still slower from the "full job done" perspective. >And CPU time that you "saved" by offload is almost always just uselessly >wasted in idle loop. Only by incompetent programmers.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-14 12:10 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250314121023.00001715@yahoo.com> |
| In reply to | #111163 |
On Thu, 13 Mar 2025 23:27:16 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Thu, 13 Mar 2025 21:42:25 GMT > >scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> >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. > >> > >> Although mostly done with DMA controllers in these modern times > >> to offload from the CPU. > >> > > > >For up to few hundreds bytes it would be slower. For few thousands > >byte it could be faster at transfer level, but data ends up in the > >wrong place in the memory hierarchy, too far away from the ultimate > >consumer, > > Most systems I work with have an 'allocate' attribute on > inbound DMA operations that will allocate in a specified > cache level (typically LLC). > > Most DMA's are far more a hundred bytes, and the application > can be doing something else while the DMA is in process. > > > >so still slower from the "full job done" perspective. > >And CPU time that you "saved" by offload is almost always just > >uselessly wasted in idle loop. > > Only by incompetent programmers. It has nothing to do with competence of programmers and everything to do with modern computers having more cores than their users need. This applies not only to client system but to at least 3/4th of the servers as well.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-14 11:15 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <vr1351$cep$1@reader1.panix.com> |
| In reply to | #111173 |
In article <20250314121023.00001715@yahoo.com>, Michael S <already5chosen@yahoo.com> wrote: >On Thu, 13 Mar 2025 23:27:16 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: >> Michael S <already5chosen@yahoo.com> writes: >> >[snip] >> >For up to few hundreds bytes it would be slower. For few thousands >> >byte it could be faster at transfer level, but data ends up in the >> >wrong place in the memory hierarchy, too far away from the ultimate >> >consumer, >> >> Most systems I work with have an 'allocate' attribute on >> inbound DMA operations that will allocate in a specified >> cache level (typically LLC). >> >> Most DMA's are far more a hundred bytes, and the application >> can be doing something else while the DMA is in process. >> >> >so still slower from the "full job done" perspective. >> >And CPU time that you "saved" by offload is almost always just >> >uselessly wasted in idle loop. >> >> Only by incompetent programmers. > >It has nothing to do with competence of programmers and everything to >do with modern computers having more cores than their users need. >This applies not only to client system but to at least 3/4th of the >servers as well. Define "need" though. Many users are running programs that do make use of those resources, and giving them up for IO would be a poor tradeoff. After all, it takes a lot of juice to have rounded corners on a window where someone's watching a 1080p video of a cat chasing a paper airplane. One might argue that that is the thing the user does not need to do, but that's the user's perogative, not ours. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-14 00:18 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <3ea6db75ea7e1a6cf83189cc30406577@www.novabbs.org> |
| In reply to | #111160 |
On Thu, 13 Mar 2025 22:16:19 +0000, Michael S wrote: > On Thu, 13 Mar 2025 21:42:25 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >>>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. >> >> Although mostly done with DMA controllers in these modern times >> to offload from the CPU. >> > > For up to few hundreds bytes it would be slower. For few thousands byte > it could be faster at transfer level, but data ends up in the wrong > place in the memory hierarchy, too far away from the ultimate consumer, > so still slower from the "full job done" perspective. > And CPU time that you "saved" by offload is almost always just uselessly > wasted in idle loop. > >>> >>>> Using MTRRs one can switch the kind of memory >>>> to and from point in the middle of a REP MOVs. >>> >>>How exactly? >> >> The REP MOV straddles the boundary between two MTRRs. >> > > Crossing boundary that way can typically be predicted far in advance, > so not really big problem. > I think, Mitch had something less mundane in mind. I was just trying to illustrate why optimal REP-MOVS is more difficult than a SW person might initially guestimate. One side might be a byte array down PCIe tree in config space, while the destination is a line access only. Yeah, just try to do this optimally. Since MM is available in the interconnect protocol, one could imagine one PCIe device transferring a page to another PCIe device without the data stream ever touching DRAM (or L3). Yeah, just try doing that with MTRRs and system MMUs in the way. ...
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-14 12:06 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250314120612.000032fc@yahoo.com> |
| In reply to | #111167 |
On Fri, 14 Mar 2025 00:18:18 +0000 mitchalsup@aol.com (MitchAlsup1) wrote: > > > >>> > >>>> Using MTRRs one can switch the kind of memory > >>>> to and from point in the middle of a REP MOVs. > >>> > >>>How exactly? > >> > >> The REP MOV straddles the boundary between two MTRRs. > >> > > > > Crossing boundary that way can typically be predicted far in > > advance, so not really big problem. > > I think, Mitch had something less mundane in mind. > > I was just trying to illustrate why optimal REP-MOVS is more difficult > than a SW person might initially guestimate. > This particular SW person thinks that availability of microcode + microtraps simplifies handling of corner cases correctly in a way that does not affect the speed of common cases. The only really hard part is how to reduce startup overhead. > One side might be a byte array down PCIe tree in config space, > while the destination is a line access only. Yeah, just try to > do this optimally. > There is no need to do this particular case optimally. > Since MM is available in the interconnect protocol, one could > imagine one PCIe device transferring a page to another PCIe > device without the data stream ever touching DRAM (or L3). > Yeah, just try doing that with MTRRs and system MMUs in the > way. ... Outside of graphics drivers for exotic multi-GPU setups, I don't see it happening for the reasons not related to HW. A system software is not structured in a way that makes it possible. And multi-GPU setups were all rage 20 years ago, much less so today. That is, today people use multiple GPUs more than ever, but they are used to run independent jobs rather than to co-operate.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-14 12:25 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <2025Mar14.132532@mips.complang.tuwien.ac.at> |
| In reply to | #111172 |
Michael S <already5chosen@yahoo.com> writes: >On Fri, 14 Mar 2025 00:18:18 +0000 >mitchalsup@aol.com (MitchAlsup1) wrote: >> Since MM is available in the interconnect protocol, one could >> imagine one PCIe device transferring a page to another PCIe >> device without the data stream ever touching DRAM (or L3). >> Yeah, just try doing that with MTRRs and system MMUs in the >> way. ... > >Outside of graphics drivers for exotic multi-GPU setups, I don't see it >happening for the reasons not related to HW. Since a few years, there is some buzz (maybe it's just a marketing feature) about loading textures etc. directly from the SSD into the graphics memory. However, the programs that do this know that they are doing this and don't do it with a synchronous instruction like rep movsb or MM (I expect that MM is also synchronous). - 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-14 14:38 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <vbXAP.584093$FVcd.181223@fx10.iad> |
| In reply to | #111167 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Thu, 13 Mar 2025 22:16:19 +0000, Michael S wrote: > > >Since MM is available in the interconnect protocol, one could >imagine one PCIe device transferring a page to another PCIe >device without the data stream ever touching DRAM (or L3). That's called peer-to-peer PCI and isn't exactly uncommon in higher-end systems.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-03-14 12:52 +0100 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <vr1593$18dvk$1@dont-email.me> |
| In reply to | #111160 |
Michael S wrote: > On Thu, 13 Mar 2025 21:42:25 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >>> 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. >> >> Although mostly done with DMA controllers in these modern times >> to offload from the CPU. >> > > For up to few hundreds bytes it would be slower. For few thousands byte > it could be faster at transfer level, but data ends up in the wrong > place in the memory hierarchy, too far away from the ultimate consumer, > so still slower from the "full job done" perspective. > And CPU time that you "saved" by offload is almost always just uselessly > wasted in idle loop. > >>> >>>> Using MTRRs one can switch the kind of memory >>>> to and from point in the middle of a REP MOVs. >>> >>> How exactly? >> >> The REP MOV straddles the boundary between two MTRRs. >> > > Crossing boundary that way can typically be predicted far in advance, > so not really big problem. > I think, Mitch had something less mundane in mind. Yeah, I read it as some other core modifying the relevant MTTRs in the middle of the ongoing block move. The solution seems somewhat obvious, i.e any modification of an MTTR which is involved in the move wil cause a hw interrupt. Upon restarting the remainder of the move, the new MTTR rules apply? The alternative would be to specify that any block move is atomic as seen from the MTTR rules, i.e the update(s) only apply after the move has finished? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-14 14:00 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250314140037.00002653@yahoo.com> |
| In reply to | #111175 |
On Fri, 14 Mar 2025 12:52:02 +0100 Terje Mathisen <terje.mathisen@tmsw.no> wrote: > Michael S wrote: > > On Thu, 13 Mar 2025 21:42:25 GMT > > scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >>> 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. > >> > >> Although mostly done with DMA controllers in these modern times > >> to offload from the CPU. > >> > > > > For up to few hundreds bytes it would be slower. For few thousands > > byte it could be faster at transfer level, but data ends up in the > > wrong place in the memory hierarchy, too far away from the ultimate > > consumer, so still slower from the "full job done" perspective. > > And CPU time that you "saved" by offload is almost always just > > uselessly wasted in idle loop. > > > >>> > >>>> Using MTRRs one can switch the kind of memory > >>>> to and from point in the middle of a REP MOVs. > >>> > >>> How exactly? > >> > >> The REP MOV straddles the boundary between two MTRRs. > >> > > > > Crossing boundary that way can typically be predicted far in > > advance, so not really big problem. > > I think, Mitch had something less mundane in mind. > > Yeah, I read it as some other core modifying the relevant MTTRs in > the middle of the ongoing block move. > MTRRs are not in memory. They are MSRs, each HW thread has its own set. So, AFAIK, modification by other core/thread is not possible. > The solution seems somewhat obvious, i.e any modification of an MTTR > which is involved in the move wil cause a hw interrupt. Upon > restarting the remainder of the move, the new MTTR rules apply? > > The alternative would be to specify that any block move is atomic as > seen from the MTTR rules, i.e the update(s) only apply after the move > has finished? > > Terje > May be, for some other complications. For MTRRs I see no need.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-14 13:18 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <2025Mar14.141837@mips.complang.tuwien.ac.at> |
| In reply to | #111160 |
Michael S <already5chosen@yahoo.com> writes: >On Thu, 13 Mar 2025 21:42:25 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >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. >> >> Although mostly done with DMA controllers in these modern times >> to offload from the CPU. >> > >For up to few hundreds bytes it would be slower. For few thousands byte >it could be faster at transfer level, but data ends up in the wrong >place in the memory hierarchy, too far away from the ultimate consumer, >so still slower from the "full job done" perspective. >And CPU time that you "saved" by offload is almost always just uselessly >wasted in idle loop. The usual case where "from" is memory-mapped I/O and "to" is cache-coherent is when loading from an NVME SSD. AFAIK this is usually done in larger block sizes, because of the overhead of setting up the DMA, and is usually done in an asynchronous way. As for the wrong level: The DMA engine transfers the data to the CPU chip in any case: it contains all caches and the DRAM controller. It might put the data in, e.g., L3 cache, marked dirty, for later writeback to DRAM, and if a CPU accesses that memory soon, it will only see the latency and bandwidth limits of L3. I have certainly read about a project for high-speed network routing where the network cards deliver the packets to L3, and the routing software has to process each packet in an average of 70ns; if the packets were delivered to DRAM, that speed would be impossible. As for the "transfer level speed", I would not know why delivering to DRAM should be faster than delivering to L3, L2, or L1. On the contrary, it seems to me that delivering to DRAM is at least as slow as the other variants. In any case, that's not what most uses of memcpy() or memmove(), or rep movsb with their synchronous interfaces are about. >> >> Using MTRRs one can switch the kind of memory >> >> to and from point in the middle of a REP MOVs. >> > >> >How exactly? >> >> The REP MOV straddles the boundary between two MTRRs. >> > >Crossing boundary that way can typically be predicted far in advance, >so not really big problem. It does not happen in practice, so making it fast or "optimal" by using a prediction is not necessary. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-14 16:20 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250314162009.000078cf@yahoo.com> |
| In reply to | #111179 |
On Fri, 14 Mar 2025 13:18:37 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > As for the "transfer level speed", I would not know why delivering to > DRAM should be faster than delivering to L3, L2, or L1. On the > contrary, it seems to me that delivering to DRAM is at least as slow > as the other variants. > Transfer level speed would be faster with DMA, because CPU typically has no way to issue Read requests for chunks of data that are bigger than 64 bytes. OTOH, DMA resides on device itself and uses as big transfer unit as appropriate, up to maximum of 4 KB. In theory, "rep movsb" can generate bigger (than 64B) read transfers, but I don't belive that by now state of the art is that advanced. Besides, on all PCE buses, but especially so on PCIe, write transfers (DMA is doing Write transfer in this case) utilizes bus significantly better than read transfers. The difference is most pronounced for small transfers, but on something like 4-lane PCIe Gen4 the difference can be quite big even when Read transactions uses maximal transfer size. > In any case, that's not what most uses of memcpy() or memmove(), or > rep movsb with their synchronous interfaces are about. > Agreed.
[toc] | [prev] | [next] | [standalone]
Page 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web