On 3/10/2025 9:49 PM, Robert Finch wrote:
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.
In my case, the high 16 bits of pointers are ignored (usually left for tag bits and similar), except for certain instructions.
Not much consistency it seems.
Can note that SH-4 had used a physical map sorta like (IIRC):
00000000..0000FFFF: ROM
00010000..007FFFFF: Hardware IO (RAM like)
00800000..1FFFFFFF: RAM Space
RAM wrapped to fill the rest of the space.
Some stuff treated 10000000 as the start of RAM.
20000000..3FFFFFFF: Repeat
40000000..5FFFFFFF: Repeat
60000000..7FFFFFFF: Repeat
80000000..9FFFFFFF: Repeat, System
A0000000..BFFFFFFF: Repeat, System (NoMMU)
C0000000..DFFFFFFF: Repeat, NoCache
E0000000..FFFFFFFF: Hardware MMIO (NoMMU, NoCache)
Effectively, it had a 29-bit physical space, but a 31-bit virtual address space (high 2GB being special/system-only).
Within the low 8MB, it had:
Display VRAM;
As a linear framebuffer and a hardware renderer.
Audio RAM;
UART and similar;
A CD-ROM interface (N/A; was ATAPI based IIRC);
...
When I started my current ISA project, the hardware interfaces were redesigned to be simpler, and initially moved entirely into MMIO space (though the display and audio hardware did later regain RAM backed buffers).
Display didn't fully move back to a linear framebuffer though. Technically, it can sorta be configured into a linear framebuffer, but due to memory-fetch issues it looks a lot worse (on actual hardware) than the tile-ordered buffer (in 8bpp and 16bpp modes, the display memory is organized in 4x4 pixel tiles).
It was initially designed more around 8x8 pixel color cell graphics (which can do both text and graphics, though with worse color fidelity than a true bitmapped mode as it is limited to 2 colors per 4x4 or 8x8 tile, depending on sub-mode).
Generally, modes that have both high resolution and high color depth would take too much memory bandwidth.
Within the bitmapped modes, the current practical limit is roughly 640x400 256-color.
So, say, 800x600 is only really viable with color-cell graphics.
There is a 1024x768 monochrome mode, but it could be possible to stretch it into a color-cell mode by using 16 extra bits per 8x8 cell (or 1.25 bpp). Likely, these would use colors from the 256 color palette.
Basically, the idea being that each bit in the 8x8 pixel cell selects between the 2 colors.
Initially, some of the modes that exist were partly because I was trying to design something that could display Doom and Quake passably with 16K or 32K of VRAM (or, basically, a 320x200 mode needs to fit into 2bpp).
The VRAM later got bigger, but high-res high-depth modes need a lot of bandwidth...
But, probably no mainline OS will have native support for such hardware or modes, which might be an issue.
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.
In my case, a single set of instructions is used, with a 48-bit address range like:
0000_00000000..7FFF_FFFFFFFF: Userland VAS
8000_00000000..BFFF_FFFFFFFF: System VAS
C000_00000000..CFFF_FFFFFFFF: Physical Space (No MMU)
D000_00000000..DFFF_FFFFFFFF: Physical Space (No MMU, Volatile)
E000_00000000..EFFF_FFFFFFFF: Reserved
F000_00000000..FFFF_FFFFFFFF: MMIO Space
Would, within Physical Space:
Z000: All of the physical map goes here.
Z001..ZFFF: Nothing
Then, within the low 4GB:
00000000..00007FFF: ROM
0000C000..0000DFFF: SRAM
00010000..00FFFFFF: Special ROM Pages (mostly NULL)
01000000..3FFFFFFF: RAM
40000000..EFFFFFFF: Nothing
F0000000..FFFFFFFF: Optional MMIO (32-bit config)
The 28-bit MMIO space is mapped into FFFF_Fxxxxxxx, with pretty much the whole rest of MMIO space being unused.
Early on, the 32-bit MMIO space and low 4GB were special (including in the VAS), bit this has gone away (so, now only the 48-bit forms are recognized if configured for a 48-bit addressing).
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?
I had an instruction to load/store CRs...
I had called it... "MOV" ...
Ironically, this was a reduction from SH, which called them LDC/STC/LDS/STS, depending on which registers one was going to/from.
>
------------
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.
At least, function names are not:
Try to find a short acronym that also has relatively few web hits.
>
Hilarious--and reason enough to change names.
>
When you do change names, can you spell LD and ST instead of MOV ??
Yes, please LD / ST it is so much clearer what is going on. Less trouble getting confused by the placement of operands.
I always put the memory operand second, which breaks the pattern of having the destination operand first. Otherwise the destination is first.
I go cross-eyed reading code that is a whole lot of moves.
A low of people swear by:
movl %eax, 16(%rdi)
...
Why VAX Was the Ultimate CISC and Not RISC
Re: Why VAX Was the Ultimate CISC and Not RISC
