Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 05 Sep 2024 15:04:14 -0700
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <86h6atoizl.fsf@linuxsc.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <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=us-ascii
Injection-Date: Fri, 06 Sep 2024 00:04:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e8cf81bb8aea3e69f32958c8dbde0aad";
	logging-data="533708"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18LIc0ykBFdnWX4Be0i40iywx7TBggerpE="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:xWYCxXp4dVuUWYtXVIOEus/SK58=
	sha1:349AFefi/sGXpGG1LaD3VshEogo=
Bytes: 3575

Terje Mathisen <terje.mathisen@tmsw.no> writes:

[...]

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

See below.

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

This code isn't the same as the for() loop above.  If start is
0, the for() loop runs once, but the do..while loop runs zero times.

Regarding the given for() loop, namely this:

    for (int i = START; i >= 0; i-- ) {
      // Do something with data[i]
    }

If START is signed (presumably of type int), so the loop might run
zero times, but never more than INT_MAX times, then

    for(  unsigned u = START < 0 ? 0 : START + 1u;  u > 0 && u--;  ){
      // Do something with data[i]
    }

If START is unsigned, so in all cases the loop must run at
least once, then

    unsigned u = START;
    do {
      // Do something with data[i]
    } while(  u > 0  &&  u--  );

(Yes I know the 'u > 0' expressions can be replaced by just 'u'.)

The optimizer should be smart enough to realize that if 'u > 0'
is true then the test 'u--' will also be true.  The same should
hold if 'u > 0' is replaced by just 'u'.

(Disclaimer:  code not compiled.)