Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 9 Sep 2024 02:07:51 +0100
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <vblhp7$249ug$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <87v7zjuyd8.fsf@bsb.me.uk>
 <20240829084851.962@kylheku.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Sep 2024 03:07:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f78fc89e66291041ea37870e95b59fc2";
	logging-data="2238416"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/VQPkvpF/9WUNRf77dhEtd"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/02NG+dY/sH8LqPrj2cVwvGl83E=
In-Reply-To: <vblfgb$2dkij$1@paganini.bofh.team>
Content-Language: en-GB
Bytes: 4913

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.

(Have you tried 64-bit versions of xext, yext, c to see it it makes any 
difference? I may try it myself if I can set up a suitable test, but I 
can only test on a 64-bit machine.

Do you still have 32-bit machines around? I haven't been able to find 
one for a decade and a half!)

> In my version type of pp is clearly visible, together with casts
> this gives string hint what is happening: this is 32-bit addition
> producing carry in 'c'. 

It seems to do a 64-bit addition with a carry on bit 32 of the result 
stored in c.

> Note, I did not intend to post a trap for you, but in your
> egerness to shorten the code you removed important information.
> And while this code is unlikely to change much (basically
> upgrade to 64-bit version on 64-bit machines in the only likely
> change), normally code evolves and your version is harder
> to change.

3 copies of 'pp' is a bit harder to change than one!

Your code is basically doing 'p = a[i] + b[i] + c' in a loop, but spread 
over multiple lines and completed buried in all those 'unsigned long 
long' declarations:

         unsigned long long pp = (unsigned long long)(xp[i])
                               + (unsigned long long)(yp[i])
                               + (unsigned long long)c;

That was my main objection. And yes, all those casts because of mixing 
32/64-bit arithmetic is another source of clutter.

> More generally, my aim is to make code obviously correct
> (I not saying that I was fully successful in this case).
> I consider your version worse, because with your version
> reader has more work checking correctness (even taking into
> account that you lowered number of lines).

Sorry, I think mine (either version I posted) is easier to check.

> Anyway, I illustrated to you how I use declarations in the middle
> of a function.  There is nothing chaotic about this, type is
> declared when variable first time gets its value.  And in most
> cases variable scope is tiny.  AFAICS neither early Pascal nor
> your language allows me to write programs in this way.

You can write declarations mixed within code in my language, but they 
will have function-wide scope. I tend to do that only for temporary code.

> And if
> you do not see benefits, well, this your loss.

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!