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 18:01:09 -0300
Organization: A noiseless patient Spider
Lines: 207
Message-ID: <v9602l$60n0$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>
 <v95okr$2oa92$1@dont-email.me> <87ikw9788w.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 Aug 2024 23:01:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="358699822bb9c263f3cfeb8ab794a410";
	logging-data="197344"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/XHz6FVTntN9V9poaRB3B6Gu4xgg4xQtM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:G/kGUpYSCJqpGMSiYspC+1/CDAA=
In-Reply-To: <87ikw9788w.fsf@nosuchdomain.example.com>
Content-Language: en-GB
Bytes: 9732

Em 8/9/2024 5:26 PM, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> 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.
> 
> Why you keep talking about registers?  The C standard does not talk
> about registers, and the promotion rules are based on which *operations*
> are available, not what kinds of registers a given CPU happens to have.
> 

I use "register" to talk about how hardware works.

>> In C, when you have an expression like char + char, each char is
>> promoted to int. The computation then occurs as int + int.
> 
> Right.  And the most important thing to keep in mind is that it works
> that way *because the C standard says so*.
> 
> If you're looking for a rationale for this, it's probably because some
> early C compilers were for target systems that didn't provide operations
> on narrow types.  (The PDP-11 does have instructions that operate on
> 8-bit bytes, but the arithmetic instructions operate only on 16-bit
> words.)  But the C standard rules apply to all conforming C
> implementations.  If a target CPU happens to provide a 1-byte add
> instruction, a C compiler can't use it unless it can prove that the
> result is consistent with C semantics.
> 
> Knowing why the C standard says what it says can be interesting, but
> it's not necessarily directly useful.
> 
>> On the other hand, when you have float + float, it remains as float + float.
> 
> That's implementation-defined.  Read the "Characteristics of floating
> types <float.h>" section of the C standard (it's 5.2.5.3.3 in the N3220
> draft) and look for FLT_EVAL_METHOD.  If FLT_EVAL_METHOD (defined in
> <float.h>) is 0, float operations are done in type float.  If it's 1,
> float operations are done in type double.  If it's 2, all floating-point
> operations are done in type long double.
> 
>> My guess for this design is that computations involving char are done
>> using registers that are the size of an int.
> 
> Who says the target CPU even has registers, or that computations can't
> be done directly on values in memory?
> 
>> But, float + float is not promoted to double, so I assume that the
>> computer has specific float registers or similar operation
>> instructions for float.
> 
> Again, some CPUs have floating-point registers and some do not.  Those
> that don't might store floating-point values in the same registers used
> for integer values, applying different instructions to operate on them.
> Of those that do have floating-point registers, some have registers that
> can hold a double value (typically 64 bits); they may or may not be able
> to treat a half-register as a 32-bot float value.
> 
> The rules in the C standard are, for the most part, based on the
> capabilities of CPUs that existed when the standard was written, not
> necessarily on modern CPUs (though there have been tweaks in later
> editions).
> 
>> 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?
> 
> Maybe.
========== REMAINDER OF ARTICLE TRUNCATED ==========