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).
Why VAX Was the Ultimate CISC and Not RISC
Re: Why VAX Was the Ultimate CISC and Not RISC
