Path: ...!3.eu.feeder.erje.net!feeder.erje.net!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 16:05:21 -0300
Organization: A noiseless patient Spider
Lines: 150
Message-ID: <v95p9h$2oa92$2@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>
 <v95okr$2oa92$1@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 21:05:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="358699822bb9c263f3cfeb8ab794a410";
	logging-data="2894114"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+drDkBOIB7cTjcYmEhOa6iGfnmeZ/sAKY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:bOHM8d4Q49WgMKjLXZblDFpbqcA=
In-Reply-To: <v95okr$2oa92$1@dont-email.me>
Content-Language: en-GB
Bytes: 6558

Em 8/9/2024 3:54 PM, Thiago Adams escreveu:
> 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?
> 
> 
> 
> 


and I am still curious if _Bool/bool makes the programs slower (more 
instructions) compared with
"typedef int bool" because the generated code has to convert bool->int 
int->bool all the time.