Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Sun, 15 Sep 2024 19:13:31 +0000 Organization: Rocksolid Light Message-ID: <50cd3ba7c0cbb587a55dd67ae46fc9ce@www.novabbs.org> References: <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> <32a15246310ea544570564a6ea100cab@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="2187741"; mail-complaints-to="usenet@i2pn2.org"; posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A"; User-Agent: Rocksolid Light X-Rslight-Site: $2y$10$ghuEO5eIZXMLSgeNqFJWFu8dHF8fp/NgGbvPtuvRmRv6xsR771k2W X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 Bytes: 4576 Lines: 74 On Sun, 15 Sep 2024 18:48:48 +0000, David Brown wrote: > On 15/09/2024 19:21, MitchAlsup1 wrote: >> On Sun, 15 Sep 2024 17:07:58 +0000, Scott Lurndal wrote: >> >>> Robert Finch writes: >>>> On 2024-09-15 12:09 p.m., David Brown wrote: >>> >>>>>> In addition, some padding-related things can be defined by Standard >>>>>> itself. Not in this particular case, but, for example, it could be >>>>>> defined that when field of one integer type is immediately followed by >>>>>> another field of integer type with the same or narrower width then >>>>>> there should be no padding in-between. >>>>>> >>>>> >>>> What about bit-fields in a struct? I believe they are usually packed. In >>>> case its for something like an I/O device. >>> >>> That's a bit more complicated as it depends on the target byte-order. >>> >>> e.g. >>> >>>     struct GIC_ECC_INT_STATUSR_s { >>> #if __BYTE_ORDER == __BIG_ENDIAN >>>         uint64_t reserved_41_63              : 23; >>>         uint64_t dbe                         :  9; /**< R/W1C/H - RAM >>> ECC DBE detected. */ >>>         uint64_t reserved_9_31               : 23; >>>         uint64_t sbe                         :  9; /**< R/W1C/H - RAM >>> ECC SBE detected. */ >>> #else >>>         uint64_t sbe                         :  9; >>>         uint64_t reserved_9_31               : 23; >>>         uint64_t dbe                         :  9; >>>         uint64_t reserved_41_63              : 23; >>> #endif >>>     } s; >> >> Which brings to mind a slight different but related bit-field issue. >> >> If one has an architecture that allows a bit-field to span a register >> sized container, how does one specify that bit-field in C ?? >> >> So, assume a register contains 64-bits and we have a 17-bit field >> starting at bit 53 and continuing to bit 69 of a 128-bit struct. >> How would one "properly" specify this in C. > > You do so inconveniently, perhaps with access inline functions rather > than a bit-field struct. > > Fortunately, not many hardware designers are that sadistic. (Or perhaps > they /are/ that sadistic, but lack the imagination for that particular > trick.) In My 66000 ISA it is both efficient and straightforward:: i = struct.field; ... struct.field = j; CARRY Rsf1,{I} SRA Ri,Rsf0,<17,53> and CARRY Rsf1,{O} INS Rsf0,Rj,<52,17> Note: Rsf1 and Rsf0 combined are the 128 bits container, but there is no need for these registers to be sequential. As to HW sadism:: this not not any harder than mis- aligned DW accesses from the cache. Many ISA from the rather distant past could do these rather efficiently {360 SRDL,...} If the ISA has any realistically efficient grasp on multi-precision integer operations, these fall out almost for free.