announcement of minimal binary boot (mb2) with indirection table forth

announcement of minimal binary boot (mb2) with indirection table forth

[Stefan Karrmann]

[-- Attachment #1: Type: text/plain, Size: 2974 bytes --]

Dear all,

the articles [1, 2] about the struggle to reduce the binary seed for the
guix bootstrap was really interesting for me. I took up the challenge to
reduce the binary seed further.

[1] https://guix.gnu.org/manual/en/html_node/Reduced-Binary-Seed-Bootstrap.html
[2] https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/

My hard binay seed is a monitor, which takes octal encoded octets (aka
bytes) as input, writes the octets in reverse order into the memory, and
finally jumps to the new code. It's size is:

  - for octal keyboard input on x86:             32 octets (!)
  - for octal uninitialized serial input on x86: 34 octets
  - for octal initialized serial input on x86:   41 octets
  - for octal linux input on x86:                48 octets

  - for octet keyboard input on x86:             18 octets
    This make sense, if we use the alt numpad input method.

For those, who don't regard octal encoded octets as real source code, I
provide a second binary seed which implements a forth nucleus. I call it
itf or indirection table forth.
The sizes for this interpreter are much bigger than the sizes of the
monitors but still small in comparision to a boot sector (512 octets):

  - 75 octets for bios monitor on x86
  - **__81__** octets for bios standalone on x86 (!)
    i.e. six of them fit easily into one boot sector!
  For easier development we have:
  - 102 octets for linux monitor on 32 bit x86
  - 101 octets for linux standalone on 32 bit x86

The bootstrap code in forth source code is still in its development phase.
I've compiled and tested the first colon words. The next task is a more
normal forth interpreter and a regular dictionary.

As it is common in forth, we define new code words, i.e. primitives in
machine code. (Think of asm(...) in gcc.) At start it is hard work on such
a tiny base. But already after 2 new words, it is mainly writing down the
bit pattern of the octets for the machine code in forth source code.

It still needs improvement of the forth word set. Afterwards, we can use it
to bootstrap either gForth or a scheme interpreter [3]. AFAIK, we already
have a c-compiler in scheme, cf. [4]. Therfore, this will open the path to
c programs etc.pp. I'll appreciate help on this path.

[3] http://www.complang.tuwien.ac.at/~schani/oldstuff/scheme_in_forth.tar.gz
[4] https://www.gnu.org/software/mes/

You find git repository of this project at:

https://codeberg.org/StefanK/MinimalBinaryBoot

IMHO, we can transfer both, the monitor and the itf, easily to other
architectures, i.e. cpu.

I'm curious when someone writes a smaller binary seed.
On [5], we read that brainf#*k is down to 99 bytes (on x86) but I haven't
found the source. Moreover, who want's to write source in it?

[5] https://justine.lol/sectorlisp2/

Kind regards,
-- 
Stefan Karrmann
Sichere Kommunikation? GPG: 0x8C3260C01550B612E4C5730D22E42112094CE53F

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: announcement of minimal binary boot (mb2) with indirection table forth

[Tobias Platen]

On Wed, 2022-02-23 at 22:54 +0100, Stefan Karrmann wrote:
> for octal keyboard input on x86:             32 octets (!)
>   - for octal uninitialized serial input on x86: 34 octets
>   - for octal initialized serial input on x86:   41 octets
>   - for octal linux input on x86:                48 octets
> 
>   - for octet keyboard input on x86:             18 octets
>     This make sense, if we use the alt numpad input method.
> 
> For those, who don't regard octal encoded octets as real source code,
> I
> provide a second binary seed which implements a forth nucleus. I call
> it
> itf or indirection table forth.
> The sizes for this interpreter are much bigger than the sizes of the
> monitors but still small in comparision to a boot sector (512
> octets):
That looks interesting, I have been thinking about something similar
for the Rasperry PI GPU, which has been reverse engineered.

Tobias

Re: announcement of minimal binary boot (mb2) with indirection table forth

[Ludovic Courtès]

Hello,

Stefan Karrmann <S.Karrmann@web.de> skribis:

> My hard binay seed is a monitor, which takes octal encoded octets (aka
> bytes) as input, writes the octets in reverse order into the memory, and
> finally jumps to the new code. It's size is:
>
>   - for octal keyboard input on x86:             32 octets (!)
>   - for octal uninitialized serial input on x86: 34 octets
>   - for octal initialized serial input on x86:   41 octets
>   - for octal linux input on x86:                48 octets
>
>   - for octet keyboard input on x86:             18 octets
>     This make sense, if we use the alt numpad input method.
>
> For those, who don't regard octal encoded octets as real source code, I
> provide a second binary seed which implements a forth nucleus. I call it
> itf or indirection table forth.
> The sizes for this interpreter are much bigger than the sizes of the
> monitors but still small in comparision to a boot sector (512 octets):
>
>   - 75 octets for bios monitor on x86
>   - **__81__** octets for bios standalone on x86 (!)
>     i.e. six of them fit easily into one boot sector!
>   For easier development we have:
>   - 102 octets for linux monitor on 32 bit x86
>   - 101 octets for linux standalone on 32 bit x86
>
> The bootstrap code in forth source code is still in its development phase.
> I've compiled and tested the first colon words. The next task is a more
> normal forth interpreter and a regular dictionary.

This is truly impressive!  I’m of those who don’t regard octal-encoded
octets as “real source” :-), unless it’s short and comes with extensive
comments (which is more or less what stage0 does, IIRC).  The tiny Forth
kernel remains super small though, well done!

Thanks,
Ludo’.