Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 6 Sep 2024 15:41:12 -0700
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <vbg0e8$v9mi$2@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: Sat, 07 Sep 2024 00:41:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="021f863eb614e1e6cbca79908b964879";
	logging-data="1025746"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/b4IWkR0IyU7UN7fwM1EF/VX8LQQrkny4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qA8pvIUqz9Nv4uWQpIFXoIGH1Lc=
In-Reply-To: <vbcob9$dvp4$1@dont-email.me>
Content-Language: en-US
Bytes: 4246

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]
}

;^)

> 
> One of my alternatives are
> 
>    unsigned u = start; // Cannot be less than zero
>    if (u) {
>      u++;
>      do {
>        u--;
>        data[u]...
>      while (u);
>    }

any unsigned integer cannot be less than zero?


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