Re: Top 10 most common hard skills listed on resumes...

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