Re: Computer architects leaving Intel...

On 2024-09-16 10:25, Thomas Koenig wrote:

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:

If the loop variable
represents degrees C or F, or some other naturally signed measure it
should be signed (or maybe floating point).

 The first one is a bad idea because temperature is a continuous
physical quantity.
 The second has bad implications for constructs like
        DO R = 0.0, 1.0, 0.1
 where it will depend on details floating point arithmetic if the
number of loop trips is 10 or 11.
 You can argue that people can write
        DO R=0.0, 1.05, 0.1
 but this construct was error-prone enough that it was deleted
from the Fortran standards.
 

What kind of loop it
is, whether ascending or descending, or what the increment is, etc,
is secondary;  a more important factor is what sort of value is
being represented, and in almost all cases that is what should
determine the type used.

 Not for floating point numbers.  For that, you should simply do
        DO I=0,10
         R = I * 0.1
 or
        R = 0.0
       DO I=0,10
...
         R = R + 0.1
       END DO
 whichever rounding error you prefer.
 

Bringing it back to "architecture" Like Anton Ertl has said, LP64 for
C/C++ is a mistake.  It should always have been ILP64, and this nonsense
would go away.  Any new architecture should make C ILP64 (looking at you
RISC-V, missing yet another opportunity to not make the same mistakes as
everyone else).

>
I believe this view is shortsighted.  The big mistake is developers
hardcoding types everywhere - especially int, but also long, and
their unsigned variants.  It's almost never a good idea to hardcode
a specific width (eg, uint32_t) in a type name used for parameters
or local variables, but that is by far a very common practice.

I agree. This issue guided the design of the scalar type system in Ada.
C programmers can use typedef to get part way there, but not all the way because typedefs are still weakly typed.

Hence Fortran's SELECTED_REAL_KIND and SELECTED_INT_KIND...

And the way Ada programmers can define application-specific types with the ranges and precisions the application needs.