Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: Waldek Hebisch <antispam@fricas.org>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 9 Sep 2024 16:46:40 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vbn8pe$2g9i6$2@paganini.bofh.team>
References: <vab101$3er$1@reader1.panix.com>   <vbcs65$eabn$1@dont-email.me> <vbekut$1kd24$1@paganini.bofh.team> <vbepcb$q6p2$1@dont-email.me> <vbgb5q$1ruv8$1@paganini.bofh.team> <vbhbbb$1blt4$1@dont-email.me> <vbipp5$24kl5$1@paganini.bofh.team> <vbk0d9$1tajm$1@dont-email.me> <vbkpfc$27l2o$1@paganini.bofh.team> <vbl3am$228vv$1@dont-email.me> <vblfgb$2dkij$1@paganini.bofh.team> <vblhp7$249ug$1@dont-email.me> <vbloje$2e34o$1@paganini.bofh.team> <vbmeae$2bn2v$2@dont-email.me>
Injection-Date: Mon, 9 Sep 2024 16:46:40 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2631238"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 4229
Lines: 53

David Brown <david.brown@hesbynett.no> wrote:
> On 09/09/2024 05:04, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>> On 09/09/2024 01:29, Waldek Hebisch wrote:
>>>> Bart <bc@freeuk.com> wrote:
>>>
>>>> No.  It is essential for efficiency to have 32-bit types.  On 32-bit
>>>> machines doing otherwise would add useless instructions to object
>>>> code.  More precisly, really stupid compiler will generate useless
>>>> intructions even with my declarations, really smart one will
>>>> notice that variables fit in 32-bits and optimize accordingly.
>>>> But at least some gcc versions needed such declarations.  Note
>>>> also that my version makes clear that there there is
>>>> symmetry (everything should be added using 64-bit precision),
>>>> you depend on promotion rules which creates visual asymetry
>>>> are requires reasoning to realize that meaning is symetric.
>>>
>>> Your posted code used 64-bit aritmetic. The xext and c 32-bit variables
>>> were used in loops where they need to be widened to 64 bits anyway. The
>>> new value of c is set from a 32-bit result.
>> 
>> Well, at C level there is 64-bit type.  The intent is that C compiler
>> should notice that the result is 32-bit + carry flag.  Ideally
>> compiler should notice that c has only one bit and can keep it
>> in carry flag.  On i386 comparison needed for loop control would
>> destroy carry flag, so there must be code using value of carry in
>> register and code to save carry to register.  But one addition
>> of highs parts can be skipped.  On 32-bit ARM compiler can use
>> special machine istructions and actually generated code which
>> is close to optimal.
> 
> When you have a type that you want to be at least 32 bits (to cover the 
> range you need), and want it to be as efficient as possible on 32-bit 
> and 64-bit machines (and 16-bit and 8-bit, still found in 
> microcontrollers), use "int_fast32_t".  On x86-64 it will be 64-bit, on 
> 32-bit systems it will be 32-bit.  Use of the [u]int_fastNN_t types can 
> make code significantly more efficient on 64-bit systems while retaining 
> efficiency on 32-bit (or even smaller) targets.

Well, I have constraints, some of which are outside of C code.
To resolve contraints I normally use some configure machinery.
If a standard type is exact match for my constraints, then I would
use standard type, possibly adding some fallbacks for pre-standard
systems.  But if my constranits differ, I see no advantage in
using more "fancy" standard types compared to old types.

Concerning '<stdint.h>', somewhat worring thing is that several types
there seem to be optional (or maybe where optional in older versions
of the standard).  I am not sure if this can be real problem,
but too many times I saw that on various issues developers say
"this in not mandatory, so we will skip it".

-- 
                              Waldek Hebisch