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.
Could do similar with __int128 (or uint128_t), which extends it up to 63 bits.
But, doesn't work on GCC, which (for whatever reason) doesn't seem to support integer types larger than 64 bits on any of the targets I actually care about.
As well as the traditional strategy being a whole lot more efficient in
this case...
>
>
I guess the case could be made for a generic dense bit array.
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.
If I added it, it would probably be a 64-bit encoding (generally needed for 4R).
The logic needed for a funnel shift operation basically already exists, though the mapping might be funky as it is mostly set up for 128-bit shifts, vs a typical 4R operation, where the register port mappings and similar are different.
Though, likely, this would be a special case to probably either do something weird in decode, or add something to redirect inputs based on whether it is being used for a 128-bit shift or a funnel-shift.
Though, an open question is how one would define it in a way that is
consistent with existing semantics rules.
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).
...
But, yeah, there is probably some stuff that could be shaved off.
Most likely, if I did a soft reset, I might drop XG1 support...
Main tradeoff here is that XG1 can generate binaries that are around 10-20% smaller, but with worse performance (XG1 has performance issues for a similar reasons to RISC-v + C).
The "cleanest" option might be to go to XG3-only or XG3+RV.
In the simple case, could align things such that the basic configurations for both ISAs have a mostly similar feature set.
Also, an OS that runs a kernel in RISC-V mode could also support code running in a basic form of XG3 mode with little special handling (unlike XG1 or XG3 which have additional architectural support). Albeit with some wonk (there would be some additional state hidden in PC and LR/RA).
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).
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
This differs from my own memory map where generally RAM starts at the 16MB mark, and the space between 64K and 16MB is mostly special-purpose ROM ranges (mostly NULL pages).
If really needed, I could make all of this also RAM range, and find some other range in the physical map to put the NULL pages (if present), or just use a zeroed RAM page as the designated NULL page.
Though, other SOC's seem to use:
00000000..3FFFFFFF: Architectural Stuff
40000000..7FFFFFFF: ROM and MMIO
80000000..FFFFFFFF: RAM goes here
Though, looking around, RAM being located starting at 80000000 seems to be specified in some things related to the Linux RISC-V Platform spec, which is more easily pulled off (I don't have anything else there).
Laziest option is probably just to have RAM cover the entire space from 01000000..BFFFFFFF, repeating however many times is necessary. Maybe move the default RAM-backed addresses for the framebuffer and audio hardware maybe to up near the 128MB or 256MB mark.
0FA00000: VRAM goes here.
4FA00000: VRAM also goes here (another redundant address).
Though, better would be to have two separate address ranges.
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?...).
My boot ROM is able to load ELF images already, I guess the main practical difference here would be theoretically needing to support GPT (vs just MBR), and (AFAIK) provide a method-table or similar for the UEFI interfaces. Apparently there is the idea that hardware interface configuration would be done via PCIe / device trees. But, dunno about specific hardware interfaces. Would need to find some basic "hopefully cheap to implement" semi-standard hardware interfaces.
There would likely be some amount of learning curve here...
So, it is more likely that if a partial reboot were done, it would mostly be reworking the hardware level interfaces (to hopefully be able to host a more traditional OS) rather than all that much ISA related.
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).
Could just do a soft-reboot and move on to BJX3, but mostly have it as a direct continuation, or maybe come up with something different.
Usual difficulty being to come up with something decent that hasn't already been used for something else.
Decided to leave out the annoyance of the seemingly all of the "good" naming patterns having seemingly already been taken (including most of the "random keyboard mash" acronyms, ...).
Almost seems like a fluke that I managed to land on something that wasn't already in-use / overused, if going by search results...
...
Why VAX Was the Ultimate CISC and Not RISC
Re: Why VAX Was the Ultimate CISC and Not RISC
