Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 9 Sep 2024 19:21:33 +0200
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <vbnaqt$2g0vc$1@dont-email.me>
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>
 <vbn8pe$2g9i6$2@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Sep 2024 19:21:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3efea3e64b610dbd0655d184f54f1324";
	logging-data="2622444"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/dhHmJvmlPRbkBooCIE1pOmmnw+VeHTm4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:R9N2k/669C5gi9CdjYJmSZvODWo=
Content-Language: en-GB
In-Reply-To: <vbn8pe$2g9i6$2@paganini.bofh.team>

On 09/09/2024 18:46, Waldek Hebisch wrote:
> 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.
> 

The "fancy" standard types in this case specify /exactly/ what you 
apparently want - a type that can deal with at least 32 bits for range, 
and is as efficient as possible on different targets.  What other 
constraints do you have here that make "int_fast32_t" unsuitable?

> 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".
> 

<stdint.h> has been required since C99.  It has not been optional in any 
C standard in the last 25 years.  That's a /long/ time - long enough for 
most people to be able to say "it's standard".

And almost every C90 compiler also includes <stdint.h> as an extension.

If you manage to find a compiler that is old enough not to have 
<stdint.h>, and you need to use it for actual code, it's probably worth 
spending the 3 minutes it takes to write a suitable <stdint.h> yourself 
for that target.