Liste des Groupes | Revenir à c arch |
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.
Les messages affichés proviennent d'usenet.