Re: Computer architects leaving Intel...

On 16/09/2024 15:04, Michael S wrote:

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.

Ah, okay - I was thinking of it as a C unsigned int.

With one exception that usize overflow panics under debug
build.
 

I'm quite happy with unsigned types that are not allowed to overflow, as long as there is some other way to get efficient wrapping on the rare occasions when you need it.
But I am completely against the idea that you have different defined semantics for different builds.  Run-time errors in a debug/test build and undefined behaviour in release mode is fine - defining the behaviour of overflow in release mode (other than possibly to the same run-time checking) is wrong.