Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 5 Sep 2024 21:36:04 +0200
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <vbd174$eulp$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me>
 <vb91e7$3o797$1@dont-email.me> <vb9eeh$3q993$1@dont-email.me>
 <vb9l7k$3r2c6$2@dont-email.me> <vba26l$3te44$1@dont-email.me>
 <vbag2s$3vhih$1@dont-email.me> <vbbnf9$8j04$1@dont-email.me>
 <vbbsl4$9hdg$1@dont-email.me> <vbcbob$bd22$3@dont-email.me>
 <vbcob9$dvp4$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 05 Sep 2024 21:36:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d6cec6b333058dd055a395c7bb0cf729";
	logging-data="490169"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Hd0PUyzPxWCi/mLRdmMbe5CQpuh/zmTY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:710RVFl3m6xmFwJ8APvXPPlGZUI=
Content-Language: en-GB
In-Reply-To: <vbcob9$dvp4$1@dont-email.me>
Bytes: 5088

On 05/09/2024 19:04, Terje Mathisen wrote:
> David Brown wrote:
>> On 05/09/2024 11:12, Terje Mathisen wrote:
>>> David Brown wrote:
>>>> Unsigned types are ideal for "raw" memory access or external data, 
>>>> for anything involving bit manipulation (use of &, |, ^, << and >> 
>>>> on signed types is usually wrong, IMHO), as building blocks in 
>>>> extended arithmetic types, for the few occasions when you want two's 
>>>> complement wrapping, and for the even fewer occasions when you 
>>>> actually need that last bit of range.
>>>
>>> That last paragraph enumerates pretty much all the uses I have for 
>>> integer-type variables, with (like Mitch) a few apis that use (-1) as 
>>> an error signal that has to be handled with special code.
>>>
>>
>> You don't have loop counters, array indices, or integer arithmetic?
> 
> Loop counters of the for (i= 0; i < LIMIT; i++) type are of course fine 
> with unsigned i, arrays always use a zero base so in Rust the only array 
> index type is usize, i.e the largest supported unsigned type in the 
> system, typically the same as u64.

Loop counters can usually be signed or unsigned, and it usually makes no 
difference.  Array indices are also usually much the same signed or 
unsigned, and it can feel more natural to use size_t here (an unsigned 
type).  It can make a difference to efficiency, however.  On x86-64, 
this code is 3 instructions with T as "unsigned long int" or "long int", 
4 with "int", and 5 with "unsigned int".

int foo(int * p, T x) {
     int a = p[x++];
     int b = p[x++];
     return a + b;
}


Anyway, I count loop counters and array indices as "use of integer-type 
variables", whether you prefer signed or unsigned.



> 
> unsigned arithmetic is easier than signed integer arithmetic, including 
> comparisons that would result in a negative value, you just have to make 
> the test before subtracting, instead of checking if the result was 
> negative.

I can't follow that at all.  Unsigned and signed arithmetic and 
comparisons both work simply and as you'd expect.  /Mixing/ signed and 
unsigned types can get things wrong.

> 
> I.e I cannot easily replicate a downward loop that exits when the 
> counter become negative:
> 
>    for (int i = START; i >= 0; i-- ) {
>      // Do something with data[i]
>    }
> 
> One of my alternatives are
> 
>    unsigned u = start; // Cannot be less than zero
>    if (u) {
>      u++;
>      do {
>        u--;
>        data[u]...
>      while (u);
>    }
> 
> This typically results in effectively the same asm code as the signed 
> version, except for a bottom JGE (Jump (signed) Greater or Equal instead 
> of JA (Jump Above or Equal, but my version is far more verbose.
> 

A more important thing is that the first version, with signed i, is 
/vastly/ simpler and clearer in the source code.

> Alternatively, if you don't need all N bits of the unsigned type, then 
> you can subtract and check if the top bit is set in the result:
> 
>    for (unsigned u = start; (u & TOPBIT) == 0; u--)
> 
> Terje
> 

Or you could just write sane code that matches what you want to say.