Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 9 Sep 2024 15:21:27 +0300
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <20240909152127.00006e6f@yahoo.com>
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>
	<vbm67e$2apse$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 09 Sep 2024 14:21:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="45fff2496b15112b5e4e03cadfa28742";
	logging-data="2041887"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Y7w1b7XvO+czVs3A+Tz8LS7XBb2Eu0W4="
Cancel-Lock: sha1:McFJk9eDq9mpsHOAyX6O557hKg4=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4222

On Mon, 9 Sep 2024 08:56:45 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> David Brown wrote:
> > On 05/09/2024 19:04, Terje Mathisen wrote: =20
> >> David Brown wrote: =20
> >>> On 05/09/2024 11:12, Terje Mathisen wrote: =20
> >>>> David Brown wrote: =20
> >>>>> 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. =20
> >>>>
> >>>> 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.=20
> >>>
> >>> You don't have loop counters, array indices, or integer
> >>> arithmetic? =20
> >>
> >> 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
> >=20
> > Loop counters can usually be signed or unsigned, and it usually
> > makes no difference.=C2=A0 Array indices are also usually much the same
> > signed or 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, this code is 3 instructions with T as
> > "unsigned long int" or "long int", 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;
> > } =20
>=20
> ;;  assume *p in rdi, x in rsi
>=20
>    mov rax,[rdi+rsi]
>    add rax,[rdi+rsi+8]
>    ret
>=20

more like
   mov rax,[rdi+rsi*4]
   add rax,[rdi+rsi*4+8]
   ret

But that's not the point (=3D=3Dtrap).
The point (=3D=3Dtrap), I'd guess, is that for T=3Duint32_t code generator
has to account for possibility of x=3D=3D2**32-1.