izaya/collapseos
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

doc/bootstrap: fix inaccuracies

Browse Source
This commit is contained in:
Virgil Dupras 2020-10-31 15:27:00 -04:00
parent 7001446212
commit 3a0084aa31
1 changed files with 22 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
doc/bootstrap.txt
View File

@ -16,7 +16,7 @@ This binary can be separated in 5 distinct layers:
2. Arch-specific boot words (B305 for Z80) 2. Arch-specific boot words (B305 for Z80)
3. Arch-independant core words (low) (B350) 3. Arch-independant core words (low) (B350)
4. Drivers, might contain arch-specific code 4. Drivers, might contain arch-specific code
5. Arch-independant core words (high) (B380) 5. Arch-independant core words (high) (B390)
# Boot code # Boot code
@ -28,9 +28,7 @@ It also of course does core initialization: set RSP/PSP, HERE
CURRENT, then call BOOT. CURRENT, then call BOOT.
It also contains what we call the "stable ABI" in its first It also contains what we call the "stable ABI" in its first
0x100 bytes. The beginning of the dict is intertwined in this few (<0x20) bytes.
layer because EXIT, (br), (?br) and (loop) are part of the
stable ABI.
# Boot words # Boot words
@ -53,25 +51,26 @@ See B260 for details.
# Drivers # Drivers
Up until now, we haven't implemented EMIT or KEY yet: those Core words don't include (key) and (emit) implementations be-
words are defined in the "high" part of core words because we cause that's hardware-dependant. This is where we need to load
generally need machine-specific drivers to implement (emit) and code that implement it, as well as any other code we want to
(key). include in the binary.
Well, now is their time to shine. We split core in two We do it now because if we wait until the high layer of core
precisely to fit drivers in there. This way, they have access words is loaded, we'll have messed up immediates and ":" will
to a pretty good vocabulary and they're also give the oppor- be broken. If we load our code before, we won't have access to
tunity to provide (emit) and (key). a wide vocabulary.
# Core words (high) # Core words (high)
Then come EMIT, KEY and everything that depend on it, until The final layer of core words contains the BOOT word as well
we have a full Forth interpreter. At the very end, we define as tricky immediates which, if they're defined sooner, mess
tricky IMMEDIATEs that, if defined earlier, would break cross cross compilation up. Once this layer is loaded, we become
compilation. severly limited in the words we can use without messing up.
We end that with a hook words which is also where CURRENT will After having loaded that last layer, we end that with a hook
be on boot. word which is also where CURRENT will be on boot, which is then
followed by the initialization string (see below).
So that's the anatomy of a Collapse OS binary. How do you build So that's the anatomy of a Collapse OS binary. How do you build
one? If your machine is already covered by a recipe, you're in one? If your machine is already covered by a recipe, you're in
@ -110,4 +109,9 @@ part. The boot sequence is designed to interpret whatever comes
after LATEST as Forth source, and this, until it reads ASCII after LATEST as Forth source, and this, until it reads ASCII
EOT character (4). This is generally used for driver init. EOT character (4). This is generally used for driver init.
To produce a Collapse OS binary, you run that xcomp unit and
then observe the values of "ORG @" and "H@". That will give you
the start and stop offset of your binary, which you can then
copy to your target media.
Good luck! Good luck!