Minor update in bootstrapping Steps note

This commit is contained in:
Jeremiah Orians 2019-04-29 20:03:15 -04:00
parent 20c03c0d25
commit d12606c9bb
No known key found for this signature in database
GPG Key ID: 5410E91C14959E87
1 changed files with 22 additions and 2 deletions

View File

@ -159,11 +159,11 @@ It is recommended to run with no less than 4MB of Memory
* Step 6b Build us a Forth
Since forth fans kept telling me Forth is easier to implement than lisp, I also implemented a Forth but it certainly took far longer to get the bugs out.
You'll note that this forth is only 3360 bytes large (almost half the size of the lisp) but you'll also note that it is also in a much more primitive state.
You'll note that this forth is only 4372 bytes large (almost half the size of the lisp) but you'll also note that it is also in a much more primitive state.
Having done all of the above; I must say if I had to start with this forth or the hex monitor, I would always choose the forth but I wouldn't dare dream of trying to jump straight to forth from Hex.
If you want to bootstrap anything, NEVER EVER EVER START WITH FORTH. Get yourself a good assembler first and you might find writing a garbage collected lisp is actually much easier.
If you want to bootstrap anything, NEVER EVER EVER START WITH FORTH. Get yourself a good assembler first and you might find writing a garbage collected lisp or a C compiler is actually much easier.
We first need to create our prepared tape:
cat High_level_prototypes/defs stage2/forth.s > temp
@ -179,3 +179,23 @@ roms/forth should with the sha256sum of f4bbf9e9c4828170d0c153ac265382dc705643f9
Our forth will first attempt to evaluate any code in tape_01 and then evaluate any code that the user types in
(Otherwise there is no way for a forth fan to have a chance against the lisp in terms of being able to bootstrap something cool)
Tuning needs to be done to run with any less than 4MB of Memory
* Step 6c Build us a C compiler
Since I got tired of people saying you can't write a C compiler in assembly, I did exactly that and as you can see it was completed relatively quickly.
You'll note that the C compiler is 16370 bytes large, making it larger than the Lisp and FORTH put together but not much harder to implement than the lisp.
Having done all of the above; I must say one needs a really solid assembler and a minimal disassembler to effectively bootstrap a C compiler (alteast until you get the point that the tokenizer is working).
We first need to create our prepared tape:
cat High_level_prototypes/defs stage2/cc_x86.s > cc_TEMP
Then we use our M0 Line macro assembler to convert our assembly into hex2 format:
./bin/vm --rom roms/M0 --tape_01 cc_TEMP --tape_02 cc_TEMP2 --memory 256K
Then we need to assemble that hex into our desired program:
./bin/vm --rom roms/stage1_assembler-2 --tape_01 cc_TEMP2 --tape_02 roms/cc_x86 --memory 48K
roms/cc_x86 should with the sha256sum of 12bb96de936fff18b27c2382ddcee2db6afb6a94b9f4c6e9e9b3d1d0d0d3b0ed
Our C compiler will read any code in tape_01 and output the compiled output to tape_02.
The compiled output is macro assembly (allowing for easy inspection) which then must go through the appropriate macro assembler and hex2 steps to become a working binary.
Should you wish to port the C compiler to a different target, one need only update the strings and a few minor places in the code; looking at M2-Planet's multi-arch support will cover all of those questions quickly.