[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [epsilon-devel] Jitter: stacks as a new argument kind

From: Luca Saiu
Subject: Re: [epsilon-devel] Jitter: stacks as a new argument kind
Date: Wed, 30 Jan 2019 02:43:01 +0100
User-agent: Gnus (Gnus v5.13), GNU Emacs, x86_64-unknown-linux-gnu

On 2019-01-30 at 02:25 +0100, Luca Saiu wrote:

> Stack effects, if any, being implicit.

Apart from prototypes and experiments to stress GCC, this point deserves
some development.

I want to execute user code in a state where the arguments have been
already read into constants, and space has been already made (or
dropped) for every result.  Assigning to an operand macro in order to
set a result will compile to a register write or a store, but *not* a
stack position change.  In other words, the effect on stack height is
determined by the instruction argument modes whenever an instruction has
at least one stack operand.  Changing the stack height from user code in
such a case will have weird effects (but it is allowed as it is now in
an instruction without an explicit stack operand).

Rationale: I cannot alter the stack and copy results to the right stack
position at the end in machine-generated epilog C code for a VM
instruction: the epilog may not be reachable, while instead reachable
assignment to operands macro should always take effect, wherever they
are.  Doing it like in the proposal doesn't interfere with branches,
fast branches and escaping instructions such as the ones calling
longjmp: any effect on "!"  operands will be correctly visible as long
as the corresponding "output" macro has been assigned.

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".

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]