Simple Forth Interpreter

This project will probably take a lifetime, but might be an interesting hobby – which is the point, to fill up time in an interesting manner, rather than be a feasible project.

The reason Forth was chosen because I wanted to get interactive as soon as possible.

Work in progress

Portability layer

A ‘virtual machine’ which assembles a stream of instructions using GNU as (assembler), e.g.

// .fdef NAME, MNEMONIC, INSTRUCTIONS...
.fdef "1-", DECR, LIT, L,1, SUB, EXIT
.fdef "1+", INCR, LIT, L,1, ADD, EXIT
.fdef "2DUP", TWO_DUP, OVER, OVER, EXIT
    

• One written in C
• One written in arm32 assembly
• Set of common words to both (TODO move to stage1 REPL?)

REPL

A REPL which compiles text onto said virtual machine. This outputs assembly code to be assembled with portability layer.

Future ideas

Data-types

Data-types? Algebraic?

Local names

Extensions to the REPL to make it more like C, e.g.

:c swap { arg1 arg2 -- ret1 ret2 }
   ret1 := arg2 ;;
   ret2 := arg1 ;;
   ;c
    

and loops

:c sum-n { n -- 0+...+n }
   do i 0 ;; n ;; ( i from 0 [incl] to [excl] n )
      0+...+n := 0+...+n i + ;;
      loop
   0+...+n := 0+...+n n + ;;
   ;c
    

Works by having l- and r- value dictionaries? Written on top of stage1

Dynamic Libraries

Not sure where they fit in, possibly require position-independent portability layer?

malloc

Memory allocation, manual?

GC

Memory allocation, GC?

OO

Object-orientation? Possibly one that also works with GC? On top of data-types?

Syntax

Parser? Variable fixity? Macros like in Isabelle?

Threads

Multi-threading (single address-space)? Sharing or not sharing state (like Erlang’s “green threads”)?

Processes

Multiple processes (multiple address-space)?

Actors

Actor model (message-passing)? Scheduling?

Relational

Relational programming?

Build-system

Based on relational programming?

Static types

Static type-system? Type-classes?

Store

Persistent store? Databases?

Swap

Paging datastructures in and out? Virt Mem? Hibernate?

Filesystems

Filesystems as objects on the persistent store? Journalling?

Arrays

APL-like arrays?

Optimisations

Optimiser, track granularity? I.e. a soft dependency on the previous stages, so that only the optimisations for the selected tracks get compiled.

With an ordering like

Perhaps being able to pick&mix for target application? E.g. for micros without virtual memory we don’t want the multiple-address space processes.