3 ms·

TinyCC is not heavier than would be a JIT generating code of comparable quality. And as for maturity: I have used tcc. It is buggy and lacks useful features.

TinyCC is not heavier than would be a JIT generating code of comparable quality. And as for maturity: I have used tcc. It is buggy and lacks useful features. As a point of comparison: luajit is 600k, and unlike tcc, it actually generates good code.

exebook 4y ago
What are the bugs in tcc you have discovered? I am using it almost every day for many years and yet to encounter a single bug. It generates much slower code than gcc but the point is it does it at least an order of magnitude faster. The code it generates is similar to code generated by Delphi mentioned in a sibling comment. I wish they added linear scan register allocator and inlining of small functions to tinyc wich would not slow down compilation I believe but would make the code much faster.
samatman 4y ago
The solution is clear: Fork TCC to use DynASM, and layout code in a way that's amenable to tracing. Extend LuaJIT to trace the TCC output, teach it to do this across the FFI, implement the hyperblock scheduler and quad-color GC. Make a FreeBSD distribution which uses a one-sector Forth to bootstrap the TCCJIT, which compiles the source code directly into memory, and uses the GC for process allocation and cleanup. The JIT makes the happy path fast, until or unless it changes. Binaries on disk being no longer a useful starting point, they can just be frozen process images. If they break, start again from source code, otherwise, incrementally compile changes into the image while it's in memory. Quitting is just writing it to SSD cache.
raible 4y ago
I have found the libtcc from https://github.com/TinyCC/tinycc https://github.com/TinyCC/tinycc to be absolutely fantastic. I'm using it to instantaneously compile the C output from my hobby language to create a repl. Once I had the compiler in good shape it allowed me to create a 100% compatible interpreter for (basically) free. The libtcc API is minimal. For my needs that has been 100% sufficient and a pleasure to work with.

exebook 4y ago

What are the bugs in tcc you have discovered? I am using it almost every day for many years and yet to encounter a single bug. It generates much slower code than gcc but the point is it does it at least an order of magnitude faster. The code it generates is similar to code generated by Delphi mentioned in a sibling comment. I wish they added linear scan register allocator and inlining of small functions to tinyc wich would not slow down compilation I believe but would make the code much faster.

samatman 4y ago

The solution is clear: Fork TCC to use DynASM, and layout code in a way that's amenable to tracing. Extend LuaJIT to trace the TCC output, teach it to do this across the FFI, implement the hyperblock scheduler and quad-color GC. Make a FreeBSD distribution which uses a one-sector Forth to bootstrap the TCCJIT, which compiles the source code directly into memory, and uses the GC for process allocation and cleanup. The JIT makes the happy path fast, until or unless it changes. Binaries on disk being no longer a useful starting point, they can just be frozen process images. If they break, start again from source code, otherwise, incrementally compile changes into the image while it's in memory. Quitting is just writing it to SSD cache.

raible 4y ago

I have found the libtcc from https://github.com/TinyCC/tinycc https://github.com/TinyCC/tinycc to be absolutely fantastic. I'm using it to instantaneously compile the C output from my hobby language to create a repl. Once I had the compiler in good shape it allowed me to create a 100% compatible interpreter for (basically) free. The libtcc API is minimal. For my needs that has been 100% sufficient and a pleasure to work with.