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

On 13/03/2025 02:36, Lawrence D'Oliveiro wrote:

On Wed, 12 Mar 2025 14:04:16 +0000, bart wrote:
 

Another backend possibility is LLVM, but is vastly more complex, and
just as slow.

 There are lighter-weight alternatives <https://c9x.me/compile/>.

I found it limiting:
* It only works on Linux
* The input (intermediate language or IL) has to be textual SSA format
* The output is AT&T assembly...
* ...which has to be assembled with 'as'...
* ...which has to be linked with 'ld'
* Input and output files need to be piped (?)
When I tested it on bigger inputs (my whole-program tools would produce larg monolithic files) it also got quite slow.
If you compare with my own backend, if built into a standalone program:
* It is 40% the size of QBE (for a version targetting Win64 ABI)
* The input is simpler stack-based code with no SSA requirements
* The input can be either textual IL or via an API
* It can directly create binary executables with no external tools
* It can translate large inputs at millions of intructions per second
* It can optionally directly /execute/ programs in memory
* It can optionally /interpret/ the IL
Normally it's directly incorporated into my two main compilers and is used via it's API.
So lightweight, small-footprint alternatives are quite viable.
Mine is a personal product, but if comparing instead to Tiny C:
* It can be smaller than QBE for an MVP (tcc.exe + headers + lib,
   but when I tried it as backend, no headers were needed)
* The input is standard C code that everyone knows
* The output, like mine, is an executable binary
* It can process input at up to 1M lines per second
* It can also run the input directly in memory
The only downside is its poorer code (mine is somewhat better than tcc's and seems to match QBE on the few benchmarks I tried).