Re: Computer architects leaving Intel...

On 9/6/2024 2:10 AM, David Brown wrote:

On 06/09/2024 00:51, BGB wrote:

On 9/5/2024 8:27 AM, David Brown wrote:

On 05/09/2024 10:51, Niklas Holsti wrote:

On 2024-09-05 10:54, David Brown wrote:

On 05/09/2024 02:56, MitchAlsup1 wrote:

On Thu, 5 Sep 2024 0:41:36 +0000, BGB wrote:
>

On 9/4/2024 3:59 PM, Scott Lurndal wrote:
>
Say:
   long z;
   int x, y;
   ...
   z=x*y;
Would auto-promote to long before the multiply.

>
\I may have to use this as an example of C allowing the programmer
to shoot himself in the foot; promotion or no promotion.

>
You snipped rather unfortunately here - it makes it look like this was code that Scott wrote, and you've removed essential context by BGB.
>
>
While I agree it is an example of the kind of code that people sometimes write when they don't understand C arithmetic, I don't think it is C-specific.  I can't think of any language off-hand where expressions are evaluated differently depending on types used further out in the expression.  Can you give any examples of languages where the equivalent code would either do the multiplication as "long", or give an error so that the programmer would be informed of their error?

>
>
The Ada language can work in both ways. If you just have:
>
    z : Long_Integer;  -- Not a standard Ada type, but often provided.
    x, y : Integer;
    ...
    z := x * y;
>
the compiler will inform you that the types in the assignment do not match: using the standard (predefined) operator "*", the product of two Integers gives an Integer, not a Long_Integer.

>
That seems like a safe choice.  C's implicit promotion of int to long int can be convenient, but convenience is sometimes at odds with safety.
>

>
A lot of time, implicit promotion will be the "safer" option than first doing an operation that overflows and then promoting.
>
Annoyingly, one can't really do the implicit promotion first and then promote afterwards, as there may be programs that actually rely on this particular bit of overflow behavior.
>

 A programming language has to work as it is defined.  And people should not be relying on code doing things that are /not/ defined.
 So promoting arguments implicitly before the operation is only useful if it is a clearly defined part of the language.  (In C, that is the way it works up to the size of "int".)
 In C, if you have :
      long int foo(int x, int y) {
         return z = x *y ;
     }
 then the compiler is free to implement this as full 64-bit multiplication and return that 64-bit value.  This is because the result of a 32 x 32 bit multiplication either gives the correct answer without overflow, and promoting it to 64 bit keeps that value, or there is an overflow and the results are undefined, so the compiler can return whatever it likes.
 But unless the compiler documents this behaviour (in which case the code would be correct but non-portable), the code is buggy.
 Conversely, if unsigned types are used here, the results of the multiplication must be truncated to 32 bits - keeping higher bits in the return value would be a compiler bug.
  However a language wants to handle this, it needs to be specified by the language.  Most languages (AFAIK) have no implicit promotion that is dependent on what you are doing with the results.  (Some, including C, will have various degrees of implicit promotion dependent solely on the expression itself, but not on what is done with the evaluated result.) Ada, AFAIK, does not have implicit promotions between types - "int" does not automatically promote to "long int".  This can be seen as an inconvenience compared to many other languages, but it means that it is possible to have a consistent and safe way to overload by return type.
 

In effect, in my case, the promotion behavior ends up needing to depend on the language-mode (it is either this or maybe internally split the operators into widening or non-widening variants, which are selected when translating the AST into the IR stage).
>

 Dependency on a "language mode" does not sound "safe" to me.
 

The language mode indicates what source language was compiled, say:
   C, BS, BS2,
   C++ (sorta), Java (sorta), C# (sorta).
Or, what "skin" was applied over the parser and front-end stages.
As-is, this information is basically lost by the time it hits the RIL3 IR, or the 3AC IR, where the backend doesn't know which source language was used.

Well, as opposed to dealing with the widening cases by emitting IR with an implicit casts added into the IR.
>
>