Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 6 Sep 2024 23:10:16 +0000
Organization: Rocksolid Light
Message-ID: <a3e7614794a11b67739888bcaa7e734a@www.novabbs.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1114298"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$1HeaY53hS71k3z82bFXD.eumPIdfvXgvmJVc/Fk9c.05goLDb8T4O
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4216
Lines: 72

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

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