Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Tue, 11 Mar 2025 17:57:02 +0000
Organization: Rocksolid Light
Message-ID: <a3304eadd68c10acb8385c43e326f4ec@www.novabbs.org>
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> <vqofeo$1qgv6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3912459"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$9SAptk2bSrt4iHxpb1P/Me58wtXt8firTsOETuKUVSOoeKRF2bY5C
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0

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.