clauf VS omr

Want to see your mind blown? Check out cling, a (sort of) C and C++ interpreter (it's a REPL). Or the work in progress, live-developed clauf, a real C interpreter.

I'm currently writing an interpreter for C, I plan on adding a JIT at some point as well: https://github.com/foonathan/clauf

I've continued working on developing my C interpreter: https://github.com/foonathan/clauf

I've been working on a generic bytecode interpreter the last couple of months. It reached a point where I needed to test it in a real compiler, so I've started writing a C interpreter.

Source code is available here: https://github.com/foonathan/clauf

Thank you.

There is also OMR

https://github.com/eclipse/omr

but I'm not sure how powerful that is.

I started writing a simple multithreaded interpreter that processes an imaginary assembly. Here's a program in that imaginary assembly that sends integers to other threads and then sends a jump instruction to another thread to jump to some code.

  threads 25

I am interested in this too. I would do different tradeoffs. I am more interested in optional garbage collection, the parallelism and async story in the language such as threading and coroutines or both together.

I suspect combining garbage collection, exceptions, closures, tail call optimisation, parallelism, JIT compilation and coroutines is difficult to do orthogonally.

On eatonphil's discord someone recently shared this link: This is a framework for building high performance language runtimes

https://github.com/eclipse/omr

I am currently implementing a programming language and compiler and interpreter in my multiversion-concurrency-control repository.

https://github.com/samsquire/multiversion-concurrency-contro...

Git Crash Course by eclipse/omr project at github.com

I like this part "We continue to employ dozens of developers that work directly and openly in the Eclipse OMR and Eclipse OpenJ9 projects at GitHub. IBM doesn’t produce a separate enterprise version of OpenJ9; we don’t hold back any of the innovation in our runtime."