🚀 go-pugleaf

I can't speak to the various claims of the author about coding of a single
application which only runs on a single processor, but I would like to point
out that the issue of moving code from one place to another seems to have
been ignored.

I don't think that a universal assembler is reasonable or even likely.
Machines vary widely, and contain concepts which don't even relate.  Some
machines (particularly multiprocessors) have a hierarchy of memory
requiring different machine instructions to access different classes of
memory, while others don't.  Some machines have particular register sets,
such as vector registers or register windows.

Transportable code is important in distributed environments.  I regularly
write "throwaway" code on a VAX which is routinely executed on Amdahls,
68K workstations and Crays.  Most of this code doesn't get executed enough
times before it is replaced to justify the tradeoff in development time
it would take to implement it in assembler for one machine, let alone for
the four that it runs on.

I'm not saying that all code is of this nature.  Some of the code I've written
for the Cray 2 has been profiled, and then had the hot spots reimplemented
in tightly crafted assembler code.  Other people have handcrafted entire
libraries and even complete applications to take advantage of the machine.
There are (arguably) somethings for which assembler is better, but there
are many distributed, light duty, "throwaway" applications for which
assembly language crafting doesn't make sense.

Actually, as I write this, I think I would address some of the claims in
favor of assembler code.  The idea that it takes the same amount of effort
to maintain and debug assembler based systems as for HLL systems is not
born out in operating system maintenance.

We have 4 Vaxen and a Cray 2 running native Un*x implementations, and a
dual processor Amdahl running MVS and UTS under VM.  We have as many people
doing Amdahl software support as we have supporting the rest of the systems
combined.

Ports of HLL applications are easier, even when the architecture is similar.
In one case I am aware of, a vendor chose to port an existing assembly lanaguge
Fortran compiler to a new machine and also to implement a new Fortran compiler
in Pascal for both the existing and the new machine.  They have put less
(maybe less than half?) effort into the Pascal implementation then in the
assembly language port and have about equal products.

I reject any claim that language A or language type X is better than language
B or language type Y for all purposes.  Somethings make sense to do in
assembler and others in HLLs.  As HLL implementations get better, machines
become more difficult to understand, and distributed applications become
more prevalent, the number of things which it makes sense to do in assembler
becomes less.