[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
Re: [epsilon-devel] How to write a simple code generation which is not terrible
Thu, 31 Jan 2019 13:33:22 +0100
Gnus (Gnus v5.13), GNU Emacs 184.108.40.206, x86_64-unknown-linux-gnu
On 2019-01-31 at 12:55 +0100, Jose E. Marchesi wrote:
> Let's take plus 1 2 %s, for example. Would Jitter generate pushes for 1
> and 2?
No, they would be immediates, possibly residuals. Of course a good
compiler would not generate a plus instructions with two immediates,
independently from the destination, but having that particular
specialized instruction among the rest is not a problem.
> What would be instruction definition look for the `plus'?
The instruction will look like this (to make things even nicer let us
say that 1 and 2 are both common literals occurring in the first or
second position, so they will not even be ever residualized):
instruction plus (?RSn 1 2, ?RSn 1 2, !RS)
OUTPUT2_LVALUE = INPUT0_RVALUE + INPUT1_RVALUE;
The instruction has three operands, two input-mode and one output-mode.
I'm putting, arbitrarily, the output operand on the right. Each of the
inputs can be a register, a stack or an immediate. The output can be a
register or a stack -- of course, not an immediate.
Every input operand of a stack kind entails a pop. Having a stack-kind
output entails a push. Here are the stack effects, Forth-style, for a
few unspecialized uses of plus, which map to different specializations:
plus 1, 2, %s ( -- 3 )
plus %s, 1, %s ( a -- a+1 )
plus %r0, %s, %s ( a -- %r0+a )
plus %s, %s, %s ( a b -- a+b )
plus %r1, 2, %r1 ( -- )
The stack effect would be achieved automatically, by machine-generating
code taking action before the user code is run.
Nothing is needed from the user point of view. Before the user code is
run, the stack has been already popped or pushed (with unspecified
elements) to achieve the stack effect of the particular specialization
we are in. Input (r-value) macros for stack-kind input-mode operands
will also have been defined by reading stack elements *before* altering
the stack, and output macros for stack-kind output-mode operands will be
defined as l-values referring the result stack -- these may include the
TOS. My manual tests show that the machine code quality does not suffer
at all despite complicated stack effect on TOS-optimized stacks, where
push and drop also involves loads and stores; this is the discovery
which surprised me in the first place.
> Also, how would this support non-consuming instructions? Using an
> instruction attribute?
I would say a new mode; we can call it @, for example. The idea would
make sense for writing as well. We could sat that @ works exactly like
?, except that when the operand kind is a stack, then the argument is
I haven't thought very hard on non-consuming instructions. They make
things less intuitive and less orthogonal when such instructions are
few, but I understand that they would be nice, in a context where you
don't have a complete set of instructions with every possible operand
kind in every position: a non-consuming plus would be useless when you
have my plus defined above, but that might be expensive or undesirable
to have for every instruction.
Do you find any flaws with this?
* 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".
Description: PGP signature