Port of C in 4 functions with OWC

[toncho11]

https://github.com/rswier/c4

@ghaerr Looking at #1443 (comment) now C in 4 functions has a better chance with the OWC. If needed the low memory use modes developed for DOOM can be used while the compiler is executed inside ELKS.

[toncho11]

Yes, I see the 4 x 256 kb mallocs, but it also says that these are "// arbitrary size".

[ghaerr]

I'm very familiar with C4, its slick and very small - I'm sure it could easily be ported in an hour or so (with greatly reduced buffer sizes for very small programs) using IA16 or OWC to ELKS. It compiles a small but useful subset of C and then interprets it in-memory, no object files, no linking. All source must be compiled at once and it calls the host for a few supported system calls required for it to compile itself, that's it, and no C library. It's main purpose I think is that it can compile (actually, interpret) itself, and for that its design is ingenious.

It'd be great for those who say "Hey, I'd like to write a 10-line program to play around with C on ELKS". But "porting" any existing .c files to ELKS for anything but non-trivial use will usually require the C library (currently 18,000 lines of code) and a nearly ANSI compliant compiler (the C89 spec is 552 pages long). The "C" language is no longer small at all, and everyone wants to do something different with it. When I ported our ELKS C library to OWC, it took me a couple of months to get that done.

That said, I was thinking of porting C4 to ELKS just for the fun of it, but I'm not sure as-is it can actually do much for ELKS users? My guess is either no one would use it, as they'd try to compile their favorite C program, and find it doesn't work since a majority of the language and C library are unimplemented.

So I think here, as well as #1443, the important question to get answered is: "What do I want to do with a native C compiler on ELKS"? The user's expectations for what the C compiler might be used for greatly affect the solution.

[toncho11]

I understand. Then users' expectations should be lowered since the beginning. It should be called a c4 compiler "that provides a C like language" or "that provides a subset of the C language".

So we have the ELKS libc statically compiled, right? What about something like a dynamically compiled libc?
Here is a dynamic load of a function: https://www.devxperiences.com/pzwp1/2023/05/17/c-dynamic-loading-of-a-shared-library-also-create-and-load-one-on-your-own/

So my idea is to add an extra command in the interpreted language in c4 that allows for dynamic function call to ELKS libc functions.
Or a small subset of ELKS libc library ...