| Deutsch English Français Italiano |
|
<v95okr$2oa92$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Thiago Adams <thiago.adams@gmail.com> Newsgroups: comp.lang.c Subject: Re: how cast works? Date: Fri, 9 Aug 2024 15:54:19 -0300 Organization: A noiseless patient Spider Lines: 134 Message-ID: <v95okr$2oa92$1@dont-email.me> References: <v8vlo9$2oc1v$1@dont-email.me> <slrnvb7kis.28a.dan@djph.net> <v929ah$3u7l7$1@dont-email.me> <87ttfu94yv.fsf@nosuchdomain.example.com> <v93a3t$6q7v$1@dont-email.me> <v93e2q$8put$1@dont-email.me> <v94smd$mgp8$1@dont-email.me> <v95j4r$qh1q$3@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 09 Aug 2024 20:54:20 +0200 (CEST) Injection-Info: dont-email.me; posting-host="358699822bb9c263f3cfeb8ab794a410"; logging-data="2894114"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18tlzJEL08ai6TYRr8mEoUvuyJGgdDvtMc=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:KXPqIKvIOGhiYkOopTy9mE2jxIo= Content-Language: en-GB In-Reply-To: <v95j4r$qh1q$3@dont-email.me> Bytes: 6056 Em 8/9/2024 2:20 PM, David Brown escreveu: > On 09/08/2024 12:57, Thiago Adams wrote: >> Em 8/8/2024 6:41 PM, Bart escreveu: >>> On 08/08/2024 21:34, Thiago Adams wrote: >>>> On 08/08/2024 16:42, Keith Thompson wrote: >>>>> Thiago Adams <thiago.adams@gmail.com> writes: >>>>>> On 07/08/2024 17:00, Dan Purgert wrote: >>>>>>> On 2024-08-07, Thiago Adams wrote: >>>>> [...] >>>>>>>> How about floating point? >>>>>>> Floating point is a huge mess, and has a few variations for >>>>>>> encoding; >>>>>>> though I think most C implementations use the one from the IEEE >>>>>>> on 1985 >>>>>>> (uh, IEEE754, I think?) >>>>>> >>>>>> I didn't specify properly , but my question was more about floating >>>>>> point registers. I think in this case they have specialized >>>>>> registers. >>>>> >>>>> Who is "they"? >>>>> >>>>> Some CPUs have floating-point registers, some don't. C says nothing >>>>> about registers. >>>>> >>>>> What exactly is your question? Is it not already answered by reading >>>>> the "Conversions" section of the C standard? >>>>> >>>> >>>> >>>> This part is related with the previous question about the origins of >>>> integer promotions. >>>> >>>> We don't have "char" register or signed/unsigned register. But I >>>> believe we may have double and float registers. So float does not >>>> need to be converted to double. >>>> >>>> There is no specif question here, just trying to understand the >>>> rationally behind the conversions rules. >>> >>> The rules have little to do with concrete machines with registers. >>> >>> Your initial post showed come confusion about how conversions work. >>> They are not performed 'in-place', any more than writing `a + 1` >>> changes the value of `a`. >>> >>> Take: >>> >>> int a; double x; >>> >>> x = (double)a; >>> >>> The cast is implicit here but I've written it out to make it clear. >>> My C compiler produces intermediate code like this before converting >>> it to native code: >>> >>> push x r64 # r64 means float64 >>> fix r64 -> i32 >>> pop a i32 >>> >>> I could choose to interprete this code just as it is. Then, in this >>> execution model, there are no registers at all, only a stack that can >>> hold data of any type. >>> >>> The 'fix' instruction pops the double value from the stack, converts >>> it to int (which involves changing both the bit-pattern, and the >>> bit-width), and pushes it back onto the stack. >>> >>> Registers come into it when running it directly on a real machine. >>> But you seem more concerned with safety and correctness than >>> performance, so there's probably no real need to look at actual >>> generated native code. >>> >>> That'll just be confusing (especially if you follow the advice to >>> generate only optimised code). >>> >>> >>> >>> >> This part was always clear to me: >> >> "They are not performed 'in-place', any more than writing `a + 1` >> changes the value of `a`." >> >> Lets take double to int. >> >> In this case the bits of double needs to be reinterpreted (copied to) >> int. >> >> So the answer "how it works" can be >> >> always/generally machine has a instruction to do this >> >> or.. this is defined by the IIE ... standard as ... >> >> > > It would be helpful if you made more of an effort to write clearly here. > (We know you can do so when you want to.) It is very difficult to > follow what you are referring to here - what is "this case" here? A > conversion from a double to an int certainly does not re-interpret or > copy bits - like other conversions, it copies the /value/ to the best > possible extent given the limitations of the types. > Everything is a bit mixed up, but I'll try to explain the part about registers that I have in mind. In C, when you have an expression like char + char, each char is promoted to int. The computation then occurs as int + int. On the other hand, when you have float + float, it remains as float + float. My guess for this design is that computations involving char are done using registers that are the size of an int. But, float + float is not promoted to double, so I assume that the computer has specific float registers or similar operation instructions for float. Regarding the part about signed/unsigned registers and operations, I must admit that I'm not sure. I was planning to check on Compiler Explorer, but I haven't done that yet. I can frame the question like this: Does the computer make a distinction when adding signed versus unsigned integers? Are there specific assembly instructions for signed versus unsigned operations, covering all possible combinations?