Deutsch English Français Italiano |
<v6okru$2fdnt$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Malcolm McLean <malcolm.arthur.mclean@gmail.com> Newsgroups: comp.lang.c Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?= =?UTF-8?B?IGEgIm5ldyIgQyA/?= Date: Thu, 11 Jul 2024 13:57:34 +0100 Organization: A noiseless patient Spider Lines: 50 Message-ID: <v6okru$2fdnt$1@dont-email.me> References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me> <v687h2$36i6p$1@dont-email.me> <v68sjv$3a7lb$1@dont-email.me> <v6a76q$3gqkm$6@dont-email.me> <87plrruvmt.fsf@nosuchdomain.example.com> <v6argi$3ngh6$5@dont-email.me> <v6crb5$1gpa$1@dont-email.me> <v6kma1$1jcln$7@dont-email.me> <v6lcg3$1qhmn$1@dont-email.me> <v6nhbr$29e0c$3@dont-email.me> <v6od5q$2djgq$3@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 11 Jul 2024 14:57:35 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f46bd0f45f760461c149213d65494ecb"; logging-data="2602749"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ye82ow5kFtkCjbgnewXrL7973SJLTECs=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:OB6NCvkJGpBrxLH2RbGSGMChGfg= Content-Language: en-GB In-Reply-To: <v6od5q$2djgq$3@dont-email.me> Bytes: 3771 On 11/07/2024 11:46, David Brown wrote: > On 11/07/2024 04:51, Lawrence D'Oliveiro wrote: >> On Wed, 10 Jul 2024 03:16:18 -0400, James Kuyper wrote: >> >>> On 7/9/24 20:57, Lawrence D'Oliveiro wrote: >>> >>>> On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote: >>>> >>>>> On many platforms, if _Alignof(type) is less than the word size, then >>>>> a C pointer to that type is implemented as the combination of the >>>>> machine address of the correct word, combined with an offset within >>>>> that word of the first byte of that object. >>>> >>>> Which is a terrific idea, except it cannot be carried to its logical >>>> conclusion (addressing of arbitrarily-aligned dynamically-defined >>>> bitfields) because of the requirement in the C spec that the size of a >>>> “byte” be at least 8 bits. >>> >>> I will grant you that I failed to mention the fact that this is a >>> feasible way of implementing C only on platforms with a word size of 16 >>> bits or longer. >> >> Don’t you think C needs a better way of handling bitfields than >> shift-and- >> mask? Many architectures have bitfield instructions, but C cannot easily >> make use of them without the ability to have arbitrarily-bit-aligned >> pointers. > > There are pros and cons of different ways to support bitfields in a > language, and there are certainly aspects of C's bitfields that many > people think are less than ideal. > > But (good) C compilers have no problem using bitfield instructions on > architectures that have these, so that at least is not an issue. > It's something I very rarely need for the type of prgramming I do, which is portable algortithm implentations on systems wheee the constraint is primarily time rather than memory.And that type of programming does represent quite a lot of C programming or larger hosted systems. Bitfields come into their own in embedded systems, either to save memory, or to address hardware bits directly. And the last use is inherently non-portable, so it's OK if non-target compilers cannot generate efficient code. And the first use is theoretically portable, but but practice not very likely to be ported, because when you do that sor of micro-optimisation you lose portabliity. -- Check out my hobby project. http://malcolmmclean.github.io/babyxrc