FAST-EXECUTE

[Other proposals]

Problem

The stack-effect of EXECUTE usually cannot be determined statically. In the context of an optimizing compiler this creates a significant performance problem: no register allocation can be performed across an EXECUTE or across any word that may call EXECUTE directly or indirectly.

The frequent invocation of EXECUTE in object-oriented programs makes it important to avoid this cost.

Proposal

FAST-EXECUTE core-ext
Interpretation:
Interpretation semantics for this word are undefined.
Compilation: ( u1 u2 u3 u4 -- )
Append the run-time semantics given below to the current definition.
Run-time: ( u1*x u3*r xt -- u2*x u4*r )
Remove xt from the stack and perform the semantics identified by it. Other stack effects are due to the word EXECUTEd. An ambiguous definition exists if xt does not have the stack effect ( u1*x u3*r -- u2*x u4*r )

Typical Use

... ['] + [ 2 1 0 0 ] FAST-EXECUTE ...

Remarks

This word does not introduce new functionality. It can be implemented (without the performance-enhancing effect) on standard systems with
: FAST-EXECUTE 2DROP 2DROP POSTPONE EXECUTE ; IMMEDIATE
We can therefore wait safely until we have more experience with this word before adopting it.

Experience

none.

Comments

Michael L. Gassanenko:
I think, the new standard must have a section of "experimental words",
as FORTH-83 did, and this proposal can go only to this section.
Peter Knaggs:
I can see very much why you would want this, especially
for optimising compilers.  However, using the assume command from my
stack algebra will have the same effect.  (I must write up a version of
that for JFAR.)

Anton Ertl