jit: A header-only, cross-platform JIT compiler library in C. Targets x86-32, x86-64, ARM32 and ARM64
12 points by linkdd
12 points by linkdd
I just took a second look at this project and it smells like LLM slop. The red flags are:
This is really sad to me. I don't want to have to investigate every project that's posted here to check if it's slop before engaging with it. I don't fundamentally object to (partially) vibe-coded projects, but this stuff is clearly so low-effort that it's insulting. At least put in some thought ...
EDIT: Another red flag is that the project claims to be things it it's, as was pointed out by ~olliej (it say it's cross-platform, but it's apparently not working on macOS and it says it's a JIT compiler, but it's more of a JIT assembler). This is something that would likely not happen to a human who engaged deeply with the technical details of the implementation.
As a C or C++ programmer, please never write code like this: https://c.godbolt.org/z/PbcnqjK5f. This isn't Rust where you have pervasive noalias guarantees. The type-based aliasing rules for char pointers in C and C++ are maximally permissive. You should default to being completely explicitly about where you want your loads and stores when writing C code. It's only for non-escaping local variables where you can safely assume the compiler will do an adequate job due to the provenance rules (the only legal way to read or write an object is through a derived pointer).
This particular example I noticed in the code base is especially sad because it's trying to do a host-neutral little-endian store to memory, which should turn into a nop on a little-endian host, but (in addition to the repeated reloads of j->buf and j->len) it ends up blocking that optimization opportunity as well.
I initially read this as "the aliasing causes correctness errors" rather than "sigh, C++ tbaa vs char buffers", and was so very confused :D
Ah, I see now how it could read that way. Yeah, I was just griping about the pervasive inefficiency of the coding style. The stores through the char pointer (in the guise of u8*) are indeed the immediate culprit, but in my opinion there's a broader lesson: you should not rely on load/store elimination when writing C code except for non-escaping locals (and maybe 'restrict' if you're that kind of person).
I don't really think it's right to call this a cross platform JIT - it would be more correct to call it an assembler library as it's just a function for encoding each supported instruction with no abstraction layer at all. e.g. even for something as basic as adding two numbers together you have to write at least two different versions of that function.
Also it says it's compatible with macOS but seems to assume RWX memory is available, which isn't true on the arm ones.
I think they call it a JIT because, in addition to assembling the code, the library also allocates executable memory and runs the code in the process that calls into the library. That's kind of the defining characteristic of a JIT, no? Maybe it should be called a JIT assembler.
I think that they call it a JIT because it's a ripoff of GNU Lightning, which advertises itself as a JIT library. Compare and contrast with an example of GNU Lightning's API.