Interesting thread! I'd like to summarize a few notes: 1) Historical status of bootstrapping tinycc and the current status of it's central role with bootstrapping all other toolchains (binutils/gcc/llvm/clang) was outlined below. Currently there is no fully capable alternative to Tinycc, hence it's importance in this context.
2) A principle tradeoff must be considered between standards compliance and supported language features and "bootstrappability" of tinycc. Bootstrapping should not be excluded from this reasoning. Simplified speaking the more language features are implemented or relied upon internally (C99/C11 and later, in particular NPTL and __thread extension are painful) the more the feasibility of bootstrapping tinycc becomes complicated, close to impossible. Currently tinycc-0.9.26 jannecke fork intermediate version must be kept in maintenance for that reason, instead of rolling along with tinycc mob/HEAD directly. 3) Another principle twist surrounding bootstrapping tinycc, that is any compiler (typically spawn from macro assembly) which is sufficiently capable to bootstrap/compile tinycc by itself any such compiler is a candidate to replace tinycc. I would like to mention mes-cc and pnut-cc in this context again, in particular the latter which can be spawn from macro assembly alike is a rather capable and efficient compiler itself but it does not rely upon "self-hosting" exclusively, and just as said can be spawn from macro-assembly (see live-bootstrap M0/M1/M2 and GNU mes) pnut-cc, mes-cc, and too another option known as MES-replacement stack language c-compiler were/are discussed among #bootstrappable 4) Since rust-lang was mentioned, i would like to point to some notes at http://tinyfront.mooo.com/docs.html#Acceptance-Criteria together with a footnote referencing rust-lang http://tinyfront.mooo.com/docs.html#tos-manual:2 "Without any vendor-neutral standard followed development cannot agree upon a common baseline of which releases or versions of rustc could compile itself self-hosting!" Details concerning bootstrapping of rust-lang are discussed among #bootstrappable 5) While ago i proposed a definition to distinguish terminology for - A "compiler/language bootstrap" (such as python, perl, rust-lang, java etc.) - From a "full system bootstrap" which typically involves further aspects to support a C-toolchain, Kernel, Libc etc. (something i was working on with https://codeberg.org/aggi/linux-tcc kernel fork and musl-libc backported onto linux-2.4 syscall abi) Those terms are often confused mistaking one for another, misguiding a "complete system bootstrap" was accomplished when instead it's limited to any individual language or toolchain without considerations of further problems. For that matter original TCCBOOT from Bellard too was aiming at closing some gap for a full system bootstrap including kernel, partially at least. While ago i merely could re-confirm tccboot/libtcc could still be compiled and remain functional with tinycc mob/HEAD (a year ago or so) Long story short, tinycc is a crucial component to accomplish the only known complete(!) system bootstrap which exists today, that is live-bootstrap for x86_32 "only". For this the tradeoff between standards compliance and C language features supported should be evaluated always. To roll along with tinycc mob/HEAD branch (among other reasons) i've forked https://codeberg.org/aggi/tiny-bootstrap which too implements a complete nightly-build CI setup inside /chroot for tcc mob/HEAD (instead of tcc-0.9.27 pinned down by live-bootstrap master branch) Recently i was working on supporting a few more components to keep those bootstrappable and compiled by tinycc directly (cdrtools, musl, linux-tcc busybox and another ~500 components already forked and known working for this, it's just alot of efforts to migrate all this into some sane and simple build-system/packaging that live-bootstrap steps/conigurator is; the most relevant pieces are git-pushed and published already regardless) Anyway, thanks to tinycc-devel and bootstrappable who greatly helped with this. Regards Michael Ackermann On 2026-07-06 15:40, Charlie Gordon wrote: > John, > > I am also curious about the historical side of the story. Do we know > what compiler Fabrice Bellard actually used to build the original OTCC > release, and whether that bootstrap path has ever been documented? I'm > interested both from a historical perspective and because it seems like > an important part of understanding TinyCC's origins. > > The answer is quite simple: Fabrice used gcc to compile the original > OTCC project, as well as TinyCC itself. > He used gcc 2.95 to compile the code, but not as a source of ideas for > how to implement it! He always starts > from a blank page for his projects, writing down just a few ideas > regarding architecture and implementation and > off he goes writing code and marking achievements by crossing out the > corresponding line on his paper roadmap. > The project originated during a lunchtime discussion with the team: > people were raving about Fabrice having > won a IOCCC award in 2000 and I challenged Fabrice with a new idea: > write a small C program that could > compile itself and yet fit the rules of the IOCCC, a significant step > up from programs that can output their own source code. > This required a syntax close enough to C that the program could be > compiled by the standard C compiler > and by the resulting executable. > Fabrice stopped to think for a brief moment and said: “Ça devrait être > faisable”. (should be doable) > And so he did! and won another award for OTCC, > Fabrice must have been a bit frustrated by the many restrictions he had > to settle for in OTCC so he kept working > on the compiler that later became TinyCC. We had been working on a > single pass javascript interpreter and he > insisted on the same approach in TinyCC. > I cannot remember the exact dates, but the IOCCC announced the 2000 > awards on Dec 1st 2000 and opened the submissions for the 2001 awards > from Oct 1st to Dec 1st 2001. > OTCC announced its 2001 award winners on March 8, 2002. > I have a version 0.9.1 version of TInyCC without floating point support > dated Dec 2nd, 2001 (just after the deadline for the IOCCC 2001 > submissions) > Best regards > Chqrlie > > [1]The International Obfuscated C Code Contest > [2]web.archive.org > [3][RZ9GmHnkbIQAAAABJRU5ErkJggg==] > > On 2 Jun 2026, at 21:57, J Mastron via Tinycc-devel > <[email protected]> wrote: > > Michael, > > Thank you for the detailed explanation. I found the current > bootstrappable-builds route particularly interesting, especially the > role of the patched TCC 0.9.26 as an intermediate step and the > discussion surrounding keeping TinyCC HEAD bootstrappable. > > One of my biggest takeaways from your reply is that compiler > bootstrapping is viewed not merely as a response to the "Trusting > Trust" problem, but as a practical engineering concern in its own > right. I had not fully appreciated that perspective before. > > I am also curious about the historical side of the story. Do we know > what compiler Fabrice Bellard actually used to build the original OTCC > release, and whether that bootstrap path has ever been documented? I'm > interested both from a historical perspective and because it seems like > an important part of understanding TinyCC's origins. > > Thank you again for taking the time to explain the current state of the > bootstrap chain. > > Best regards, > > John > > On Jun 2, 2026, at 2:09 PM, Michael Ackermann via Tinycc-devel > <[email protected]> wrote: > > Other than "trusting trust" it is a principle engineering concern. > Furthermore i might point to the fact bootstrappable.org already did > solve > the problem on the software side with great efforts (except for > firmware/bios > and hardware related issues which were discussed occasionally), but > some patches > from janneke/tcc-0.9.26 weren't rebased onto tcc-head to simplify the > whole > procedure a bit on the live-bootstrap side. And this too touches the > concern > which C standard iteration tcc itself should follow, and which language > constructs could more or less easily be avoided to retain > bootstrappability of > tcc. This topic had been discussed many years ago already if > tinycc-devel could > align internal implementation to bootstrapping criteria a bit, but > there seems > to have been some disagreement hence the 0.9.26 fork persisted. I just > do not > know yet myself, how complicated a rebase of related changes onto HEAD > would be, > and if it's considered desirable by tinycc-devel and if it is worth the > efforts. > This is a non-trivial discussion and involved different perspectives > naturally. > Because Tinycc was and is a crucial piece to resolve the whole > bootstrapping up > until most recent c++/gcc/clang compilers. And while there was no > alternative to tcc yet for doing this, i would suggest tinycc itself > deserved a little attention to keep it's latest mob/HEAD bootstrappable > too. > As a bonus the bootstrappable.org proceeding provides a decent > system-integration and nightly build CI testing option. There simply is > no need > to "trust" opaque binaries of unknown origin then, since you can easily > bootstrap i386-tcc plus libc etc. inside /chroot within a few minutes > of > compilation time already. And from there you can cross/compile almost > everything > else as usual, including support for other ARCH. All this is mission > accomplished already, but needs the mentioned patched tcc-0.9.26 as an > intermediate step still to arrive at tcc-HEAD. > The current route taken for tcc is: > M0 -> M1 -> M2 -> pnut-cc|mes-cc -> patched tcc-0.9.26 -> > tcc-0.9.27|tcc-HEAD > (my tiny-bootstrap fork differs a little with a direct transition from > 0.9.26 > to tcc-HEAD and pnut-cc chosen instead of mes-cc because the former is > much > faster compile-time for the sake of quicker test cycles) > The c-standard and language construct limitations are intruded by the > transtion > from pnut-cc|mes-cc -> tcc. The M2 C-compiler is a capable but more > limited > compiler hence cannot directly compile tcc (you might talk to stikonas > and > others who can explain to you in detail which options exist and which > limitations this implies). > For that matter there's too linux-tcc (and fiwix) kernels available, > fully > bootstrapped and driven by tcc, myself is still working on a few > things, mainly > cleanup and testing (too much to mention here and i've yet had no luck > with any contracting to sustain a living either). > Greetings > On 2026-06-02 09:30, John Mastronardo via Tinycc-devel wrote: > > I came across the following statement from Bootstrappable.org when I > clicked Michael’s link: > > “Compilers are often written in the language they are compiling. > This creates a chicken-and-egg problem that leads users and > distributors to rely on opaque, pre-built binaries of those > compilers that they use to build newer versions of the compiler.” > > At first, I wasn’t sure I agreed with the premise because I had > always assumed that most compilers were ultimately written in > assembly language. After looking into it more, I realized the > situation is more nuanced and actually touches on a fascinating > aspect of compiler history. > > Historically, many early compilers were indeed written largely in > assembly language. In the early days of computing, there was no > alternative. If you wanted a compiler, assembler, or operating > system, someone first had to write machine code or assembly code to > make it happen. > > However, once a language became mature enough, compiler developers > often rewrote the compiler in the language itself. This is known as > a self-hosting compiler. > > Some modern examples include: > > GCC is written primarily in C and C++. > > Clang/LLVM is written primarily in C++. > > The Go compiler is written primarily in Go. > > The Rust compiler (rustc) is written primarily in Rust. > > This raises an obvious question: > > How was the first compiler for a language built if no compiler for > that language existed yet? > > Rust provides a good example. The first Rust compiler was not > written in Rust. It was written primarily in OCaml by Graydon Hoare > and early contributors. Once that compiler became capable enough, it > was used to compile a new implementation of the Rust compiler > written in Rust itself. Eventually the OCaml implementation was > retired. > > The evolution looked roughly like this: > > OCaml compiler > > ↓ > > Early Rust compiler (written in OCaml) > > ↓ > > Compiles > > ↓ > > Rust compiler (written in Rust) > > ↓ > > Compiles > > ↓ > > Future Rust compilers > > If we keep following the chain backward, we eventually arrive at > something like: > > Modern Rust compiler > > ↓ > > Older Rust compiler > > ↓ > > OCaml Rust compiler > > ↓ > > OCaml compiler > > ↓ > > C compiler > > ↓ > > Older C compiler > > ↓ > > Assembly-language compiler > > ↓ > > Assembler > > ↓ > > Hand-entered machine code > > This is the bootstrap chain that Bootstrappable.org is concerned > about. > > The issue is not that modern compilers are untrustworthy. Rather, > their point is that at some stage everyone relies on a pre-built > binary that they did not personally create. Most of us accept this > as a practical necessity. We trust compiler binaries provided by > established projects and distributions. > > However, researchers interested in software supply-chain integrity > ask a deeper question: > > “Can we reproduce the entire toolchain from source all the way back > to a tiny, auditable starting point?” > > This is closely related to the famous “Trusting Trust” problem > described by Ken Thompson. Even if source code appears clean, a > malicious compiler binary could theoretically inject unwanted > behavior during compilation. > > That is why projects such as Stage0, GNU Mes, and the broader > bootstrappable-builds effort exist. Their goal is to minimize the > amount of binary software that must be trusted at the beginning of > the build process. > > As someone interested in TinyCC, I find this particularly > interesting because TinyCC occupies a unique place in the compiler > ecosystem. Its relatively small size makes it easier to study, > understand, and potentially use as part of a bootstrap path compared > to the massive codebases of GCC or LLVM. > > What’s especially fascinating about TinyCC is that it appears to > trace its roots to Fabrice Bellard’s remarkably small self-hosting > OTCC compiler. OTCC was only a few kilobytes of source code, yet it > could already compile itself. Bellard then expanded that foundation > into the much more capable TinyCC we know today. > > If I were to speculate on the likely bootstrap path, it might have > looked something like: > > Hand-written machine code > > ↓ > > Assembler > > ↓ > > Early Unix C compiler > > ↓ > > GCC > > ↓ > > OTCC (first version) > > ↓ > > Self-hosting OTCC > > ↓ > > TinyCC > > ↓ > > Modern TinyCC > > In the end, I came away with two conclusions: > > My assumption that most compilers are written in assembly language > is historically true for many early compilers, but not for most > modern compilers. > > The “chicken-and-egg” problem described by Bootstrappable.org is > real, although whether it is an important practical concern depends > on one’s threat model and goals. > > I’m curious how the TinyCC community views this issue and whether > anyone here has explored compiler bootstrapping, trusted build > chains, or participation in the bootstrappable-builds effort. More > specifically, has Fabrice Bellard ever documented exactly which > compiler built the first OTCC release? If so, does a reproducible > bootstrap path from that original version still exist today? > > I suspect some long-time TinyCC developers may know the answer from > old mailing-list discussions, historical source archives, or > Bellard’s original development notes. > > Best regards, > > John M. > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > <signature.asc> > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > References > > Visible links: > 1. > https://web.archive.org/web/20020604005602/http://www1.us.ioccc.org/main.html > 2. > https://web.archive.org/web/20020604005602/http://www1.us.ioccc.org/main.html > 3. > https://web.archive.org/web/20020604005602/http://www1.us.ioccc.org/main.html > > Hidden links: > 5. > https://web.archive.org/web/20020604005602/http://www1.us.ioccc.org/main.html
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
