Re: Why VAX Was the Ultimate CISC and Not RISC

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;
...