Re: technology discussion → does the world need a "new" C ?

On 7/6/2024 5:23 AM, Malcolm McLean wrote:

On 05/07/2024 23:40, Ben Bacarisse wrote:

BGB <cr88192@gmail.com> writes:
>

Like, for example, I had tried (but failed) to write a usable C compiler in
less than 30k lines (and also ideally needing less than 4MB of RAM). But,
if the language design is simplified some, this might be a little
closer. Might still be doable, but a C compiler in 50-75k lines is much
less impressive.

>
Why do you think this matters to other people?
>

 To the average prgrammer, no, the compiler is "just there". Someone else wrote it, if it is a paid-for compiler than usually the university of the empployer paid for it. But of course someone smewere has to write it.
 And if this difficult to do it limits the usability of the language. Now C is so popular that it almost doesn't matter. When  a new chip comes out, usually the first thing the manufacturers is provide a C compiler for it. For other languages, this isn't the case.
 And the moment I'm writing a shell. And it would be nice to add a "cc" command. But that's a huge task. However I already have a "bb" (BabyBasic), and it's still going to be quite a big job to get it to a state where it is easy to write useful prgrams with it. But not comparable to implementing a C compiler.
 

Yeah.
In my case I did a BASIC interpreter in under 1k lines, albeit for a fairly limited form of the language.
Something like a JavaScript interpreter could probably be done in a few thousand lines (assuming one limits it to ES3 or similar).
Something like a C compiler is a whole different thing entirely...
It isn't really the parser that is hard in this case, more that C has a fairly difficult typesystem. Many other mainstream static-typed languages (such as Java or C#) have comparably simpler typesystems.
This is part of why my idea for a simplified language would effectively redesign the typesystem to be a little more like the one in C#, albeit hopefully still usable for many of the types of tasks C is used for.
But, yeah, for most people, writing the compiler is always "someone else's problem".
Granted, even with as much suck as it was to write my own C compiler to target my ISA, it is still likely a better experience than it would have been trying to retarget GCC or Clang.
GCC is sort of a tangled mess of code, trying to add a new target would likely involve weaving it in all across the codebase, which is comparably fairly large (well into MLOC territory IIRC).
Any desire to retarget Clang is limited by the issue that it would involve needing to edit and recompile LLVM a large number of times, and LLVM takes an absurdly long time to recompile...
They are like "well, use -j N".
   But, like, "-j 1": It takes like 4 hours;
   "-j 4": It still takes around 1 hour, PC still usable.
   "-j 8": It takes 45 minutes, but PC is made unusable.
Doing so also eats most of the RAM, on a PC with 112 GB... (Can't install a full 128GB with my MOBO/chipset it seems).
At "-j 8", the HDD with the pagefile is basically running at full capacity.
It is a mystery why anyone uses LLVM, I would have considered it a dead end due to all this...
If there is any merit to GCC, it is at least that it doesn't wreck the PC so hard trying to recompile it...
One other traditional option is LCC, but here, it is only the parser/frontend stages, pretty much everything else one needs to write themselves. And, the preprocessor and parser is not the hard part of writing a C compiler.
It is mostly when one gets into dealing with the typesystem, and 3AC / SSA stuff, that a lot of the pain begins.
But, in a way, this is where a stack-based bytecode IR comes in:
   Easy to generate from a frontend;
   Easy to translate into 3AC or SSA form on load.
As noted, the two mainstream examples of this sort of bytecode being the Java JVM and .NET / CIL.
Technically, my compiler organizes things more like in the JVM; essentially with two big tables: One holds all the top-level declarations, and another all the types/structs/etc.
But, with a bytecode design more like in the .NET VM (the stack operators don't directly encode the types, but rather the type of the operation is based on the types of the input values).
Granted, there are a few things I would have preferred to have been different in the design of my IR, but alas.
While it may be tempting to have the front-end emit code in SSA form, this makes things harder. It could potentially allow a little more flexibility for the front-end to optimize things in advance, but not clear it is worth the added pain.
This was more the approach taken by Clang (producing LLVM bitcode as output). However, it is unclear that LLVM bitcode would be terribly useful in anything that is not LLVM (seems to be more designed more as a compact serialization scheme for objects within LLVM).
There is SPIR-V as another example of this approach.
By themselves, the assembler and linker stages aren't too bad, if one does these sensibly (my existing backend kinda botched this part).
My short lived "new compiler" effort did at least implement a more proper assembler and linker stages. And, did the "more sensible" thing of translating instruction encodings using an instruction-listing table (as opposed to a bunch of giant "switch()" statements and bit-twiddling).
Translating 3AC or SSA form to ASM is one of those things:
Can be done "simply", but compiler output is not going to be efficient;
Doing it "better" is where things get to be an issue.
Ideally, one wants to try to limit the amount of complexity that this stage needs to deal with (in terms of typesystem mechanics or behavior).
Note that SSA is typically a special case of 3AC, where conceptually in SSA every variable may only be assigned once and the logical identity of variables through control flow paths is merged via PHI operators.
In BGBCC, I had used a hybrid approach where variables are assigned "version numbers" instead; so each time a given variable is assigned it is given a new version. These may behave as distinct variables within a basic-block, but typically all variables with the same base variable will merge together (as-if a PHI had been used) in the space between basic-blocks.
Though, this does lead to some obvious differences in the handling of registers between BGBCC and GCC. Have also noted that MSVC seems to use registers in a similar way to BGBCC (among various other things that seem "oddly similar").
...