Re: question about linker

On 10/12/2024 14:56, bart wrote:

On 07/12/2024 16:06, David Brown wrote:

On 06/12/2024 20:20, Bart wrote:

 

If your task to get from A to B was split into two, you'd be happy to do the first part by a fast car, then complete the rest of it on a horse and cart, for no reason at all?
>

>
The comparison was between C to object code (with a real compiler) and from X to C and then to the object code (using a real compiler).  If your beliefs were true that gcc (and other proper C compilers) are incredibly slow, why would it make any difference if someone is starting from X or starting from C?  In both cases, compilation would take a long time - C compilation speed is neither more nor less important whether you are programming in X or C.

 You don't appear to get it.

No, /you/ don't get it.  I did not say that people using language X don't care about the speed of C compilation.  I said it doesn't matter any more or any less than for people writing C.

If you are writing C by hand, then people like you would want to use a more powerful, and therefore slower, compiler, that will analyse that C. It can also take care of the many shortcomings in the language.
 But if the C has been machine-generated, that analysis is no longer relevant. Then you may just want the fastest and simplest conversion.
 

As I said before, the analysis is needed for good optimisation - generating static error checking takes very little extra time when you are optimising.  And often people using C as an intermediary language want optimisation of the C code.
But maybe sometimes they don't, and maybe they want to prioritise the fastest practical compilation speed.  Then if a smaller tool is faster while still being good enough, then it's a benefit to be smaller and/or faster.
The key issue, however, is "good enough".  No one would want to use a C compiler that is small and fast if they are not confident that it generates correct results, or if it does not target their processor or OS, or does not cope with the third-party libraries and code that they want to include.

This was the basis of my use-case for a fast and possibly compact compiler.
 

And you are the only one so far who finds gcc to be inconveniently slow.

 

Okay, to be more accurate, you are the only one /here/ who has said they find compilation of /C/ (not C++) to be /problematically/ slow using gcc or clang.
Is that better?
No one has ever denied that they'd be happier if their compiler ran faster - what people don't, for the most part, want to do is swap their top-shelf compiler with an inferior one simply because it runs faster. (And they even more rarely care about the size on the disk.)