Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Thu, 5 Sep 2024 19:10:14 +0100
Organization: A noiseless patient Spider
Lines: 105
Message-ID: <vbcs65$eabn$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <vai1ec$2fns2$1@dont-email.me>
 <874j75zftu.fsf@bsb.me.uk> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 05 Sep 2024 20:10:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1134213a6b4dc156fe912d61e74dfa43";
	logging-data="469367"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19FqQ01cX2JJ0BmzUQKC8k5"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MRqzVtU4HeYJOjlamouW6oDsanw=
In-Reply-To: <vbci8r$1c9e8$1@paganini.bofh.team>
Content-Language: en-GB
Bytes: 5637

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.

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.

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.)

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.



>  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.

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.


> 
> 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 said this was a definining characteristic of HLLs, but which BLISS 
does not have, or has it lop-sidedly: you need the explicit dereference 
in an rvalue context, but not an lvalue one, like RHS and LHS of an 
assignment. I considered that assymetric, but most who took part decided 
that that was made it symmetric!