🚀 go-pugleaf

To respond to some issues that have been raised.

First, I don't believe the Assembler should
reorganise code.  The purpose of assembler code
is to allow the user total control over what
the machine will do, and the assembler has no business
taking away any of that control.

Moreover, why would you WANT the assembler to
reorganise?  Presumably you are writing in
assembler to do things the compiler can't, such
as access interrupts, devices &c, in which case you
probably need tight control.  If you are writing
in assembler because you don't trust the optimising
compiler, well, would you trust an optimising
assembler?

Filling the hole after a delayed branch, and similar
transformations, are done at a late stage in the
compilation process, because it is only at that
late stage that the program representation has
branch instructions in it.  While being compiled,
a program usually goes through several intermediate
transformations, gradually becoming more and more
like machine code.  What starts as a Pascal WHILE
loop becomes a tree node with the key token "while",
then maybe a flowgraph node with two entries and
one exit, then maybe a code node with "branch false"
token.  Only at the last stage is it possible to
do instruction reordering.

Unfortunately, this way of building compilers misses
a lot of optimisations.  To reuse a previous example,
filling the hole by loop rotation may be impossible,
because at the stage where the compiler knows about
branches, it has forgotten about WHILE statements,
and must laboriously reanalyse the flow by scanning the
linear machine code.  The lesson here is that one can
get good code with successive optimisations based on
partial information and heuristics, but to get truly
"optimal" code one must never throw information away.
Hence, the program representation must contain the
fact that there is a branch, and SIMULTANEOUSLY the
fact that this branch is the branch back at the
end of a pure WHILE loop.