Re: question about linker

On 11/26/2024 2:00 PM, Bart wrote:

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.
 

My usual list of things:
   Drop stuff that is pretty much never used;
     Such as digraphs and trigraphs.
   Drop stuff that is very rarely used:
     Such as C's bitfield declarations;
   Simplify the type syntax.
     Allow declaration parsing without checking prior typedefs;
     Eliminate some syntactic ambiguities;
   Simplify the type-system:
     Drop complex cases (*1).
*1: Or, what probably to keep:
   Primitive types;
   Pointer to a primitive type (up to N levels);
   Pointer to a structure;
   Pointer to a function.
An array might become an aspect of a declaration rather than the type of the declaration (so, values of with an array type might no longer exist, only a pointer to a type, with the destination happening to be an array). Loading an array into an expression would implicitly always decay to a pointer to the primitive type. In this model, things like multidimensional arrays being part of the type-system would essentially disappear (but can be done in other ways, such as via manual calculation or pointer indirection).
One could possibly also allow for more implementation-defined limits, say:
A function may not contain more than 256 local variables;
A function may not have more than 16 or 32 arguments;
A function may not have more than 16K of local array or structure storage;
A function may not contain more than 4092 assignments to the same local variable;
A "switch()" may not contain more than 1020 "case" labels;
...
Possibly, the conceptual model for by-value structure passing could be modified:
The concept of the structure-type and data storage could be split into a conceptually paired structure-pointer type and an "untyped blob of bytes" type;
Struct assignment could be defined to behave "as-if" it were a memcpy from one blob of bytes to another;
By-value structs might have a minimum alignment padding larger than that otherwise implied for the structure (say, for example, if any structure larger than 64 bytes was implicitly padded to a multiple of 16 bytes, and one larger than 32 to a multiple of 8);
Using a structure in an expression will cause it to decay to a pointer in a similar way to arrays.
Similarly, may drop the distinction between "a.b" and "a->b" as serving little real purpose.
A lot of this would potentially break source compatibility with C in lots of subtle ways, but could allow for a simpler compiler.

>
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.)
 

My compiler normally assumes one of:
   Plain ASCII;
   Codepage-1252;
   UTF-8;
   UTF-16.
My project also tends to use a modified version of the Unicode space where the C1 control codes are dropped in favor of interpreting them as the corresponding 1252 characters. This allows treating 8859-1 and 1252 scenarios as equivalent, and because actually using the C1 control codes is very rare.
It could be considered to some extent context-sensitive though.

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.
 

BGBCC generally uses ".strtab":
   ".data", read/write global data;
   ".rodata", read-only global data;
   ".strtab", strings table.

 

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.
 

Yeah.
If one has a full parser, this would save very little.
It would make sense if one is doing a limited parser.
But, then, it may also make sense to limit *any* sort of complex expressions.
Say:
   z=x*y+3;
Is no longer valid and needs to be decomposed:
   t0=x*y;
   z=t0+3;
This could then allow the compiler to operate one line at a time.
But, at that point, almost may as well drop down to a BASIC or FORTRAN style syntax.