Internal of wfroth

This chapter presents the internals of this language.

Last update:	10-December-1998
State (estimation)	2%

---

This chapter includes the following sections:

• Differents models of forth implementations
• direct-threaded
• indirect-threaded
• direct-call
• token
• byte-code string
• Byte-code string model and vm
• Global Variables

---

Differents models of forth implementations

As far as I know, I can talk about these several model of forth implementations:

• direct-threaded
• indirect threaded
• direct-call
• token
• byte-code

Direct-threaded

to be developped

Indirect-threaded

to be developped

Direct-call

to be developped

Token

to be developped

Byte-code string

to be developped

Byte-code string model

We have defined some basic forth definitions in the "C" language.

We have also defined a virtual machine to execute byte-coded string.

Let's take a first very simple example:

We create the next definition:

: test 10 100 + . ;

Here is how into this is translated by the wfroth interpret/compiler:

1000	1004	1008	100C	1010	1014	1018
LIT	10	LIT	100	+	.	;S

(To make thinks easier, we show an hypothetical and convenient address for each cell).

Address	Value	Type	What is performed at run-time
1000	LIT	"C" function number	Get next cell and push value on stack.
1004	10	literal
1008	LIT	"C" function number	Get next cell and push value on stack.
100C	100	literal
1010	+	"C" function number	Pop twice, add, and push result.
1014	.	"C" function number	Pop and display number (binary to ascii conversion)
1018	;S	"C" function number	Pop a level from the return stack.

Into each cell, if this something to execute, not a data to be interpreted, we consider 2 types:

• C function to execute
• In wfroth, each C-function (the kernel-defined words) is associated to a number, which is an index into a table of pointer of functions.
• user defined definition.
• this is simply a pointer into the code dictionnary (starting at 0), the CFA (Code Field Address).

How the distinction is made between a c-function code-number and a CFA? A C function code-number is stored as a negative number. That lets still an addresse space of 2^31 for the user definitions.

The pseudo-code for the wfroth vm is something like:

Global Variables

First, let's see how for example the definition INT is coded:

: int
build> 1 allot
does> ;

Creation of a variable TEMP:

int temp

Here a snapshot of the code dictionnary:

670210	670214	670218	67021C	670220	670224
(build>)	lit	1	allot	(does>)	(;)

67024C	670250	670254
rt_does>	7813A0	670224

• (build>) is the runtime part of the definition build>
• lit is the runtime part of the definition build>
• (does>) is the runtime part of the definition does>
• (;) is the runtime part of the definition ;
• rt_does> is a run-time definition. The C code for this definition is the next one:

areg = (CELL*)*ip++	load the address register with the value which is stored into the next cell
ip = (CELL*)*ip	continue execution on the "run-time part" of creating definition int.

The value 7813A0 is given as example and is an address of memory ( 4 bytes) allocated at the time the sequence 'int temp' has been executed, ie temp created.

The next example is maybe more explicit:

: const
build> 1 allot !
does> @ ;
123 const myConst

67024C	670250	670254	670258	67025C	670260	670264	670268	67026C	670270	670274
(build>)	lit	1	allot	!	(does>)	@	(;)	rt_does	7813A0	670264

It's also possible, and preferable, to define const as the next definition:

: const
build> ,
does> @ ;
123 const myConst

67024C	670250	670254	670258	67025C	670260	670264	670268
(build>)	,	(does>)	@	(;)	rt_does	7813A0	670258