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: References: <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <2024Sep10.101932@mips.complang.tuwien.ac.at> <2024Sep11.123824@mips.complang.tuwien.ac.at> <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com> <20240915001153.000029bf@yahoo.com> <20240915154038.0000016e@yahoo.com> <2024Sep15.194612@mips.complang.tuwien.ac.at> 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.