Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Mon, 10 Mar 2025 22:49:00 -0400
Organization: A noiseless patient Spider
Lines: 184
Message-ID: <vqo8b1$1ln7o$1@dont-email.me>
References: <vpufbv$4qc5$1@dont-email.me>
 <2025Mar1.125817@mips.complang.tuwien.ac.at> <vpvrn5$2hq0$1@gal.iecc.com>
 <2025Mar1.232526@mips.complang.tuwien.ac.at> <vq2dfr$2skk$1@gal.iecc.com>
 <2025Mar2.234011@mips.complang.tuwien.ac.at> <5pkg9l-kipt.ln1@msc27.me.uk>
 <2025Mar3.174417@mips.complang.tuwien.ac.at> <vq4qav$1dksd$1@dont-email.me>
 <vq5dm2$1h3mg$5@dont-email.me> <2025Mar4.110420@mips.complang.tuwien.ac.at>
 <vq829a$232tl$6@dont-email.me> <2025Mar5.083636@mips.complang.tuwien.ac.at>
 <vqdljd$29f8f$2@paganini.bofh.team> <vqdrh9$3cdrc$1@dont-email.me>
 <vqek6h$3fro6$1@dont-email.me>
 <fe70b48cd6fef0aaf89278163d8b6322@www.novabbs.org>
 <vqfmr4$3npgk$1@dont-email.me> <vqg04o$3p80h$1@dont-email.me>
 <vqgbao$3rbkh$1@dont-email.me>
 <9371fe9be75cdd606c876f539e1d2d78@www.novabbs.org>
 <vqnps4$1j63b$1@dont-email.me>
 <0da86de26bac1912b190793512255aa4@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 11 Mar 2025 03:49:06 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7915f04a97b32907654e62769222860c";
	logging-data="1760504"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+vNXKlqem4uazt6c4kfIMbCSrvlzOKM2Y="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hETkKKPe0qAskFxW9lDRpE2BVGg=
In-Reply-To: <0da86de26bac1912b190793512255aa4@www.novabbs.org>
Content-Language: en-US
Bytes: 8603

On 2025-03-10 8:53 p.m., MitchAlsup1 wrote:
> On Mon, 10 Mar 2025 22:40:55 +0000, BGB wrote:
> 
>> On 3/7/2025 9:28 PM, MitchAlsup1 wrote:
>>> On Sat, 8 Mar 2025 2:49:50 +0000, BGB wrote:
>>>
>>> ------------------------
>>>>
>>>> I guess, while a person could do something like (in C):
>>>>    _BitInt(1048576) bmp;
>>>>    _Boolean b;
>>>>    ...
>>>>    b=(bmp>>i)&1;  //*blarg* (shift here would be absurdly expensive)
>>>>
>>>> This is liklely to be rare vs more traditional strategies, say:
>>>>    uint64_t *bmp;
>>>>    int b, i;
>>>>    ...
>>>>    b=(bmp[i>>6]>>(i&63))&1;
>>>
>>> Question: How do you handle the case where the bit vector is an odd
>>> number of bits in width ?? Say <3, 5, 7, 17, ...>
>>>
>>
>> It is rare for bitmap bits to not be a power of 2...
>>
>> I would guess, at least for C, something like (for 3 bits):
>>    uint32_t *bmp;
>>    uint64_t bv;
>>    int i, b, bp;
>>    ...
>>    bp=i*3;
>>    bv=*(uint64_t *)(bmp+(bp>>5));
>>    b=(bv>>(bp&31))&7;
>>
>> Could apply to anything up to 31 bits.
> 
> Not bad.
> 
>> Could do similar with __int128 (or uint128_t), which extends it up to 63
>> bits.
> ------------
>>> Mc 68020 had instructions to access bit-fields that cross word
>>> boundaries.
>>>
>>
>> I guess one could argue the use-case for adding a generic funnel shift
>> instruction.
> 
> My 66000 has CARRY-SL/SR which performs a double wide operand shifted
> by a single wide count (0..63) and produces a double wide result {IO}.
> 
>> If I added it, it would probably be a 64-bit encoding (generally needed
>> for 4R).
> 
> By placing the width in position {31..37} you can compress this down
> to 3-Operand.
> 
> ----------
>>> Architecture is more about what gets left OUT than what gets left IN.
>>
>> Well, except in this case it was more a question of trying to fit it in
>> with C semantics (and not consideration for more ISA features).
> 
> Clearly, you want to support C semantics--but you can do this in a way
> that also supports languages with real bit-field support.
> ---------------
>> There are still some limitations, for example:
>> In my current implementation, CSR's are very limited (may only be used
>> to load and store CSRs; not do RMW operations on CSRs).
> 
> <y 66000 only has 8 CPU CRs, and even these are R/W through MMI/O
> space. All the other (effective) CRs are auto loaded in line quanta.
> 
> This mechanism allows one CPU to figure out what another CPU is up to
> simply by meandering through its CRs...
> 
>> Though, have noted that seemingly some number of actual RISC-V cores
>> also have this limitation.
>>
>>
>> A more drastic option might be to try to rework the hardware interfaces
>> and memory map hopefully enough to try to make it possible to run an OS
>> like Linux, but there doesn't really seem to be a standardized set of
>> hardware interfaces or memory map defined.
>>
>> Some amount of SOC's though seem to use a map like:
>>    00000000..0000FFFF: ROM goes here.
>>    00010000..0XXXXXXX: RAM goes here.
>>    ZXXXXXXX..FFFFFFFF: Hardware / MMIO
> 
I got used to a lot of micro-computer maps which have RAM at low end and 
ROM at the high end.

