Deutsch English Français Italiano |
<d906b4630b3bd746091b259f9d5a481c@www.novabbs.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!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 21:05:05 +0000 Organization: Rocksolid Light Message-ID: <d906b4630b3bd746091b259f9d5a481c@www.novabbs.org> References: <vaqgtl$3526$1@dont-email.me> <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> <vc70sl$285g2$4@dont-email.me> <vc73bl$28v0v$1@dont-email.me> <OvEFO.70694$EEm7.38286@fx16.iad> <32a15246310ea544570564a6ea100cab@www.novabbs.org> <86seu0d7br.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="2197393"; mail-complaints-to="usenet@i2pn2.org"; posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A"; User-Agent: Rocksolid Light X-Rslight-Site: $2y$10$07bNM3YiEmD6f8g4LMPms.Fd/rXvERhQpcObrPB7j98O7KLF7FQ4a X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 Bytes: 3942 Lines: 62 On Sun, 15 Sep 2024 19:51:04 +0000, Tim Rentsch wrote: > mitchalsup@aol.com (MitchAlsup1) writes: > >> On Sun, 15 Sep 2024 17:07:58 +0000, Scott Lurndal wrote: >> >>> Robert Finch <robfi680@gmail.com> 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; >>> uint64_t reserved_9_31 : 23; >>> uint64_t sbe : 9; >>> #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. > > The 17-bit bitfied can be specified in the usual way. Example: > > struct bitfield_example { > unsigned one : 32; > unsigned two : 20; > unsigned hmm : 17; > }; > > An implementation is allowed to use up the last 12 bits of the > first 64-bit unit and the first 5 bits of the next 64-bit unit. > But, whether that happens or not is up to the implementation. > The bitfield for member 'hmm' could instead be put entirely in > the second 64-bit unit, with the last 12 bits of the first 64-bit > unit simply left as padding. There is no standard way to force > it.