Re: question about linker

On 27/11/2024 07:29, Waldek Hebisch wrote:

Thiago Adams <thiago.adams@gmail.com> 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
>
>
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 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?

 1) campilers for embedded targets care very much about const.  const
    qualified arrays go into read-only data section which is typically
    located in flash.  Other arrays go to RAM.  Embedded targets
    frequently have very small RAM and larger flash, so after
    dropping const program may no longer fit in available RAM.

I think your comment applies for const in declarations like
const int i = 1;
I used to find const confusing, as it sometimes meant 'read-only' and other times 'immutable.'
Now, it seems less confusing to me. When const is used with variables that can be initialized (init-declarator), it acts as 'immutable', meaning the storage is constant.
In other contexts, like function parameters, const means 'read-only' because we don’t know if the storage is constant or not.
 From the backend perspective this const used as 'immutable' maybe is useful. The other one "ready only" is that I think can be ignored by this simpler C89, in case it does not cause linker problems.

2) Linkers for non-standard formats may do whatever they please.  In
    particular compiler could emit type information and linker may
    check it.

3) If you want later C, then C89 as intermediate format will not
    work, basically it is hard to implement VLA-s without VLA-s
    in target language.  In principle you can replace VMT-s by
    pointer arithmetic, but then you have nontrivial chunk of
    code generator inside your front end.
 

I think in some cases generated C code can have limitations. I remember to read, probably on "the design and evolution of C++" that exceptions were hard to implement and this was a motivation to not generate C code anymore at the CFront compiler.