I have the Q+ SoC setup like this (which is pretty much the way I setup 
all SoC) I use 32-bit addressing for demo purposes. Low cost FPGA boards 
typically do not have many gigabytes of memory.

00000000..3FFFFFFF	DRAM
40000000..CFFFFFFF	DRAM expansion area (not present on board)
D0000000..DFFFFFFF	config (FTA DDBB device discovery black boxes)
E0000000..FEBFFFFF	unassigned
FEC00000..FEFFFFFF	MMI/O
FF000000..FFF7FFFF	ROM expansion area (unimplemented)
FFF80000..FFFBFFFF      Scratchpad RAM
FFFC0000..FFFFFFFF      ROM

The DDBB can configure the MMI/O to appear at any address, but I have 
devices defaulting to
FEC00000..FEFFFFFF	MMI/O
Each DDBB is a 4kB space, the last 3kB are ROM for device support

There is a CSR that can reconfig the config area, which defaults to 
Dxxxxxxx.

Addresses are double bit sign extended from 32-bits to 64-bits when 
setup by the boot ROM, but the high order 64-bits are ignored by the 
hardware.

I went with dynamically determined MMI/O addressing setup at boot time 
which is hopefully usable with and OS. Defaults are such that the system 
is able to boot.

> My 66000::
>   00 0000000000000000..FFFFFFFFFFFFFFFF: DRAM
>   01 0000000000000000..FFFFFFFFFFFFFFFF: MMI/O
>   10 0000000000000000..FFFFFFFFFFFFFFFF: config
>   11 0000000000000000..FFFFFFFFFFFFFFFF: ROM
> 
How does one reference DRAM vs MMI/O at the same address using a LD / ST 
instruction?

Q+ CPU just uses a 64-bit address range. The config space is specified 
in a CR defaulting to FFFFFFFFDxxxxxxx The TLB is setup at boot to 
access ROM at FFFFFFFFFFFCxxxxx Otherwise there is no distinction with 
addresses. There is a region table in the system that describes up to 
eight distinct regions.

> Whatever you are trying to do, you won't run out of address space until
> 64 bits becomes insufficient. Note: all HW interfaces are in config
> space
> and all CRs are in MMI/O space.

Are there any CRs accessible with any instructions besides LD / ST?
> 
> ------------
>> They seem to also be asking for a UEFI based boot process, but this
>> would require having a bigger BootROM (can't likely fit a UEFI
>> implementation into 32K). Seems that the idea is to have the UEFI BIOS
>> boot the kernel directly as an ELF image (traditionally UEFI was always
>> PE/COFF based?...).
> 
> Boot ROM should be big enough that no BOOT ROM will ever exceed its
> size.
> --------------
>> There is a probable need to move away from the "BJX2" name, which as
>> noted, has some unfortunate connotations (turns out it was also used for
>> a lewd act) and seems to be triggering to Google's automatic content
>> filtering (probably for a similar reason).

Coming up with names is surprisingly difficult. I got into a discussion 
with a colleague a while ago about this. They were having difficulty 
coding something an it turned out to be simply what names to choose for 
routines.
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========