Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!nntp.comgw.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 17 Sep 2024 20:11:55 +0000
Organization: Rocksolid Light
Message-ID: <e060fe2e0ee375efff2a9ab1223652f5@www.novabbs.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2441842"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$ekRkMwH4W8QRfC8IMGRpxeDzC3Tc9KRHVCxwulwXDnNsqtdMbX2OO
Bytes: 4349
Lines: 78

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

>>
>
> 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};

>>>>
>>>
>>> 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.

>
> 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.
>
> 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

This only gives 36-bits (top) or 30-bits (bottom) or range. What you are
going to want is 64-bits of range -- especially when switching modes--
you PROBABLY want to use an entirely different sub-tree of the
translation
table trees.