Re: Top 10 most common hard skills listed on resumes...

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