Re: Motivation of tccc mainatainers (Was: Python recompile)

On 12/03/2025 08:53, Michael S wrote:

On Wed, 12 Mar 2025 00:43:51 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
 

On Wed, 12 Mar 2025 00:58:43 +0200, Michael S wrote:
>

BTW, I think that tcc is doing damage to itself by refusal to
support ucrt variant of Microsoft's C RTL.

>
Damaging their market share and hurting their revenues?

 I don't know what exactly motivates people to continue to maintain tcc
after all fun things, like, for example, writing working compiler*, are
done years ago. But it seems that extending user base and increasing
satisfaction of existing users is not totally unimportant for this
people.

Tcc is a more important product than you might think. It is a compact program of 200-300KB that can turn C source code into binary.
It's looked down upon by most people here. But if you've implemented a language that generates intermediate C for example, then it will depend on a C compiler to complete the process.
Tcc provides simple solution with a small footprint, that is also very, very fast. A backend solution like gcc will be at least 50MB is you strip all the necessary stuff (some 0.7GB typically), or well north of 100MB with Clang.
They will also be 20-30 times slower even to generate the same code quality. Tcc's code is not great but it's certainly interpreter-speed either, which is another backend option.
Another backend possibility is LLVM, but is vastly more complex, and just as slow.
Note that for this kind of application, the input C source should already be verified by the front-end compiler. No deep analysis is needed. If there are C compiler errors, it will be a fault in the front-end.
   c:\cx>tim gcc lua.c
   Time: 3.359
   c:\cx>tim tcc lua.c
   Time: 0.130

 --------
* - writing compiler is not my personal idea of fun, but I am pretty
   sure that it was considered fun by original tcc developers
 

I think the original was meant to be very small, like 2000 lines or something.