Re: [epsilon-devel] How to write a simple code generation which is not terrible

[Luca Saiu]

On 2019-01-31 at 14:11 +0100, Jose E. Marchesi wrote:

> I guess the pops and pushes are always generated in left-to-right order?
> What about adding something like S{n} to indicate the ordering of the
> stack operations?  Something like:
>
> instruction plus (?RS{0}n 1 2, ?RS{1}n 1 2, !RS{0})
>
> The default can be left-to-right.

I suspect that this will be very error-prone but it's a good idea to
decouple code generation strategies from the VM, and the flexibility
will be handy in weird cases.  Thanks, I will do this.

One caveat, however: it only makes sense that the outputs are written
after *all* the inputs have been read.  So by using the optional indices
(when even just one is introduced, the others become all mandatory on
the same instructions) we establish a fixed ordering on every input
access, and on every output access.  If there are n inputs and m
outputs, then the two sets of indices must define two permutations of
the sets {0, ..., n-1} and {0, ..., m-1}, with every element of each set
occurring exactly once, no repetitions allowed.

Left-to-right in the sense of code generation corresponds to
deep-to-shallow in terms of stack elements: 0 is the highest depth, and
the predecessor of the number of input or output operands is the top,
unless there are non-consuming stack accesses.

The way I see it, your example

> instruction plus (?RS{0}n 1 2, ?RS{1}n 1 2, !RS{0})

follows in fact the default order:
* read under-top;
* read top;
* drop one element (or, as a naïve alternative which seems to be just
  as good, drop two elements and push an unspecified element back);
* user computation, writing into the result which is the new top.

The exact semantics of all of this is tricky, particularly with
non-consuming stack accesses.  I will try and sketch that in a separate
message.

> Well... with the explicit (and optional) ordering of stack operands, I
> guess I would certainly use this for many of my instructions: the code
> generated would be much smaller.

Good.  I didn't think you could make use of this, with your variables
not in registers.  I thought your instructions were more or less
stack-only, with few possible alternatives on kinds for the same
operand.

Regards,

-- 
Luca Saiu
* GNU epsilon:           http://www.gnu.org/software/epsilon
* My personal web site:  http://ageinghacker.net

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

signature.asc
Description: PGP signature