4 ms·

This person seems to have greenspun themselves a JIT. > It is difficult to get the boundary right between code which can and cannot be dynamically loaded. This

This person seems to have greenspun themselves a JIT. > It is difficult to get the boundary right between code which can and cannot be dynamically loaded. This is the same issue with using embedded dynamic scripting languages like Lua or Python—how much of your application should be written in them? All of it. > JIT compilation requires generating machine code, which is usually a complex process and a large maintenance burden. In practice this means shipping out to a 3rd party library for JIT, and the libraries are typically very large dependencies. Is a c compiler not a large dependency and a maintenance burden?

lelanthran 4y ago
> Is a c compiler not a large dependency and a maintenance burden? Not in my experience, unless you feel that 577KB is a large dependency. For size, ship TinyCC(100kb, also available as a `libcc.so` or `libcc.dll`) and a small stdlib (377kb for musl) with your app and you're done. For the maintenance issue, it's not different from depending on any other library, except that TinyCC and/or Musl are incredibly more mature than any other library you are bound to use (with the exception of SQLite).
- moonchild 4y ago
  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.
HarHarVeryFunny 4y ago
No - he's addressing the linker/loader stage, not compilation. Code is getting fully compiled before it's run, but then there's no linking step, and he also allows individual source files to be updated (recompiled, and dynamically loaded) while the program is running.
jesse__ 4y ago
>> It is difficult to get the boundary right between code which can and cannot be dynamically loaded. This is the same issue with using embedded dynamic scripting languages like Lua or Python—how much of your application should be written in them? > All of it. Hard disagree. Games, which the OP works on, cannot be written in traditional scripting languages due to performance. Thus, games use ad-hoc methods of either segmenting non-critical paths off that can be written (and reloaded) in slow languages, or putting reloadable code in DLLs, which comes with a host of exceptions and special cases you have to keep in mind. What he's proposing is basically writing a clever .o loader that allows you to ignore all of the above, write plain C or (presumably) C++ code, and have it automagically show up in your running process when you hit the compile button. Sounds pretty compelling to me.

lelanthran 4y ago

> Is a c compiler not a large dependency and a maintenance burden? Not in my experience, unless you feel that 577KB is a large dependency. For size, ship TinyCC(100kb, also available as a `libcc.so` or `libcc.dll`) and a small stdlib (377kb for musl) with your app and you're done. For the maintenance issue, it's not different from depending on any other library, except that TinyCC and/or Musl are incredibly more mature than any other library you are bound to use (with the exception of SQLite).

moonchild 4y ago
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.

HarHarVeryFunny 4y ago

No - he's addressing the linker/loader stage, not compilation. Code is getting fully compiled before it's run, but then there's no linking step, and he also allows individual source files to be updated (recompiled, and dynamically loaded) while the program is running.

jesse__ 4y ago

>> It is difficult to get the boundary right between code which can and cannot be dynamically loaded. This is the same issue with using embedded dynamic scripting languages like Lua or Python—how much of your application should be written in them? > All of it. Hard disagree. Games, which the OP works on, cannot be written in traditional scripting languages due to performance. Thus, games use ad-hoc methods of either segmenting non-critical paths off that can be written (and reloaded) in slow languages, or putting reloadable code in DLLs, which comes with a host of exceptions and special cases you have to keep in mind. What he's proposing is basically writing a clever .o loader that allows you to ignore all of the above, write plain C or (presumably) C++ code, and have it automagically show up in your running process when you hit the compile button. Sounds pretty compelling to me.