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 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-14 14:46 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <NiXAP.584095$FVcd.23739@fx10.iad> |
| In reply to | #111180 |
Michael S <already5chosen@yahoo.com> writes: >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. ARM has load and store instructions that load/store 64 byte chunks of data. This are primarily aimed at accelerators used to offload certain computations.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-14 16:51 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <20250314165121.00000635@yahoo.com> |
| In reply to | #111184 |
On Fri, 14 Mar 2025 14:46:05 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >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. > > ARM has load and store instructions that load/store 64 byte chunks > of data. This are primarily aimed at accelerators used to offload > certain computations. > Which does not contradict my statement above. 64 bytes are not bigger than 64 bytes.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-14 15:39 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <4f96ab13a13a89144667f7e115122232@www.novabbs.org> |
| In reply to | #111185 |
On Fri, 14 Mar 2025 14:51:21 +0000, Michael S wrote: > On Fri, 14 Mar 2025 14:46:05 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >>>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. >> >> ARM has load and store instructions that load/store 64 byte chunks >> of data. This are primarily aimed at accelerators used to offload >> certain computations. >> > > Which does not contradict my statement above. 64 bytes are not bigger > than 64 bytes. Just a note: My 66000 core doing Memmove() MM instruction:: unCacheable DRAM can do page at a time transfers Cacheable DRAM can do line at a time transfers over the interconnect.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-14 17:38 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <2QZAP.37554$D_V4.32387@fx39.iad> |
| In reply to | #111188 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Fri, 14 Mar 2025 14:51:21 +0000, Michael S wrote: > >> On Fri, 14 Mar 2025 14:46:05 GMT >> scott@slp53.sl.home (Scott Lurndal) wrote: >> >>> Michael S <already5chosen@yahoo.com> writes: >>>>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. >>> >>> ARM has load and store instructions that load/store 64 byte chunks >>> of data. This are primarily aimed at accelerators used to offload >>> certain computations. >>> >> >> Which does not contradict my statement above. 64 bytes are not bigger >> than 64 bytes. > >Just a note: > >My 66000 core doing Memmove() MM instruction:: >unCacheable DRAM can do page at a time transfers > Cacheable DRAM can do line at a time transfers >over the interconnect. The ARM instructions noted above are single-copy-atomic, by design. ARM chose 64 to match the cache-line size - the loads and stores must be cache-line aligned. For networking applications, 128-byte cache lines are more suitable to support the smallest IP packets (64-bytes + ethernet + IP + TCP headers).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-14 14:44 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <ahXAP.584094$FVcd.570298@fx10.iad> |
| In reply to | #111179 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Michael S <already5chosen@yahoo.com> writes: >>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. Indeed. The ARM AXI bus, for example, supports allocation hints. > >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. BTDT. Further deponent sayeth not. > >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. Delivering to SRAM will be more efficient and lower latency. >>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. Indeed. One generally will not access MMIO space with discrete (e.g. 64-bit) transactions for bulk data movement.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-14 16:37 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <jwv4izvz742.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111179 |
Anton Ertl [2025-03-14 13:18:37] wrote:
> 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.
Also, is the data transfer separate from the "disk" access? I'd expect
that the NVMe interface lets the CPU say "read block B and DMA it to
DRAM at address X" (after which we get an interrupt), so there is no
opportunity for a `rep movsb` or `MM` instruction to do part of the job.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-14 22:23 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <8ed8346bcd30444661510440ca3b0557@www.novabbs.org> |
| In reply to | #111193 |
On Fri, 14 Mar 2025 20:37:08 +0000, Stefan Monnier wrote: > Anton Ertl [2025-03-14 13:18:37] wrote: >> 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. > > Also, is the data transfer separate from the "disk" access? I'd expect > that the NVMe interface lets the CPU say "read block B and DMA it to > DRAM at address X" (after which we get an interrupt), so there is no > opportunity for a `rep movsb` or `MM` instruction to do part of the job. Correct, REP-MOVS or MM is simply the DMA device that happens to reside in a core rather than down the PCIe tree on a device. $3.00 devices have them, why not $3,000.00 CPU chips ?? > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-13 23:06 +0200 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..) |
| Message-ID | <20250313230602.000031c3@yahoo.com> |
| In reply to | #111116 |
On Wed, 12 Mar 2025 16:46:36 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> Michael S <already5chosen@yahoo.com> writes:
> >On Wed, 12 Mar 2025 11:28:36 GMT
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >> My experiments were with the code in
> >> <https://github.com/AntonErtl/move/>.
> >
> >Non of those are simple loops that I mentioned above.
>
> They are not. If you want short code, rep movsb is unbeatable (for
> memmove(), you have to do a little more, however).
>
> >> I posted performance results in
> >> <2017Sep19.082137@mips.complang.tuwien.ac.at>
> >> <2017Sep20.184358@mips.complang.tuwien.ac.at>
> >> <2017Sep23.174313@mips.complang.tuwien.ac.at>
> >>
> >> My routines were generally faster than rep movsb, except for pretty
> >> large blocks (16KB).
> >>
> >
> >Idiots from corporate IT blocked http://al.howardknight.net/
>
> I feel with you. In my workplace, Usenet is blocked (probably
> unintentionally). I have to post from home.
>
> >So, link to google groups
>
> Sorry, I cannot provide that service. Trying to access
> groups.google.com tells me:
>
> |Couldn’t sign you in
> |
> |The browser you’re using doesn’t support JavaScript, or has
> JavaScript |turned off.
> |
> |To keep your Google Account secure, try signing in on a browser that
> |has JavaScript turned on.
>
> I certainly won't turn on JavaScript for Google, and apparently Google
> wants me to log in to a Google account to access groups.google.com. I
> don't have a Google account and I don't want one.
>
For me it works fine without login. But not without JS.
For those who are willing to use JS, the link:
https://groups.google.com/g/comp.arch/c/ULvFgEM_ZSY/m/ysPySToGAwAJ
> But all I would do is try whether google groups finds the message-ids.
> You can do that yourself.
>
GG only searches by contexts. It appears to have no idea about message
ids.
> >or, if posts are relatively recent, to
> >https://www.novabbs.com/devel/thread.php?group=comp.arch
> >would be helpful.
>
> The posts are from 2017; these message-ids are not random-generated.
>
Then GG is the only place to find it that I am aware of.
http://al.howardknight.net helped me to see that start of the message,
but not the full message.
And eternal-september is still struggling with restoration of its
archives after the crash of 9 months ago. More and more it looks like
they will never be restored.
> >I don't know why gnu memcpy is huge. I don't even know if it is
> >really *that* huge. But several KB is number that I had seen
> >stated by other people.
>
> I stated in one of these messages that I have seen an 11KB memmove in
> glibc. Let's see:
>
> objdump -t /debian8/usr/lib/x86_64-linux-gnu/libc.a|grep .text|grep
> 'memmove' 00000000000001a0 g i .text 0000000000000047
> __libc_memmove 0000000000000000 g F .text 000000000000019f
> __memmove_sse2 00000000000001a0 g i .text 0000000000000047
> memmove 0000000000000000 g F .text.ssse3 0000000000000009
> __memmove_chk_ssse3 0000000000000010 g F .text.ssse3
> 0000000000002b67 __memmove_ssse3 0000000000000000 g F .text.ssse3
> 0000000000000009 __memmove_chk_ssse3_back 0000000000000010 g F
> .text.ssse3 0000000000002b06 __memmove_ssse3_back ...
>
> Yes, 11111 bytes for __memmove_ssse3. Debian 8 is one of the systems
> I used at the time.
>
> Let's see how it looks in Debian 12:
>
> objdump -t /usr/lib/x86_64-linux-gnu/libc.a|grep .text|grep
> 'memmove'|grep -v wmemmove 0000000000000000 l F .text
> 00000000000000f6 __libc_memmove_ifunc 0000000000000000 g i .text
> 00000000000000f6 __libc_memmove 0000000000000000 g i .text
> 00000000000000f6 memmove 0000000000000010 g F .text.avx
> 000000000000002f __memmove_avx_unaligned 0000000000000080 g F
> .text.avx 00000000000006de __memmove_avx_unaligned_erms
> 0000000000000010 g F .text.avx.rtm 000000000000002d
> __memmove_avx_unaligned_rtm 0000000000000080 g F .text.avx.rtm
> 00000000000006df __memmove_avx_unaligned_erms_rtm 0000000000000020 g
> F .text.avx512 0000000000000009
> __memmove_chk_avx512_no_vzeroupper 0000000000000030 g F
> .text.avx512 000000000000073b __memmove_avx512_no_vzeroupper
> 0000000000000010 g F .text.evex512 0000000000000037
> __memmove_avx512_unaligned 0000000000000080 g F .text.evex512
> 00000000000007a0 __memmove_avx512_unaligned_erms 0000000000000020 g
> F .text 0000000000000009 __memmove_chk_erms 0000000000000030 g
> F .text 000000000000002d __memmove_erms 0000000000000010 g F
> .text.evex 0000000000000034 __memmove_evex_unaligned
> 0000000000000080 g F .text.evex 00000000000007bb
> __memmove_evex_unaligned_erms 0000000000000010 g F .text
> 0000000000000028 __memmove_sse2_unaligned 0000000000000080 g F
> .text 0000000000000552 __memmove_sse2_unaligned_erms
> 0000000000000040 g F .text.ssse3 0000000000000f3d
> __memmove_ssse3 0000000000000000 g F .text 000000000000000e
> __memmove_chk
>
> So __memmove_ssse3 is no longer that big ("only" 3901 bytes); it's
> still the biggest implementation, but many others are quite a bit
> bigger than the 0x113=275 bytes of my ssememmove.
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-13 22:07 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove |
| Message-ID | <622e7dd0a1601a593b1b319b39905bf6@www.novabbs.org> |
| In reply to | #111151 |
On Thu, 13 Mar 2025 21:06:02 +0000, Michael S wrote: > On Wed, 12 Mar 2025 16:46:36 GMT > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: ------------- >>> >>>Idiots from corporate IT blocked http://al.howardknight.net/ >> >> I feel with you. In my workplace, Usenet is blocked (probably >> unintentionally). I have to post from home. >> >>>So, link to google groups >> >> Sorry, I cannot provide that service. Trying to access >> groups.google.com tells me: >> >> |Couldn’t sign you in >> | >> |The browser you’re using doesn’t support JavaScript, or has >> JavaScript |turned off. >> | >> |To keep your Google Account secure, try signing in on a browser that >> |has JavaScript turned on. >> >> I certainly won't turn on JavaScript for Google, and apparently Google >> wants me to log in to a Google account to access groups.google.com. I >> don't have a Google account and I don't want one. >> > > For me it works fine without login. But not without JS. > For those who are willing to use JS, the link: > https://groups.google.com/g/comp.arch/c/ULvFgEM_ZSY/m/ysPySToGAwAJ Prior to the attack 9 months ago:: Google Groups was happy to use my AOL.email.address. I have not tried recently.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-14 12:43 +0000 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..) |
| Message-ID | <2025Mar14.134327@mips.complang.tuwien.ac.at> |
| In reply to | #111151 |
Michael S <already5chosen@yahoo.com> writes: >On Wed, 12 Mar 2025 16:46:36 GMT >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >On Wed, 12 Mar 2025 11:28:36 GMT >> >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: =20 >> >> My experiments were with the code in >> >> <https://github.com/AntonErtl/move/>. =20 ... >> >> I posted performance results in >> >> <2017Sep19.082137@mips.complang.tuwien.ac.at> >> >> <2017Sep20.184358@mips.complang.tuwien.ac.at> >> >> <2017Sep23.174313@mips.complang.tuwien.ac.at> ... >http://al.howardknight.net helped me to see that start of the message, >but not the full message.=20 That's deplorable. The postings with the second and third Message-Id are delivered from http://al.howardknight.net in full. For <2017Sep19.082137@mips.complang.tuwien.ac.at>, the remaining parts (including a few lines still shown by http://al.howardknight.net) are: |K8 (Athlon 64 X2 4400+), glibc 2.3.6 | 1 8 32 64 128 256 512 1K 2K 4K 8K 16K block size | 21 28 54 90 162 307 595 1171 2325 4632 9244 18467 repmovsb | 17 40 69 80 104 161 253 433 794 1514 2955 5836 memmove | 24 31 57 82 98 129 199 323 570 1064 2053 4032 memcpy | 21 28 53 87 155 292 566 1113 2206 4394 8768 17516 repmovsb aligned | 17 40 33 37 46 68 118 234 451 834 1635 3237 memmove aligned | 24 31 56 45 54 72 120 193 338 627 1207 2367 memcpy aligned | 17 27 53 89 161 306 594 1171 2325 4629 9248 18461 repmovsb blksz-1 | 17 37 61 81 105 152 251 433 792 1513 2952 5825 memmove blksz-1 | 20 30 56 83 100 130 202 325 572 1067 2054 4030 memcpy blksz-1 | |K10 (Phenom II X2 560), glibc 2.19 | 1 8 32 64 128 256 512 1K 2K 4K 8K 16K block size | 15 22 48 84 157 309 566 1080 2107 4161 8270 16487 repmovsb | 16 35 56 69 104 152 262 456 839 1604 3135 6201 memmove | 16 19 13 19 31 68 114 226 408 774 1505 2968 memcpy | 14 21 48 85 158 122 154 219 348 606 1122 2155 repmovsb aligned | 16 39 35 38 46 63 95 190 364 664 1268 2583 memmove aligned | 19 21 13 20 25 56 89 177 306 566 1084 2121 memcpy aligned | 14 21 47 83 155 300 565 1079 2106 4160 8269 16487 repmovsb blksz-1 | 17 32 55 68 91 156 261 454 837 1602 3131 6190 memmove blksz-1 | 17 23 13 18 30 69 114 228 411 774 1508 2966 memcpy blksz-1 | |Zen (Ryzen 5 1600X), glibc 2.24 | 1 8 32 64 128 256 512 1K 2K 4K 8K 16K block size | 25 33 57 105 110 119 140 184 321 599 1160 2324 repmovsb | 13 14 13 14 30 42 65 107 175 325 600 1222 memmove | 10 10 11 12 30 43 67 113 185 329 604 1226 memcpy | 25 33 57 83 87 95 111 143 207 335 594 1136 repmovsb aligned | 12 13 12 13 16 24 40 72 136 264 536 1094 memmove aligned | 11 11 12 11 21 27 42 74 139 267 541 1092 memcpy aligned | 23 32 56 90 110 120 140 184 321 600 1160 2324 repmovsb blksz-1 | 13 13 14 13 30 42 67 108 176 325 599 1219 memmove blksz-1 | 10 10 11 12 31 43 67 113 185 331 604 1221 memcpy blksz-1 | |Zen (Ryzen 5 1600X), glibc 2.3.6 (-static) | 1 8 32 64 128 256 512 1K 2K 4K 8K 16K block size | 25 32 56 106 111 119 140 184 321 600 1161 2334 repmovsb | 10 18 29 36 49 77 132 263 501 940 1816 3581 memmove | 26 34 59 80 88 102 133 198 342 599 1114 2182 memcpy | 25 33 56 85 89 97 113 145 209 337 595 1145 repmovsb aligned | 10 18 20 19 24 40 72 137 286 542 1054 2110 memmove aligned | 26 34 59 50 55 70 100 165 311 567 1079 2126 memcpy aligned | 22 32 56 90 111 119 142 184 321 600 1161 2338 repmovsb blksz-1 | 8 16 29 36 49 76 131 261 499 938 1814 3582 memmove blksz-1 | 24 33 58 82 88 101 134 198 345 602 1117 2184 memcpy blksz-1 >And eternal-september is still struggling with restoration of its >archives after the crash of 9 months ago. More and more it looks like >they will never be restored. My impression pretty soon after the event was that it would not happen. Given that they lost the mapping message-id <-> article number, the insertion of the old messages would have been disruptive to clients that work with the article number. It was bad enough as it was. - 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 | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-03-16 01:22 -0400 |
| Subject | Re: rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..) |
| Message-ID | <banctjt840qmn925lqujh7r1b83c142dee@4ax.com> |
| In reply to | #111116 |
On Wed, 12 Mar 2025 16:46:36 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >... Trying to access groups.google.com tells me: > >|Couldn’t sign you in >| >|The browser you’re using doesn’t support JavaScript, or has JavaScript >|turned off. >| >|To keep your Google Account secure, try signing in on a browser that >|has JavaScript turned on. > >I certainly won't turn on JavaScript for Google, and apparently Google >wants me to log in to a Google account to access groups.google.com. I >don't have a Google account and I don't want one. > >But all I would do is try whether google groups finds the message-ids. >You can do that yourself. You don't have to log in: just enter "group:comp.arch" (or whatever group you want) into your search engine [I use duckduckgo] and follow the link that says "Google Groups". Once in the the group, you can move around and search within it. What you can't do (easily) is switch to another group or get back to the start point if you lose track of it ... for these things you have to return to your search engine and start over.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-13 00:03 +0000 |
| Message-ID | <vqt7c2$2se4a$4@dont-email.me> |
| In reply to | #111113 |
On Wed, 12 Mar 2025 14:09:15 +0200, Michael S wrote: > I don't know why gnu memcpy is huge. Full of special cases, for speed. Back in the old MacOS days, there was a system routine called BlockMove (plus later BlockMoveData), that similarly got larger over time as it got faster.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-13 00:01 +0000 |
| Message-ID | <vqt784$2se4a$3@dont-email.me> |
| In reply to | #111106 |
On Wed, 12 Mar 2025 08:42:28 GMT, Anton Ertl wrote: > The much-critized VAX CALL instruction is designed for a software > ecosystem where various languages can call each other, there exists a > common debugger for all of them, etc. And don’t forget it also reserved a longword in the call frame for use for exception handling. > I am sure that they were aware that this call instruction was > expensive, but they expected that it was worth the cost ... For high-level languages, yes. For lower-level stuff you had BSBB/BSBW/ JSB, which did nothing more than push a return address on the stack and jump. And remember, all kernel calls were done via CHMK/CHME instructions wrapped in procedures meant to be invoked via CALL.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-03-07 13:57 +0200 |
| Message-ID | <20250307135702.00000976@yahoo.com> |
| In reply to | #110981 |
On Fri, 7 Mar 2025 02:27:59 -0000 (UTC) antispam@fricas.org (Waldek Hebisch) wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > By contrast, making good use of the complex instructions of VAX in a > > compiler consumed significant resources (e.g., Figure 2 of > > https://dl.acm.org/doi/pdf/10.1145/502874.502876 reports about a > > factor 1.5 more code in the code generator for VAX than for > > RISC-II). Compilers at the time did not use the CISCy features > > much, which is one reason why the IBM 801 project and later the > > Berkeley RISC and Stanford MIPS proposed replacing them with a > > load/store architecture. > > VAX intstructions are very complex and much of that complexity > is hard to use in compilers. But even extremaly simple compiler > can generate load-op combinations decreasing number of instructions. > Rather simple hack is enough to combine additions in address > artihmetic into addressing mode. Also, operations with two or three > memory addresses are easy to generate from compiler. I think > that chains of pointer dereferences in C should be not hard to > convert to indirect addressing mode. > > I think that state of chip technology was more important. For > example 486 has RISC-like pipeline with load-ops, but load-ops > take the same time as two separate instructions. Similarly, > operations on memory take the same time as load-op-store. > So there were no execution time gain from combined instructions > and clearly some complication compared to load/store > architecture. In specific case of i486, with its small (8KB) unfied I+D cache, you will see good gain from load+Op combining, even if going by cycle count in the manual they are the same. For Pentium , not necessarily so. > Main speed gain of RISC came from having > pipeline on a chip (multichip processors were pipelined, > but expensive, earlier single chip ones had no pipeline). > So load/store architecture (and no microcode) meant that > early RISC could offer good pipeline earlier. > >
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-03-07 15:23 +0100 |
| Message-ID | <vqevg6$3iv5i$1@dont-email.me> |
| In reply to | #110985 |
Michael S wrote: > On Fri, 7 Mar 2025 02:27:59 -0000 (UTC) > antispam@fricas.org (Waldek Hebisch) wrote: > >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> By contrast, making good use of the complex instructions of VAX in a >>> compiler consumed significant resources (e.g., Figure 2 of >>> https://dl.acm.org/doi/pdf/10.1145/502874.502876 reports about a >>> factor 1.5 more code in the code generator for VAX than for >>> RISC-II). Compilers at the time did not use the CISCy features >>> much, which is one reason why the IBM 801 project and later the >>> Berkeley RISC and Stanford MIPS proposed replacing them with a >>> load/store architecture. >> >> VAX intstructions are very complex and much of that complexity >> is hard to use in compilers. But even extremaly simple compiler >> can generate load-op combinations decreasing number of instructions. >> Rather simple hack is enough to combine additions in address >> artihmetic into addressing mode. Also, operations with two or three >> memory addresses are easy to generate from compiler. I think >> that chains of pointer dereferences in C should be not hard to >> convert to indirect addressing mode. >> >> I think that state of chip technology was more important. For >> example 486 has RISC-like pipeline with load-ops, but load-ops >> take the same time as two separate instructions. Similarly, >> operations on memory take the same time as load-op-store. >> So there were no execution time gain from combined instructions >> and clearly some complication compared to load/store >> architecture. > > In specific case of i486, with its small (8KB) unfied I+D cache, > you will see good gain from load+Op combining, even if going by cycle > count in the manual they are the same. > For Pentium , not necessarily so. Right: My Pentium-optimized Word Count program ran nearly twice as fast (in cycle counts) on a Pentium as on a 486. The inner loop was inverted to maximize the load-use distance and I got close to perfect pairing: From memory, similar to REPT 64 add ax,dx mov dx,increment_table[bx] mov bl,[es:di] ;; 64 KB table to classify a pair of chars mov di,[si+OFFSET] add ax,dx mov dx,increment_table[bx+16] mov bh,[es:di] mov di,[si+OFFSET+2] ENDM On the Pentium this was only possible with separate load and operate instructions. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Robert Swindells <rjs@fdy2.co.uk> |
|---|---|
| Date | 2025-03-03 22:15 +0000 |
| Message-ID | <vq59mh$1ghrl$1@dont-email.me> |
| In reply to | #110932 |
On Mon, 03 Mar 2025 16:44:17 GMT, Anton Ertl wrote: > MarkC <usenet@em-ess-see-twenty-seven.me.uk> writes: >>NetBSD still has a VAX port, so the sizes of pre-built packages from >>there might be informative. > > Thanks. The NetBSD pkgsrc is not limited to NetBSD, and there is a wide > variety of prebuilt stuff there. I took those that sound like > architecture names (and probably belong to NetBSD): aarch64 alpha amd64 > earmv7hf i386 m68k mips64eb mipsel powerpc sparc sparc64 vax > > Unfortunately, they do not seem to port to RISC-V in any form yet, and > their earmv7hf port uses ARM A32, not T32. So the NetBSD competition is > performed without entries for those two instruction set encodings that > showed the smallest code sizes on Debian. Anyway, here are the results: You could compare sizes of applications in the base.tgz tarball for each architecture, this is available for RISC-V as well as all the others.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-04 08:39 +0000 |
| Message-ID | <2025Mar4.093916@mips.complang.tuwien.ac.at> |
| In reply to | #110942 |
Robert Swindells <rjs@fdy2.co.uk> writes:
>You could compare sizes of applications in the base.tgz tarball for each
>architecture, this is available for RISC-V as well as all the others.
I did that, see below. There is one problem: RISC-V is only available
in the daily builds, many of the other architectures are not. So I
used 10.0 for all architectures except RISC-V. I also measured the
daily builds for AMD64, to see how the difference in versions of the
source affects the code sizes.
The .text section sizes are (sorted by the ksh column):
libc ksh pax ed
1102054 124726 66218 26226 riscv-riscv32
1077192 127050 62748 26550 riscv-riscv64
1030288 150686 79852 31492 mvme68k
779393 155764 75795 31813 vax
1302254 171505 83249 35085 amd64
1229032 178332 89180 36876 evbarm-aarch64
1539052 179055 82280 34717 amd64-daily
1374961 184458 96971 37218 i386
1247476 185792 96728 42028 evbarm-earmv7hf
1333952 187452 96328 39472 sparc
1586608 204032 106896 45408 evbppc
1536144 204320 106768 43232 hppa
1397024 216832 109792 48512 sparc64
1538536 222336 107776 44912 evbmips-mips64eb
1623952 243008 122096 50640 evbmips-mipseb
1689920 251376 120672 51168 alpha
2324752 2259984 1378000 ia64
libc seems to be quite different between different architectures,
probably with specialized code for different architectures (with vax
being an outlier towards small sizes, see below), the programs seem to
be less specialized. Looking at the two amd64 results, the current
differences between 10.0 and daily seem to be small for pax and ed,
while ksh and libc seem to have grown. quite a bit. The RISC-V
variants use compressed instructions, evbarm-earmv7hf use A32 (no
16-bit instructions). The ia64 binaries are statically linked and no
shared libraries are present in the base package.
I looked at what the largest functions in libc are:
For vax:
000afab4 g F .text 0000266d __ns_sprintrrf
00079d06 g F .text 00002c09 __vfwprintf_unlocked_l
000cd5f0 g F .text 00003888 __vfprintf_unlocked_l
For riscv-riscv32:
000792ac g F .text 0000238a __vfwprintf_unlocked_l
001169ec g F .text 000026aa __vfprintf_unlocked_l
000f64b2 g F .text 00002af0 __ns_sprintrrf
000c798c l F .text 00002c74 malloc_conf_init_helper
0013be64 l F .text 0000503a stats_arena_print
The last two functions do not occur in the vax's libc (as do a lot of
others), which probably explains much of the size difference.
__ns_sprintrrf is larger on RISC-V while __vfprintf_unlocked_l and
__vfwprintf_unlocked_l are smaller; for the total of these three
functions: they are a factor of 1.186 larger on the vax than on
riscv-riscv32. So the difference in libc sizes is probably due to
additional functions in riscv-riscv32.
Looking at ksh, pax and ed, the RISC-V variants have the smallest code
sizes, even for ksh. The VAX has significantly larger sizes, even
though it is still small relative to most other architectures.
So if a major goal of the VAX project was to have small code sizes,
going for RV32GC (riscv-riscv32) would have been a good idea. And an
implementation somewhat similar to the HP-PA TS-1 (with smaller cache
due to the SRAM technology at the time) plus a PDP-11-to-microcode
decoder would not have increased the cost compared to the actual VAX,
and probably resulted in faster execution.
In an earlier posting I suggested a PDP-11->RV32G decoder, but that's
not be a good match given the condition-code architecture of the
PDP-11 and the CC-less architecture of RISC-V. So one solution is to
have a microarchitecture that has a CC register for PDP-11 emulation
and decode the PDP-11 code to that. Another approach would be to add
carry and overflow to the GPRs as RISC-V extension as I suggested
elsewhere, and I guess then PDP-11 -> extended RISC-V would be
possible.
Instead of having a cache, an interleaved memory subsystem might also
be able to provide the memory bandwidth to make better use of the RISC
execution rate potential. Also, the compressed instructions reduce
the instruction bandwidth requirements (compared to RISC-V without
compressed instructions), but require an additional instruction buffer
(additional TTL chips).
Here are the scripts I used:
for i in alpha evbarm-earmv7hf evbmips-mips64eb evbmips-mipseb evbppc hppa i386 ia64 mvme68k sparc vax; do mkdir -p $i/unpacked && (cd $i && wget http://ftp.fr.netbsd.org/pub/NetBSD/NetBSD-10.0/$i/binary/sets/base.tgz); done
for i in amd64 evbarm-aarch64 sparc64; do mkdir -p $i/unpacked && (cd $i && wget http://ftp.fr.netbsd.org/pub/NetBSD/NetBSD-10.0/$i/binary/sets/base.txz); done
for i in riscv-riscv32 riscv-riscv64; do mkdir -p $i/unpacked && (cd $i && wget http://ftp.fr.netbsd.org/pub/NetBSD-daily/HEAD/latest/$i/binary/sets/base.tgz); done
mkdir -p amd64-daily/unpacked
cd amd64-daily
wget http://ftp.fr.netbsd.org/pub/NetBSD-daily/HEAD/latest/amd64/binary/sets/base.tar.xz
cd ..
for i in *; do (cd $i/unpacked; if test -f ../base.tgz; then tar xfz ../base.tgz; else tar xfJ ../base.tar.xz; fi); done
for i in *; do for j in lib/libc.so bin/ksh bin/pax bin/ed; do (cd $i/unpacked; if test -f $j; then objdump -h $j|awk --non-decimal-data '/[.]text/ {printf("%8d ","0x"$3)}'; else echo -n " "; fi); done; echo $i; done|sort -nk2
For determining the largest functions in libc (in an unpacked/lib
directory):
objdump -t libc.so|grep '[.]text'|sort -t '\0' -k1.25
- 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 | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-01 16:29 -0600 |
| Message-ID | <vq01oh$dq4s$1@dont-email.me> |
| In reply to | #110877 |
On 3/1/2025 5:58 AM, Anton Ertl wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> Could the VAX have been designed as a
>> RISC architecture to begin with? Because not doing so meant that, just
>> over a decade later, RISC architectures took over the “real computer”
>> market and wiped the floor with DEC’s flagship architecture,
>> performance-wise.
>>
>> The answer was no, the VAX could not have been done as a RISC
>> architecture. RISC wasn’t actually price-performance competitive until
>> the latter 1980s:
>>
>> RISC didn’t cross over CISC until 1985. This occurred with the
>> availability of large SRAMs that could be used for caches.
>
> Like other USA-based computer architects, Bell ignores ARM, which
> outperformed the VAX without using caches and was much easier to
> design.
>
> As for code size, we see significantly smaller code for RISC
> instruction sets with 16/32-bit encodings such as ARM T32/A32 and
> RV64GC than for all CISCs, including AMD64, i386, and S390x
> <2024Jan4.101941@mips.complang.tuwien.ac.at>. I doubt that VAX fares
> so much better in this respect that its code is significantly smaller
> than for these CPUs.
>
Possibly counter-intuitively, I am beating RV64GC in terms of code sizes
with 32/64 encoding schemes...
Though, a lot of this is addressing cases where RV64 is inefficient:
Load/Store Index
Larger Imm/Disp encodings;
Load/Store Pair;
LI (Imm17s), SHORI (Imm16u)
...
Seemingly, BGBCC can manage to shave more off the size of the binary
mostly by addressing larger imm/disp/constant cases than GCC manages to
save by having 16 bit instructions. Though, likely depends a lot of the
program how effectively they are used. In the programs I have tested,
they reduce the binary size by around 20%, implying around 40% of
instructions can be turned into 16-bit forms.
For BGBCC RV+Jx output, it is around 24% smaller, and slightly beating
GCC's RV64GC output.
XG3 and XG2 both save more.
XG3: 38% smaller than RV64G
XG2: 54% smaller than RV64G
Not entirely sure why there is this much of a delta between XG2 and XG3,
they are more or less the same ISA feature wise, though there is a
difference that BGBCC treats XG3 like it was a RISC-V variant, and XG3
isn't currently using any predication.
Weirdly, I seem to be winning on code-size, design my priority having
been mostly on performance.
Can shave another 2% off the code size for RV64 by filling out the SLT
instruction with the other cases:
SLT , SGE , SEQ , SNE
SLTU, SGEU, STST, SNTST
Not much, but something...
Or:
* 0000000-ttttt-sssss-010-nnnnn-01-10011 SLT Rn, Rs, Rt
* 0100000-ttttt-sssss-010-nnnnn-01-10011 SGE Rn, Rs, Rt
* 1000000-ttttt-sssss-010-nnnnn-01-10011 SEQ Rn, Rs, Rt
* 1100000-ttttt-sssss-010-nnnnn-01-10011 SNE Rn, Rs, Rt
* 0000000-ttttt-sssss-011-nnnnn-01-10011 SLTU Rn, Rs, Rt
* 0100000-ttttt-sssss-011-nnnnn-01-10011 SGEU Rn, Rs, Rt
* 1000000-ttttt-sssss-011-nnnnn-01-10011 STST Rn, Rs, Rt
* 1100000-ttttt-sssss-011-nnnnn-01-10011 SNTST Rn, Rs, Rt
Not sure why the 'B' extension didn't do this, seemingly they were more
inclined to add a bunch of random weird/niche stuff than address issues
like this...
Like, seemingly, it would have made more sense to address a lot of the
"sharp corners" and "non-orthogonality" before adding a bunch of
weird/random stuff?...
But, this was mostly by noting that BGBCC was encoding these mostly
using Jumbo encoded forms, and they were a fair chunk of the
Jumbo-encoded instructions. Adding 32-bit encodings reduced the number
of Jumbo-coded forms (though, with jumbo prefixes still being needed to
encode immediate-form variants).
Though, the 32-bit encodings open up the possibility of 64-bit:
SEQI Rn, Rs, Imm26s
And similar...
A lot of these other compares need around 3 instructions to encode using
just RV64G instructions (or, up to around 4 or 5 for an Imm32 compare).
Granted, BGBCC was using them in a lot of cases where GCC would instead
use a branch.
Say:
if((x<10) && (y<10))
...
GCC will use two branches, 4 instructions.
Granted, this follows nominal C semantics, so works.
BGBCC, RV+JX:
Will use 4 instructions, with a single branch.
BGBCC, XG2 or XG3:
Can be encoded in 3 instructions (with a single branch).
Can save an instruction here because my ISA's also have Test-and-Branch.
Doing these in RV64 needs a AND+BEQ or AND+BNE.
Where:
BTST/BNTST is less common than BEQ/BNE or BLT/BGE, but more common than
BLTU/BGEU, ...
I haven't yet tried adding BTST/BNTST to my RV variant, but it gets
tempting...
As for debugging efforts (in the Verilog core):
In current testing, I seem to have resolved most of the issues with XG3.
My extended RISC-V variant is still buggy.
One of the remaining issues for XG3 (fixed in my working version) was
that the STST and SNTST instructions were mixed up, resulting in some
buggy behavior in Doom and demos would desync.
On my extended RV variant, there are rendering glitches, memory
corruption, and crashes. Most likely something isn't being decoded
correctly somewhere, but the cause is being hard to identify.
I did start some very early work on trying to add Verilog support to
BGBCC, but I don't expect this will happen quickly, if at all. Had
mostly started for now on some parts of the parsing.
While, structurally, it is quite different from C or BS2 or similar,
most basic elements are "similar enough".
General thinking is that most reg/wire/etc types will be handled similar
to _BitInt:
1..128 bits:
Fixed integer type internally, padded to the next power of 2 size.
For VL, each would be a bitfield within the base value.
129+: Padded to the next multiple of 128 bits.
256, 384, 512, ...
These types are handled in a similar way to struct types.
May consider augmenting the existing "BitInt" type with support for some
additional metadata needed for Verilog semantics.
Would likely need some new internal operators to deal with bit-array
operations and similar, with bit-ranges allowed as a pseudo-value type
(may exist in constant expressions but will not necessarily exist as an
actual value type at runtime).
Say:
val[63:32]
Has the (63:32) as a BitRange type, which then has special semantics
when used as an array index on an integer type, ...
The previous idea for bitfield extract/insert had turned into a
composite BITMOV instruction that could potentially do both operations
in a single instruction (along with moving a bitfield directly between
two instructions).
Idea here is that it may do, essentially a combination of a shift and a
masked bit-select, say:
Low 8 bits of immediate encode a shift in the usual format:
Signed 8-bit shift amount, negative is right shift.
High bits give a pair of bit-offsets used to compose a bit-mask.
These will MUX between the shifted value and another input value.
I am still not sure whether this would make sense in hardware, but is
not entirely implausible to implement in the Verilog.
Would likely be a 2 or 3 cycle operation, say:
EX1: Do a Shift and Mask Generation;
May reuse the normal SHAD unit for the shift;
Mask-Gen will be specialized logic;
EX2:
Do the MUX.
EX3:
Present MUX result as output (passed over from EX2).
Doing it as a 2-cycle op could be possible, but would be worse for cost
(as the MUX output would feed directly into the forwarder chains). While
the MUX operation itself shouldn't be too bad (in theory, 32 LUT6's,
each MUX'ing 2 bits). The forwarder path tends to multiply the cost of
anything fed into it. So, maybe still better to leave it as a 3-cycle
operation (the forwarders are less prone to multiply the cost of inputs
fed directly from FF's, as some of the cost may be absorbed in the
previous cycle in routing the value to the FF's in question, which serve
mostly to carry the working output to the next stage).
The Mask-Gen would basically have two 7 or 8 bit fields, with a range of
0..64 for a 64-bit BITMOV (8-bit would allow for potentially doing a
128-bit BITMOV with the same basic logic; using both the Lane 1 and 2
SHAD units as in a SHLDX instruction).
For mask generation:
Lo: Generates 1s for bits >= Lo;
Hi: Generates 1s for bits < Hi;
Hi> Lo: Combine using AND
Hi<=Lo: Combine using OR
Granted:
Lo: Generates 1s for bits >= Lo;
Hi: Generates 1s for bits <= Hi;
Hi>=Lo: Combine using AND
Hi< Lo: Combine using OR
Could allow shaving 1 bit off the needed ranges for the bit offsets
(allowing 6 or 7 bits; or Imm20/Imm22 vs Imm24).
A more compact encoding (using the same logic) could be adapted for a
bitfield extract, likely internally using ZZR (zero) for the 3rd input.
Rs: Value to be shifted and MUX'ed;
Rt: Shift/Mask Control (Immed);
Rp: Third source, Zero, or Dest
Rn: Dest.
Though, one possibility (besides separate Shift and Mask handling) is to
glue the mask generation and MUX'ing logic directly onto the SHAD units
(and probably keeping these as 2-cycle operations, doing the MUX'ing at
the end of EX1 rather than EX2).
The considered encoding for this instruction would be a little wonky (I
don't currently have any large-immediate 4RI encodings, so this would
need to deviate from the usual decoder behavior). Or, I use a more
typical 3RI Imm33s encoding, but this requires an additional MOV or
similar for the Dest register.
This instruction would likely have more limited applicability to C and
would be more difficult for the compiler to use (but could be relevant
to bitfields); or inferred from expressions like: ((x>>SHL)&MASK).
However, this operation would likely be very relevant if trying to run
Verilog on the ISA (otherwise, extreme bit-twiddly is likely to hurt
pretty bad).
The debate is more whether it would make sense to also add it to
hardware, or leave it as an emulator-only instruction.
There is nothing too absurd about adding it to hardware, and as noted,
it could potentially help with things like bitfields.
> Bottom line: If you sent, e.g., me and the needed documents back in
> time to the start of the VAX project, and gave me a magic wand that
> would convince the DEC management and workforce that I know how to
> design their next architecture, and how to compiler for it, I would
> give the implementation team RV32GC as architecture to implement, and
> that they should use pipelining for that, and of course also give that
> to the software people.
>
> As a result, DEC would have had an architecture that would have given
> them superior performance, they would not have suffered from the
> infighting of VAX9000 vs. PRISM etc. (and not from the wrong decision
> to actually build the VAX9000), and might still be going strong to
> this day. They would have been able to extend RV32GC to RV64GC
> without problems, and produce superscalar and OoO implementations.
>
While RISC-V is still not perfect, it is arguably a whole lot better
than a lot of the other stuff from that era, so probably works...
> OTOH, DEC had great success with the VAX for a while, and their demise
> may have been unavoidable given their market position: Their customers
> (especially the business customers of VAXen) went to them instead of
> IBM, because they wanted something less costly, and they continued
> onwards to PCs running Linux when they provided something less costly.
> So DEC would also have needed to outcompete Intel and the PC market to
> succeed (and IBM eventually got out of that market).
>
It almost seems like they could have tried making a PDP-11 based PC.
Say, if they could make a PDP-11 variant that was cost competitive with
the 8086 or M68K, and maybe tried underselling IBM (where the early IBM
PC's were very expensive, and Compaq later captured that part of the
market by being better and cheaper).
DEC could have maybe had a marketing advantage in, say, "Hey, our crap
can run UNIX" and "UNIX is better than DOS".
This alongside any VAX based workstations.
...
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-02 01:02 +0000 |
| Message-ID | <525e0ecc62c0275aba6ba75e6515929f@www.novabbs.org> |
| In reply to | #110883 |
On Sat, 1 Mar 2025 22:29:27 +0000, BGB wrote: > On 3/1/2025 5:58 AM, Anton Ertl wrote: >> Lawrence D'Oliveiro <ldo@nz.invalid> writes: ------------------------------ > Would likely need some new internal operators to deal with bit-array > operations and similar, with bit-ranges allowed as a pseudo-value type > (may exist in constant expressions but will not necessarily exist as an > actual value type at runtime). > Say: > val[63:32] > Has the (63:32) as a BitRange type, which then has special semantics > when used as an array index on an integer type, ... Mc 88K and My 66000 both have bit-vector operations. > The previous idea for bitfield extract/insert had turned into a > composite BITMOV instruction that could potentially do both operations > in a single instruction (along with moving a bitfield directly between > two instructions). Using CARRY and extract + insert, one can extract a field spanning a doubleword and then insert it into another pair of doublewords. 1 pseudo-instruction, 2 actual instructions. > Idea here is that it may do, essentially a combination of a shift and a > masked bit-select, say: > Low 8 bits of immediate encode a shift in the usual format: > Signed 8-bit shift amount, negative is right shift. > High bits give a pair of bit-offsets used to compose a bit-mask. > These will MUX between the shifted value and another input value. You want the offset (a 6-bit number) and the size (another 6-bit number) in order to identify the field in question. > I am still not sure whether this would make sense in hardware, but is > not entirely implausible to implement in the Verilog. In the extract case, you have the shifter before the masker In the insert case, you have the masker before the shifter followed by a merge (OR). Both maskers use the size. Offset goes only to the shifter. > Would likely be a 2 or 3 cycle operation, say: > EX1: Do a Shift and Mask Generation; > May reuse the normal SHAD unit for the shift; > Mask-Gen will be specialized logic; > EX2: > Do the MUX. > EX3: > Present MUX result as output (passed over from EX2). I have done these in 1 cycle ...
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-02 02:56 -0600 |
| Message-ID | <vq16gp$n467$1@dont-email.me> |
| In reply to | #110890 |
On 3/1/2025 7:02 PM, MitchAlsup1 wrote:
> On Sat, 1 Mar 2025 22:29:27 +0000, BGB wrote:
>
>> On 3/1/2025 5:58 AM, Anton Ertl wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> ------------------------------
>> Would likely need some new internal operators to deal with bit-array
>> operations and similar, with bit-ranges allowed as a pseudo-value type
>> (may exist in constant expressions but will not necessarily exist as an
>> actual value type at runtime).
>> Say:
>> val[63:32]
>> Has the (63:32) as a BitRange type, which then has special semantics
>> when used as an array index on an integer type, ...
>
> Mc 88K and My 66000 both have bit-vector operations.
>
OK.
I didn't previously.
But, use-cases have started to appear.
>> The previous idea for bitfield extract/insert had turned into a
>> composite BITMOV instruction that could potentially do both operations
>> in a single instruction (along with moving a bitfield directly between
>> two instructions).
>
> Using CARRY and extract + insert, one can extract a field spanning
> a doubleword and then insert it into another pair of doublewords.
> 1 pseudo-instruction, 2 actual instructions.
>
>> Idea here is that it may do, essentially a combination of a shift and a
>> masked bit-select, say:
>> Low 8 bits of immediate encode a shift in the usual format:
>> Signed 8-bit shift amount, negative is right shift.
>> High bits give a pair of bit-offsets used to compose a bit-mask.
>> These will MUX between the shifted value and another input value.
>
> You want the offset (a 6-bit number) and the size (another 6-bit number)
> in order to identify the field in question.
It is 8 bits partly because this is what the existing shifter uses.
This can also deal with up to 128 bits (-128 .. 127).
Don't necessarily want to have different encodings for 64 and 128 bit
variants.
It would represent a shift of (DestOffset-SrcOffset), where:
For insert it will be positive, for extract, negative.
Keeping this part as-is means that the operation doesn't need to
fundamentally change the behavior of the SHAD unit (it will just do the
shift as normal).
If I used bare 6 bit fields:
I couldn't do both extract and insert using the same operation;
It couldn't directly perform 128-bit extract or insert, which needs at
least 7 bits.
Granted, full 8 bit for all the fields is possibly overkill.
Though, this leaves possibly 8+7+7.
Or, 7+6+6 is limiting to 64-bits only.
But, would need to special-case the handling, as Bit(7) is effectively
used as the shift direction:
00..3F: Left, 0..63 bits
40..7F: Also Left, 0..63 bits.
80..BF: Right, 64..1 bits.
C0..FF: Also Right, 64..1 bits.
Except for 128 bit:
00..7F: Left, 0..127 bits
80..FF: Right, 128..1 bits.
And, 32 bits:
00..1F: Left, 0..31 bits
20..3F: Also Left, 0..31 bits
...
For the right shift operators, the sign is inverted in hardware (these
existed initially mostly to save a need to negate the input for variable
right shift).
For RISC-V mode, it still uses this behavior, but generally code doesn't
notice (a more strict interpretation of the RV spec would require
masking off Bit(7) for the shift amount, such that giving them negative
amounts wouldn't flip the shift direction).
Though, AFAIK, my existing behavior is closer to the original PDP/VAX
shift operators...
As-is, decoding rules would have:
JumboImm+3RI: Gives Imm33s with XG3, imm29s with XG1/XG2
JumboOp +3RI: Gives 4RI Imm11, or 3RI Imm17s
One consideration was to special-case SHLR.L and similar, such that
JumboImm+SHLR could instead encode:
BITMOV Rs, Rp, Rn, Imm24
With SHLR.Q encoding a 128-bit BITMOVX.
But, debatable if this would be "actually a good idea".
>
>> I am still not sure whether this would make sense in hardware, but is
>> not entirely implausible to implement in the Verilog.
>
> In the extract case, you have the shifter before the masker
> In the insert case, you have the masker before the shifter
> followed by a merge (OR). Both maskers use the size. Offset
> goes only to the shifter.
>
I was thinking:
tmp=Rm<<Ro
mask=MASKGEN(H, L)
Rn=(Rp&(~mask))|(tmp&mask);
With a singed shift amount, this can do both insert and extract with the
same logic.
Though, extract will require feeding a 0 into Rp.
MASKGEN(H, L):
H>L:
((1<<H)-1) & (~((1<<L)-1))
H<=L:
((1<<H)-1) | (~((1<<L)-1))
The H<=L could encode some other cases that don't directly correlate to
bitfields, such as shifting most of the bits left or right but then
inserting something non-moving in between (possibly from a different
bitfield).
Generating H dynamically as L+W was considered, and could possibly save
bits, but would increase the cost of the mask generation logic in this case.
>> Would likely be a 2 or 3 cycle operation, say:
>> EX1: Do a Shift and Mask Generation;
>> May reuse the normal SHAD unit for the shift;
>> Mask-Gen will be specialized logic;
>> EX2:
>> Do the MUX.
>> EX3:
>> Present MUX result as output (passed over from EX2).
>
> I have done these in 1 cycle ...
This is pushing it though.
As-is, Shift is a 2 cycle operation. Mostly to keep timing from being tight.
Granted, I have noted that at present, timing is made a lot tighter
(throughout most of the core), due to the SIMD unit.
If I disable the SIMD unit, I am suddenly left with around 2.5ns of
slack... (vs otherwise sitting at around 0.4ns of slack).
But, then, OpenGL is slower (as, without the SIMD unit, FPU SIMD
operators go from pipelined 3 cycles to stalling 10 cycles; but does
save around 2 kLUT).
But, thinking, since the MUX is only a single level of LUTs, could
probably fit in onto the end of the shift stage without too much issue.
The MaskGen operation can be done with actually lower latency than a
shift, as although it looks like a shift on paper, it can be implemented
more cheaply.
[toc] | [prev] | [next] | [standalone]
Page 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web