Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 17 Sep 2024 17:15:12 -0500
Organization: A noiseless patient Spider
Lines: 233
Message-ID: <vccv3r$3nfqv$1@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me> <86r09ulqyp.fsf@linuxsc.com>
 <2024Sep8.173639@mips.complang.tuwien.ac.at>
 <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
 <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z>
 <2024Sep11.123824@mips.complang.tuwien.ac.at> <vbsoro$3ol1a$1@dont-email.me>
 <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com>
 <vbuu5n$9tue$1@dont-email.me> <20240915001153.000029bf@yahoo.com>
 <vc6jbk$5v9f$1@paganini.bofh.team> <20240915154038.0000016e@yahoo.com>
 <2024Sep15.194612@mips.complang.tuwien.ac.at> <vc8m5k$2nf2l$1@dont-email.me>
 <vc8tlj$2od19$3@dont-email.me> <vca209$319ci$1@dont-email.me>
 <vcbiov$3ecji$3@dont-email.me> <vccmm3$3m42h$1@dont-email.me>
 <e060fe2e0ee375efff2a9ab1223652f5@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 18 Sep 2024 00:16:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f294aec13410514d4030784d3213085a";
	logging-data="3915615"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19YwIikOHgf1iTpoEcmCtC/7ASN2YHfOcI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Qr+wqPynjw82zbp2lygVa8d54A0=
Content-Language: en-US
In-Reply-To: <e060fe2e0ee375efff2a9ab1223652f5@www.novabbs.org>
Bytes: 10010

On 9/17/2024 3:11 PM, MitchAlsup1 wrote:
> On Tue, 17 Sep 2024 19:51:19 +0000, BGB wrote:
> 
>> On 9/17/2024 4:39 AM, David Brown wrote:
>>> On 16/09/2024 21:46, BGB wrote:
>>>> On 9/16/2024 4:27 AM, David Brown wrote:
>>>>
>>>> Albeit, types like _Bool in my implementation are padded to a full
>>>> byte (it is treated as an "unsigned char" that is assumed to always
>>>> hold either 0 or 1).
>>>
>>> That's the usual way to handle them.
> 
> Smallest C container is 1 byte
> __BOOL can use as small a container as C can address
> 

It works, and is typical.

But, does kinda seem like a waste sometimes to burn 8 bits to hold a 1 
bit value.

Then again, it wastes even more space in function argument lists (a full 
64 bits), but then again, one doesn't usually care too much about the 
size of function arguments (or the bits "wasted" in the upper unused 
parts of GPRs).


>>>
>>
>> Another option would be for adjacent _Bool values to merge similar to
>> bitfields...
>> Though, seems that simply turning it into a byte is the typical option.
> 
> One can do ATOMIC stuff on a __BOOL
> one cannot do ATOMIC stuff on struct { unsigned __bool: 1};
> 

Probably true.


>>>>>
>>>>
>>>> This comes up as an issue in some Windows file formats, where one
>>>> can't just naively use a struct with 32-bit fields because some 32-bit
>>>> members only have 16-bit alignment.
>>>
>>> Ah, the joys of using ancient formats with new systems!
>>>
>>
>> I was around when this stuff was still newish.
>>
>> Some are essentially frozen in time with their misaligned members.
> 
> In HW the packing and unpacking of multi-container single variables
> is easy--its just wires.
> 

>> Still better than:
>>    "Well, initial field wasn't big enough";
>>    "Repurpose those bytes from over there, and glue them on".
> 
> Really NOT a problem in HW--understandably low efficiency in SW.
> 

Yeah.

Bunch of shifts and OR's.

Then again, by the time one is dealing with this part (say, in a FAT 
directory entry), chances are they have already gone through the (more 
expensive) process of linearly searching the directory to find the file 
they are looking for.


Ironically, also, FAT is a much more convoluted format than, say, ELF.


But conversely getting ELF shared-object loading to work is being a much 
bigger pain, mostly because seemingly no one has really bothered to 
document this stuff for crap (like, "what, exactly, is supposed to be 
the correct initial state of the registers, auxiliary vectors, ..., such 
that ld-linux.so and similar is happy?...").

As-is, it now seems it gets a good part of the way though the process, 
but then dies trying to deref a NULL pointer before getting to the last 
stage (after which it will apparently transfer control to the entry 
point for the main binary).

Seemingly, I would also expect there to be some way to supply to 
ld-linux.so the locations for where one put the various ELF images 
(besides just the main binary and the interpreter, as it appears to 
assume that the kernel loads them into memory, but ld-linux.so does the 
symbol lookups and relocs).

All this being made a little harder as I don't have any symbolic 
information for these images, so need to try to manually figure out 
where it is at based on the memory addresses (and by looking at the code 
for the C library).


>>
>> There would need to be a mechanism in the ISA to select between these
>> modes though (probably a "magic branch" scheme different from the one
>> used for Inter-ISA branches).
> 
> Modes make testing significantly harder. Each mode adds 1 to the
> exponent
> how many test cases it takes to adequately test a part.

Possibly.

But, modes are kinda unavoidable here:
   CPU only runs RV64GC or similar:
     Doomed to relative slowness;
   CPU only does CoEx:
     Closes off the ability to run binaries that assume RV64GC.
   CPU only does new ISA:
     Well, then it can't run RISC-V code, making all this kinda moot.


This would be different from my current multi-ISA scheme, where RISC-V 
and BJX2 are essentially entirely separate ISAs (and jumping from RV64 
to BJX2 mode currently requires using a full 64-bit pointer).

And, also the ABIs don't match.
The "new ISA" design could express both the RISC-V and BJX2 ABI;
While there are a few differences, they would matter more for a kernel 
mode context switcher (the new ISA lacks access to R0/R1/R14 from the 
existing ISA, similar to XG2RV, but this will not matter for function 
calls);
....


As-is, the CoEx scheme would not be possible with XG2 + RISC-V as BJX2 
and RISC-V instruction encodings are entirely incompatible.

Whereas, in the new ISA case, I designed the encoding to allow for some 
level of compatibility with RISC-V.

Modes would also avoid one of the argued main downsides of the Qualcomm 
proposal. Though, apparently, from what I gather they had also added 
auto-increment addressing, which I am not so sold on (wasn't able to 
find a proper spec though for what exactly they did; have only been able 
to find second-hand accounts).



>>
>> This would likely include an RV64 encoding for "Branch to/from CoEx",
>> and an encoding within this ISA to jump between CoEx and "Native" mode.
>>
>> Magic branches make sense mostly as any such mode switch is going to
>> require a pipeline flush.
>>
>> This is assuming an implementation that would want to be able to support
>> both this ISA and also RV64GC.
>>
>> One possibility could be (in native RV notation):
>> RV64 (Branches if supported, NOP if not):
>>    LBU X0, Xs, Disp12s  //Dest=RV64GC
>>    LWU X0, Xs, Disp12s  //Dest=CoEx
>>    LHU X0, Xs, Disp12s  //Dest=Native
>> New ISA:
>>    LBU X0, Xs, Disp10s  //Dest=RV64GC
>>    LWU X0, Xs, Disp10s  //Dest=CoEx
>>    LHU X0, Xs, Disp10s  //Dest=Native
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========