OSDev.org

bzt wrote:

sj95126 wrote:My kernel is built with gcc and doesn't use libgcc.

Mine neither. I've deliberately eliminated all compiler-specific libraries (wasn't easy, but possible). Now I can compile my OS with both gcc and CLang as-is (and possibly with many other ANSI C compilers too).

bzt wrote:

sj95126 wrote:To be *really* pedantic, you could conceivably compile simple C code into a standalone flat binary and never use a stack either.

On the other hand I don't think this is possible (not on all architectures that is). Regardless to the ABI, on x86 some CPU instructions need the stack (like "call" or "ret" for example), and I don't think you can convince a C compiler not to use such instructions.

nexos wrote:Overall, C itself appears to be a freestanding language with no dependencies.

sj95126 wrote: main() that doesn't invoke any functions shouldn't need any call instructions. Theoretically, you could implement simple "subroutines" with gotos. There may be architectures I don't know in detail where this can't work.

nullplan wrote:Even then, stack is required for the code that will end up calling the main() function. Depending on architecture, call instructions (or closest equivalent) are going to be necessary to establish GOT pointers, or else you cannot even access your global variables. And your automatic variables might end up on stack anyway, depending on architecture, available registers, and whether or not the compiler decides to spill.

nullplan wrote:Besides, without something like a Wheeler jump being possible (and it isn't possible portably in C), your "subroutines" cannot return from whence they came. They can only "return" to a single place.

bzt wrote:

nullplan wrote:For example, GCC compiled C code can make calls to libgcc functions, and calls to memcpy, memmove, or memcmp. So something must implement those. And at least the mem* functions aren't going to fall from the sky.

In freestanding mode without optimization, no C compiler will make such calls (neither gcc, nor Clang, nor TCC, nor MSVC etc.).

Solar wrote:--no-builtin...?!?

struct block { char c[1024];};

struct block blockcopy(struct block y)
{
    return y;
}

Solar wrote:This still leaves those functions with "__builtin_..." to be used by the compiler for efficiency, but I am not quite clear on how this qualifies as "required runtime support".

PeterX wrote:- Can Go?

eekee wrote:

PeterX wrote:- Can Go?

Go was initially released without the capacity for dynamic linking at all. Its authors initially argued against adding it. I don't know what the current situation is, having lost interest after a couple of years.

Go's runtime provides some basic operating system abstractions. Goroutine corresponds to processes and channel corresponds to inter-process communication. In addition, go has its own virtual memory management, so the idea of running Go programs on bare metal was born.

sj95126 wrote:Technically, mine does use code that's not of my own creation by using the builtin va_* functions for the kprintf() I wrote

sj95126 wrote:but gcc is inlining whatever code it adds. There are no function calls generated.

sj95126 wrote:I didn't say it was practical, just possible.

eekee wrote:You know, I don't think Plain English Programming has much runtime. The package you get includes just 5 files of source, and that's sufficient to rebuild itself. To build other programs with it, you only need to include one of those files. In other words, the entire language runtime is in one file.

https://osmosianplainenglishprogramming.blog/