Re: question about linker

Em 11/26/2024 9:59 PM, Bart escreveu:

On 26/11/2024 20:00, Bart wrote:

On 26/11/2024 19:38, Thiago Adams wrote:

 

Do you have any idea what else can be simplified when creating a C compiler?

>
What are you asking; are you thinking of writing one? Because C compilers already exist!
>
If so, think of what you would find troublesome. I could create a long list of things that makes C harder to compile than my own language.

 Since BGB posted a list, here's mine; it is not exhaustive:
  Hard C Features
 * Type declarations (which mix up variables, function pointers,
   function declarations in the same declaration, and even
   function definitions start off the same).
 * At filescope, multiple definitions of the same variable, which
   can have different linkage, eg static and extern, with only
   some orderings legal
 * Multiple declarations of the same function, which can have different
   parameter names
 * Figuring out whether any module-scope variable is imported, or
   exported, or even if it's local, since 'static' can be used at the
   same time as 'extern' or just nothing.
 * Figuring out, when compiling a dynamic library, which non-static
   functions (and variables) should be exported from the library).
 * A zoo of different integer types, perhaps 30 ways of defining the
   8 basic machine types. Except C likes to use 11 basic types (to
   include plain 'char' and 'long' between 'int' and 'long long') which
   are expected to be distinct from other, even if the same size.
 * Multiple ways of denoting such types ('int long unsigned long' for
   example)
 * Multiple ways of placing 'const', 'static' and 'typedef':
     int const const const unsigned typedef T;
 * Forward declarations of enums and struct tags
 * Three different namespaces: normal, struct/enum tags, and labels
 * Unlimited numbers of distinct block scopes within a function
 * 'break' serving two different roles depending on context
 * The preprocessor, macros and macros expansions (this is an entire
   language by itself)
 * Implementing line continuation using '\', which not many are aware can
   occur in the middle of tokens, eg:
    /\
   /  comment
   in\
   t a;
   "ABC\                   (string with \n split across two lines)
   n"
 * Implementation-defined algorithm to locate any include file deepinside
   a nested set of includes. (You can create your own, but you also have
   to be able to compile existing code!)
 * The requirement to be able to evaluate any arithmetic/logic expression
   at compile-time, if constants are used, even for ?: ternary op
 * The algorithm for how many {...} can be omitted from an initialiser;
   the following is legal; a completely flat (and incomplete) list can be
   provided:
    int A[2][3][4] = {1,2,3,4,5,6,7};
 * The algorithm for designated initialisers, which is harder than most
   people think because designators can be nested: {a.b.c = x}
 * The algorithm for determining inter-member struct padding and end-
   padding
 * VLAs
 * Compound literals (especially elements that are runtime expressions)
 * Switch-case with its crazy syntax
 * Allowing '(********F)(x)' (it it allowed; I can't even remember the
   rules for how many more, or fewer, "*" are allowed relative to the
   type of F.
 * The rules for when ";" is needed after "}".
 * The rules for mixed signed integer operators, ie. whether the
   operation and result is done as signed or unsigned. (I created an
   8 x 8 chart of the combinations; it was weird.)
 Etc.
  That's just off the top of my head.
 

I think K&R C is simpler than C89 that is simpler than C99 etc...
My objective if to find the minimum code generator (backend)  in C and leave the other complexities (like warnings, static analysis, constexpr, preprocessor) to the frond end.
This also facilitates to have more than on backend sharing the job done by the front end.
For instance, I may move all constant expressions from the generated code. So the backend does not have to compute constant expressions any more and it still C89 compatible. I removed enuns for instance.
So my question is not about how to create a simple C compiler but how to separate and move most of the job to the front end creating a very simple backend (code generator) which the input is code C89 compatible.
I believe that K&R C is simpler than C89, which in turn is simpler than C99, and so on.
My goal is to design a minimal code generator (backend) in C reading C89, while delegating other complexities—such as warnings, static analysis, constexpr, and preprocessing—to the front end.
This approach also facilitates using multiple backends that share the work handled by the front end.
For example, I might remove all constant expressions from the generated code, so the backend no longer needs to compute them and remains C89-compatible. I've already removed features like enums, typedefs for instance.
Therefore, my question isn't about how to create a simple C compiler.
Instead, it's about how to shift most of the workload to the front end, resulting in a very simple backend (code generator) that processes C89-compatible code as input.
Does it makes sense?