version 1.3, 1995/11/09 18:28:40
|
version 1.4, 1996/02/19 18:57:27
|
Line 1
|
Line 1
|
/* 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. |
|
|
Line 19
|
Line 19
|
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 |