Path: ...!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: Waldek Hebisch <antispam@fricas.org>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Fri, 6 Sep 2024 10:19:11 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vbekut$1kd24$1@paganini.bofh.team>
References: <vab101$3er$1@reader1.panix.com>   <valrj7$367a8$2@dont-email.me> <87mskwy9t1.fsf@bsb.me.uk> <vanq4h$3iieb$1@dont-email.me> <875xrkxlgo.fsf@bsb.me.uk> <vapitn$3u1ub$1@dont-email.me> <87o75bwlp8.fsf@bsb.me.uk> <vaps06$3vg8l$1@dont-email.me> <871q27weeh.fsf@bsb.me.uk> <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk> <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk> <vaq9tu$1te8$1@dont-email.me> <vbci8r$1c9e8$1@paganini.bofh.team> <vbcs65$eabn$1@dont-email.me>
Injection-Date: Fri, 6 Sep 2024 10:19:11 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="1717316"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 8365
Lines: 174

Bart <bc@freeuk.com> wrote:
> On 05/09/2024 16:21, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>>
>>> So what exactly is different about the LHS and RHS here:
>>>
>>>     A = A;
>>>
>>> (In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A' is
>>> also valid, there is a hidden mismatch in indirection levels between
>>> left and right. It is asymmetric while in C it is symmetric, although
>>> seem to disagree on that latter point.)
>> 
>> You seem to miss the point that assigment operator is fundamentally
>> assymetic.
> 
> If you've followed the subthread then you will know that nobody disputes 
> that assignment reads from side of '=' and writes to the other.

I dispute this and I think that to same degree several other folks too.
Assgmenet _does not read_, it "only" writes.  Assigment get two
parameters which are treated in different way.  Imagine that you
are programming in a language like C, but are forbidden to use
assignment operator.  But fortunately you have C "function"
'assign' with prototype:

void assign(int * p, int v);

Instead of writing

    A = B

you need to write

    assign(&A, B)

Of course, in real life nobody is going to force you to anything,
but except for fact that in C assignment has value the 'assign'
function is doing the same thing as '=' operator.  And you can
see that it is asymetric: first agrument is an addres and right
is a value.

> The symmetry is to do with syntax when the same term appears on both 
> sides of '=', the type associated with each side, and, typically, the 
> internal representations too.

Simple compiler after parsing does not need "operators" at all.
You have parse tree where instead of "operators" are function
calls (of course you still need control structures).  Code
generator has table and if function to be called is in the table,
than it emits corresponding instruction(s), otherwise it emits
real call.  For assignment table simply will contain store
instruction.

> Clearly the '=' operation is not reversible (or cummutative), as binary 
> '+' might be, but not binary '-'. That is not what I'm claiming.
> 
>>  This is quite visible at low level, where typical
>> machine has 'store' instruction.  Store takes address (memory location)
>> as left argument, but a _value_ as right argument.  Your example
>> introdices fake symmetry, you ealuate right hand side using
>> a load ant this may look symmetric with store.
> 
> Low level can reveal symmetry too. If 'A' is stored in a register 'Ra', 
> then copying A to itself can be done like this on x64:
> 
>     mov Ra, Ra
> 
> (Whether data movement is RTL or LTR depends on the assembly syntax, but 
> in this example it doesn't matter.)

That is _very_ special case and for this reason misleading.

> If A is in memory then it could be the same on 2-address architectures:
> 
>     mov [A], [A]
> 
> but more typically it needs two instructions (here using RTL):
> 
>    mov R, [A]
>    mov [A], R
> 
> Here, [A] appears in both instructions, it means the same thing, and 
> refers to the same location. Only the position (left vs. right operand, 
> exactly the same as in A = A) tells you if it's reading or writing.
 
You somewhat miss fact that "A = B" has 3 parts, that is "A", "=", and "B".
The second 'mov' instruction came from "=", the first 'mov' is extra.
So instructions look symmetric, but clearly assigment part is asumetric.

> 
>>  But even here
>> there is asymetry, which is better visible with naive compiler.
>> You may get code like
>> 
>>     compute addres of A
>>     load
>>     compute address of A
>>     store
>> 
>> The last step implement '=', the second 'compute address' corresponds
>> to A on the left had side.  First 'compute address' corresponds to
>> A on the right hand side.  Now you see that beside address computation
>> there is also load corresponding to A on the right hand side.
> 
> 
>> So clearly in most languages treatment of sides is assymetric:
>> extra loads are inserted due to 'lvalue convertion'.
> 
> There is a Load on one operand and a balancing Store on the other. Two 
> loads or two stores would not make sense here.

Again: only store comes from assignment.  This is clearly visible
if instead of misleading "A = A" you take "A = B" and replace
'B' by various things.  Assigment part (store instruction) stays
the same, compution of value changes.  In

A = c  + d

you get two load (for c and d) and then addition.  To put it
differently, you have

compute value of B
compute address of A
store

the "compute value of B" may be as trivial as putting constant
as part of store instruction, it may be load as in your case,
it may be compute value of some complex expression.  Similarly,
"compute address of A" part can trivialize when 'A' is in
machine register, sligtly less trivial address of 'A' may be
constant put into store instruction, 'A' may a local variable
at some offset from stack, then again many machine can do this
as part of address calculation in store instruction.  But 'A'
may be more compilcated and then you need real computaion and
extra instructions.

Anyway, only store instruction corresponds to assigment operator
proper, 'A' and 'B' just compute parameters for assigment.

> If you want to go to a lower level, look at how a simple microprocessor 
> works. It will generate a /WR signal on memory accesses that tells a RAM 
> device whether to use the data bus as input or output.
> 
> Note that Load and Store can also be considered symmetric: each Load 
> reads data from somewhere and writes it somewhere else. Just like Store 
> does. So some instruction sets use the same mnemonic for both.

Concerning instruction, sure.  But load is not an assignment.
It may look so in simple misleading cases.  But even if 'A' is
allocated to register and you translate whole "A = B" to single
load, the load computes value of 'B' and if the result is in
correct register the assigment proper can be optimised to no
operation.

>> 
>> To put in more general context: early success of C was related
>> to exposing address computations, so that programmers could
>> do optimization by hand (and consequently non-optimizing compiler
>> could produce reasonably fast object code).  This has a cost:
>> need for explicit point dereferences not needed in other langiages.
>> Bliss went slightly further and requires explicit derefernces
>> to get values of variables.  My point is that this is logical
>> regardless if you like it or not.
> 
> And /my/ point was that in virtually every HLL, that dereference to turn 
> a variable's address, denoted by its name, into either a read or write 
> access of its value, is implicit.

I partially agree.  Normal case is that write access is explicit
(for example via '=' in C) and it simly takes variable address.  Only
read access in implicit.

-- 
                              Waldek Hebisch