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 7 of 17 — ← Prev page 1 … 5 6 [7] 8 9 … 17 Next page →
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-03-12 00:26 +0000 |
| Message-ID | <vqqkca$1uln$1@gal.iecc.com> |
| In reply to | #111077 |
It appears that Scott Lurndal <slp53@pacbell.net> said: >>I wonder if the different preferences is at least partially due to >>whether the person has a hardware or a software background? The idea is > >I think it may depend on first experiences with assembler language; Absolutely. My first assembler was PDP-8, where nothing has more than one operand. Next was S/360 where the result goes first, e.g. LR R1,R2 copies R2 into R1. Next was PDP=11 where MOV R1,R2 copies R1 into R2. So I think they're all about equally bad. People should get over it. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-12 00:38 +0000 |
| Message-ID | <vqql32$28fls$4@dont-email.me> |
| In reply to | #111090 |
On Wed, 12 Mar 2025 00:26:50 -0000 (UTC), John Levine wrote: > Next was PDP=11 where MOV R1,R2 copies R1 into R2. What about CMP (compare) versus SUB (subtract)? CMP does the subtract without updating the destination operand, only setting the condition codes. But are the operands the same way around as SUB (i.e. backwards for comparison purposes) or are they flipped?
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-12 04:02 -0500 |
| Message-ID | <vqrikn$2hcm7$1@dont-email.me> |
| In reply to | #111095 |
On 3/11/2025 7:38 PM, Lawrence D'Oliveiro wrote:
> On Wed, 12 Mar 2025 00:26:50 -0000 (UTC), John Levine wrote:
>
>> Next was PDP=11 where MOV R1,R2 copies R1 into R2.
>
> What about CMP (compare) versus SUB (subtract)? CMP does the subtract
> without updating the destination operand, only setting the condition
> codes. But are the operands the same way around as SUB (i.e. backwards for
> comparison purposes) or are they flipped?
Well, it is that way on x86 at least...
Otherwise, depends on arch...
At present, I have:
SUB Rm, Rn //Rn=Rn-Rm
SUB Rs, Rt, Rn //Rn=Rs-Rt
CMPGT Rm, Rn //SR.T = Rn>Rm OR ~ ((Rn-Rm)>0) (N/A XG3)
CMPGT Rs, Rt, Rn //Rn = Rs>Rt
In neither case does SUB update flags, and CMPGT only updates SR.T, but
this form is only allowed in XG1 and XG2 (in XG3, it is demoted to
optional and, if allowed, is instead encoded as "CMPGT Rs, Rt, ZZR").
There are several CMPxx ops available:
CMPEQ / SEQ
CMPNE / SNE
CMPGT / SGT / SLT
CMPGE / SGE / SLE
CMPHI / SGTU / SLTU
CMPHS / SGEU / SLEU
TEST / STST
TESTN / SNTST
The SLT/SGT and SLE/SGE operators are basically the same operator,
differing primarily in that the arguments are flipped.
That said, the combination of SLT and SGE or SGT and SLE make more sense
if immediate-synthesis is being used. This is a little bit of a design
wart in my own ISA as I didn't think of this and had used SGT and SGE.
Note that with both SLT and SGE (or the reverse), it is possible to fake
the other 2 cases (SLE and SGT).
The latter names were partly influenced by RISC-V naming, though RISC-V
only had SLT and SLTU. I added the latter cases as RV extensions (more
recently with 32-bit encodings) as they were used often enough in the
BGBCC output, that they can save a few % off the size of the binary.
With 32-bit encodings, they save a little over 3% relative to using
multi-op sequences to fake these cases.
BTST/BNTST, STST/SNTST, are actually more common than unsigned
compare-branch and compare in my compiler output, but RISC-V lacks them.
Well, the ISA variants also tweaked branches:
XG1:
CMPxx Rm, Rn; BT/BF label //Compare Rn with Rm (Core)
JCMPxx Rn, Disp10 //compare Rn with 0 (Opt)
JCMPxx Rm, Rn, Disp8 //compare Rn with Rm (Opt)
XG2:
Basically same as XG1.
Just BT/BF has a larger displacement in XG2 (8MB vs 1MB).
XG3:
Bxx Rm, Rn, Disp10 //compare Rn with Rm (Core)
Sxx Rm, Rn, ZZR; BT/BF label //Compare Rm with Rn (Opt)
In the BT/BF case, range is 16MB.
Bxx Disp10, Rn, Rm //Same, but RV ordering.
In XG1/2/3, Jumbo_Imm will expand an normal Imm/Disp field to 33 bits.
In XG3, immediate-synthesis may also encode an Imm33.
Vs 29 bits in XG1 and XG2.
In RV+Jx, typical immediate-synthesis is limited to 17 bits, though a
26-bit case exists (with some tradeoffs).
In XG1/2, there was a "CMPxx Imm10, Rn" case, to compare an Imm10 with
Rn in a 32-bit encoding. This encoding was (for now) not formally
carried over into XG3. Immediate-synthesis can deal with this, but this
is a 64-bit encoding.
One possibility would be to give RV64's "SLTI Imm12s" encoding the same
basic semantics when the destination is ZERO (like in the XG3 ops) and
then borrow the RV64 encoding in this case. Though, it seems wonky to
borrow an RV encoding to encode semantics that are, in effect, alien to
RISC-V...
The seemingly backwards compare ordering was itself partly a holdover
from SH, but, one gets used to it (it is at least consistent with how
they are decoded and performed, if one imagines them decoded as 2R
subtract).
...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-12 09:14 +0000 |
| Message-ID | <2025Mar12.101400@mips.complang.tuwien.ac.at> |
| In reply to | #111095 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >On Wed, 12 Mar 2025 00:26:50 -0000 (UTC), John Levine wrote: > >> Next was PDP=11 where MOV R1,R2 copies R1 into R2. > >What about CMP (compare) versus SUB (subtract)? CMP does the subtract >without updating the destination operand, only setting the condition >codes. But are the operands the same way around as SUB (i.e. backwards for >comparison purposes) or are they flipped? In AT&T syntax for IA-32 and AMD64, the operands are the same way round as for SUB (i.e., flipped compared to Intel syntax). This leads to counterintuitive combinations of compare and branches. E.g., "cmp %rax,%rbx; jlt ..." jumps if %rax is greater than %rbx. For the PDP-11, where the mnemonics etc. were created with that order in mind, the mnemonics of the flags-using instructions could be named appropriately. I.e., after "cmp x,y" or "sub x,y", "blt" could branch if x<y. I have not checked if that's the case for the PDP-11, though. - 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-11 22:42 +0000 |
| Message-ID | <vqqe7p$273mt$2@dont-email.me> |
| In reply to | #111069 |
On Tue, 11 Mar 2025 11:15:06 -0700, Stephen Fuld wrote: > A somewhat related question, if one wants to copy the contents of R3 > into R2, is that a load or a store? :-) The true hardware engineer knows that it is neither, it is merely a register rename. ;)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-12 00:42 +0000 |
| Message-ID | <73c17ba38fd8e9a3584cab8b923f378e@www.novabbs.org> |
| In reply to | #111083 |
On Tue, 11 Mar 2025 22:42:02 +0000, Lawrence D'Oliveiro wrote: > On Tue, 11 Mar 2025 11:15:06 -0700, Stephen Fuld wrote: > >> A somewhat related question, if one wants to copy the contents of R3 >> into R2, is that a load or a store? :-) > > The true hardware engineer knows that it is neither, it is merely a > register rename. ;) And a move of the pre-renamed register back to the free pool.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-03-12 08:02 +0000 |
| Message-ID | <2025Mar12.090207@mips.complang.tuwien.ac.at> |
| In reply to | #111069 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >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. I am a software person. When talking about register-memory copies, I prefer to talk about load and store operations, whether I talk about assembly language (even one where the mnemonic for these operations is MOV) or C; in Forth the spoken names for these operations are "fetch" (written: @) and "store" (written: !). My first programming was on the TI-58C programmable calculator, which has RCL (recall) and STO (store). Then some BASIC, where you write A = Expr. Then some 6502 assembly language, which has, e.g., LDA (load into accumulator) and STA (store from accumulator). In his HOPL paper Ritchie describes a number of competitors of C (e.g., BLISS), most of which make the use of addresses explicit, unlike C. So copying from one variable to another in one of these languages was along the lines of a = .b where a and b are addresses of variables, and "." fetches the value from the address (i.e., C's *). C won out over these languages, and it seems to me that Ritchie thought that the different approach in C with lexprs and (value) exprs was a major contributing factor. Back to assembly languages: In PDP-11-style architectures (e.g., 8086, IA-32, AMD64, 68000), where you have instructions of the form op r ,m/r op m/r,r it's pretty obvious that you implement load, store, and register-register copy as special cases of this scheme. And the common mnemonic for these three operations in all these architectures is MOV. This does not come out of higher-level software considerations, this comes out of the architecture, and how to implement the assembler and disassembler for it in the simplest way. By contrast, RISC architectures do not follow this scheme, so they have mnemonics starting with L (for load) and S (for store). Looking at <https://www.righto.com/2023/08/datapoint-to-8086.html>, the Datapoint 2200 and the 8008 called both LAM (load A from M(emory)) and LMA (store A to M(emory)) a load. This continues in the 8008. The 8080 assembly language replaces LAM with MOV A,M and LMA with MOV A,M. On the 8086 they are replaced with MOV AL,[BX] and MOV [BX],AL. >A somewhat related question, if one wants to copy the contents of R3 >into R2, is that a load or a store? :-) It's a register-register copy. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-12 23:58 +0000 |
| Message-ID | <vqt72g$2se4a$2@dont-email.me> |
| In reply to | #111105 |
On Wed, 12 Mar 2025 08:02:07 GMT, Anton Ertl wrote: > My first programming was on the TI-58C programmable calculator, which > has RCL (recall) and STO (store). It also had RCL IND and STO IND. Pointers, no less.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-03-13 12:08 -0700 |
| Message-ID | <vqvafl$2m6oe$1@dont-email.me> |
| In reply to | #111105 |
On 3/12/2025 1:02 AM, Anton Ertl wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >> 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. > > I am a software person. When talking about register-memory copies, I > prefer to talk about load and store operations, whether I talk about > assembly language (even one where the mnemonic for these operations is > MOV) or C; in Forth the spoken names for these operations are "fetch" > (written: @) and "store" (written: !). snipped lots of interesting history. A good counterpoint to my assertion. Thanks Anton. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-11 21:18 +0000 |
| Message-ID | <KM1AP.458542$2zn8.128543@fx15.iad> |
| In reply to | #111066 |
mitchalsup@aol.com (MitchAlsup1) writes: >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. Or make it relocatable anywhere in the address space. Assuming you format the config data in a standard form (e.g. PCI configuration space registers) to support off-the-shelf software, you can arrange most of your functions on a handful of buses on a single pci segment using ARI. > >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. AHCI consumes a single function on a bus, you can have up to seven functions per bus (without ARI) or 256 functions (with ARI). One or more of those functions may be a PCI-PCI bridge, which forwards to additional downstream buses. SRIOV capable devices, on the other hand, can consume an entire segment when supporting up to 64k virtual functions and the physical function for the device usually occupies function zero of the bus zero in a given segment. The endpoint device doesn't have any knowledge of the actual bus upon which it exists; if the physical function is on bus 8, function 0, for example, the virtual functions can occupy the rest of bus 8 through bus 255 on that segment for a maximum VF count of ((256 - 8) * 256 - PF#).
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-10 23:49 -0500 |
| Message-ID | <vqofeo$1qgv6$1@dont-email.me> |
| In reply to | #111059 |
On 3/10/2025 7:53 PM, 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}.
>
OK.
>> 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.
>
It is 3 operand if being used as a 128-bit shift op.
But, funnel shift operators implies 3 independent inputs and 1 output.
> ----------
>>> 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.
> ---------------
Yeah.
Amidst debugging and considering Verilog 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...
>
I had enough space for 64 CRs, but only a small subset are actually
used. Some more had space reserved, but were related to non-implemented
features.
RISC-V has a 12-bit CSR space, of which:
Some map to existing CRs;
My whole CR space was stuck into an implementation-dependent range.
Some read-only CSRs were mapped over to CPUID.
Of which, all of the CPUID indices were also mapped into CSR space.
Seemingly lacks defined user CSRs for timer or HW-RNG, which do exist in
my case. It is very useful to be able to access a HW timer in userland,
as otherwise it would waste a lot of clock-cycles using system calls for
"clock()" and similar.
>> 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.
>
There seems to be a lot here defined in terms of 32-bit physical spaces,
including on 64-bit targets.
Though, thus far, my existing core also has pretty all of its physical
map in 32-bit space.
The physical ranges from 0001_00000000 .. 7FFF_FFFFFFFF currently
contain a whole lot of nothing.
I once speculated on the possibility of special hardware to memory-map
the whole SDcard into physical space, but nothing has been done yet (and
such a hardware interface would be a lot more complicated than my
existing interface).
An intermediate option being to expand the SPI interface to support 256
bit bursts.
Say:
P_SPI_QDATA0..P_SPI_QDATA3
It appears this has already been partly defined (though not fully
implemented in the 256-bit case).
Where, the supported XMIT sizes are:
8 bit: Single Byte
64 bit: 8 bytes
256 bit: 32 bytes
With larger bursts mostly to reduce the amount of round-trip delay over
the bus.
> ------------
>> 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.
Or at least possibly the reserved space.
On reasonable FPGAs, it also eats BlockRAM, and the ROM size needs to be
small enough to not eat too much BRAM (and/or needs to be backed to some
external Flash device).
I guess, one possibility could be to fake a larger ROM (such as a UEFI
BIOS) by in effect loading it into RAM from the SDcard.
Though, I guess it is a question:
Could I fit a usable UEFI implementation into 48 or 64K ?...
Though, there does still seem to be an inconsistency:
RISC-V Platform Specification seems to imply UEFI loading ELF;
In other contexts, UEFI is described as loading PE/COFF.
Some other information implies that UEFI uses PE/COFF but for RISC-V
people compile to ELF and then use an ELF -> PE/COFF converter tool
(well, except when compiling with LLVM/Clang, which does support PE/COFF
on RISC-V).
I guess the main relevant differences:
MBR vs EFI-GPT;
But, SDcards usually use MBR and not EFI-GPT.
Different boot image name.
"efi/boot/bootXX.efi" vs "bootload.sys".
Seemingly (not confirmed) uses a DLL export as the entry point
("efi_main"), which is called using the C ABI, and is given an image
handle and a system-table pointer (which indirectly gives the relevant
VTables; which do not appear to follow COM Object conventions).
My current Boot ROM branches to the PE entry point, which does its own
boot-time init stuff. The ROM doesn't currently provide anything to the
loaded program.
UEFI seems more complicated than it needs to be.
Looking around:
Crap, it almost appears as if it would be easier just to use TestKern as
the basis of a UEFI implementation (UEFI is basically an OS).
Unless I can get by with a fairly minimal implementation, a lot of this
stuff probably isn't going to fit into 48 or 64K either.
I guess it is a question of how hard it would be to compile a Linux
RISC-V kernel to boot with something like the Coreboot, which appears
closer to what my existing ROM does (load the image, jump to it, done).
Though, apparently coreboot will also load a device-tree file and initrd
(implying some mechanism for it to signal to the kernel where these have
been loaded?...).
> --------------
>> 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.
>
It has been stuck at this issue for a while.
The current name has a problem, but also a feature:
Because hardly anything uses it, web search for it actually works.
> When you do change names, can you spell LD and ST instead of MOV ??
This mostly depends on which ASM syntax it is using...
It would likely switch over to RISC-V style naming if/when things switch
over to RISC-V ASM syntax (rather than the modified SuperH derived ASM
syntax).
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-11 17:57 +0000 |
| Message-ID | <a3304eadd68c10acb8385c43e326f4ec@www.novabbs.org> |
| In reply to | #111061 |
On Tue, 11 Mar 2025 4:49:16 +0000, BGB wrote:
> On 3/10/2025 7:53 PM, MitchAlsup1 wrote:
-------------------
>>> 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}.
>>
>
> OK.
>
>
>>> 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.
>>
>
> It is 3 operand if being used as a 128-bit shift op.
> But, funnel shift operators implies 3 independent inputs and 1 output.
And 2 shifts or exotic masking. Which is why I stopped early.
>> ----------
>>>> 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.
>> ---------------
>
> Yeah.
>
> Amidst debugging and considering Verilog 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).
>>
>> My 66000 only has 16 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...
>>
>
> I had enough space for 64 CRs, but only a small subset are actually
> used. Some more had space reserved, but were related to non-implemented
> features.
>
> RISC-V has a 12-bit CSR space, of which:
> Some map to existing CRs;
> My whole CR space was stuck into an implementation-dependent range.
My whole space is mapped by BAR registers as if they were on PCIe.
> Some read-only CSRs were mapped over to CPUID.
I don't even have a CPUID--if you want this you go to config space
and read the configuration lists and extended configuration lists.
> Of which, all of the CPUID indices were also mapped into CSR space.
CPUID is soooooo pre-PCIe.
>
> Seemingly lacks defined user CSRs for timer or HW-RNG, which do exist in
> my case. It is very useful to be able to access a HW timer in userland,
> as otherwise it would waste a lot of clock-cycles using system calls for
> "clock()" and similar.
That is why they are ALL available in MMI/O Space. If this user needs
access to that timer, then there is a PTE that translated the LD/ST
into an access to that device.
>
>>> 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.
>>
>
> There seems to be a lot here defined in terms of 32-bit physical spaces,
> including on 64-bit targets.
>
> Though, thus far, my existing core also has pretty all of its physical
> map in 32-bit space.
My 66000 does not even have a 32-bit space to map into.
You can synthesize such a space by not using any of the
top 32-address bits in PTEs--but why ??
>
> The physical ranges from 0001_00000000 .. 7FFF_FFFFFFFF currently
> contain a whole lot of nothing.
>
>
> I once speculated on the possibility of special hardware to memory-map
> the whole SDcard into physical space, but nothing has been done yet (and
> such a hardware interface would be a lot more complicated than my
> existing interface).
>
>
> An intermediate option being to expand the SPI interface to support 256
> bit bursts.
My interconnect bus is 1 cache line (512-bits) per cycle plus
address and command.
> Say:
> P_SPI_QDATA0..P_SPI_QDATA3
>
> It appears this has already been partly defined (though not fully
> implemented in the 256-bit case).
>
> Where, the supported XMIT sizes are:
> 8 bit: Single Byte
> 64 bit: 8 bytes
> 256 bit: 32 bytes
>
> With larger bursts mostly to reduce the amount of round-trip delay over
> the bus.
My 66000 interconnect bus can transmit a whole page in a single
burst--that appears ATOMIC to interested 3rd parties.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-11 16:20 -0500 |
| Message-ID | <vqq9h2$260sm$1@dont-email.me> |
| In reply to | #111067 |
On 3/11/2025 12:57 PM, MitchAlsup1 wrote:
> On Tue, 11 Mar 2025 4:49:16 +0000, BGB wrote:
>
>> On 3/10/2025 7:53 PM, MitchAlsup1 wrote:
> -------------------
>>>> 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}.
>>>
>>
>> OK.
>>
>>
>>>> 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.
>>>
>>
>> It is 3 operand if being used as a 128-bit shift op.
>> But, funnel shift operators implies 3 independent inputs and 1 output.
>
> And 2 shifts or exotic masking. Which is why I stopped early.
>
It hasn't been added yet, but exists internally as it was basically how
128-bit shifts were implemented.
Though, its inputs are currently wired to Rs,Rt,Ru for Lane1, and
Ru,Rv,Rs for Lane 2.
But, for funnel shift, would need to be Rs,Rt,Ry and Ru,Rv,Rx .
>>> ----------
>>>>> 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.
>>> ---------------
>>
>> Yeah.
>>
>> Amidst debugging and considering Verilog 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).
>>>
>>> My 66000 only has 16 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...
>>>
>>
>> I had enough space for 64 CRs, but only a small subset are actually
>> used. Some more had space reserved, but were related to non-implemented
>> features.
>>
>> RISC-V has a 12-bit CSR space, of which:
>> Some map to existing CRs;
>> My whole CR space was stuck into an implementation-dependent range.
>
> My whole space is mapped by BAR registers as if they were on PCIe.
>
Not a thing yet.
But, PCIe may need to exist for Linux or similar.
But, may still be an issue as Linux could only use known hardware IDs,
and it is a question what IDs it would know about (and if any happen to
map closely enough to my existing interfaces).
Otherwise, would be necessary to write custom HW drivers, which would
add a lot more pain to all of this.
Though, looking, could possibly scavenge some from the QEMU list, as an
OS like Linux is likely to know about them.
Looks like the default option in this case is apparently to emulate a
VGA card but mapped over to PCIe.
Though, in this question, it becomes the effort needed to mimic the
interface for a VGA card.
Annoyingly, the QEMU list doesn't seem to define any SDcard or SPI
interfaces (or seemingly any other block-device interfaces for that matter).
Or, does an OS like Linux expect to access the block-devices via the
UEFI interface?...
Usable information in these areas seems to be a bit sparse...
But, yeah, if I need to go that route, probably:
Boot ROM loads TestKern;
TestKern then behaves like it were a UEFI BIOS and proceeds to load an
OS, providing a bunch of VTables for API calls.
But, I guess the unresolved is what exactly Linux on RV64G would expect
or use from it (where, theoretically, it can provide
filesystem/display/etc itself; but would Linux use these via UEFI, or
assume looking for specific PCIe devices to access these?...).
It is a bit of a jump in any case, from assuming a world of specific
hardware devices mapped to hard-coded address ranges or IO ports (with
the assumption that the booted OS provide everything itself, and probe
for specific hardware interfaces it might want to use, and hopefully not
crash stuff in the process if some other device happens to be using the
same IO ranges and behaves unfavorably).
Though, it seems like if TestKern were taking on the role of a UEFI
BIOS, there doesn't need to be any special hardware range for PCIe
config space. Could probably just use a part of RAM and then pretend
that an actual config space exists...
Well, since no actual PCIe bus exists in this case; and the existing
MMIO bus has no equivalent concept (just devices that will respond if
their particular address ranges are accessed).
>> Some read-only CSRs were mapped over to CPUID.
>
> I don't even have a CPUID--if you want this you go to config space
> and read the configuration lists and extended configuration lists.
>
Errm, so vendor/Hardware ID's for each feature flag...
Or, some lump device that describes multiple sets of features?...
My CPUID has an index number:
0: Gives an EIGHTCC identifying the CPU.
1: Gives some feature flags (and identifies the current core);
...
30 and 31 give the microsecond timer and HW-RNG, which are more relevant
to user-land.
32..63: Currently unused.
There is also a cycle counter (along vaguely similar lines to x86
RDTSC), but for many uses a microsecond counter is more useful (where
the timer-tick count updates at 1.0 MHz, and all cores would have the
same epoch).
On x86, trying to use RDTSC as a timer is rather annoying as it may jump
around and goes at a different rate depending on current clock speed.
Usually, for software, we care about the current wall-clock time.
In my use, TestKern expresses time in terms of the logical number of
microseconds since the Unix epoch (for now, approximated as the
build-time of the kernel; in the absence of any sort of actual hardware
clock on the FPGA boards or similar). Or, if there was network/internet,
could use NTP.
A system call can be used to fetch a base offset between the CPU epoch
of the Unix-time epoch.
This scheme will not roll over for around 400k years (for a 64-bit
microsecond timer), so "good enough".
Conceptually, this time would be in UTC, likely with time-zones handled
by adding another bias value.
This can in turn be used to derive the output from "clock()" and similar.
Also, there are relatively few software timing tasks where we have much
reason to care about nanoseconds. For many tasks, milliseconds are
sufficient, but there are some things where microseconds matters.
>> Of which, all of the CPUID indices were also mapped into CSR space.
>
> CPUID is soooooo pre-PCIe.
>
Dunno.
Mine is different from x86, in that it mostly functions like read-only
registers.
RISC-V also has a range of read-only CSRs with some overlap.
Though, gets more particular in some areas, and there are things that
are lacking.
RISC-V land seemingly exposes a microsecond timer via MMIO instead, but
this is much less useful as this means needing to use a syscall to fetch
the current time, which is slow.
Doom manages to fetch the current time frequently enough that doing so
via a syscall has a visible effect on performance.
>>
>> Seemingly lacks defined user CSRs for timer or HW-RNG, which do exist in
>> my case. It is very useful to be able to access a HW timer in userland,
>> as otherwise it would waste a lot of clock-cycles using system calls for
>> "clock()" and similar.
>
> That is why they are ALL available in MMI/O Space. If this user needs
> access to that timer, then there is a PTE that translated the LD/ST
> into an access to that device.
>
OK.
Currently, MMU remapping of MMIO isn't really supported.
I think I had experimented with it before though.
Would mean needing to put the timer(s) all on their own page though, as
one doesn't want to map the timers into userland and also (implicitly)
also give them access to the SPI busses and UARTs and GPIO interface and
similar as well.
>>
>>>> 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.
>>>
>>
>> There seems to be a lot here defined in terms of 32-bit physical spaces,
>> including on 64-bit targets.
>>
>> Though, thus far, my existing core also has pretty all of its physical
>> map in 32-bit space.
>
> My 66000 does not even have a 32-bit space to map into.
> You can synthesize such a space by not using any of the
> top 32-address bits in PTEs--but why ??
>
32-bit space is just the first 4GB of physical space.
But, as-is, there is pretty much nothing outside of the first 4GB.
The actually in use MMIO space is also still 28 bits.
The VRAM maps 128K in MMIO space, but in retrospect probably should have
been more. When I designed it, I didn't figure there would have been
more than 128K. The RAM backed framebuffer can be bigger though, but not
too much bigger, as then screen refresh starts getting too glitchy (as
it competes with the CPU for the L2 cache, but is more timing sensitive).
>>
>> The physical ranges from 0001_00000000 .. 7FFF_FFFFFFFF currently
>> contain a whole lot of nothing.
>>
>>
>> I once speculated on the possibility of special hardware to memory-map
>> the whole SDcard into physical space, but nothing has been done yet (and
>> such a hardware interface would be a lot more complicated than my
>> existing interface).
>>
>>
>> An intermediate option being to expand the SPI interface to support 256
>> bit bursts.
>
> My interconnect bus is 1 cache line (512-bits) per cycle plus
> address and command.
>
My bus is 128 bits, but MMIO operations are 64-bits.
Where, for MMIO, every access involves a whole round-trip over the bus
(unlike for RAM-like access, where things can be held in the L1 cache).
In theory, MMIO operations could be widened to allow 128-bit access, but
haven't done so. This would require widening the data path for MMIO devices.
Can note that when the request goes onto the MMIO bus, data narrows to
64-bit and address narrows to 28 bits. Non-MMIO range requests (from the
ringbus) are not allowed onto the MMIO bus, and the MMIO bus will not
accept any new requests until the prior request has either finished or
timed out.
The original MMIO bus had a 32-bit data path, but it was widened to 64
bit mostly because 32-bit was inconveniently narrow for some devices.
Currently, the MMIO bus uses the original bus:
Input address, data, and request, are visible to all devices at the same
time;
The device that responds presents its output data and raises a signal
that it has responded;
The response is MUX'ed back up the chain.
One option could be to add another narrower ringbus and offload some
devices onto this. Latency would be higher for this, but per-device cost
would be lower.
Possibly, parts of the MMIO range would be routed directly to this MMIO
ringbus, say:
8b: Request/response code;
24b/28b: IO Address
32b/64b: Data
Data size is uncertain here
64b could be useful here but adds cost.
For simpler devices, one can assume 32-bit only access.
Note that 8/16 bit access does not exist as separate from 32-bit.
Note that higher bandwidth devices, like the display device and
rasterizer module, exist directly on the main ringbus, but still provide
an MMIO interface.
>> Say:
>> P_SPI_QDATA0..P_SPI_QDATA3
>>
>> It appears this has already been partly defined (though not fully
>> implemented in the 256-bit case).
>>
>> Where, the supported XMIT sizes are:
>> 8 bit: Single Byte
>> 64 bit: 8 bytes
>> 256 bit: 32 bytes
>>
>> With larger bursts mostly to reduce the amount of round-trip delay over
>> the bus.
>
> My 66000 interconnect bus can transmit a whole page in a single
> burst--that appears ATOMIC to interested 3rd parties.
Possibly, but likely less relevant for an SPI interface.
Trim relevant part:
lv=0xFFFFFFFFFFFFFFFFULL;
P_SPI_QDATA=lv;
P_SPI_CTRL=tkspi_ctl_status|SPICTRL_XMIT8X;
v=P_SPI_CTRL;
ttn=(1<<20);
while((v&SPICTRL_BUSY) && ttn--)
{ v=P_SPI_CTRL; }
lv=P_SPI_QDATA;
*(u64 *)ct=lv;
ct+=8;
n-=8;
Twiddling the SPI_CTRL register adds a lot of overhead...
If one did, say:
lv=0xFFFFFFFFFFFFFFFFULL;
P_SPI_QDATA0=lv;
P_SPI_QDATA1=lv;
P_SPI_QDATA2=lv;
P_SPI_QDATA3=lv;
P_SPI_CTRL=tkspi_ctl_status|SPICTRL_XMIT32X;
v=P_SPI_CTRL;
ttn=(1<<20);
while((v&SPICTRL_BUSY) && ttn--)
{ v=P_SPI_CTRL; }
lv=P_SPI_QDATA0;
((u64 *)ct)[0]=lv;
lv=P_SPI_QDATA1;
((u64 *)ct)[1]=lv;
lv=P_SPI_QDATA2;
((u64 *)ct)[2]=lv;
lv=P_SPI_QDATA3;
((u64 *)ct)[3]=lv;
ct+=32;
n-=32;
The number of round-trips over the bus would be less...
However, even the first version is still a big improvement over the
plain "XMIT" or "XMIT1X", which transfers a single byte.
Where, 1 byte at a time essentially bottlenecks at around 500-600
kB/sec. But, that is the more traditional way of using SPI, and is used
for things like SDcard commands (the bulk transfers are more for
sending/receiving sector data).
...
Where, in this case:
#define MMIO_BASE_E 0x0000FFFFF000E000ULL
#define SPI_BASE (MMIO_BASE_E+0x0000030ULL)
#define SPI_CTRL (SPI_BASE+0x00ULL)
#define SPI_DATA (SPI_BASE+0x04ULL)
#define SPI_QDATA (SPI_BASE+0x08ULL)
#define SPI_QDATA0 (SPI_BASE+0x08ULL)
#define SPI_QDATA1 (SPI_BASE+0x09ULL)
#define SPI_QDATA2 (SPI_BASE+0x0AULL)
#define SPI_QDATA3 (SPI_BASE+0x0BULL)
#define P_SPI_QDATA0 (*(vol_u64 *)SPI_QDATA0)
#define P_SPI_QDATA1 (*(vol_u64 *)SPI_QDATA1)
#define P_SPI_QDATA2 (*(vol_u64 *)SPI_QDATA2)
#define P_SPI_QDATA3 (*(vol_u64 *)SPI_QDATA3)
typedef volatile u32 vol_u32;
typedef volatile u64 vol_u64;
...
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-12 00:33 +0000 |
| Message-ID | <7b773a3b32e98c7b836e2250b9fb728b@www.novabbs.org> |
| In reply to | #111076 |
On Tue, 11 Mar 2025 21:20:22 +0000, BGB wrote: > On 3/11/2025 12:57 PM, MitchAlsup1 wrote: -------------- >> My whole space is mapped by BAR registers as if they were on PCIe. >> > > Not a thing yet. > > But, PCIe may need to exist for Linux or similar. > > But, may still be an issue as Linux could only use known hardware IDs, > and it is a question what IDs it would know about (and if any happen to > map closely enough to my existing interfaces). > > Otherwise, would be necessary to write custom HW drivers, which would > add a lot more pain to all of this. There is already a driver in BOOT that reads config headers for manufacture and model, and use those to look up an actual driver for that device. I simply plan on having My 66000 BOOT up code indexed by Mfg:Dev. -------------- >>> Some read-only CSRs were mapped over to CPUID. >> >> I don't even have a CPUID--if you want this you go to config space >> and read the configuration lists and extended configuration lists. >> > > Errm, so vendor/Hardware ID's for each feature flag... No, a manufacture:device for every CPU-type on the die. Then all of the core identification is found on the [extended] configuration lists. core kind fetch width decode width execute width retire width cache sizes TLB sizes predictor stuff .. In practice, I expect some later phase in BOOT will read all this out and package it for user consumption (and likely another copy for supervisor consumption.) Then it is accessed as fast as any cached chunk of memory. > 30 and 31 give the microsecond timer and HW-RNG, which are more relevant > to user-land. The timer running in virtual time or the one running in physical time ?? > 32..63: Currently unused. > > > There is also a cycle counter (along vaguely similar lines to x86 > RDTSC), but for many uses a microsecond counter is more useful (where > the timer-tick count updates at 1.0 MHz, and all cores would have the > same epoch). > > On x86, trying to use RDTSC as a timer is rather annoying as it may jump > around and goes at a different rate depending on current clock speed. By placing the timers in MMI/O memory address space*, accesses from different cores necessarily get different value--so the RTC can be used to distinguish "who got there first". MMI/O space is sequentially consistent across all cores in the system. ------------ > This scheme will not roll over for around 400k years (for a 64-bit > microsecond timer), so "good enough". So at 1GHz the roll over time is 400 years. Looks good enough to me. > Conceptually, this time would be in UTC, likely with time-zones handled > by adding another bias value. What is UTC time when standing on the north or south poles ?? > This can in turn be used to derive the output from "clock()" and > similar. > > > Also, there are relatively few software timing tasks where we have much > reason to care about nanoseconds. For many tasks, milliseconds are > sufficient, but there are some things where microseconds matters. We used to run a benchmark 1,000,000 times in order to get accurate information using a time with 1 second resolution. We do not want to continue on that level. > >>> Of which, all of the CPUID indices were also mapped into CSR space. >> >> CPUID is soooooo pre-PCIe. >> > > Dunno. > > Mine is different from x86, in that it mostly functions like read-only > registers. x86 uses a narrow bus that runs around the whole chip so it can access all sorts of stuff (only some it is available to users) and some of these accesses take 1,000's of cycles. > RISC-V land seemingly exposes a microsecond timer via MMIO instead, but > this is much less useful as this means needing to use a syscall to fetch > the current time, which is slow. Or a generous MMU handler that lets some trusted low privilege level processes direct access. > Doom manages to fetch the current time frequently enough that doing so > via a syscall has a visible effect on performance. I had an old Timex a long time ago that I had to adjust the time about 3 times a day to have any chance of accuracy. Solution-- quit wearing a watch. >> >> My 66000 does not even have a 32-bit space to map into. >> You can synthesize such a space by not using any of the >> top 32-address bits in PTEs--but why ?? >> > > 32-bit space is just the first 4GB of physical space. > But, as-is, there is pretty much nothing outside of the first 4GB. > > > The actually in use MMIO space is also still 28 bits. You are not trying to access 1,000 ACHI disks on a single rack, either; each disk supporting several hundred GuestOSs. > The VRAM maps 128K in MMIO space, but in retrospect probably should have > been more. When I designed it, I didn't figure there would have been > more than 128K. The RAM backed framebuffer can be bigger though, but not > too much bigger, as then screen refresh starts getting too glitchy (as > it competes with the CPU for the L2 cache, but is more timing > sensitive). One would think the very minimum to be do 32-bit color (8,8,8,8) on an 8K display/monitor. ----------- >> >> My interconnect bus is 1 cache line (512-bits) per cycle plus >> address and command. >> > > My bus is 128 bits, but MMIO operations are 64-bits. > > Where, for MMIO, every access involves a whole round-trip over the bus > (unlike for RAM-like access, where things can be held in the L1 cache). > > In theory, MMIO operations could be widened to allow 128-bit access, but > haven't done so. This would require widening the data path for MMIO > devices. > > Can note that when the request goes onto the MMIO bus, data narrows to > 64-bit and address narrows to 28 bits. Non-MMIO range requests (from the > ringbus) are not allowed onto the MMIO bus, and the MMIO bus will not > accept any new requests until the prior request has either finished or > timed out. I see a big source of timing problems here. We are approaching 128-cores on a die and more than 256-devices down the PCIe tree. Does allowing only 1 access from one core to one device at a time make any sense ?? No, you specify virtual channels, accesses down a PCIe segment remain ordered while on the Tree and serialize at the device (function) itself.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-12 01:09 -0500 |
| Message-ID | <vqr8gm$2finh$1@dont-email.me> |
| In reply to | #111093 |
On 3/11/2025 7:33 PM, MitchAlsup1 wrote:
> On Tue, 11 Mar 2025 21:20:22 +0000, BGB wrote:
>
>> On 3/11/2025 12:57 PM, MitchAlsup1 wrote:
> --------------
>>> My whole space is mapped by BAR registers as if they were on PCIe.
>>>
>>
>> Not a thing yet.
>>
>> But, PCIe may need to exist for Linux or similar.
>>
>> But, may still be an issue as Linux could only use known hardware IDs,
>> and it is a question what IDs it would know about (and if any happen to
>> map closely enough to my existing interfaces).
>>
>> Otherwise, would be necessary to write custom HW drivers, which would
>> add a lot more pain to all of this.
>
> There is already a driver in BOOT that reads config headers for
> manufacture
> and model, and use those to look up an actual driver for that device.
> I simply plan on having My 66000 BOOT up code indexed by Mfg:Dev.
>
OK.
> --------------
>
>>>> Some read-only CSRs were mapped over to CPUID.
>>>
>>> I don't even have a CPUID--if you want this you go to config space
>>> and read the configuration lists and extended configuration lists.
>>>
>>
>> Errm, so vendor/Hardware ID's for each feature flag...
>
> No, a manufacture:device for every CPU-type on the die. Then all of
> the core identification is found on the [extended] configuration
> lists.
> core kind
> fetch width
> decode width
> execute width
> retire width
> cache sizes
> TLB sizes
> predictor stuff
> ..
>
> In practice, I expect some later phase in BOOT will read all this out
> and package it for user consumption (and likely another copy for
> supervisor consumption.) Then it is accessed as fast as any cached
> chunk of memory.
>
As-is, a lot of this information is not available...
A lot of the feature flags are more things like whether or not the CPU
supports Load/Store Pair or SIMD or similar.
>> 30 and 31 give the microsecond timer and HW-RNG, which are more relevant
>> to user-land.
>
> The timer running in virtual time or the one running in physical time ??
>
In the emulator, it is internally based on the virtual clock-cycle count
(so, from its point of view, it seems accurate).
The emulator speed is then kept at roughly real-time based selectively
running the VM based on whether or not the number of emulated
clock-cycles is larger than the amount of clock-cycles that would have
been executed given the external wall-clock time at the specified
clock-speed.
Granted, this part isn't super exact regarding how closely things remain
in-sync (but, on-average, it works).
There is also a separate "wallspeed" mode which basically runs the
emulator as fast as it will go and uses the external wall-clock time
instead (though with some internal trickery to estimate the microsecond
values, albeit with the constraint that a later given time can't be less
than a previously given time).
Partly this is because "actual wall-clock time" isn't super fine-grained
(roughly millisecond territory on Windows), and the time within emulator
isn't too closely tied to real-time (it roughly extrapolates and guesses
based on how quickly the emulator is running in this mode).
This mode also disables some of the modeling usually used to try to keep
things cycle-accurate (such as modeling L1 and L2 cache hits and misses).
For the Verilog partial simulation, it is based on clock cycles. So, it
will drive the main clock at 50MHz, but also drive a 1MHz clock.
For the full simulation (and FPGA), there is a module that turns the
input clock into various lower-speed clocks, such as 1MHz (for the
microsecond timer, and 2Hz for the cursor and blinking text effect).
Note that the main PLL turns the 100MHz master clock into 100, 50 and
75MHz and similar.
Most other lower-speed soft clocks are based on fractional accumulation
timers.
Well, except for things like the SPI clock, which are based on
decrement-division, which give a limited range of values on the fast-end:
50, 25, 16.7, 12.5, ...
But, faster clocks via an accumulation timers gives very jittery output
(so, they are better for lower-speed clocks, such as for driving audio
output or RS232).
>> 32..63: Currently unused.
>>
>>
>> There is also a cycle counter (along vaguely similar lines to x86
>> RDTSC), but for many uses a microsecond counter is more useful (where
>> the timer-tick count updates at 1.0 MHz, and all cores would have the
>> same epoch).
>>
>> On x86, trying to use RDTSC as a timer is rather annoying as it may jump
>> around and goes at a different rate depending on current clock speed.
>
> By placing the timers in MMI/O memory address space*, accesses from
> different cores necessarily get different value--so the RTC can be
> used to distinguish "who got there first".
>
> MMI/O space is sequentially consistent across all cores in the system.
>
When it is driven by a 1MHz clock with a shared epoch across all cores,
MMIO is unnecessary.
Granted, if one wants to time the relative ordering of events between
CPU cores, a 1MHz clock may be insufficient, even at 50MHz.
> ------------
>> This scheme will not roll over for around 400k years (for a 64-bit
>> microsecond timer), so "good enough".
>
> So at 1GHz the roll over time is 400 years. Looks good enough to me.
>
The microsecond timer is ideally independent of clock-speed.
>> Conceptually, this time would be in UTC, likely with time-zones handled
>> by adding another bias value.
>
> What is UTC time when standing on the north or south poles ??
>
UTC doesn't care what the local timezone is.
Ideally, it shouldn't care about leap-seconds either, but seemingly the
world has decided that they would rather keep UTC in sync with the
calendar year than have a completely monotonic time.
Granted, the scope of a purely monotonic time would be limited by local
variations due to relativistic effects; but for the most part, everyone
on Earth can agree roughly how much time has passed.
Might start to matter in space colonization, say, when people on the
Moon or Mars have their clocks running slightly faster than those on
Earth due to the difference in the local gravity well.
Or, say, if people were out in the asteroid belt, their clocks running
slightly faster than those in the inner solar system due to the
gravity-well of the sun.
I guess it is a question then if Earth time remains the standard, or if
people accept that clock-drift is inevitable. Well, and/or maybe Earth
can broadcast a signal that can be used to keep the various clocks in
sync (say, a 100MHz carrier which in turn regularly transmits the
current time in in microseconds). Then, by picking up this transmission,
it can be used to calibrate clocks to Earth time, and measuring the
exact frequency of the signal can used to adjust for local timing skew.
Granted, would also be effected by doppler-shifts, possibly leaving a
question as to how much redshift or blueshift effects the question of
"what time it is".
Say, for example, if the signal mostly sat at the carrier frequency, and
then every 10us encodes the current time by QAM modulating the signal
(possibly at 25mbps or so, using a similar encoding scheme to RS232).
Well, and/or people don't bother, and just live with a clock drift of a
few microseconds per month or so...
Then again, the level of harm done by relativistic effects would still
be smaller than the harm regularly done by the addition of leap seconds.
And, possibly, the merit of accurate time goes away once one is outside
the range of where something like NTP could work (like, if one has a 20
minute ping time, maybe it doesn't matter if the clocks are a few
seconds out of sync?...).
>> This can in turn be used to derive the output from "clock()" and
>> similar.
>>
>>
>> Also, there are relatively few software timing tasks where we have much
>> reason to care about nanoseconds. For many tasks, milliseconds are
>> sufficient, but there are some things where microseconds matters.
>
> We used to run a benchmark 1,000,000 times in order to get accurate
> information using a time with 1 second resolution. We do not want
> to continue on that level.
>
OK.
>>
>>>> Of which, all of the CPUID indices were also mapped into CSR
>>>> space.
>>>
>>> CPUID is soooooo pre-PCIe.
>>>
>>
>> Dunno.
>>
>> Mine is different from x86, in that it mostly functions like read-only
>> registers.
>
> x86 uses a narrow bus that runs around the whole chip so it can access
> all sorts of stuff (only some it is available to users) and some of
> these
> accesses take 1,000's of cycles.
>
OK.
Most of what my CPUID reports is entirely local to the module in
question. The time is fed in externally (via a 1MHz clock).
The RNG is fed by entropy gathering, with a sort of "entropy path" that
moves along through the ringbus and can basically deliver entropy to
anything with a ringbus connection. This is basically fed into a sort of
specialized structure of free-running LFSR's.
Externally, there is some logic (out near the L2 cache) which mostly
serves the purpose of gathering entropy and basically injecting it back
into the ringbus. Granted, how much "true entropy" exists here is
subject to interpretation (one will only get true entropy so far as the
sources being probed are non-deterministic).
However, the CPU itself is in a much better place to scavenge entropy
than the OS is.
There were some amount of delays added to the 1 MHz path, as otherwise
timing was tight along this path, and of there is a few extra cycles of
delay here, it does not matter.
>> RISC-V land seemingly exposes a microsecond timer via MMIO instead, but
>> this is much less useful as this means needing to use a syscall to fetch
>> the current time, which is slow.
>
> Or a generous MMU handler that lets some trusted low privilege level
> processes direct access.
>
Probably a bit much, unless it is by itself.
Ideally, one doesn't want userland to have access to anything outside of
what is "safe".
Granted, can also note that on RasPi, userland can easily get access to
the MMIO range for GPIO, which also exposes a lot of other "sensitive"
parts of the chipset (like, the application could easily bypass the OS
and start directly poking at the SDcard or similar).
But, OTOH, RasPi didn't provide any good/fast way to access the SDcard
in a way that didn't punch a big hole in the systems' protection scheme.
>> Doom manages to fetch the current time frequently enough that doing so
>> via a syscall has a visible effect on performance.
>
> I had an old Timex a long time ago that I had to adjust the time
> about 3 times a day to have any chance of accuracy. Solution--
> quit wearing a watch.
>
Some of it was that the Doom port ends up needing to probe multiple
times per frame for things like audio and MIDI updates.
Say, to keep the loop-buffer in sync, and for MIDI which may need to
maintain a 72Hz update for music to sound OK, but with frame-rates that
are generally nowhere near the needed 72Hz. If the MIDI is updated too
slowly it might start sounding a bit "derpy" (I think in the DOS ports,
things like MIDI updates would have been driven off a timer interrupt).
But, to some extent this means, for every drawn BSP leaf or similar, it
is also needed to probe whether we need to update the MIDI state, which
(if done via a system call) will eat a lot of cycles (though, the actual
rate of issuing new MIDI commands is far less than this).
>>>
>>> My 66000 does not even have a 32-bit space to map into.
>>> You can synthesize such a space by not using any of the
>>> top 32-address bits in PTEs--but why ??
>>>
>>
>> 32-bit space is just the first 4GB of physical space.
>> But, as-is, there is pretty much nothing outside of the first 4GB.
>>
>>
>> The actually in use MMIO space is also still 28 bits.
>
> You are not trying to access 1,000 ACHI disks on a single rack, either;
> each disk supporting several hundred GuestOSs.
>
Granted.
For an FPGA implementation, the 28 bit MMIO space is plenty...
PC's got along pretty well for a while with 16-bit IO port addresses.
>> The VRAM maps 128K in MMIO space, but in retrospect probably should have
>> been more. When I designed it, I didn't figure there would have been
>> more than 128K. The RAM backed framebuffer can be bigger though, but not
>> too much bigger, as then screen refresh starts getting too glitchy (as
>> it competes with the CPU for the L2 cache, but is more timing
>> sensitive).
>
> One would think the very minimum to be do 32-bit color (8,8,8,8)
> on an 8K display/monitor.
>
That framebuffer would need more RAM than exists on the main FPGA board
I am using (and 8GB/sec of memory bandwidth just for the screen refresh).
It can basically barely manage enough bandwidth for 640x400 or 640x480
256-color.
But, when I designed the HW interface, I went with a 128K reservation
originally imagining 16K or 32K for a color-cell display (and also
partly because this is what VGA had reserved for itself, and it was
seemingly sufficient for VGA).
Eventually ended up with 320x200 hi-color though. This uses up the whole
region.
640x480 in 16-color mode exceeds this (but, apparently, VGA had dealt
with this issue by using bit plane graphics).
But, can note that, with the RAM backed framebuffer, going much over
256K requires too much bandwidth for the refresh. But, staying below
128K is better for image stability.
800x600 at 2bpp color-cell needs 120K, so this works.
1024x768 needs 197K, which works, but is pushing it.
Other options for 1024x768 being:
Monochrome: 98K
1.25bpp CC: 124K (possible, doesn't exist yet)
Text Mode : 50K (at 4 bytes per character cell)
(Has more colors and a larger glyph set vs CGA/VGA text mode).
Can note though that these higher-res modes need to be driven at a 50
MHz clock, vs 320x200 and 640x480 and similar using a 25 MHz clock;
leading to non-standard timings. But, at least the LCD monitors I had
tried had tolerated a lot of my non-standard timings (even if they would
often misidentify the intended mode and then display the image in wonky
ways).
Likely, doing this timing properly while also supporting multiple modes
would either require a freely adjustable clock (not really a thing
here). The operating frequencies for pixel clocks are generally too fast
to get good results from an accumulation timer (at least one of the LCD
monitors I had tried looks like epic dog crap if the pixel clock isn't
stable).
> -----------
>>>
>>> My interconnect bus is 1 cache line (512-bits) per cycle plus
>>> address and command.
>>>
>>
>> My bus is 128 bits, but MMIO operations are 64-bits.
>>
>> Where, for MMIO, every access involves a whole round-trip over the bus
>> (unlike for RAM-like access, where things can be held in the L1 cache).
>>
>> In theory, MMIO operations could be widened to allow 128-bit access, but
>> haven't done so. This would require widening the data path for MMIO
>> devices.
>>
>> Can note that when the request goes onto the MMIO bus, data narrows to
>> 64-bit and address narrows to 28 bits. Non-MMIO range requests (from the
>> ringbus) are not allowed onto the MMIO bus, and the MMIO bus will not
>> accept any new requests until the prior request has either finished or
>> timed out.
>
> I see a big source of timing problems here.
>
> We are approaching 128-cores on a die and more than 256-devices down
> the PCIe tree. Does allowing only 1 access from one core to one device
> at a time make any sense ?? No, you specify virtual channels, accesses
> down a PCIe segment remain ordered while on the Tree and serialize at
> the device (function) itself.
On the main FPGA I am using, it is single core.
If the FPGA can afford more than 1 or maybe 2 cores, and a small number
of relatively limited MMIO devices, maybe I could have reason to care
about the MMIO bus interface becoming system-level bottleneck.
Even the ring-bus design itself was more me trying to come up with a bus
that was both moderately fast but also cheap. Faster bus designs are
possible, but are not cheaper...
And, the MMIO bus has 28-bit address and 64-bit data because, it doesn't
really need more than this.
Well, and the devices that need more than this, generally sit on the
ringbus.
Well, except the SPI device, but it is odd, being one of the higher
bandwidth devices still on the MMIO bus. And, along with the display
module, was one of the original motivations for widening the MMIO data
path to 64 bits.
But, the SPI device more just has the working goal of being fast enough
to not bottleneck access to the SDcard (not an issue at present, but if
I ran the SDcard in UHS mode, it would be a bit more of an issue; as it
would get potentially roughly 8x faster at the same clock speed).
Contrast to x86 getting mostly OK results for a while with 16-bit port
numbers and 8|16 bit data access.
But, say, not particularly bandwidth limited accessing a serial UART or
PS2 keyboard interface or similar...
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-03-07 20:48 -0600 |
| Message-ID | <vqgb95$3r7ts$1@dont-email.me> |
| In reply to | #111003 |
On 3/7/2025 5:40 PM, Robert Finch wrote:
>> But, in Verilog, it is not uncommon to go well outside of the usual
>> 64- bit limit that C typically imposes
>
> Yes, all kinds of hardware structures use bit vectors >64. They also
> tend to have a reasonable upper limit as muxing from a bit vector can be
> expensive.
>
In my own Verilog code, I rarely go over 128 bit, but a few 512 bit
vectors are used.
This leaves 512 or 1024 as the lower-end of a vector-size limit.
Something like 32kb is well over this.
The way types are encoded has an implicit limit of 4kb before it needs
to go to an overflow type.
Say:
(11: 0): Base Type
000..0FF: Primitive Types
100..FFF: Complex/Structure Types
(15:12): Pointer Indirection Level or Array/Ref Type.
(27:16): Array Size (also used for _BitInt size)
(31:28): Type-Type Tag
There is a type that has larger arrays (up to 1M elements), but only
supports a subset of the primitive types.
Some primitive types may appear multiple types, differing in terms of
things like alignment or volatile status.
Another variant has a larger type fields, but only supports small arrays
(this case mostly comes up once the compiler gets beyond 3840
struct/union/etc types; can actually happen in practice, though one big
offender here is "GL/gl.h" defining a crapton of function-pointer types...).
In other cases, the type is expressed as an index into an array of types
whose type could not be described in one of the 32 bit formats.
>>
>> But, "32kb" in a single bit-vector should probably be enough for
>> anyone...
>>
> I would be tempted to allow an 'int' (size_t?) to be used for the size.
>
I had a 64-bit value field intended to hold an immediate value for a 3AC
operator, so I divided it into 3 parts for this operator.
3x 16b made sense as it was easy to unpack into 3 signed values (for
"technical reasons" also needs to be able to express negative values).
If needed, could switch to 1M as a limit (64/3 is 21 bits).
Can note that BGBCC can express larger literals (such as 128-bit
integers) but generally does so by encoding them as lookup table indices
(broken up into 64-bit chunks).
To go much bigger, would likely need to use multi-level indirection (or
switch to a different strategy for expressing large constants).
The variable fields can also express values:
temp/argument/local/global:
24 bit ID
12b index + 12b version got locals
24-bit global-ID for globals
32 bit type
8 bit tag
string literals use a similar format
Just encoding an index into a string table.
integer literals:
32-bit payload, 16-bit type (12b base, 4b level)
long/double literal:
56 bit value
(values that don't fit here are encoded as lookup table indices)
...
But, as such, memory use is still an issue.
Say, don't want to use lookup tables when it can be avoided, as this
requires memory.
But, can't really go much bigger than 32-bits for types, or 64-bits for
variable IDs, as this would eat a significant amount of memory in a part
of the compilers that already eats lots of RAM.
Similarly, don't want to increase the size of the 3AC operation
structure, ...
> For software bit vectors could be larger than for hardware. For example,
> I used a bit-pair vector to hold a ternary value representing memory
> pages for something called a page-allocation-map (PAM) which tracks
> which pages are allocated or free, and the end of an allocation. There
> could be a lot of pages in a large memory system. Scanning the bit-pair
> vector could be done mostly a word-at-a-time. Same thing could be done
> for disk pages.
>
Possibly, but not necessarily imagining that Verilog or similar would
make sense as a generic software programming language.
And, the bitfield stuff as-is wouldn't make sense for large bit arrays
(which as-is, only allows for constant bit offsets; most bitmap
use-cases tending to use a variable bit index).
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;
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.
Though, an open question is how one would define it in a way that is
consistent with existing semantics rules.
Note that a traditional array in Verilog is more like:
reg bitArray[1023:0];
But, this represents something conceptually different from a large bit
vector:
reg[1023:0] bitVec;
Even if it still allows:
b=bitVec[idx];
Hmm...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-07 22:25 +0000 |
| Message-ID | <cnKyP.176082$OrR5.109660@fx18.iad> |
| In reply to | #110988 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote: > >> For a simple test: >> lj[ 7: 0]=li[31:24]; >> lj[15: 8]=li[23:16]; >> lj[23:16]=li[15: 8]; >> lj[31:24]=li[ 7: 0]; >> Does seem to compile down to 4 instructions. > >1 innstruction:: BITR rd,rs1,<8> Isn't that just 'bswap32' on x86, or REV32 on ARM64?
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-07 22:45 +0000 |
| Message-ID | <25496cb4e652536e8712f641f6ab433a@www.novabbs.org> |
| In reply to | #110998 |
On Fri, 7 Mar 2025 22:25:12 +0000, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote:
>>
>>> For a simple test:
>>> lj[ 7: 0]=li[31:24];
>>> lj[15: 8]=li[23:16];
>>> lj[23:16]=li[15: 8];
>>> lj[31:24]=li[ 7: 0];
>>> Does seem to compile down to 4 instructions.
>>
>>1 innstruction:: BITR rd,rs1,<8>
>
> Isn't that just 'bswap32' on x86, or REV32 on ARM64?
A degenerate version is:: but consider::
BITR Rd,Rs1,<1>
performs bit reversion, while::
BITR Rd,Rs1,<2>
reverses pairs of bits, ...
BITR Rs,Rs1,<16>
reverses halfwords.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-08 14:36 +0000 |
| Message-ID | <VBYyP.193514$zz8b.109910@fx09.iad> |
| In reply to | #110999 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Fri, 7 Mar 2025 22:25:12 +0000, Scott Lurndal wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: >>>On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote: >>> >>>> For a simple test: >>>> lj[ 7: 0]=li[31:24]; >>>> lj[15: 8]=li[23:16]; >>>> lj[23:16]=li[15: 8]; >>>> lj[31:24]=li[ 7: 0]; >>>> Does seem to compile down to 4 instructions. >>> >>>1 innstruction:: BITR rd,rs1,<8> >> >> Isn't that just 'bswap32' on x86, or REV32 on ARM64? > >A degenerate version is:: but consider:: > > BITR Rd,Rs1,<1> > >performs bit reversion, while:: > > BITR Rd,Rs1,<2> > >reverses pairs of bits, ... Is there an application for this particular variant? > > BITR Rs,Rs1,<16> > >reverses halfwords. Since there generally aren't higher level language constructs that encapsulate this behavior, how useful is it in the real world? Does it justify the verif costs, much less the engineering cost? Bswap32/64 are genuinely useful in real world applications (particularly networking) thus the presence in most modern instruction sets.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-08 17:57 +0000 |
| Message-ID | <d030929d0fac4c30ed69d8e287ebf83f@www.novabbs.org> |
| In reply to | #111015 |
On Sat, 8 Mar 2025 14:36:37 +0000, Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >>On Fri, 7 Mar 2025 22:25:12 +0000, Scott Lurndal wrote: >> >>> mitchalsup@aol.com (MitchAlsup1) writes: >>>>On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote: >>>> >>>>> For a simple test: >>>>> lj[ 7: 0]=li[31:24]; >>>>> lj[15: 8]=li[23:16]; >>>>> lj[23:16]=li[15: 8]; >>>>> lj[31:24]=li[ 7: 0]; >>>>> Does seem to compile down to 4 instructions. >>>> >>>>1 innstruction:: BITR rd,rs1,<8> >>> >>> Isn't that just 'bswap32' on x86, or REV32 on ARM64? >> >>A degenerate version is:: but consider:: >> >> BITR Rd,Rs1,<1> >> >>performs bit reversion, while:: >> >> BITR Rd,Rs1,<2> >> >>reverses pairs of bits, ... > > Is there an application for this particular variant? > >> >> BITR Rs,Rs1,<16> >> >>reverses halfwords. > > Since there generally aren't higher level language > constructs that encapsulate this behavior, how useful > is it in the real world? Does it justify the verif > costs, much less the engineering cost? You already have a vector of bits that is spread across the data path (reversing bits.) The only cost is the multiplexer that selects certain orders of bits out as a result. So, the cost in area is negligible. > Bswap32/64 are genuinely useful in real world applications > (particularly networking) thus the presence in most modern instruction > sets. You might want to do a BE->LE conversion where they byte string contains a mixture of 8-bit and 16-bit characters.
[toc] | [prev] | [next] | [standalone]
Page 7 of 17 — ← Prev page 1 … 5 6 [7] 8 9 … 17 Next page →
Back to top | Article view | comp.arch
csiph-web