Browse Source

Simplify boot process

That INIT thing is unnecessary.
pull/102/head
Virgil Dupras 4 years ago
parent
commit
76037ca1e7
7 changed files with 26 additions and 44 deletions
  1. +7
    -7
      blk/089
  2. +15
    -16
      blk/090
  3. +0
    -16
      blk/091
  4. +1
    -2
      blk/411
  5. +1
    -1
      blk/430
  6. BIN
      emul/forth.bin
  7. +2
    -2
      emul/stage1.fs

+ 7
- 7
blk/089 View File

@@ -1,16 +1,16 @@
Initialization sequence

On boot, we jump to the "main" routine in boot.fs which does
On boot, we jump to the "main" routine in B289 which does
very few things.

1. Set SP to 0x10000-6
1. Set SP to PS_ADDR and IX to RS_ADDR
2. Sets HERE to RAMEND (RAMSTART+0x80).
3. Sets CURRENT to value of LATEST field in stable ABI.
4. Look for the word "BOOT" and calls it.

In a normal system, BOOT is in icore and does a few things:
In a normal system, BOOT is in xcomp core (B411) and does a
few things:

1. Find "(c<)" a set CINPTR to it (what C< calls).
2. Initialize all overrides to 0.
3. Write LATEST in BOOT C< PTR ( see below )
4. Find "INIT". If found, execute. Otherwise, "INTERPRET"(cont)
1. Initialize all overrides to 0.
2. Write LATEST in BOOT C< PTR ( see below )
3. Set "C<*", the word that C< calls to (boot<). (cont.)

+ 15
- 16
blk/090 View File

@@ -1,16 +1,15 @@
On a bare system (only boot+icore), this sequence will result
in (c<) reading characters from memory starting from CURRENT
(this is why we put CURRENT in BOOT C< PTR, it tracks current
pos ).

This means that you can put initialization code in source form
right into your binary, right after your last compiled dict
entry and it's going to be executed as such until you set a new
(c<).

Note that there is no EMIT in a bare system. You have to take
care of supplying one before your load core.fs and its higher
levels.


(cont.)
4. Call INTERPRET

In other words, BOOT interprets bytes directly following
CURRENT as Forth source code. This code will typically
initialize all subsystems and then call RDLN$. As soon as
this is called, INTERPRET will begin reading from RDLN< which
reads from KEY.

In the "/emul" binaries, "HERE" is readjusted to "CURRENT @" so
that we don't have to relocate compiled dicts. Note that in
this context, the initialization code is fighting for space
with HERE: New entries to the dict will overwrite that code!
Also, because we're barebone, we can't have comments. This can
lead to peculiar code in this area where we try to "waste"
space in initialization code.

+ 0
- 16
blk/091 View File

@@ -1,16 +0,0 @@
(cont.) In the "/emul" binaries, "HERE" is readjusted to
"CURRENT @" so that we don't have to relocate compiled dicts.
Note that in this context, the initialization code is fighting
for space with HERE: New entries to the dict will overwrite
that code! Also, because we're barebone, we can't have
comments. This can lead to peculiar code in this area where we
try to "waste" space in initialization code.










+ 1
- 2
blk/411 View File

@@ -9,7 +9,6 @@
['] (boot<) 0x0c RAM+ !
( boot< always has a char waiting. 06 == C<?* )
1 0x06 RAM+ !
LIT< INIT (find)
IF EXECUTE ELSE DROP INTERPRET THEN
INTERPRET
;


+ 1
- 1
blk/430 View File

@@ -6,7 +6,7 @@
the last typed 0x0a and one for the following NULL. )
IN) IN> - 2+ ALLOT
(infl)
LIT< RDLN< (find) DROP 0x0c RAM+ !
['] RDLN< 0x0c RAM+ !
1 0x06 RAM+ ! ( 06 == C<? )
;


BIN
emul/forth.bin View File


+ 2
- 2
emul/stage1.fs View File

@@ -20,9 +20,9 @@
RDLN$
LIT< _sys [entry]
." Collapse OS" NL
INTERPRET
;

(entry) _
H@ 256 /MOD 2 PC! 2 PC!
H@ 0x08 BIN+ ! ( update LATEST )
," INIT "
H@ 256 /MOD 2 PC! 2 PC!

Loading…
Cancel
Save