Where is the documentation for the C subset supported by cc_x86?

[eyalroz]

The steps.txt file tells us:

Build cc_x86 using M0 and hex2
==============================
cc_x86 is a C compiler written in M0 macro assembly. Lets break down the whole
build process etc. etc.

But - it's not a full-fledged C99 compiler, right? Otherwise, we could have used it to build GCC 4.6. It only accepts a subset of C. What is that subset? Can you add a link to the documentation, to steps.txt and/or elsewhere?

[cosinusoidally]

cc_x86 is taken from https://github.com/oriansj/stage0-posix-x86/blob/master/cc_x86.M1 (the version I have in tree is not fully up to date with upstream). The dialect itself is not fully documented, but it is a subset of the dialect supported by M2-Planet (https://github.com/oriansj/M2-Planet).

There is a C prototype version of cc_x86 here https://github.com/oriansj/stage0/tree/master/stage2/High_level_prototypes/cc_x86 but I think the M1 version has drifted from that version. I think cc_x86 is essentially based on an early version of M2-Planet.

In terms of bootstrapping up to GCC, the live-bootstrap project does that https://github.com/fosslinux/live-bootstrap/ via cc_x86->M2-Planet->mescc->tcc->gcc (see https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst). I did actually manage to integrate my tcc_bootstrap_alt project into a fork of live-bootstra (which works) but i didn't get the PR into a fully mergeable state fosslinux/live-bootstrap#407

[eyalroz]

So, this helps, but - this information should be present somewhere in the repository itself, not just as a comment on an issue. Maybe somewhere in the dev notes directory.

Also - and sorry for trying to give you more work - but it is important that a tool that's part of the bootstrapping chain be better documented. So if you can either document the subset of C covered by cc_x86, or get the people who have cause the "drift" to document what they did, that would be useful.

In fact, it would also be useful in possibly later being able to skip some of the bootstrapping steps; see the bottom of my post on StackOverflow: If cc_x86's subset was properly documented , it would be more likely someone could write a transpiler from full-C to this subset. And if we had that, we could, apriori, have GCC 4.6 sources in cc_x86 form and go from cc_x86 directly to GCC 4.6.

[cosinusoidally]

tbh the upstream repo would probably be a better place for this discussion maybe specifically the M2-Planet repo https://github.com/oriansj/m2-planet

One issue I can see with the transpilation approach is auditing the generated C code. For example if someone transpiled the GCC source code down to the M2-Planet/cc_x86 dialect then you would likely then have a million lines of machine generated C code to review. I can't speak for the upstream developers, but I know for example that the live-bootstrap project goes to extreme lengths to avoid relying on any pregenerated files (for example they regenerate every configure script from scratch as part of their bootstrap process).

[eyalroz]

tbh the upstream repo would probably be a better place for this discussion maybe specifically the M2-Planet repo

Do they know about cc_x86?

One issue I can see with the transpilation approach is auditing the generated C code. For example if someone transpiled the GCC source code down to the M2-Planet/cc_x86 dialect then you would likely then have a million lines of machine generated C code to review.

The auditing should actually be pretty simple: Do the transpilation on the original GCC sources and make sure it's the same result as what would be stored in this repository. Of course, auditing and bootstrapping don't have to happen together or on the same machine.

I can't speak for the upstream developers, but I know for example that the live-bootstrap project goes to extreme lengths to avoid relying on any pregenerated files

I'm not familiar with live-bootstrap (although maybe I should), but - wouldn't that only apply to pre-generation of files that are specific to the target platform?

[cosinusoidally]

tbh the upstream repo would probably be a better place for this discussion maybe specifically the M2-Planet repo

Do they know about cc_x86?

They were both written by the same people, so yep :)

One issue I can see with the transpilation approach is auditing the generated C code. For example if someone transpiled the GCC source code down to the M2-Planet/cc_x86 dialect then you would likely then have a million lines of machine generated C code to review.

The auditing should actually be pretty simple: Do the transpilation on the original GCC sources and make sure it's the same result as what would be stored in this repository. Of course, auditing and bootstrapping don't have to happen together or on the same machine.

live-bootstrap does actually check the hash of the resulting binaries, so in theory a "transpiled" version of GCC could be used to recompile the standard live-bootstrap version of GCC and the hashes could then be compared. That might be easier said than done though as subtle inconsistencies may creep in (eg due to subtle differences due to conditional compilation). It's definitely possible for alternative bootstrap paths to build bit identical copies of tcc (eg tcc_bootstrap_alt can generate a bit identical copy of the live-bootstrap version of tcc) but tcc is considerably smaller than gcc.

I can't speak for the upstream developers, but I know for example that the live-bootstrap project goes to extreme lengths to avoid relying on any pregenerated files

I'm not familiar with live-bootstrap (although maybe I should), but - wouldn't that only apply to pre-generation of files that are specific to the target platform?

It applies to any pregenerated files. https://github.com/fosslinux/live-bootstrap/tree/master?tab=readme-ov-file#specific-things-to-be-bootstrapped