Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: how cast works?
Date: Fri, 09 Aug 2024 14:53:01 -0700
Organization: None to speak of
Lines: 128
Message-ID: <87r0ax5poi.fsf@nosuchdomain.example.com>
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>
	<v9602l$60n0$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 Aug 2024 23:53:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="153d1bcdb0929153f62e0b2f2aa4005b";
	logging-data="212067"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+TFZVKHkKfxkB3wWyZpDMB"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:n1pUXcIrYMSjFTUfKSV7i/UbOE0=
	sha1:QNY98WbUD40F8zYZTO7wPDcXD54=
Bytes: 6419

Thiago Adams <thiago.adams@gmail.com> writes:
> 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.

I don't see how that makes sense.  Not all CPUs have registers.  For
CPUs that do have registers, some support operations directly on memory.
Register size does not constrain the set of operations that are
available; for example a CPU might have 64-bit registers and support
both 64-bit and 32-bit operations.

Registers are largely irrelevant.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */