Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.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.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 7 Sep 2024 09:15:11 +0200
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <vbguhv$18kfl$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <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> <vbg0e8$v9mi$2@dont-email.me>
 <a3e7614794a11b67739888bcaa7e734a@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 07 Sep 2024 09:15:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e918c8e72d9d7340830ec59dd43f8b6a";
	logging-data="1331701"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+dkV0J7ut90bs7DG5sCwNlnajfN8DI2dU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9TUB2vDCRiu+IccltjqkjdtGJuw=
Content-Language: en-GB, nb-NO
In-Reply-To: <a3e7614794a11b67739888bcaa7e734a@www.novabbs.org>
Bytes: 4353

On 07/09/2024 01:10, MitchAlsup1 wrote:
> On Fri, 6 Sep 2024 22:41:12 +0000, Chris M. Thomasson wrote:
> 
>> On 9/5/2024 10:04 AM, 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.
>>>
>>> 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.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]
>>>    }
>>
>> for (int i = START; i > -1; i-- ) {
>>       // Do something with data[i]
>> }
>>
>> ;^)
> 
> # define START 0x80000001
> 

No.

The great thing about 32 bit integers is that your numbers are never 
anywhere close to being too big - or you /know/ you are dealing with 
very big numbers and you can take that into account such as by using 
64-bit integer types.

A number that is the start or end of a normal count range is /never/ 
0x80000001.  Write code that is clear, simple and correct for what you 
are actually doing.  And if you think such big numbers are realistic, 
write the same clear, simple and correct code with "int64_t" instead.