<div dir="ltr">Hi David,<div><br></div><div>> <span style="font-size:13px"> </span><span style="font-size:13px">ORC in general appears to be a bunch of classes helping you build a JIT.</span></div><div><br></div><div>That sums it up perfectly.</div><div><br></div><div>OrcMCJITReplacement is built with ORC classes, and aims to exactly reproduce MCJIT's behaviour. It's intended as both a proof-of-concept and, if we decide we're going to deprecate the MCJIT code, an upgrade path for people who want to stick with MCJIT's behaviour and the ExecutionEngine interface. We haven't added support for OrcMCJITReplacement to the C API yet, but I expect we will in the future.</div><div><br></div><div>OrcCBindingsStack is, as you guessed, a new JIT implementation that is also built with ORC components. Since we can't easily/efficiently express the combination of ORC components in C, the intent is to build a stack with "the lot", and design a C interface that allows the various pieces to be accessed or disabled. I'm deliberately not going for 100% compatibility with MCJIT's behaviour in OrcCBindingsStack, but I think it should come close enough for 99% of MCJIT users. There is no common interface for all ORC based JITs, but this is the only one that will be in-tree (apart from the MCJIT replacement), so I think that's moot. It might be nice to have a common interface between the OrcCBindingsStack and the interpreter, but I expect that interface would be very limited.</div><div><br></div><div>As I mentioned - there's no nice way to express the combination of ORC components that is possible in C++ in other languages. My aim is just to provide all the functionality that users need within the OrcCBindingsStack, then expose that classes interface as directly as possible.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div>