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 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-08 03:28 +0000 |
| Message-ID | <9371fe9be75cdd606c876f539e1d2d78@www.novabbs.org> |
| In reply to | #111009 |
On Sat, 8 Mar 2025 2:49:50 +0000, BGB wrote: ------------------------ > > I guess, while a person could do something like (in C): > _BitInt(1048576) bmp; > _Boolean b; > ... > b=(bmp>>i)&1; //*blarg* (shift here would be absurdly expensive) > > This is liklely to be rare vs more traditional strategies, say: > uint64_t *bmp; > int b, i; > ... > b=(bmp[i>>6]>>(i&63))&1; Question: How do you handle the case where the bit vector is an odd number of bits in width ?? Say <3, 5, 7, 17, ...> > As well as the traditional strategy being a whole lot more efficient in > this case... > > > I guess the case could be made for a generic dense bit array. Mc 68020 had instructions to access bit-fields that cross word boundaries. > Though, an open question is how one would define it in a way that is > consistent with existing semantics rules. Architecture is more about what gets left OUT than what gets left IN.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-09 02:55 +0000 |
| Message-ID | <vqivud$e6u3$1@dont-email.me> |
| In reply to | #111011 |
On Sat, 8 Mar 2025 03:28:49 +0000, MitchAlsup1 wrote: > Mc 68020 had instructions to access bit-fields that cross word > boundaries. And, with typical big-endian quirkiness†, the numbering was completely the opposite way round from the single-bit instructions from the earlier members of the 680x0 family. †to put it politely
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-10 17:40 -0500 |
| Message-ID | <vqnps4$1j63b$1@dont-email.me> |
| In reply to | #111011 |
On 3/7/2025 9:28 PM, MitchAlsup1 wrote: > On Sat, 8 Mar 2025 2:49:50 +0000, BGB wrote: > > ------------------------ >> >> I guess, while a person could do something like (in C): >> _BitInt(1048576) bmp; >> _Boolean b; >> ... >> b=(bmp>>i)&1; //*blarg* (shift here would be absurdly expensive) >> >> This is liklely to be rare vs more traditional strategies, say: >> uint64_t *bmp; >> int b, i; >> ... >> b=(bmp[i>>6]>>(i&63))&1; > > Question: How do you handle the case where the bit vector is an odd > number of bits in width ?? Say <3, 5, 7, 17, ...> > It is rare for bitmap bits to not be a power of 2... I would guess, at least for C, something like (for 3 bits): uint32_t *bmp; uint64_t bv; int i, b, bp; ... bp=i*3; bv=*(uint64_t *)(bmp+(bp>>5)); b=(bv>>(bp&31))&7; Could apply to anything up to 31 bits. Could do similar with __int128 (or uint128_t), which extends it up to 63 bits. But, doesn't work on GCC, which (for whatever reason) doesn't seem to support integer types larger than 64 bits on any of the targets I actually care about. >> As well as the traditional strategy being a whole lot more efficient in >> this case... >> >> >> I guess the case could be made for a generic dense bit array. > > Mc 68020 had instructions to access bit-fields that cross word > boundaries. > I guess one could argue the use-case for adding a generic funnel shift instruction. If I added it, it would probably be a 64-bit encoding (generally needed for 4R). The logic needed for a funnel shift operation basically already exists, though the mapping might be funky as it is mostly set up for 128-bit shifts, vs a typical 4R operation, where the register port mappings and similar are different. Though, likely, this would be a special case to probably either do something weird in decode, or add something to redirect inputs based on whether it is being used for a 128-bit shift or a funnel-shift. >> Though, an open question is how one would define it in a way that is >> consistent with existing semantics rules. > > Architecture is more about what gets left OUT than what gets left IN. Well, except in this case it was more a question of trying to fit it in with C semantics (and not consideration for more ISA features). ... But, yeah, there is probably some stuff that could be shaved off. Most likely, if I did a soft reset, I might drop XG1 support... Main tradeoff here is that XG1 can generate binaries that are around 10-20% smaller, but with worse performance (XG1 has performance issues for a similar reasons to RISC-v + C). The "cleanest" option might be to go to XG3-only or XG3+RV. In the simple case, could align things such that the basic configurations for both ISAs have a mostly similar feature set. Also, an OS that runs a kernel in RISC-V mode could also support code running in a basic form of XG3 mode with little special handling (unlike XG1 or XG3 which have additional architectural support). Albeit with some wonk (there would be some additional state hidden in PC and LR/RA). There are still some limitations, for example: In my current implementation, CSR's are very limited (may only be used to load and store CSRs; not do RMW operations on CSRs). Though, have noted that seemingly some number of actual RISC-V cores also have this limitation. A more drastic option might be to try to rework the hardware interfaces and memory map hopefully enough to try to make it possible to run an OS like Linux, but there doesn't really seem to be a standardized set of hardware interfaces or memory map defined. Some amount of SOC's though seem to use a map like: 00000000..0000FFFF: ROM goes here. 00010000..0XXXXXXX: RAM goes here. ZXXXXXXX..FFFFFFFF: Hardware / MMIO This differs from my own memory map where generally RAM starts at the 16MB mark, and the space between 64K and 16MB is mostly special-purpose ROM ranges (mostly NULL pages). If really needed, I could make all of this also RAM range, and find some other range in the physical map to put the NULL pages (if present), or just use a zeroed RAM page as the designated NULL page. Though, other SOC's seem to use: 00000000..3FFFFFFF: Architectural Stuff 40000000..7FFFFFFF: ROM and MMIO 80000000..FFFFFFFF: RAM goes here Though, looking around, RAM being located starting at 80000000 seems to be specified in some things related to the Linux RISC-V Platform spec, which is more easily pulled off (I don't have anything else there). Laziest option is probably just to have RAM cover the entire space from 01000000..BFFFFFFF, repeating however many times is necessary. Maybe move the default RAM-backed addresses for the framebuffer and audio hardware maybe to up near the 128MB or 256MB mark. 0FA00000: VRAM goes here. 4FA00000: VRAM also goes here (another redundant address). Though, better would be to have two separate address ranges. They seem to also be asking for a UEFI based boot process, but this would require having a bigger BootROM (can't likely fit a UEFI implementation into 32K). Seems that the idea is to have the UEFI BIOS boot the kernel directly as an ELF image (traditionally UEFI was always PE/COFF based?...). My boot ROM is able to load ELF images already, I guess the main practical difference here would be theoretically needing to support GPT (vs just MBR), and (AFAIK) provide a method-table or similar for the UEFI interfaces. Apparently there is the idea that hardware interface configuration would be done via PCIe / device trees. But, dunno about specific hardware interfaces. Would need to find some basic "hopefully cheap to implement" semi-standard hardware interfaces. There would likely be some amount of learning curve here... So, it is more likely that if a partial reboot were done, it would mostly be reworking the hardware level interfaces (to hopefully be able to host a more traditional OS) rather than all that much ISA related. There is a probable need to move away from the "BJX2" name, which as noted, has some unfortunate connotations (turns out it was also used for a lewd act) and seems to be triggering to Google's automatic content filtering (probably for a similar reason). Could just do a soft-reboot and move on to BJX3, but mostly have it as a direct continuation, or maybe come up with something different. Usual difficulty being to come up with something decent that hasn't already been used for something else. Decided to leave out the annoyance of the seemingly all of the "good" naming patterns having seemingly already been taken (including most of the "random keyboard mash" acronyms, ...). Almost seems like a fluke that I managed to land on something that wasn't already in-use / overused, if going by search results... ...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-10 23:17 +0000 |
| Message-ID | <vqnruh$1jibk$3@dont-email.me> |
| In reply to | #111056 |
On Mon, 10 Mar 2025 17:40:55 -0500, BGB wrote: > It is rare for bitmap bits to not be a power of 2... In MPEG, some timestamp field was 33 bits in length, as I recall.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-10 19:30 -0500 |
| Message-ID | <vqo09g$1keml$1@dont-email.me> |
| In reply to | #111057 |
On 3/10/2025 6:17 PM, Lawrence D'Oliveiro wrote: > On Mon, 10 Mar 2025 17:40:55 -0500, BGB wrote: > >> It is rare for bitmap bits to not be a power of 2... > > In MPEG, some timestamp field was 33 bits in length, as I recall. Here, bitfield != bitmap, ... Bitfields of any weird size are common. But usually exist within a fixed layout. Contrast to bitmaps that are usually array-like. Bitmaps of weird sizes are not so common, and often when they do occur, there is often other weirdness, such as non-linear or planar encodings. Well, and most existing ISA features will not help much with planar representations... In some uses, it is semi-common to fold a 2D index into 1D by using Morton-order, which was common and useful enough that I ended up adding ISA level support for this. There is not currently any support for a 3D Morton order (3 bit interleave), but this would be possible (just not as common as the 2D case).
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-11 00:53 +0000 |
| Message-ID | <0da86de26bac1912b190793512255aa4@www.novabbs.org> |
| In reply to | #111056 |
On Mon, 10 Mar 2025 22:40:55 +0000, BGB wrote:
> On 3/7/2025 9:28 PM, MitchAlsup1 wrote:
>> On Sat, 8 Mar 2025 2:49:50 +0000, BGB wrote:
>>
>> ------------------------
>>>
>>> I guess, while a person could do something like (in C):
>>> _BitInt(1048576) bmp;
>>> _Boolean b;
>>> ...
>>> b=(bmp>>i)&1; //*blarg* (shift here would be absurdly expensive)
>>>
>>> This is liklely to be rare vs more traditional strategies, say:
>>> uint64_t *bmp;
>>> int b, i;
>>> ...
>>> b=(bmp[i>>6]>>(i&63))&1;
>>
>> Question: How do you handle the case where the bit vector is an odd
>> number of bits in width ?? Say <3, 5, 7, 17, ...>
>>
>
> It is rare for bitmap bits to not be a power of 2...
>
> I would guess, at least for C, something like (for 3 bits):
> uint32_t *bmp;
> uint64_t bv;
> int i, b, bp;
> ...
> bp=i*3;
> bv=*(uint64_t *)(bmp+(bp>>5));
> b=(bv>>(bp&31))&7;
>
> Could apply to anything up to 31 bits.
Not bad.
> Could do similar with __int128 (or uint128_t), which extends it up to 63
> bits.
------------
>> Mc 68020 had instructions to access bit-fields that cross word
>> boundaries.
>>
>
> I guess one could argue the use-case for adding a generic funnel shift
> instruction.
My 66000 has CARRY-SL/SR which performs a double wide operand shifted
by a single wide count (0..63) and produces a double wide result {IO}.
> If I added it, it would probably be a 64-bit encoding (generally needed
> for 4R).
By placing the width in position {31..37} you can compress this down
to 3-Operand.
----------
>> Architecture is more about what gets left OUT than what gets left IN.
>
> Well, except in this case it was more a question of trying to fit it in
> with C semantics (and not consideration for more ISA features).
Clearly, you want to support C semantics--but you can do this in a way
that also supports languages with real bit-field support.
---------------
> There are still some limitations, for example:
> In my current implementation, CSR's are very limited (may only be used
> to load and store CSRs; not do RMW operations on CSRs).
<y 66000 only has 8 CPU CRs, and even these are R/W through MMI/O
space. All the other (effective) CRs are auto loaded in line quanta.
This mechanism allows one CPU to figure out what another CPU is up to
simply by meandering through its CRs...
> Though, have noted that seemingly some number of actual RISC-V cores
> also have this limitation.
>
>
> A more drastic option might be to try to rework the hardware interfaces
> and memory map hopefully enough to try to make it possible to run an OS
> like Linux, but there doesn't really seem to be a standardized set of
> hardware interfaces or memory map defined.
>
> Some amount of SOC's though seem to use a map like:
> 00000000..0000FFFF: ROM goes here.
> 00010000..0XXXXXXX: RAM goes here.
> ZXXXXXXX..FFFFFFFF: Hardware / MMIO
My 66000::
00 0000000000000000..FFFFFFFFFFFFFFFF: DRAM
01 0000000000000000..FFFFFFFFFFFFFFFF: MMI/O
10 0000000000000000..FFFFFFFFFFFFFFFF: config
11 0000000000000000..FFFFFFFFFFFFFFFF: ROM
Whatever you are trying to do, you won't run out of address space until
64 bits becomes insufficient. Note: all HW interfaces are in config
space
and all CRs are in MMI/O space.
------------
> They seem to also be asking for a UEFI based boot process, but this
> would require having a bigger BootROM (can't likely fit a UEFI
> implementation into 32K). Seems that the idea is to have the UEFI BIOS
> boot the kernel directly as an ELF image (traditionally UEFI was always
> PE/COFF based?...).
Boot ROM should be big enough that no BOOT ROM will ever exceed its
size.
--------------
> There is a probable need to move away from the "BJX2" name, which as
> noted, has some unfortunate connotations (turns out it was also used for
> a lewd act) and seems to be triggering to Google's automatic content
> filtering (probably for a similar reason).
Hilarious--and reason enough to change names.
When you do change names, can you spell LD and ST instead of MOV ??
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-10 22:49 -0400 |
| Message-ID | <vqo8b1$1ln7o$1@dont-email.me> |
| In reply to | #111059 |
On 2025-03-10 8:53 p.m., MitchAlsup1 wrote:
> On Mon, 10 Mar 2025 22:40:55 +0000, BGB wrote:
>
>> On 3/7/2025 9:28 PM, MitchAlsup1 wrote:
>>> On Sat, 8 Mar 2025 2:49:50 +0000, BGB wrote:
>>>
>>> ------------------------
>>>>
>>>> I guess, while a person could do something like (in C):
>>>> _BitInt(1048576) bmp;
>>>> _Boolean b;
>>>> ...
>>>> b=(bmp>>i)&1; //*blarg* (shift here would be absurdly expensive)
>>>>
>>>> This is liklely to be rare vs more traditional strategies, say:
>>>> uint64_t *bmp;
>>>> int b, i;
>>>> ...
>>>> b=(bmp[i>>6]>>(i&63))&1;
>>>
>>> Question: How do you handle the case where the bit vector is an odd
>>> number of bits in width ?? Say <3, 5, 7, 17, ...>
>>>
>>
>> It is rare for bitmap bits to not be a power of 2...
>>
>> I would guess, at least for C, something like (for 3 bits):
>> uint32_t *bmp;
>> uint64_t bv;
>> int i, b, bp;
>> ...
>> bp=i*3;
>> bv=*(uint64_t *)(bmp+(bp>>5));
>> b=(bv>>(bp&31))&7;
>>
>> Could apply to anything up to 31 bits.
>
> Not bad.
>
>> Could do similar with __int128 (or uint128_t), which extends it up to 63
>> bits.
> ------------
>>> Mc 68020 had instructions to access bit-fields that cross word
>>> boundaries.
>>>
>>
>> I guess one could argue the use-case for adding a generic funnel shift
>> instruction.
>
> My 66000 has CARRY-SL/SR which performs a double wide operand shifted
> by a single wide count (0..63) and produces a double wide result {IO}.
>
>> If I added it, it would probably be a 64-bit encoding (generally needed
>> for 4R).
>
> By placing the width in position {31..37} you can compress this down
> to 3-Operand.
>
> ----------
>>> Architecture is more about what gets left OUT than what gets left IN.
>>
>> Well, except in this case it was more a question of trying to fit it in
>> with C semantics (and not consideration for more ISA features).
>
> Clearly, you want to support C semantics--but you can do this in a way
> that also supports languages with real bit-field support.
> ---------------
>> There are still some limitations, for example:
>> In my current implementation, CSR's are very limited (may only be used
>> to load and store CSRs; not do RMW operations on CSRs).
>
> <y 66000 only has 8 CPU CRs, and even these are R/W through MMI/O
> space. All the other (effective) CRs are auto loaded in line quanta.
>
> This mechanism allows one CPU to figure out what another CPU is up to
> simply by meandering through its CRs...
>
>> Though, have noted that seemingly some number of actual RISC-V cores
>> also have this limitation.
>>
>>
>> A more drastic option might be to try to rework the hardware interfaces
>> and memory map hopefully enough to try to make it possible to run an OS
>> like Linux, but there doesn't really seem to be a standardized set of
>> hardware interfaces or memory map defined.
>>
>> Some amount of SOC's though seem to use a map like:
>> 00000000..0000FFFF: ROM goes here.
>> 00010000..0XXXXXXX: RAM goes here.
>> ZXXXXXXX..FFFFFFFF: Hardware / MMIO
>
I got used to a lot of micro-computer maps which have RAM at low end and
ROM at the high end.
I have the Q+ SoC setup like this (which is pretty much the way I setup
all SoC) I use 32-bit addressing for demo purposes. Low cost FPGA boards
typically do not have many gigabytes of memory.
00000000..3FFFFFFF DRAM
40000000..CFFFFFFF DRAM expansion area (not present on board)
D0000000..DFFFFFFF config (FTA DDBB device discovery black boxes)
E0000000..FEBFFFFF unassigned
FEC00000..FEFFFFFF MMI/O
FF000000..FFF7FFFF ROM expansion area (unimplemented)
FFF80000..FFFBFFFF Scratchpad RAM
FFFC0000..FFFFFFFF ROM
The DDBB can configure the MMI/O to appear at any address, but I have
devices defaulting to
FEC00000..FEFFFFFF MMI/O
Each DDBB is a 4kB space, the last 3kB are ROM for device support
There is a CSR that can reconfig the config area, which defaults to
Dxxxxxxx.
Addresses are double bit sign extended from 32-bits to 64-bits when
setup by the boot ROM, but the high order 64-bits are ignored by the
hardware.
I went with dynamically determined MMI/O addressing setup at boot time
which is hopefully usable with and OS. Defaults are such that the system
is able to boot.
> My 66000::
> 00 0000000000000000..FFFFFFFFFFFFFFFF: DRAM
> 01 0000000000000000..FFFFFFFFFFFFFFFF: MMI/O
> 10 0000000000000000..FFFFFFFFFFFFFFFF: config
> 11 0000000000000000..FFFFFFFFFFFFFFFF: ROM
>
How does one reference DRAM vs MMI/O at the same address using a LD / ST
instruction?
Q+ CPU just uses a 64-bit address range. The config space is specified
in a CR defaulting to FFFFFFFFDxxxxxxx The TLB is setup at boot to
access ROM at FFFFFFFFFFFCxxxxx Otherwise there is no distinction with
addresses. There is a region table in the system that describes up to
eight distinct regions.
> Whatever you are trying to do, you won't run out of address space until
> 64 bits becomes insufficient. Note: all HW interfaces are in config
> space
> and all CRs are in MMI/O space.
Are there any CRs accessible with any instructions besides LD / ST?
>
> ------------
>> They seem to also be asking for a UEFI based boot process, but this
>> would require having a bigger BootROM (can't likely fit a UEFI
>> implementation into 32K). Seems that the idea is to have the UEFI BIOS
>> boot the kernel directly as an ELF image (traditionally UEFI was always
>> PE/COFF based?...).
>
> Boot ROM should be big enough that no BOOT ROM will ever exceed its
> size.
> --------------
>> There is a probable need to move away from the "BJX2" name, which as
>> noted, has some unfortunate connotations (turns out it was also used for
>> a lewd act) and seems to be triggering to Google's automatic content
>> filtering (probably for a similar reason).
Coming up with names is surprisingly difficult. I got into a discussion
with a colleague a while ago about this. They were having difficulty
coding something an it turned out to be simply what names to choose for
routines.
>
> Hilarious--and reason enough to change names.
>
> When you do change names, can you spell LD and ST instead of MOV ??
Yes, please LD / ST it is so much clearer what is going on. Less trouble
getting confused by the placement of operands.
I always put the memory operand second, which breaks the pattern of
having the destination operand first. Otherwise the destination is first.
I go cross-eyed reading code that is a whole lot of moves.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-11 01:14 -0500 |
| Message-ID | <vqokel$1rcu2$1@dont-email.me> |
| In reply to | #111060 |
On 3/10/2025 9:49 PM, Robert Finch wrote:
> On 2025-03-10 8:53 p.m., MitchAlsup1 wrote:
>> On Mon, 10 Mar 2025 22:40:55 +0000, BGB wrote:
>>
>>> On 3/7/2025 9:28 PM, MitchAlsup1 wrote:
>>>> On Sat, 8 Mar 2025 2:49:50 +0000, BGB wrote:
>>>>
>>>> ------------------------
>>>>>
>>>>> I guess, while a person could do something like (in C):
>>>>> _BitInt(1048576) bmp;
>>>>> _Boolean b;
>>>>> ...
>>>>> b=(bmp>>i)&1; //*blarg* (shift here would be absurdly expensive)
>>>>>
>>>>> This is liklely to be rare vs more traditional strategies, say:
>>>>> uint64_t *bmp;
>>>>> int b, i;
>>>>> ...
>>>>> b=(bmp[i>>6]>>(i&63))&1;
>>>>
>>>> Question: How do you handle the case where the bit vector is an odd
>>>> number of bits in width ?? Say <3, 5, 7, 17, ...>
>>>>
>>>
>>> It is rare for bitmap bits to not be a power of 2...
>>>
>>> I would guess, at least for C, something like (for 3 bits):
>>> uint32_t *bmp;
>>> uint64_t bv;
>>> int i, b, bp;
>>> ...
>>> bp=i*3;
>>> bv=*(uint64_t *)(bmp+(bp>>5));
>>> b=(bv>>(bp&31))&7;
>>>
>>> Could apply to anything up to 31 bits.
>>
>> Not bad.
>>
>>> Could do similar with __int128 (or uint128_t), which extends it up to 63
>>> bits.
>> ------------
>>>> Mc 68020 had instructions to access bit-fields that cross word
>>>> boundaries.
>>>>
>>>
>>> I guess one could argue the use-case for adding a generic funnel shift
>>> instruction.
>>
>> My 66000 has CARRY-SL/SR which performs a double wide operand shifted
>> by a single wide count (0..63) and produces a double wide result {IO}.
>>
>>> If I added it, it would probably be a 64-bit encoding (generally needed
>>> for 4R).
>>
>> By placing the width in position {31..37} you can compress this down
>> to 3-Operand.
>>
>> ----------
>>>> Architecture is more about what gets left OUT than what gets left IN.
>>>
>>> Well, except in this case it was more a question of trying to fit it in
>>> with C semantics (and not consideration for more ISA features).
>>
>> Clearly, you want to support C semantics--but you can do this in a way
>> that also supports languages with real bit-field support.
>> ---------------
>>> There are still some limitations, for example:
>>> In my current implementation, CSR's are very limited (may only be used
>>> to load and store CSRs; not do RMW operations on CSRs).
>>
>> <y 66000 only has 8 CPU CRs, and even these are R/W through MMI/O
>> space. All the other (effective) CRs are auto loaded in line quanta.
>>
>> This mechanism allows one CPU to figure out what another CPU is up to
>> simply by meandering through its CRs...
>>
>>> Though, have noted that seemingly some number of actual RISC-V cores
>>> also have this limitation.
>>>
>>>
>>> A more drastic option might be to try to rework the hardware interfaces
>>> and memory map hopefully enough to try to make it possible to run an OS
>>> like Linux, but there doesn't really seem to be a standardized set of
>>> hardware interfaces or memory map defined.
>>>
>>> Some amount of SOC's though seem to use a map like:
>>> 00000000..0000FFFF: ROM goes here.
>>> 00010000..0XXXXXXX: RAM goes here.
>>> ZXXXXXXX..FFFFFFFF: Hardware / MMIO
>>
> I got used to a lot of micro-computer maps which have RAM at low end and
> ROM at the high end.
>
> I have the Q+ SoC setup like this (which is pretty much the way I setup
> all SoC) I use 32-bit addressing for demo purposes. Low cost FPGA boards
> typically do not have many gigabytes of memory.
>
> 00000000..3FFFFFFF DRAM
> 40000000..CFFFFFFF DRAM expansion area (not present on board)
> D0000000..DFFFFFFF config (FTA DDBB device discovery black boxes)
> E0000000..FEBFFFFF unassigned
> FEC00000..FEFFFFFF MMI/O
> FF000000..FFF7FFFF ROM expansion area (unimplemented)
> FFF80000..FFFBFFFF Scratchpad RAM
> FFFC0000..FFFFFFFF ROM
>
> The DDBB can configure the MMI/O to appear at any address, but I have
> devices defaulting to
> FEC00000..FEFFFFFF MMI/O
> Each DDBB is a 4kB space, the last 3kB are ROM for device support
>
> There is a CSR that can reconfig the config area, which defaults to
> Dxxxxxxx.
>
> Addresses are double bit sign extended from 32-bits to 64-bits when
> setup by the boot ROM, but the high order 64-bits are ignored by the
> hardware.
>
> I went with dynamically determined MMI/O addressing setup at boot time
> which is hopefully usable with and OS. Defaults are such that the system
> is able to boot.
>
In my case, the high 16 bits of pointers are ignored (usually left for
tag bits and similar), except for certain instructions.
Not much consistency it seems.
Can note that SH-4 had used a physical map sorta like (IIRC):
00000000..0000FFFF: ROM
00010000..007FFFFF: Hardware IO (RAM like)
00800000..1FFFFFFF: RAM Space
RAM wrapped to fill the rest of the space.
Some stuff treated 10000000 as the start of RAM.
20000000..3FFFFFFF: Repeat
40000000..5FFFFFFF: Repeat
60000000..7FFFFFFF: Repeat
80000000..9FFFFFFF: Repeat, System
A0000000..BFFFFFFF: Repeat, System (NoMMU)
C0000000..DFFFFFFF: Repeat, NoCache
E0000000..FFFFFFFF: Hardware MMIO (NoMMU, NoCache)
Effectively, it had a 29-bit physical space, but a 31-bit virtual
address space (high 2GB being special/system-only).
Within the low 8MB, it had:
Display VRAM;
As a linear framebuffer and a hardware renderer.
Audio RAM;
UART and similar;
A CD-ROM interface (N/A; was ATAPI based IIRC);
...
When I started my current ISA project, the hardware interfaces were
redesigned to be simpler, and initially moved entirely into MMIO space
(though the display and audio hardware did later regain RAM backed buffers).
Display didn't fully move back to a linear framebuffer though.
Technically, it can sorta be configured into a linear framebuffer, but
due to memory-fetch issues it looks a lot worse (on actual hardware)
than the tile-ordered buffer (in 8bpp and 16bpp modes, the display
memory is organized in 4x4 pixel tiles).
It was initially designed more around 8x8 pixel color cell graphics
(which can do both text and graphics, though with worse color fidelity
than a true bitmapped mode as it is limited to 2 colors per 4x4 or 8x8
tile, depending on sub-mode).
Generally, modes that have both high resolution and high color depth
would take too much memory bandwidth.
Within the bitmapped modes, the current practical limit is roughly
640x400 256-color.
So, say, 800x600 is only really viable with color-cell graphics.
There is a 1024x768 monochrome mode, but it could be possible to stretch
it into a color-cell mode by using 16 extra bits per 8x8 cell (or 1.25
bpp). Likely, these would use colors from the 256 color palette.
Basically, the idea being that each bit in the 8x8 pixel cell selects
between the 2 colors.
Initially, some of the modes that exist were partly because I was trying
to design something that could display Doom and Quake passably with 16K
or 32K of VRAM (or, basically, a 320x200 mode needs to fit into 2bpp).
The VRAM later got bigger, but high-res high-depth modes need a lot of
bandwidth...
But, probably no mainline OS will have native support for such hardware
or modes, which might be an issue.
>> My 66000::
>> 00 0000000000000000..FFFFFFFFFFFFFFFF: DRAM
>> 01 0000000000000000..FFFFFFFFFFFFFFFF: MMI/O
>> 10 0000000000000000..FFFFFFFFFFFFFFFF: config
>> 11 0000000000000000..FFFFFFFFFFFFFFFF: ROM
>>
> How does one reference DRAM vs MMI/O at the same address using a LD / ST
> instruction?
>
> Q+ CPU just uses a 64-bit address range. The config space is specified
> in a CR defaulting to FFFFFFFFDxxxxxxx The TLB is setup at boot to
> access ROM at FFFFFFFFFFFCxxxxx Otherwise there is no distinction with
> addresses. There is a region table in the system that describes up to
> eight distinct regions.
>
In my case, a single set of instructions is used, with a 48-bit address
range like:
0000_00000000..7FFF_FFFFFFFF: Userland VAS
8000_00000000..BFFF_FFFFFFFF: System VAS
C000_00000000..CFFF_FFFFFFFF: Physical Space (No MMU)
D000_00000000..DFFF_FFFFFFFF: Physical Space (No MMU, Volatile)
E000_00000000..EFFF_FFFFFFFF: Reserved
F000_00000000..FFFF_FFFFFFFF: MMIO Space
Would, within Physical Space:
Z000: All of the physical map goes here.
Z001..ZFFF: Nothing
Then, within the low 4GB:
00000000..00007FFF: ROM
0000C000..0000DFFF: SRAM
00010000..00FFFFFF: Special ROM Pages (mostly NULL)
01000000..3FFFFFFF: RAM
40000000..EFFFFFFF: Nothing
F0000000..FFFFFFFF: Optional MMIO (32-bit config)
The 28-bit MMIO space is mapped into FFFF_Fxxxxxxx, with pretty much the
whole rest of MMIO space being unused.
Early on, the 32-bit MMIO space and low 4GB were special (including in
the VAS), bit this has gone away (so, now only the 48-bit forms are
recognized if configured for a 48-bit addressing).
>> Whatever you are trying to do, you won't run out of address space until
>> 64 bits becomes insufficient. Note: all HW interfaces are in config
>> space
>> and all CRs are in MMI/O space.
>
> Are there any CRs accessible with any instructions besides LD / ST?
I had an instruction to load/store CRs...
I had called it... "MOV" ...
Ironically, this was a reduction from SH, which called them
LDC/STC/LDS/STS, depending on which registers one was going to/from.
>>
>> ------------
>>> They seem to also be asking for a UEFI based boot process, but this
>>> would require having a bigger BootROM (can't likely fit a UEFI
>>> implementation into 32K). Seems that the idea is to have the UEFI BIOS
>>> boot the kernel directly as an ELF image (traditionally UEFI was always
>>> PE/COFF based?...).
>>
>> Boot ROM should be big enough that no BOOT ROM will ever exceed its
>> size.
>> --------------
>>> There is a probable need to move away from the "BJX2" name, which as
>>> noted, has some unfortunate connotations (turns out it was also used for
>>> a lewd act) and seems to be triggering to Google's automatic content
>>> filtering (probably for a similar reason).
>
> Coming up with names is surprisingly difficult. I got into a discussion
> with a colleague a while ago about this. They were having difficulty
> coding something an it turned out to be simply what names to choose for
> routines.
At least, function names are not:
Try to find a short acronym that also has relatively few web hits.
>>
>> Hilarious--and reason enough to change names.
>>
>> When you do change names, can you spell LD and ST instead of MOV ??
>
> Yes, please LD / ST it is so much clearer what is going on. Less trouble
> getting confused by the placement of operands.
>
> I always put the memory operand second, which breaks the pattern of
> having the destination operand first. Otherwise the destination is first.
>
> I go cross-eyed reading code that is a whole lot of moves.
>
A low of people swear by:
movl %eax, 16(%rdi)
...
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-11 18:00 +0000 |
| Message-ID | <d9ca952fdc4a6cb667ed15515f97996e@www.novabbs.org> |
| In reply to | #111062 |
On Tue, 11 Mar 2025 6:14:31 +0000, BGB wrote: > > A low of people swear by: > movl %eax, 16(%rdi) > .... More swear at it than for it. Most likely: those who swear by it have brain damage by x86-ism.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-11 21:29 +0000 |
| Message-ID | <IW1AP.458544$2zn8.26913@fx15.iad> |
| In reply to | #111068 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Tue, 11 Mar 2025 6:14:31 +0000, BGB wrote: >> >> A low of people swear by: >> movl %eax, 16(%rdi) >> .... > >More swear at it than for it. > >Most likely: those who swear by it have brain damage by x86-ism. It's the oververbose, bas-ackwards intel syntax that one does swear at. The AT&T syntax that BGB noted above is far superior. YMMVO.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-03-11 22:41 +0100 |
| Message-ID | <vqqamt$26g0n$1@dont-email.me> |
| In reply to | #111078 |
Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >> On Tue, 11 Mar 2025 6:14:31 +0000, BGB wrote: >>> >>> A low of people swear by: >>> movl %eax, 16(%rdi) >>> .... >> >> More swear at it than for it. >> >> Most likely: those who swear by it have brain damage by x86-ism. > > It's the oververbose, bas-ackwards intel syntax that one does swear at. > > The AT&T syntax that BGB noted above is far superior. > > YMMVO. x86 asm, as used in MASM and DEBUG, was the first assembler language O used, I found it very familiar that mov ax,bx or mov ax,[bx] or mov ax,[bx+1234] all correspond nicely to a = b a = *b a = b[1234] I.e having the target on the left is the only one that makes sense to me. I can read the wrong one of course, but I have internally translate everything before I can grok it. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <david.schultz@earthlink.net> |
|---|---|
| Date | 2025-03-11 16:57 -0500 |
| Message-ID | <-cGcnYCDc65FLE36nZ2dnZfqnPqdnZ2d@earthlink.com> |
| In reply to | #111079 |
On 3/11/25 4:41 PM, Terje Mathisen wrote: > x86 asm, as used in MASM and DEBUG, was the first assembler language O > used, I found it very familiar that > > mov ax,bx > or > mov ax,[bx] > or > mov ax,[bx+1234] > > all correspond nicely to > > a = b > a = *b > a = b[1234] Looks more like move a to b. -- http://davesrocketworks.com David Schultz "The cheeper the crook, the gaudier the patter." - Sam Spade
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-11 22:40 +0000 |
| Message-ID | <vqqe4j$273mt$1@dont-email.me> |
| In reply to | #111079 |
On Tue, 11 Mar 2025 22:41:48 +0100, Terje Mathisen wrote:
> I.e having the target on the left is the only one that makes sense to
> me.
One of the early programming languages I came across was POP-2. This was
fully dynamic and heap-based, like Lisp, but also had an operand stack. So
a simple assignment statement looked like
a -> b;
but this could actually be written as two separate statements:
a;
-> b;
The first one pushed the value of a on the stack, the second one popped it
off and stored it in b.
This made it easy to do things like swap variable values:
a, b -> a -> b;
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-12 08:57 +0000 |
| Message-ID | <2025Mar12.095719@mips.complang.tuwien.ac.at> |
| In reply to | #111082 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >One of the early programming languages I came across was POP-2. This was >fully dynamic and heap-based, like Lisp, but also had an operand stack. So >a simple assignment statement looked like > > a -> b; > >but this could actually be written as two separate statements: > > a; > -> b; > >The first one pushed the value of a on the stack, the second one popped it >off and stored it in b. > >This made it easy to do things like swap variable values: > > a, b -> a -> b; In Forth you can define VALUEs that work like these POP-11 variables. In standard Forth you can write 3 value a 5 value b a b to a to b \ swaps the contents of a and b a . b . \ print a and b In some Forth systems you can write it in a syntax even closer to that of POP: On VFX Forth you can write: a b -> a -> b In Gforth (development version) you can write a b ->a ->b That's all not very idiomatic, though. VARIABLEs (which push their address rather than their value) are more popular than VALUEs, but usage such as the following is also not idiomatic; you usually use variables (and values) sparingly. variable a 3 a ! variable b 5 b ! a @ b @ a ! b ! a @ . b @ . - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-12 21:35 +0000 |
| Message-ID | <vqsunj$2qkvk$1@dont-email.me> |
| In reply to | #111108 |
On Wed, 12 Mar 2025 08:57:19 GMT, Anton Ertl wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> One of the early programming languages I came across was POP-2. This >> was fully dynamic and heap-based, like Lisp, but also had an operand >> stack. > > In Forth you can define VALUEs that work like these POP-11 variables. Never saw much point in Forth. I suppose in the early days when memories were smaller and CPUs were slower, it gave you something a little bit better than assembler, but not by much. Besides garbage collection, POP-2 also had macros and custom operators.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-11 17:44 +0000 |
| Message-ID | <5e696219dedf30d0095dfd7671a4c87f@www.novabbs.org> |
| In reply to | #111060 |
On Tue, 11 Mar 2025 2:49:00 +0000, Robert Finch wrote:
> On 2025-03-10 8:53 p.m., MitchAlsup1 wrote:
>> On Mon, 10 Mar 2025 22:40:55 +0000, BGB wrote:
>>>> ------------------------
>> My 66000::
>> 00 0000000000000000..FFFFFFFFFFFFFFFF: DRAM
>> 01 0000000000000000..FFFFFFFFFFFFFFFF: MMI/O
>> 10 0000000000000000..FFFFFFFFFFFFFFFF: config
>> 11 0000000000000000..FFFFFFFFFFFFFFFF: ROM
>>
> How does one reference DRAM vs MMI/O at the same address using a LD / ST
> instruction?
The MMU translates the virtual address to a universal address.
The PTE supplies the extra bits.
> Q+ CPU just uses a 64-bit address range. The config space is specified
> in a CR defaulting to FFFFFFFFDxxxxxxx The TLB is setup at boot to
> access ROM at FFFFFFFFFFFCxxxxx Otherwise there is no distinction with
> addresses. There is a region table in the system that describes up to
> eight distinct regions.
Every major block in my architecture has ports in config space that
smell just like that of a device on PCIe having said control block.
My thought was that adding all these to the config name space might
cramp any fixed (or programmable) partition. So, the easiest thing
is to give it its own big space.
Then every device header gets 1 or more pages of address space for
its own control registers. PCIe is now a 42-bit address space::
segment, bus; device; function, xreg, reg and likely to grow as
ACHI can consume a whole PCIe segment by itself.
>> Whatever you are trying to do, you won't run out of address space until
>> 64 bits becomes insufficient. Note: all HW interfaces are in config
>> space
>> and all CRs are in MMI/O space.
>
> Are there any CRs accessible with any instructions besides LD / ST?
CRs accessible via HR instruction theoretically == 40
CRs accessible via HR instruction at a privilege >= 16
Basically, HR provides access to this threads critical CRs
{IP, Root, ASID, CSP, exception ctrl, inst ctrl, interrupts ...}
and has access to the CPU SW stack according to privilege.
>> ------------
>>> They seem to also be asking for a UEFI based boot process, but this
>>> would require having a bigger BootROM (can't likely fit a UEFI
>>> implementation into 32K). Seems that the idea is to have the UEFI BIOS
>>> boot the kernel directly as an ELF image (traditionally UEFI was always
>>> PE/COFF based?...).
>>
>> Boot ROM should be big enough that no BOOT ROM will ever exceed its
>> size.
>> --------------
>>> There is a probable need to move away from the "BJX2" name, which as
>>> noted, has some unfortunate connotations (turns out it was also used for
>>> a lewd act) and seems to be triggering to Google's automatic content
>>> filtering (probably for a similar reason).
>
> Coming up with names is surprisingly difficult. I got into a discussion
> with a colleague a while ago about this. They were having difficulty
> coding something an it turned out to be simply what names to choose for
> routines.
>>
>> Hilarious--and reason enough to change names.
>>
>> When you do change names, can you spell LD and ST instead of MOV ??
>
> Yes, please LD / ST it is so much clearer what is going on. Less trouble
> getting confused by the placement of operands.
>
> I always put the memory operand second, which breaks the pattern of
> having the destination operand first. Otherwise the destination is
> first.
>
> I go cross-eyed reading code that is a whole lot of moves.
I agree.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-03-11 11:15 -0700 |
| Message-ID | <vqpuja$22eta$1@dont-email.me> |
| In reply to | #111066 |
On 3/11/2025 10:44 AM, MitchAlsup1 wrote:
> On Tue, 11 Mar 2025 2:49:00 +0000, Robert Finch wrote:
>
>> On 2025-03-10 8:53 p.m., MitchAlsup1 wrote:
>>> On Mon, 10 Mar 2025 22:40:55 +0000, BGB wrote:
>>>>> ------------------------
>
>>> My 66000::
>>> 00 0000000000000000..FFFFFFFFFFFFFFFF: DRAM
>>> 01 0000000000000000..FFFFFFFFFFFFFFFF: MMI/O
>>> 10 0000000000000000..FFFFFFFFFFFFFFFF: config
>>> 11 0000000000000000..FFFFFFFFFFFFFFFF: ROM
>>>
>> How does one reference DRAM vs MMI/O at the same address using a LD / ST
>> instruction?
>
> The MMU translates the virtual address to a universal address.
> The PTE supplies the extra bits.
>
>> Q+ CPU just uses a 64-bit address range. The config space is specified
>> in a CR defaulting to FFFFFFFFDxxxxxxx The TLB is setup at boot to
>> access ROM at FFFFFFFFFFFCxxxxx Otherwise there is no distinction with
>> addresses. There is a region table in the system that describes up to
>> eight distinct regions.
>
> Every major block in my architecture has ports in config space that
> smell just like that of a device on PCIe having said control block.
> My thought was that adding all these to the config name space might
> cramp any fixed (or programmable) partition. So, the easiest thing
> is to give it its own big space.
>
> Then every device header gets 1 or more pages of address space for
> its own control registers. PCIe is now a 42-bit address space::
> segment, bus; device; function, xreg, reg and likely to grow as
> ACHI can consume a whole PCIe segment by itself.
>
>>> Whatever you are trying to do, you won't run out of address space until
>>> 64 bits becomes insufficient. Note: all HW interfaces are in config
>>> space
>>> and all CRs are in MMI/O space.
>>
>> Are there any CRs accessible with any instructions besides LD / ST?
>
> CRs accessible via HR instruction theoretically == 40
> CRs accessible via HR instruction at a privilege >= 16
>
> Basically, HR provides access to this threads critical CRs
> {IP, Root, ASID, CSP, exception ctrl, inst ctrl, interrupts ...}
> and has access to the CPU SW stack according to privilege.
>
>>> ------------
>>>> They seem to also be asking for a UEFI based boot process, but this
>>>> would require having a bigger BootROM (can't likely fit a UEFI
>>>> implementation into 32K). Seems that the idea is to have the UEFI BIOS
>>>> boot the kernel directly as an ELF image (traditionally UEFI was always
>>>> PE/COFF based?...).
>>>
>>> Boot ROM should be big enough that no BOOT ROM will ever exceed its
>>> size.
>>> --------------
>>>> There is a probable need to move away from the "BJX2" name, which as
>>>> noted, has some unfortunate connotations (turns out it was also used
>>>> for
>>>> a lewd act) and seems to be triggering to Google's automatic content
>>>> filtering (probably for a similar reason).
>>
>> Coming up with names is surprisingly difficult. I got into a discussion
>> with a colleague a while ago about this. They were having difficulty
>> coding something an it turned out to be simply what names to choose for
>> routines.
>>>
>>> Hilarious--and reason enough to change names.
>>>
>>> When you do change names, can you spell LD and ST instead of MOV ??
>>
>> Yes, please LD / ST it is so much clearer what is going on. Less trouble
>> getting confused by the placement of operands.
>>
>> I always put the memory operand second, which breaks the pattern of
>> having the destination operand first. Otherwise the destination is
>> first.
>>
>> I go cross-eyed reading code that is a whole lot of moves.
>
> I agree.
I wonder if the different preferences is at least partially due to
whether the person has a hardware or a software background? The idea is
that when hardware guys see the instruction, they think in terms of
register ports (read versus write), what is required of the memory
system (somewhat different for loads versus stores), etc. However
software guys think of a language construct, e.g. X = Y, which is
logically a move. I don't know if this is right, but I think it is
interesting.
A somewhat related question, if one wants to copy the contents of R3
into R2, is that a load or a store? :-)
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-11 18:56 +0000 |
| Message-ID | <1ad795d74196830d2232d4f0b50ac2e4@www.novabbs.org> |
| In reply to | #111069 |
On Tue, 11 Mar 2025 18:15:06 +0000, Stephen Fuld wrote:
> On 3/11/2025 10:44 AM, MitchAlsup1 wrote:
>>>> When you do change names, can you spell LD and ST instead of MOV ??
>>>
>>> Yes, please LD / ST it is so much clearer what is going on. Less trouble
>>> getting confused by the placement of operands.
>>>
>>> I always put the memory operand second, which breaks the pattern of
>>> having the destination operand first. Otherwise the destination is
>>> first.
>>>
>>> I go cross-eyed reading code that is a whole lot of moves.
>>
>> I agree.
>
> I wonder if the different preferences is at least partially due to
> whether the person has a hardware or a software background?
Even when both LD and ST are written MOV there is a different OpCode
for the inbound MOV versus the outbound MOV, so, in effect, they are
really different instructions requiring different pipeline semantics.
Only (O N L Y) when one has a memory to memory move instruction can
the LDs and STs be MOVs. VAX had this, BJX* does not.
One should argue that different pipeline semantics requires a different
OpCode--and you already have said OpCode having different bit patterns
and different signedness semantics different translation access rights
, ... At the HW level about the only thing LD has in common with ST is
the way the address is generated--although MIPS did something different.
> The idea is
> that when hardware guys see the instruction, they think in terms of
> register ports (read versus write), what is required of the memory
> system (somewhat different for loads versus stores), etc. However
> software guys think of a language construct, e.g. X = Y, which is
MARY and MARY2 used X = Y to mean the value in X is deposited into Y.
Both were left to right only languages. This should surprise most !!
{{Although to be fair, Mary used the =: operator to perform assign.}}
It took me 40 years of writing specifications to get to the point where
I can write a specification such that neither the uninformed benevolent
reader nor the malicious engineer can misread that specification. MOV
is one of those things that makes getting the specification perfect
harder--and down the road, you too will figure out why I carry this
torch ...
> logically a move. I don't know if this is right, but I think it is
> interesting.
>
> A somewhat related question, if one wants to copy the contents of R3
> into R2, is that a load or a store? :-)
In several RISC ISAs it is an ADD #0 or OR #0, however, in My 66000
we get a MOV instruction (reg-reg only) as a degenerate version of
the CMOV instruction {Hey, fell out for free}
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-03-11 13:46 -0700 |
| Message-ID | <vqq7f0$22eta$2@dont-email.me> |
| In reply to | #111071 |
On 3/11/2025 11:56 AM, MitchAlsup1 wrote:
> On Tue, 11 Mar 2025 18:15:06 +0000, Stephen Fuld wrote:
>
>> On 3/11/2025 10:44 AM, MitchAlsup1 wrote:
>>>>> When you do change names, can you spell LD and ST instead of MOV ??
>>>>
>>>> Yes, please LD / ST it is so much clearer what is going on. Less
>>>> trouble
>>>> getting confused by the placement of operands.
>>>>
>>>> I always put the memory operand second, which breaks the pattern of
>>>> having the destination operand first. Otherwise the destination is
>>>> first.
>>>>
>>>> I go cross-eyed reading code that is a whole lot of moves.
>>>
>>> I agree.
>>
>> I wonder if the different preferences is at least partially due to
>> whether the person has a hardware or a software background?
>
> Even when both LD and ST are written MOV there is a different OpCode
> for the inbound MOV versus the outbound MOV, so, in effect, they are
> really different instructions requiring different pipeline semantics.
>
> Only (O N L Y) when one has a memory to memory move instruction can
> the LDs and STs be MOVs. VAX had this, BJX* does not.
>
> One should argue that different pipeline semantics requires a different
> OpCode--and you already have said OpCode having different bit patterns
> and different signedness semantics different translation access rights
> , ... At the HW level about the only thing LD has in common with ST is
> the way the address is generated--although MIPS did something different.
You are making my point. No software guy talks about "pipeline
semantics" :-) Note that I am not saying you are wrong, just noting the
difference.
>
>> The idea is
>> that when hardware guys see the instruction, they think in terms of
>> register ports (read versus write), what is required of the memory
>> system (somewhat different for loads versus stores), etc. However
>> software guys think of a language construct, e.g. X = Y, which is
>
> MARY and MARY2 used X = Y to mean the value in X is deposited into Y.
> Both were left to right only languages. This should surprise most !!
> {{Although to be fair, Mary used the =: operator to perform assign.}}
And see my point about COBOL in the post above.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-11 22:43 +0000 |
| Message-ID | <vqqe9r$273mt$3@dont-email.me> |
| In reply to | #111074 |
On Tue, 11 Mar 2025 13:46:24 -0700, Stephen Fuld wrote: > No software guy talks about "pipeline semantics" :-) Remember what pipes are in Unix, and how they can be used to construct command pipelines.
[toc] | [prev] | [next] | [standalone]
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web