Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Mon, 10 Mar 2025 17:40:55 -0500
Organization: A noiseless patient Spider
Lines: 191
Message-ID: <vqnps4$1j63b$1@dont-email.me>
References: <vpufbv$4qc5$1@dont-email.me>
 <2025Mar1.125817@mips.complang.tuwien.ac.at> <vpvrn5$2hq0$1@gal.iecc.com>
 <2025Mar1.232526@mips.complang.tuwien.ac.at> <vq2dfr$2skk$1@gal.iecc.com>
 <2025Mar2.234011@mips.complang.tuwien.ac.at> <5pkg9l-kipt.ln1@msc27.me.uk>
 <2025Mar3.174417@mips.complang.tuwien.ac.at> <vq4qav$1dksd$1@dont-email.me>
 <vq5dm2$1h3mg$5@dont-email.me> <2025Mar4.110420@mips.complang.tuwien.ac.at>
 <vq829a$232tl$6@dont-email.me> <2025Mar5.083636@mips.complang.tuwien.ac.at>
 <vqdljd$29f8f$2@paganini.bofh.team> <vqdrh9$3cdrc$1@dont-email.me>
 <vqek6h$3fro6$1@dont-email.me>
 <fe70b48cd6fef0aaf89278163d8b6322@www.novabbs.org>
 <vqfmr4$3npgk$1@dont-email.me> <vqg04o$3p80h$1@dont-email.me>
 <vqgbao$3rbkh$1@dont-email.me>
 <9371fe9be75cdd606c876f539e1d2d78@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 10 Mar 2025 23:42:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d8a0bb474d801eda28f6feea8f6e336c";
	logging-data="1677419"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1824HRQLgPBbyLjbEu/mFzsy2V1YFdVkf4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:mlreR7/LnY6jezP2QR6YPEJGXZw=
Content-Language: en-US
In-Reply-To: <9371fe9be75cdd606c876f539e1d2d78@www.novabbs.org>
Bytes: 8849

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.
========== REMAINDER OF ARTICLE TRUNCATED ==========