Re: Computer architects leaving Intel...

On Tue, 17 Sep 2024 11:48:12 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

David Brown wrote:

On 17/09/2024 08:07, Terje Mathisen wrote: 

David Brown wrote: 

On 16/09/2024 10:37, Terje Mathisen wrote: 

This becomes much simpler in Rust where usize is the only legal
index type:
>
Yeah, you have to actually write it as
>
 Â  y = p[x];
 Â  x += 1;
>
instead of a single line, but this makes zero difference to the
compiler, right?
 

>
I don't care much about the compiler - but I don't think this is
an improvement for the programmer.  (In general, I dislike
trying to do too much in a single expression or statement, but
some C constructs are common enough that I am happy with them.Â
It would be hard to formulate concrete rules here.)
>
And the resulting object code is less efficient than you get with
signed int and "y = p[x++];" (or "y = p[x]; x++;") in C. 

>
Is that true? I'll have to check godbolt myself if that is really
the case!
 

 
It is not true - or at least, it shouldn't be true.  I had thought
the Rust code was using the equivalent of a C "unsigned int" here,
which would require extra code for wrapping semantics.  But that
was just my misunderstanding of Rust and its types - with a 64-bit
unsigned type, it should give the same results as C.  However,
there's no harm in checking it and letting us know. 

 
No need to check this particular point, Rust's usize was obviously
designed to be an unsigned type large enough to index into the entire
addressable memory range, so on a 64-bit platform it has to be 64
bits.

 
(I've previously shown how "y = p[x++];" in C is less efficient on
x86-64 if x is "unsigned int", compared to "int" or 64-bit types
for x.)

That's actually surprising to me, I would have guessed any 32-bit
index would be less efficient than a full-width type, but if the
idionm is very, very common in C code, then it makes sense to make it
fast.
 
Doing so would typically require either sign- or zero-extending all
32-bit variables when loaded into a 64-bit register, right?
 
Terje
 

Taken in isolation, on something like x86=64 or aarch64, where result
of 32-bit addition is by default zero-extended, there is no difference
between 32-bit and 64-bit unsigned x.
However when statement shown above is part of the sequence, even short
one, 64-bit x allows compiler optimizations that are impossible with
32-bit.
E.g.
y1 = p[x++]
y2 = p[x++]

On x86-64 with 64-bit x the second load can be implemented as
mov dstreg, [rcx+rdx*4+4]
On aarch64 with 64-bit x both loads can be folded into single 'load
pair' instruction.