[BACK]Return to threading.h CVS log [TXT] [DIR] Up to [gforth] / gforth

Diff for /gforth/Attic/threading.h between versions 1.3 and 1.4

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
Removed from v.1.3  
changed lines
  Added in v.1.4

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>