Re: Computer architects leaving Intel...

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.