This is a multi dimensional project, which is using the C programming language as its vehicle.

It can be used to create tiny static executables, without any dependency even in standard C libraries and C runtime.

The main idea is that all this end code (except of course the system calls) should be produced by this repository only (we try hard to avoid even compiler builtin functions). We really want to have the blame. And the glory too.

We implement an own C library, that can be also used as an educational tool, so to demystify the underlying system mechanics. For that, the code should prioritize clarity and intentions instead of optimizations, or else it should be considered as a weakness to develop understandable and readable code, that can also serve as a documentation.

As we are seeing C as a bright new language, we are following always the latest development, starting from the latest C revision known as C23 and onwards.

As there isn't any kind of obligation to noone and to history (we want to feel free to experiment with the exact way we like), so our C should look and feel like a modern programming language. Plus we want to try to establish a common and one way to do any kind of coding flow, using the same patterns. It is firmly believed that in this modern era of Rust and overcomplication, C can be really feel as a breath of fresh air. Under the hood and no matter the style though, it is still pure unbeatable C. Plain easy to review and understand the code intentions, and with the most straight access to machine possible. Long live the compilers (and we have many now, even one from AI!)!

We compile with -O2 and with as many warnings possible on, and we aim for a warning free compilation. We really think that the compiler is our best friend that really care for us.

Currently there is support for five compilers:

• gcc (15 major release and onwards)
• clang (21 major release and onwards)
• kefir (develop branch)
• tcc (mob branch)
• slimcc

All but tcc (which implements some of the core features we use from C11 and so is usable), implement most if all of the C23 standard. TinyCC is an exception, as currently is the compiler that can being used to compile the latest gcc written in C (4.7.4), during bootstrapping.

We intent though to follow C2y as soon as possible. In that case we'll keep tcc but only for demonstationg bootstraping, but we really hope to adopt.

Note, that we are interested to be used by tcc, kefir and slimcc (mostly), at some point early in the bootstraping process path, for a usable basic system that can at least administrate the machine. We think that we can do also net requests if we can have a freestanding TLS library that can do HTTPS.

Usage

Bootstrap the C.make utility:

 cd src/bootstrap
 sh bootstrap gcc|clang|tcc|kefir|slimcc

Example (assuming C.make is on $PATH):

 C.make -c Time/now

The build procedure.

The C.make utility breaks down the procedure into the following steps:

• generates a single unit by resolving dependencies.

• calls the compiler that preprocess the unit. The idea here is that the code in the preprocessed unit, is the actual code (what you see is what you get) that will be translated finally to machine code.

  As we use -nostdlib and -ffreestanding, we made sure that this code is all but ours, as -ffreestanding implies -fno-builtin (that means none of the builtin compiler functions is being used), and -nostdlib instruct the linker to avoid linking with the C runtime startup files.

  We want really to assure that if anything breaks hardly, we'll be the only responsible for the breakage and not external factors or hidden functions.

  This is a major point in our priority list.

• calls the compiler to generate assembly (usefull for those to know assembly).

• calls the compiler that calls the assembler to generates machine code.

• calls the compiler that calls the linker to create the executable.

Note that tcc, only preprocess the generated unit and does the rest with its builtin generator and linker and so it walks fast after the preprocessed step.

Notes

The implementation has been developed under Linux/x86_64, so we are considered a C Linux port in x86_64 architecture.

Here is a command that can explain this last statement. Issue in your zsh shell:

mkdir -p universe/{sys/{data,x86_64/bin},src/L/C/{compiler/kefir,lib/linux/x66_64,app/{shell,editor,core,net,usr}}}

visualize:

find universe

Where L stands for Language.

Utilities:

Status:

The C.make utility is in prototype state. Currently it handles what we want nicely, so it is not a priority a rewrite. No known bug. It also handles it's own resources too gracefully (as it is reported by valgrind).

Most of the standard utilities are from iterations over in time (since 2020 in C and since 2010/12 in S-Lang) of the same functionality (mostly the most used operations and arguments to their corresponded from GNU-coreutils (and usually with the same semantics)). Unfortunately and because of the translation between the languages, or between C dialects, or now with no standard libc ( in the second iteration (which was also translated to a different C dialect)) it might be that the previous iteration has done it better!!!

Many (if all) of them have been checked for merory leaks at the initial stage. We didn't continue until we've found to fix the leak or any uninitialations. Of course much part of the code hasn't been checked (only the basix operations corresponded code did).

Again. The code is written and thus handles and tests, in a x86_64 machime that runs on Linux. But this is a general thing, as we care here to expose the ideas (our project ideas), and a first prototype in C (which and in our own biased opinion, is much more than a prototype and usually nice code. as the style is focused to reveal the intention of the code).

Absolutely, not even a bit of docunentation (besides the code itself and (on all of them) a usage message (with --help or usually with -h on invocatiao)))n.

Specifically for C.

For our libc, it is much more than what you can expect by a standard library.

But first what is missing:

- thread support. We don't care as it is not a part of our buissness for the
 next 5-10 years. But of course very welcomed.
- atomics. Likewise, except that there is an implementation that we can use
 if we need it.

Now. In our libc every little everything is considering a library, even functionality that is provided by the core utilities. The main function is just a driver that parses the arguments from the environment, and then just set the corresponding struct field of the library type.

For instance in standard libc, there isn't any function that implement a copy file functionality. We are small and rather uneducated (and thinking loudly here), what could be happened (after more than 30++ years of code evolution) if this functionality was implemented from the very begining, that could be used by every C codebase through all this time?

... to be continued.

Acknowledgements, References, Algorithms, Libraries, Compilers:

• Bootstrapping an Operating System.
• Live Bootstrap
• Minibase: a base system and early userspace for Linux.
• Neat Libc.
• Diet Libc.
• Mlibc.
• Picolibc.
• LibLinux.
• klibc from Linux Kernel.
• A minimal C Runtime.
• musl.
• Tinycc: A tiny C compiler.
• GCC.
• Clang.
• Kefir.
• slimcc.

From all those projects, I would like especially thank the Neat libc authors, becuase it was their code that helped me to develop the initial code, and through out the fears, and minibase for their syscalls code (my main advisor for long).

License:

We don't believe in licenses. We believe that we do not need laws and licenses to make the right thing, but only developed conscience.

But we respect a lot the GNU philosophy and we feel that we (human beings) owe a lot to the GNU project, as we wouldn't be here (with all this tremendous code evolution in those forty years (so much development in such a tiny fraction of time, unprecedented in the human history, without force but with only the inner will and cooperation)), if it wasn't the GNU tools and ... GPL.

That is the reason for the GPL3. However, our actual law should obey in common sense and an inner will, to do what we have to do by our own, and not because we have to do. Hopefully this day will come soon.

Αγαθοκλής