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

Bart <bc@freeuk.com> wrote:

On 06/09/2024 11:19, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

 

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.

 
If you have to use a function, yes. Because you've introduced an
artificial split in Where and When those dereferences are done.

Well, this is natural if you want simple semantics.  As result of
parsing you ge a parse tree (it does not matter if parse tree
exists as a real data structure or is just a conceptual thing).
To get meaning of an expression you get meanings of arguments,
which conceptually is simple recursion (pragmaticaly compiler
may work in bottom-up way) and then you get meaning of whole
expression by applying operator at the top to meanings of the
subtrees.  Point is that once you got meaning of a subtree
it does not change, so you can throw out source subtree.
In terms of code generation you can immediately generate
code and there is no need to change it after it is generated
(no need to turn read opcodes into writes).

With A=B they can be done at about the same time and the same place.
 
With ASSIGN(), the B dereference is done at the call-site; the A
deference is done inside ASSIGN(), so you are obliged to pass an
explicit reference to A. While B has already been dereferenced and you
have its value to pass.
 
(You can balance it out by by requiring ASSIGN(&A, &B)!)

This would not work in general, as I wrote it, the following are
valid:

assign(&a, 42)
assign(&a, a + 1)

but the second argument has no address, so your variant would not
work.

As I wrote, implementing this leads to very simple compiler, that
is why Forth uses that way.  In optimizing compiler you want to
allocate variables into registers, and for this you need to get
rid of addresses (when you use variable address variable can not
be in register (some machines have/had addressable registers,
but even if you can address registers this usually leads to
slow code)).  So probably using read/write variable accesses
leads to overall simpler compiler (with more complex front end,
but simpler optimizer).  I have read that DEC had highly optimizing
Bliss compiler, I am not sure it this was due to Bliss features
or despite Bliss features.

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.

 
Here is A:=B from my HLLs in one of my ILs (intermediate language):
 
    load  B
    store A
 
That was stack-based; here it is in 3-address-code IL:
 
    a := b         # more formally, 'move a, b'
 
This is it in dynamic byte-code:
 
    push B
    pop  A
 
In every case, both A and B operands have the same rank and the same
levels of indirection.

You can use stack machines to get reasonably simple definition of
semantics.  But still slightly more complex than what I outlined
above.  And code for stack machines is unpleasent to optimize.
In a compiler for a language where official semantics is stack
based the first things that compiler does is to track few items
on top of the stack and match them to sequences like

push a
push b
call op

Once sequence is matched it is replaced by corresonding operation
on variables.  If this matching works well you get conventional
(non-stack) intermediate representaion and reasonably good code.
If matching fails, the resulting object code wastes time on stack
operations.

Of course, if you don not minds slowdowns due to stack use, then
stack machine leads to very simple implemantaion.  Best Forth compilers
have sophisticated code to track stack use and replace it by
use of registers.  Other Forth compilers just accept slowness.

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

 
This has been covered. The syntactical symmetry is that whatever you
have on the LHS, you can write the same thing on the RHS:
 
    A[i+1].m = A[i+1].m
 
Obviously, you can have RHS terms that cannot appear on the left, like
'42', but that's usually due to separate constraints of the language.

Well, logically you can not change value of a number, so you can
not assign to a number, that is very fundamental.  You could
try to define

x + 1 = y

as solving equation for x, that quickly runs into trouble due to
equations which are no solutions or multiple solutions.  And solving
frequently is a complex process, not suitable as basic operation.
OK, if you trurly insist on symmetry, than Prolog unification
is symmetric, here information can flow in both directions.
But unification is quite different than assigment.

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

 
Why don't you need to compute the address of B?

Well, B may have no address.  In case when B is variable computing
its address is part of computation of its value.  In general,
computing value of B need computing addresses of all variables
contained in B.

Why don't you need to
load the value of B?

"compute value" means putting result in place which is available
to subsequent operations, so logically no extra load is needed.
And for variables "compute value" includes loading them.

It is more like this:
 
  compute address of B
  load value of B via that address to some temporary location
  compute address of A
  store new value of A via that address

The point is that last part (that is store instruction) logically
does not change when you vary A and B.  Only this part corresponds to
assignment.  The first to lines logically form a whole, that
is "compute B".  And when you vary B you may get quite different split
of "compute B" into part.  Moreover, logically "compute value of B"
and "compute address of A" are completely independent.
 

The only asymmetry in all my examples has been between Load/Store;
Push/Pop; or positional as in Left/Right.
 
The mechanism for EITHER reading or writing the value of an object via
its reference is the same; only the direction of data movement is the
parameter.

In more complex case mechanism may differ.  Pascal compiler may
wish to check that variables are in declared range.  On read it
is consequence of type correctness, so no need for extra instructions.
But writes usually need checking (optimizer may be smart enough to
infer that assigned value is in range, but in general there is
need for actual checking code).  Read access may more complex
than simple load instruction.  I actually run into problem of
this sort in GNU Pascal.  Read access was not entirely trivial
piece of intermediate representation and compiler tried to pattern
match it to find out what it was reading and turn it into write
access.  But intermediate representation was transformed between
creation and write.  For some time there was kind of whack-a-mole
game: new transformations were introduced which broke the compiler
and were fixed by better pattern.  I resolved the problem by
creating special intermediate representation which was immune
to transformations, so simple pattern always worked.  But there
was a cost, this intermetiate representation had to be expanded
(and transformed) in other places.

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.

 
In my PUSH B example from interpreted code, it will read B from memory,
and write it to a stack (also in memory). POP A will read from the
stack, and write to memory.
 
So both operations are really memory-to-memory.

Stack does not change here anything compared to load/store pair,
this looks symmetric due to fusing two parts of logically three
step process into single intruction.  Like above, varying A and
B will show actual parts.

 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.

 
I've done this stuff at the chip level (writing into an 8-bit latch for
example, then reading from it); it's going to take a lot to convince me
that this is anything much different from a read/write or direction flag!

Chips got more complicated, but this in not relevant to the problem.
Of course, logically there is symmetry between read and write.  At
lower level, reading a bit string from memory beside load needs
some masking and shifting.  For write, one needs to read unmodified
part first, paste in new thing and write back.  So there are
differences, but they are irrelevant to the problem, what I wrote
applies in case when there is symmetry between read and write
instructions.

In more complicated cases in languages, then some asymmetry does come
up. For example, suppose C allowed this (my language allows the equivalent):
 
   (c ? a : b) = x;
 
So this assigns to either a or b depending on c. My implementation
effectively turns it into this:
 
   *(c ? &a : &b) = x;
 
So using explicit references and derefs. However, that is internal. The
symmetry still exists in the syntax:
 
   (c ? a : b) = (c ? a : b);

As noticed, people prefer symmetric notation, so most languages
make it "symmetric looking".  But if you dig deeper there is
fundametal asymetry.

--
                              Waldek Hebisch