On 06/02/18 03:53, Paul Raulerson wrote:
z/OS as the epitome of a portable OS? HLASM more portable that C?
Does anyone really buy into that? I assumed it was a just leg
pulling… :)
:-) Here is another gem from Jon:
2. I don't see a difference in using MVC A,B and MEMCPY(A,B,SIZEOF(A))
Just a few of the differences:
(1) MVC can only handle sizes of 1 to 256 bytes,
memcpy can handle any size from zero upwards;
(2) MVC processes overlapping data areas in a specified way:
allowing you to fill an area of memory with a single byte.
memcpy is undefined when the areas overlap (C has memmove
to correctly handle overlapping areas and memset to fill
a memory area with a byte);
(3) memcpy can handle variable length moves, MVC requires
an EXecute or self-modifying code to change the length
of the move at runtime.
This point illustrates what I mean about assembler,
and to a lesser extent C, forcing the programmer
to think at a very low level. There are several
machine code instructions for copying data from
one memory location to another: MVC, MVCL, MVCLE etc.
Which instruction should you use? Is MVC more
efficient than MVCL? If so, at what point does
a loop of MVC instructions become less efficient
than MVCL or MVCLE? Should you use Duff's device
to unroll the loop of MVC instructions? Etc. etc.
All the above could be handled by a generic MOVE
macro which does the calculations and generates
the most efficient sequence of instructions
in each case. But hardly any assembler programmers
use such a macro (as I know from analysing millions
of lines of assembler code).
The C programmer can just write memcpy (if they know
for certain that the areas will not overlap),
or memmove, and leave the compiler to generate
the most efficient code sequence in each case.
In a higher level language you just write:
A := B
and the compiler handles allocating memory,
sharing sub-structures between A and B to avoid copying,
freeing the memory used by whatever was in A before
(if it is no longer needed), and so on, leaving the programmer
to treat A and B as variables holding values in an
abstract data type.
--
Martin
Dr Martin Ward | Email: [email protected] | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
