Re: question about linker

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

On 26/11/2024 16:18, Bart wrote:

On 26/11/2024 18:35, Thiago Adams wrote:

>
(I think I know the answer but I would like to learn more.)
>
I am using C89 as "compiler backend intermediate language".
>
I want a very simple output that could facilitate the construction of a simple C89 compiler focused on code generation.
>
I am removing these features from the generated code.
>
  - typedef
  - enum
  - preprocessor
  - const

>
I don't use them in generated code either. (Only in a brief section at the top to define my prefered type designations.)

  I am generating the prototypes for all functions called.
No includes, no macros.
 The generated code is depending on compiler flags , platform and headers. It is intended to direct usage like in the pipeline
 use my_compiler -> C89 -> CC
 

>

>
At this output, I am generating the prototypes for the functions I call.
>
For instance,
int strcmp( const char* lhs, const char* rhs );
>
is generated as
>
int strcmp( char* lhs, char* rhs );

>
I don't use #include either, not even for standard headers, although gcc doesn't like it when I define my own std library functions. There are ways to shut it up though.
>
>

I am also generating the structs as required (on demand). For the structs I am renaming it because I am generating all structs at global scope.
>
Question:
Does the compiler/linkers? Cares If I am lying about const? Or If rename the structs?
>
I think it does not care, and it seems to work (it compiles and run).

>
I don't know why the linker would care about anything. All it sees are symbol imports and exports.
>
A compiler might care about lack of 'const' in that it could stop it doing doing some optimisations.
>
But it can't report a type mismatch between 'const' and non-'const' types if 'const' has been banished completely.
>
>

 I think GCC has some builtin functions and he can complain if the function prototype differs.
 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.

 I was thinking about literal strings.
 Instead of
 f("abc");
 Generating something like
 char literal_string_1[] = {'a', 'b', 'c', '\0' }; //or numbers global
 f(literal_string_1);

I wouldn't bother with this. How hard is it to deal with string constants? Even a 4KB BASIC from a microcomputer had them!
If you want to simplify, perhaps get rid of 'A' constants. (Unless you think you're likely to be running on an EBCDIC system. However in my compilers, 'A' gets turned into 65 early on anyway.)

The reason I believe compilers already have to do this right? (put strings in a data section)

Data like {'a', 'b', 'c', 0} will be put into in a .data segment. But "abc" will be put by gcc into a .rodata segment, so it's safer. Maybe 'const' will fix the former, but you no longer have that.

So this was one extra simplification I was thinking about.
Also remove  loops (for , while) and switches.

This sort of simplification is of more benefit when /generating/ C code. It's not usually something to worry about in the tool that will turn that intermediate C into native code.
This comes back to the question above.