Re: Why VAX Was the Ultimate CISC and Not RISC

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.