• R/O
  • HTTP
  • SSH
  • HTTPS

fig-forth-68000: Repository summary

Source code for fig-forth-68000


Recent Commits RSS

Rev. Time Author Message
036116c 2023-08-14 00:09:44 Joel Matthew Rees master 64/16 run-time optimized unsigned division, not fully tes...
25e35ce 2023-08-13 01:58:56 Joel Matthew Rees buggy but improving U/ , fixed doc for M/MOD
6386958 2023-08-11 16:52:43 Joel Matthew Rees I want to remember the mess I'm making of things in divis...
96b12c8 2023-08-07 21:43:27 Joel Matthew Rees fixing range error for division run-time optimization
72affa5 2023-08-07 21:22:38 Joel Matthew Rees some functioning flattening, buggy division work
9e0120f 2023-07-05 20:45:24 Joel Matthew Rees branching the return version
6579521 2023-07-02 22:17:28 Joel Matthew Rees More in README about directions from here
53cacfc 2023-07-01 23:02:36 Joel Matthew Rees Adding a README and another intermediate false step sourc...
76d1780 2023-07-01 21:32:56 Joel Matthew Rees backing away from the FIG68KSB.S subroutine call version
7e9d7f0 2023-06-21 19:59:59 Joel Matthew Rees Commenting the problem with long calls and CREATE.

Branches

Name Rev. Time Author Message
master 036116c 2023-08-14 00:09:44 Joel Matthew Rees 64/16 run-time optimized un...

README

Two relatively functional versions of fig-Forth for the 68000 exist in this 
repository:

FIG68K.S is a straight adaptation of the fig 6800 model by Dave Lion, et. al., 
with a 32-bit cell and address width, mapping the VM in the 6800 model 
to registers and instructions in the 68000 (via my previous not-quite 
functional adaptation to the 6809).

FIG68KRT.S modifies the adaptaion to use a native 68000 subroutine call/return 
in the inner interpreter, instead of the JMP NEXT mechanism of the straight model.

Both of the above are stand-alone, and should be easily adapted to single-board 
computers and such. Look at the memory map and the IO routines.

Neither contain actual disk I/O, only including disk simulations of blocks of RAM.
Adding disk I/O really shouldn't be hard, however.

The memory map used is restored to the map used in the 6800 model, backing out the 
remapping I had attempted in the 6809 adaptation. (At this point, I still need to 
check whether the modified memory map is the source of the bugs in the 6809 
adaptation.)

FIGRL68K.S and FIGSB68K.S were early false steps.

FIG68KSB.S is another false (I think) step that goes partway through using 
subroutine calls instead of pointers to thread the definitions. It's not the 
right step after FIG68KRT.S, and I think I have abandoned it, also. 

fig58kts.s was sort of between FIG68KSB.S and FIG68KRT.S

The 6800, 6801, and 6809 source files are provided for reference here, but will 
not be kept up-to-date.

The license follows the MIT model license and is in each file itself.

=====

I'm not sure whether I will proceed from here to flatten FIG68KRT.S (and probably 
add the assembler), or proceed to convert BIF-6809 to the 68000. Or go back to 
trying to write novels.

A conversion of BIF-6809 to the 68000 will want macros such as BIF-6809 uses. 
NEXT will be something like MOVE.L (IP)+,A0; JMP (A0) , since memory indirection 
isn't available before the 68020. But it's still only four bytes of op-code, so
it's not so bad. And BIF-6809 also has the (mis-)feature of using calls instead of 
pointers for the threading.

FIG68KRT.S has the feature of the dictionary being most like a standard symbol 
table, which is the direction I thought I wanted to head with this -- compiler 
with its own libraries available to the target program, ultimately able to compile 
a split-stack version of Small C.

Things that need to be added and changed to get from here to there:

Support for global variables will be removed. In exchange, allocation in the 
user/task variable space must be managed, and the inter-module call interface
must be designed.

Flattening FIG68KRT.S is proceeding by fits and starts in FIG68KFL.S . 

I need to start by flattening MESSAGE, but, in order to do so, I need to define 
a new approach to persistent store. (But, see below.)

Since I want the error messages to be loadable from persistent store (ergo, from 
the file system, in *nix terms, and since I want textual messages available even 
when there is no persistent store, I need to play games with "drive 0" and "drive 1".

MESSAGE wants to be settable to deliver numeric error codes, string constants from 
the dictionary, strings from a ROMmed or in-RAM simulation of persistent store, or 
from actual persistent store.

BUT:

Before I start flattenig, I need to go through and decide
how tightly the each word should be bound to the underlying code,
that is, for each word, whether it should always be invoked as a call,
or whether the defining object code can be compiled into the caller.
And that should get a compiler flag in the headers.

Except that the best way to decide may be to flatten first.


Show on old repository browser