| /* This file defines a number of threading schemes. |
/* This file defines a number of threading schemes. |
| |
|
| Copyright (C) 1995 Free Software Foundation, Inc. |
Copyright (C) 1995, 1996 Free Software Foundation, Inc. |
| |
|
| This file is part of Gforth. |
This file is part of Gforth. |
| |
|
| Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. |
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. |
| |
|
| |
|
| |
This files defines macros for threading. Many sets of macros are |
| |
defined. Functionally they have only one difference: Some implement |
| |
direct threading, some indirect threading. The other differences are |
| |
just variations to help GCC generate faster code for various |
| |
machines. |
| |
|
| |
(Well, to tell the truth, there actually is another functional |
| |
difference in some pathological cases: e.g., a '!' stores into the |
| |
cell where the next executed word comes from; or, the next word |
| |
executed comes from the top-of-stack. These differences are one of |
| |
the reasons why GCC cannot produce the right variation by itself. We |
| |
chose disallowing such practices and using the added implementation |
| |
freedom to achieve a significant speedup, because these practices |
| |
are not common in Forth (I have never heard of or seen anyone using |
| |
them), and it is easy to circumvent problems: A control flow change |
| |
will flush any prefetched words; you may want to do a "0 |
| |
drop" before that to write back the top-of-stack cache.) |
| |
|
| |
These macro sets are used in the following ways: After translation |
| |
to C a typical primitive looks like |
| |
|
| |
... |
| |
{ |
| |
DEF_CA |
| |
other declarations |
| |
NEXT_P0; |
| |
main part of the primitive |
| |
NEXT_P1; |
| |
store results to stack |
| |
NEXT_P2; |
| |
} |
| |
|
| |
DEF_CA and all the NEXT_P* together must implement NEXT; In the main |
| |
part the instruction pointer can be read with IP, changed with |
| |
INC_IP(const_inc), and the cell right behind the presently executing |
| |
word (i.e. the value of *IP) is accessed with NEXT_INST. |
| |
|
| |
If a primitive does not fall through the main part, it has to do the |
| |
rest by itself. If it changes ip, it has to redo NEXT_P0 (perhaps we |
| |
should define a macro SET_IP). |
| |
|
| |
Some primitives (execute, dodefer) do not end with NEXT, but with |
| |
EXEC(.). If NEXT_P0 has been called earlier, it has to perform |
| |
"ip=IP;" to ensure that ip has the right value (NEXT_P0 may change |
| |
it). |
| |
|
| |
Finally, there is NEXT1_P1 and NEXT1_P2, which are parts of EXEC |
| |
(EXEC(XT) could be defined as "cfa=XT; NEXT1_P1; NEXT1_P2;" (is this |
| |
true?)) and are used for making docol faster. |
| |
|
| |
We can define the ways in which these macros are used with a regular |
| |
expression: |
| |
|
| |
For a primitive |
| |
|
| |
DEF_CA NEXT_P0 ( IP | INC_IP | NEXT_INST | ip=...; NEXT_P0 ) * ( NEXT_P1 NEXT_P2 | EXEC(...) ) |
| |
|
| |
For a run-time routine, e.g., docol: |
| |
PFA1(cfa) ( NEXT_P0 NEXT | cfa=...; NEXT1_P1; NEXT1_P2 | EXEC(...) ) |
| |
|
| |
This comment does not yet describe all the dependences that the |
| |
macros have to satisfy. |
| |
|
| To organize the former ifdef chaos, each path is separated |
To organize the former ifdef chaos, each path is separated |
| This gives a quite impressive number of paths, but you clearly |
This gives a quite impressive number of paths, but you clearly |
| find things that go together. |
find things that go together. |
| |
|
| |
It should be possible to organize the whole thing in a way that |
| |
contains less redundancy and allows a simpler description. |
| |
|
| */ |
*/ |
| |
|
| #ifndef GETCFA |
#ifndef GETCFA |
