Path: ...!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 22:04:54 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vbnre4$2h8k3$1@paganini.bofh.team>
References: <vab101$3er$1@reader1.panix.com>   <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> <vbnaqt$2g0vc$1@dont-email.me>
Injection-Date: Mon, 9 Sep 2024 22:04:54 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2663043"; 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: 6056
Lines: 88

David Brown <david.brown@hesbynett.no> wrote:
> 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?

This routine is part of small library.  Good approximation is that
I want a type (posibly depending on target) which will make this
library fast.  As I wrote in another message I plan to use 64-bit
units of work on 64-bit targets.  I have not plans to use the
library in 8-bit or 16-bit targets, but if I needed them on such
targets I probably would use 16-bit work unit.  So, while 32-bit
work unit represents current state, it not correct statement of
intentions.  Consequently, 'int_fast32_t' would be as misleading
or more misleading than 'int' ('int' is reasonable indication
that choice of types is not finished, 'int_fast32_t' suggest that
it is proper choice for all targets).

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

ATM I do not have standard text handy to check, but AFAIR several
_types_ in <stdint.h> were not required but optional.

-- 
                              Waldek Hebisch