Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 9 Sep 2024 08:56:45 +0200
Organization: A noiseless patient Spider
Lines: 127
Message-ID: <vbm67e$2apse$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> <vbd174$eulp$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 09 Sep 2024 08:56:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0116348fdc9cc4f161bd0f09196863ce";
	logging-data="2451342"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/wT9djbAwvBLaZYDDHDLadN08CWmyNnAx9pRXcwHrMKw=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:W0TGxjHb7fJYqNLvkC9uyopFZl0=
In-Reply-To: <vbd174$eulp$1@dont-email.me>
Bytes: 6128

David Brown wrote:
> 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=20
>>>>> extended arithmetic types, for the few occasions when you want=20
>>>>> two's complement wrapping, and for the even fewer occasions when=20
>>>>> you actually need that last bit of range.
>>>>
>>>> That last paragraph enumerates pretty much all the uses I have for=20
>>>> integer-type variables, with (like Mitch) a few apis that use (-1)=20
>>>> 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=3D 0; i < LIMIT; i++) type are of course=20
>> fine with unsigned i, arrays always use a zero base so in Rust the=20
>> only array index type is usize, i.e the largest supported unsigned=20
>> type in the system, typically the same as u64.
>=20
> Loop counters can usually be signed or unsigned, and it usually makes n=
o=20
> difference.=C2=A0 Array indices are also usually much the same signed o=
r=20
> unsigned, and it can feel more natural to use size_t here (an unsigned =

> type).=C2=A0 It can make a difference to efficiency, however.=C2=A0 On =
x86-64,=20
> this code is 3 instructions with T as "unsigned long int" or "long int"=
,=20
> 4 with "int", and 5 with "unsigned int".
>=20
> int foo(int * p, T x) {
>  =C2=A0=C2=A0=C2=A0 int a =3D p[x++];
>  =C2=A0=C2=A0=C2=A0 int b =3D p[x++];
>  =C2=A0=C2=A0=C2=A0 return a + b;
> }

;;  assume *p in rdi, x in rsi

   mov rax,[rdi+rsi]
   add rax,[rdi+rsi+8]
   ret

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

OK

>=20
>>
>> unsigned arithmetic is easier than signed integer arithmetic,=20
>> including comparisons that would result in a negative value, you just =

>> have to make the test before subtracting, instead of checking if the=20
>> result was negative.
>=20
> I can't follow that at all.=C2=A0 Unsigned and signed arithmetic and=20
> comparisons both work simply and as you'd expect.=C2=A0 /Mixing/ signed=
 and=20
> unsigned types can get things wrong.

Oh yeah!

>=20
>>
>> I.e I cannot easily replicate a downward loop that exits when the=20
>> counter become negative:
>>
>> =C2=A0=C3=82=C2=A0 for (int i =3D START; i >=3D 0; i-- ) {
>> =C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0 // Do something with data[i=
]
>> =C2=A0=C3=82=C2=A0 }
>>
>> One of my alternatives are
>>
>> =C2=A0=C3=82=C2=A0 unsigned u =3D start; // Cannot be less than zero
>> =C2=A0=C3=82=C2=A0 if (u) {
>> =C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0 u++;
>> =C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0 do {
>> =C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0 u--=
;
>> =C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0 dat=
a[u]...
>> =C2=A0=C3=82=C2=A0=C3=82=C2=A0=C3=82=C2=A0 while (u);
>> =C2=A0=C3=82=C2=A0 }
>>
>> This typically results in effectively the same asm code as the signed =

>> version, except for a bottom JGE (Jump (signed) Greater or Equal=20
>> instead of JA (Jump Above or Equal, but my version is far more verbose=
=2E
>>
>=20
> A more important thing is that the first version, with signed i, is=20
> /vastly/ simpler and clearer in the source code.
>=20
>> Alternatively, if you don't need all N bits of the unsigned type, then=
=20
>> you can subtract and check if the top bit is set in the result:
>>
>> =C2=A0=C3=82=C2=A0 for (unsigned u =3D start; (u & TOPBIT) =3D=3D 0; u=
--)
>>
>> Terje
>>
>=20
> Or you could just write sane code that matches what you want to say.
>=20
:-)

Terje

--=20
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"