guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Karrmann
Subject: announcement of minimal binary boot (mb2) with indirection table forth
Date: Wed, 23 Feb 2022 22:54:03 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]