Re: Computer architects leaving Intel...

On Mon, 16 Sep 2024 14:48:50 +0200
David Brown <david.brown@hesbynett.no> wrote:

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

David Brown wrote: 

On 14/09/2024 21:26, Thomas Koenig wrote: 

MitchAlsup1 <mitchalsup@aol.com> schrieb:
 

In many cases int is slower now than long -- which violates the
notion of int from K&R days. 

>
That's a designers's choice, I think.  It is possible to add
32-bit instructions which should be as fast (or possibly faster)
than 64-bit instructions, as AMD64 and ARM have shown.
 

>
For some kinds of instructions, that's true - for others, it's not
so easy without either making rather complicated instructions or
having assembly instructions with undefined behaviour (imagine the
terror that would bring to some people!).
>
A classic example would be for "y = p[x++];" in a loop.  For a
64-bit type x, you would set up one register once with "p + x",
and then have a load with post-increment instruction in the loop.
You can also do that with x as a 32-bit int, unless you are of the
opinion that enough apples added to a pile should give a negative
number of apples.  But with a wrapping type for x - such as
unsigned int in C or modulo types in Ada, you have little choice
but to hold "p" and "x" separately in registers, add them for
every load, and do the increment and modulo operation.  I really
can't see this all being handled by a single instruction. 

 
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.
 
 
 

It's not less efficient. usize in Rust is approximately the same as
size_t in C. With one exception that usize overflow panics under debug
build.