Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.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 11:14:54 +0200
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <vbmeae$2bn2v$2@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <87mskvuxe9.fsf@bsb.me.uk>
 <vaq9tu$1te8$1@dont-email.me> <vbci8r$1c9e8$1@paganini.bofh.team>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Sep 2024 11:14:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="245842e44c78e95d3bc5cb773286c128";
	logging-data="2481247"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19qf7c5WQHlFD66CaIgeOdWSel+0hN9NwI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:TXX46kzlJZrnBUxT6TasfwH1YGg=
In-Reply-To: <vbloje$2e34o$1@paganini.bofh.team>
Content-Language: en-GB
Bytes: 4664

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.


>> Average number of local variables in a half-dozen C codebases I surveyed
>> was 3 variables per function. So I find it hard to see the point of
>> splitting them up into different scopes!
> 
> My style tends to produce more local variables than older style.
> Some functions are big and in those there are most benefits.
> But even if there is only 1 variable wrong/missing initialization
> may be a problem.  My style minimizes such issues.
> 

Local variables are free in C as used by most people, so IMHO it is a 
good idea to use them generously.  Breaking big calculations into parts 
with names can make code a lot clearer.  Consider declaring them "const" 
to be clear that they do not change after initialisation.

(Bart dislikes extra locals because he has a style of declaring them all 
at the start of functions, usually without initialisation, and likes to 
use non-optimising compilers and then complain about the speed.)