Path: ...!npeer.as286.net!dummy01.as286.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 9 Sep 2024 00:51:24 -0500
Organization: A noiseless patient Spider
Lines: 122
Message-ID: <vbm2d2$2a4al$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me>
 <vb91e7$3o797$1@dont-email.me> <vb9eeh$3q993$1@dont-email.me>
 <vb9l7k$3r2c6$2@dont-email.me> <vba26l$3te44$1@dont-email.me>
 <vbag2s$3vhih$1@dont-email.me> <vS3CO.10106$kow1.6330@fx35.iad>
 <vbauo3$18sj$1@dont-email.me>
 <a2d65085c90f4d93f3d70df3121adc59@www.novabbs.org>
 <vbbo4g$8j04$2@dont-email.me> <ljt9okF86o3U1@mid.individual.net>
 <vbcbkj$bd22$2@dont-email.me> <vbdcmk$gug7$1@dont-email.me>
 <vbe9sc$nlm3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 09 Sep 2024 07:51:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="928d32c5bae13d8f357b884af2bb52a4";
	logging-data="2429269"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/iE+9nCP2PZ0GVCYWHeOW/8fVftHtnLOE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:mAJTdS5COlJgvsDiY23cPIs9shQ=
Content-Language: en-US
In-Reply-To: <vbe9sc$nlm3$1@dont-email.me>
Bytes: 6855

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.
>>
>>
>