[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