bootstrappable.org project                                           -*- org -*-

* What?
** Full source bootstrapping for GuixSD
* Why?
** Reproducibility is essential to Software Freedom
Reproducible builds are a set of software development practices that
create a verifiable path from human readable source code to the binary
code used by computers.
*** What about the compiler?
We have the sources: they always lead to bitwise-same binary, but what
about the compiler?
*** The current way out: Ignore the problem

 ``recipe for yoghurt: add yoghurt to milk''

*** From the GuixSD manual

   The distribution is fully “bootstrapped” and “self-contained”: each
package is built based solely on other packages in the distribution.

The root of this dependency graph is a small set of “bootstrap
binaries”, provided by the ‘(gnu packages bootstrap)’ module.  For more
information on bootstrapping, *note Bootstrapping::.

*** New solution: Full source bootstrapping path, Stage0 and Mes
* How?
** Software: Stage0 and Mes
** Stage0

*** hex.0: amazing ~300 byte self-hosting hex assembler that we consider to be source
*** a M0 macro assembler written in .0
*** a M1 macro assembler written in M0
*** a hex2 linker written in M0

Look:
    https://git.savannah.nongnu.org/cgit/stage0.git/tree/Linux%20Bootstrap/hex0.hex

Do:
    git clone https://git.savannah.nongnu.org/git/stage0.git
    cd stage0
    make
    bin/hex < Linux\ Bootstrap/hex0.hex > hex-1
    chmod +x hex-1  # later: bin/exec_enable hex-1
    ./hex-1 < Linux\ Bootstrap/hex0.hex > hex-2

** Mes

    https://gitlab.com/janneke/mes

*** mes.c: a scheme interpreter prototyped in C ~1400 Lines
*** mescc.scm: a C compiler written in Scheme (uses Nyacc C99 parser in Scheme)
*** mes.M1: this scheme interpreter in annotated M1 assembly

** Naive recipe
    hex + hex.0 => hex-1
    hex-1 + M0.0 -> M0
    M0 + M1.M0 -> M1.0
    M0 + hex2_linker.M0 -> hex2_linker
    M1 + mes.M1 -> mes.hex2
        hex2_linker + stage0/elf32-header.hex2 + mes.hex2 + elf32-footer.hex2 -> mes
    mes + mescc.scm + tcc.c -> tcc.M1 -> tcc.hex2 -> mes-tcc
    mes-tcc + gcc.c -> gcc
    *done*
** Less naive recipe
*** Use hex2_linker, M1 prototyped in C from
    https://github.com/oriansj/mescc-tools
*** Remember that mes.M1 is compiled by mescc from prototyped src/mes.c in C.
*** stage0/mescc-tools: TODO
*** Mes
   M1 -f stage0/x86.M1 -f mlibc/crt1.M1 --LittleEndian --Architecture=1 > mlibc/crt1.hex2
   M1 -f stage0/x86.M1 -f mlibc/mini-libc-mes.M1 --LittleEndian --Architecture=1  > mlibc/libc-mes.hex2
   M1 -f stage0/x86.M1 -f src/mes.M1 --LittleEndian --Architecture=1 > src/mes.hex2
   hex2 --LittleEndian --Architecture=1 --BaseAddress=0x1000000 -f stage0/elf32-header.hex2 -f mlibc/crt1.hex2 -f mlibc/libc-mes.hex2 -f src/mes.hex2 -f stage0/elf32-footer-single-main.hex2 > src/mes-mes
   exec_enable src/mes-mes
*** Tinycc
   ./build.sh
   ./link.sh
* DONE
** stage0: hex.0, M0 done; M1, hex2_linker prototyped in C
** tcc compiled with mescc correctly compiles: int main () {return 42;}
** mes+mescc.scm are mutual self hosting
** during development we run mescc.scm on Guile (mes is slooowww)
** tcc compiled with gcc is known to compile gcc

* TODO
** fix mescc.scm so that tcc can correctly compile gcc
** fix bootstrap-loops: (Nyacc?, mes.M1?, psyntax.pp?)
** make GNU gcc (8.0?) bootstrappable again, remove [need for] tcc stage
** stage1/2 LISP, FORTH?
** rain1's LISP compiler?
** integrate with GuixSD
** x86_64, arm?
* Contact
** #bootstrappable, #guix on freenode
** bootstrappable.org