Re: Computer architects leaving Intel...

On 9/4/2024 3:59 PM, Scott Lurndal wrote:

Brett <ggtgp@yahoo.com> writes:

David Brown <david.brown@hesbynett.no> wrote:

On 04/09/2024 14:53, jseigh wrote:

On 9/4/24 06:57, David Brown wrote:

On 04/09/2024 09:15, Terje Mathisen wrote:

David Brown wrote:

>

Maybe?
>
Rust will _always_ check for such overflow in debug builds, then when
you've determined that they don't occur, the release build falls back
standard CPU behavior, i.e. wrapping around with no panics.

>
But if you've determined that they do not occur (during debugging),
then your code never makes use of the results of an overflow - thus
why is it defined behaviour?  It makes no sense.  The only time when
you would actually see wrapping in final code is if you hadn't tested
it properly, and then you can be pretty confident that the whole thing
will end in tears when signs change unexpectedly.  It would be much
more sensible to leave signed overflow undefined, and let the compiler
optimise on that basis.
>

>
You absolutely do want defined behavior on overflow.

>
No, you absolutely do /not/ want that - for the vast majority of use-cases.
>
There are times when you want wrapping behaviour, yes.  More generally,
you want modulo arithmetic rather than a model of mathematical integer
arithmetic.  But those cases are rare, and in C they are easily handled
using unsigned integers.

>
I tried using unsigned for a bunch of my data types that should never go
negative, but every time I would have to compare them with an int somewhere
and that would cause a compiler warning, because the goal was to also
remove unsafe code.

 We use it exclusively for datatypes in the domain [0, 2**n).  It's always
compared against other unsigned variables or constants.   Works quite well.
Safer and cleaner than willy-nilly using int.
 This is in a multi-million line C++ application.
 

FWIW: To me, promoting signed and unsigned of the same size to an unsigned type of that size seemed a bit suspect.
In my own BS2 language, these cases would tend to promote to the next larger signed type. Say, comparing 'int' and 'uint' would first promote to 'long', and 'long' with 'ulong' would promote to 'int128' (int128 didn't promote further, as it was the largest integer type).
Though, the type-system did differ from C in that in many cases it would also often take the destination type into account for type-promotion (partly also using inward type propagation rather than strictly outward).
Say:
   long z;
   int x, y;
   ...
   z=x*y;
Would auto-promote to long before the multiply.
Whereas "C tradition" holds that the value remain as int, potentially overflow (giving a wrapping value), and then get converted to 'long'.
But, integer overflow edge cases can effect some amount of software (mostly the same software that is prone to break if one doesn't give "-fwrapv" and similar with GCC).
So, for example, everything smaller than 'int' quietly promotes to 'int', but 'int' may not quietly promote to long, as some software will break.
To a more limited extent, one can do similar in C, but mostly to limit cases where C rules would normally require promoting to "double" only to immediately truncate to float.
   float x, y;
   ...
   y=x+1.5;
A strict interpretation would promote to double only to immediately truncate, but it may be cheaper to just sort of treat it as-if the programmer had written:
   y=x+1.5f;
...

>
Complete and udder disaster, went back to plain sized ints.

 s/udder/utter/
 

This distinction seems MOOOt...
But sometimes you need to milk these things for all they are worth.