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 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: References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <505954890d8461c1f4082b1beecd453c@www.novabbs.org> 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: 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. >> >> >