mir VS LuaJIT

MIR comes from the Rubyverse and isn't related to LLVM MLIR.

https://github.com/vnmakarov/mir?tab=readme-ov-file#mir

When you say a fork of LLVM, am I correct in assuming that you specifically mean a fork of Clang? I don't see how the compiler backend would affect support for language extensions, regardless of whether it's an exception to that such as Tcc, Cproc, the MIR C jitter, lacc, 8cc, 9cc, and chibicc. Most of those are not for production, excluding Cproc and Tcc (at least according to Suckless or Oasis).

MIR

I've learned about them, staring endlessly at the luajit source code - for example (not the best example I can remember, but still) - https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/lj_lex.h#L15

there it defines a TOKEN(_,__) macro generator the luajit token/keywords and later generates enums with them.

I've used it recently to wrap a "C" api with lots of functions, such that I can redirect calls.

> This is strictly about how much memory LuaJIT can address on that platform

No it is not.

https://github.com/LuaJIT/LuaJIT/issues/285#issuecomment-197...

> If your workload fits inside 2 GiB (IIRC) it will be fast.

This has nothing to do with the issue being mentioned here.

I love this idea so much.

I got stuck at how to tackle "new language doesn't compile with a standard C compiler" for many times, but my solution is much worse than yours: Like LuaJIT, they left one unreadable "minilua" C file [1] to bootstrap some stuff, we could have a source-code version of the "new C" compiler, compile things twice. That sounds bad.

For languages with a very advanced type system that compiles to C, I could only think of Koka [2], which translates the "algebraic effect and handlers" code into pure C, achieving pure C generators, coroutines and async/await without the support of setjmp/setcontext. But the generated C code is unreadable, I would definitely think about how to handle the readability and debugging issue with sidecar files.

[1]: https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/host/minilua....

[2]: https://koka-lang.github.io/koka/doc/book.html

Python may not be the best example, but some other languages also exist and are both less "weird" than https://github.com/denysdovhan/wtfjs and fast (e.g. see http://luajit.org/ which is far less complex than V8).

You're probably referring to what he wrote here [1]:

> Is the sponsor prepared to sponsor the initial review and integration into the LuaJIT default code base by me?

> Is the sponsor prepared to sponsor the inevitable initial bug fixes and the extra effort for continued maintenance that a new architecture entails?

Also, I should have be clearer about the new GC I linked to: I have not seen Mike say anything about it, and I wouldn't be surprised in the least if he rejects it and writes his own, because he had his own plan for one. It seems super difficult to get anything past him.

[1] https://github.com/LuaJIT/LuaJIT/issues/628#issuecomment-716...

Indeed, LuaJIT support for Windows/Arm64 was added in https://github.com/LuaJIT/LuaJIT/issues/593, and there’s experimental out-of-tree support for Windows/Arm64EC in https://github.com/LuaJIT/LuaJIT/issues/1096

The issue linked in the sibling comment is the main one, but for a specific example them having reservations about a feature in more recent version, there's this:

https://github.com/LuaJIT/LuaJIT/issues/1013#issuecomment-16...

> are suppression files ever actually used due to an actual false positive,

There used to be one in LuaJIT because it had an optimized string comparison that compared outside of the allocation (which is allowed by the OS as long as you don't cross a page boundary, which LuaJIT's allocation algorithm made sure it never did)

The suppression was removed in https://github.com/LuaJIT/LuaJIT/commit/ff34b48ddd6f2b3bdd26... when the string hashing got a new implementation

For an implementation of logical immediate encoding without the loop, see https://github.com/LuaJIT/LuaJIT/blob/04dca7911ea255f37be799...