Re: Computer architects leaving Intel...

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
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"