Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Why VAX Was the Ultimate CISC and Not RISC Date: Tue, 11 Mar 2025 00:53:31 +0000 Organization: Rocksolid Light Message-ID: <0da86de26bac1912b190793512255aa4@www.novabbs.org> References: <2025Mar1.125817@mips.complang.tuwien.ac.at> <2025Mar1.232526@mips.complang.tuwien.ac.at> <2025Mar2.234011@mips.complang.tuwien.ac.at> <5pkg9l-kipt.ln1@msc27.me.uk> <2025Mar3.174417@mips.complang.tuwien.ac.at> <2025Mar4.110420@mips.complang.tuwien.ac.at> <2025Mar5.083636@mips.complang.tuwien.ac.at> <9371fe9be75cdd606c876f539e1d2d78@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="3805675"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Site: $2y$10$zf.JLgMiv/LichBL2E3My.ZWv5RzhbnNpvmLAeObfnFRcSi5vsvcK X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 Bytes: 5921 Lines: 118 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). 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. ------------ > 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). Hilarious--and reason enough to change names. When you do change names, can you spell LD and ST instead of MOV ??