drj11 / sixtyforth

64-bit implementation of Forth

SixtyForth

Welcome to SixtyForth, 64th for short.

SixtyForth is a 64-bit implementation of FORTH written in 64-bit Intel assembler.

SixtyForth implements the ANSI Forth standard (1994 edition). The CORE word set is present.

In this implementation a cell is 64-bits wide, and signed integers are represented in 2's complement.

As per the ANSI standard, the required words from the standard are required to be in UPPER CASE. Obviously lower case is a bit more comfortable, and SixtyForth may accept that in the future. Note that you can define your own words in any case you like; when using them the case must be exactly as you defined it.

Input is accepted from the keyboard (and interactively ^A ^E ^P ^N ^D ^K work); from the command line (./64th -c 'SOURCE TYPE'); and from files (./64th example/hw.4).

Building SixtyForth and running it

Unpack the distribution from the magnetic tape. Ensure NASM is installed. Then:

cd sixtyforth
make

This creates the executable binary 64th. Run this to start using SixtyForth:

./64th

Testing

The skeptical may want to run the tests first:

make test

The tests are run using urchin which is an npm module. urchin will be installed if npm works.

Bugs, Issues, Fun

Please refer to github.

https://github.com/drj11/sixtyforth/

On ANSI

The CORE word set is implemented.

Other word sets are not implemented completely, but the intention is that where SixtyForth has facilities that overlap with ANSI words, SixtyForth will implement those ANSI words.

For example, SixtyForth has a word that adds two double cell numbers together, it is D+ from the ANSI DOUBLE word set, even though the entire word set is not implemented.

CORE EXT

None of the words marked as obsolescent are implemented: #TIB CONVERT EXPECT QUERY SPAN TIB.

Implemented: .( 0> 2>R 2R> 2R@ <> ?DO FALSE HEX NIP PAD PARSE TO TRUE TUCK U> VALUE WITHIN [COMPILE] \

Not implemented: .R 0<> :NONAME AGAIN C" CASE COMPILE, ENDCASE ENDOF ERASE MARKER OF PICK REFILL RESTORE-INPUT ROLL SAVE-INPUT SOURCE-ID U.R UNUSED

sixtyforth's Issues

Whether Unicode strings are supported?

Segmentation fault (core dumped)

Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal

Dell Inspiron N5040
8 GB Ram
500 GB SSD

sudo apt-get nasm
make sixtyforth
./64th
Recieved Segmentation fault (core dumped)

Cannot use 64th as a scripting language

We would like to be able to start a #! script with:

#! /usr/bin/env 64th

and then write a Forth script.

This requires:

1. 64th should process a command line argument as a filename to be read and evaluated; and,
2. An initial line beginning #! should be ignored.

Drop and Store ASM subroutine may improve things

Many words, such as +, -, AND, have a common final part which DROPs then replaces the new TOS with RAX.

Consider factoring it.

FM/MOD isn't implemented

A note on how to implement FM/MOD (floored division) in terms of SM/REM (symmetric division).
SM/MOD is what the Intel idiv instruction implements.

See Leijen 2003 for more discussion.

The result of SM/REM only differs from that of FM/MOD when
the remainder and the divisor have opposite signs.
Note that the case where remainder = 0 has to been handled with care
(in this case no adjustment is necessary).
Using the 3-valued signum function the condition for adjustment is:

signum(remainder) = -signum(divisor)

The adjustment is:
the quotient is decremented by 1, and
the remainder has the divisor added to it.

Consider rewriting SEARCH-WORDLIST

or rather, its factors. Particularly the large ASM routine, MATCHASM.

DOES> doesn't work

It's not implemented yet.

Implementation Note:

The compile time behaviour of DOES> is to compile (does>) followed by EXIT into the current word, followed by(INIT), a short primary machine code sequence that implements the initialisation time behaviour. (note that the rest of the current word will be compiled after(INIT)up to the final;.

The run time behaviour of DOES> (implemented by (does>)) is to modify the Code Field of the most recently defined word to point to (INIT) (which immediately follows (does>) in the word list).

The initialisation time behaviour (of the word defined using the defining word that contains DOES> in its source) is implemented by the (INIT) code:
it is to set CODEPOINTER to the words following (INIT) and continue in the threaded interpreter.
Thus executing the word following DOES>.

(INIT) is the same code everywhere is appears, it needs to setup CODEPOINTER to a different sequence of threaded code (each defining word will instantiate a fresh (INIT)).
This is possible because after the indirect jump THIS will point to (INIT).

The minimal (INIT) then is just a jmp to the code that actually does the work.
Intel-64 doesn't have an absolute 64-bit jump.
But it does have this:

See http://www.ragestorm.net/blogs/?p=107 for this piece of code:

jmp [rip+0]
DQ someaddr

This is handy.
It's a fixed 14 byte sequence that will jump to a fixed location.

So at compile time DOES> can copy this fixed machine code sequence after (does>).

Recursive

How difficult is implementing "recursive"? e.g. this factorial code:

: fac recursive
  dup 1 > if
    dup 1 - fac *
  else
    drop 1
  then ;
 
: lp
  swap 1 + swap
  do
    i . i ." ! = " i fac . cr
  loop ;
 
20 0 lp

Actually, I've answered my own question - "recursive" is unnecessary in your implementation!

Feature set - documentation

Maybe it is implicit from the 1994 standard and "CORE", but I suggest making it explicit in the ReadMe file if the floating point word set is supported or not (or if there is some other kind of floating point operations possible).

It could be in the form of a feature list (if it is not too short), included what is not supported.

The feature list could also include some indication of operating system(s) this Forth runs on (e.g., is it only Linux?) - I don't assume it is a bare-metal Forth.