[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [epsilon-devel] How to write a simple code generation which is not t
From: |
Luca Saiu |
Subject: |
Re: [epsilon-devel] How to write a simple code generation which is not terrible |
Date: |
Thu, 31 Jan 2019 19:00:48 +0100 |
User-agent: |
Gnus (Gnus v5.13), GNU Emacs 25.1.50.2, x86_64-unknown-linux-gnu |
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