Tiny D suitable for embedded JIT

[Dibyendu Majumdar]

On Wednesday, 24 July 2019 at 10:11:37 UTC, a11e99z wrote:
> Just saw your post and I have some questions:
> - does OMR supports value types or only ref types as JVM(all 
> classes) and Lua(all tables) used?

The OMR JIT engine only knows about primitive types and an array 
type. Classes etc are done by the Java front-end.

> - (too few infos about ORM) did ORM implement different types 
> of GC or just support?

I have no experience with the GC part unfortunately.

> - with what lib you fill more comfort to work: LLVM or ORM?

LLVM has a mature api. OMR's api is still being defined.
OMR's JIT is also not very well tested with C like languages 
where stack values can be aliased. Java doesn't allow that so OMR 
by default assumes that this type of aliasing doesn't happen. I 
have some pending pull requests to enable such aliasing to be 
detected.

> - what lib do best optimization? (probably LLVM)

LLVM was better in my tests. LLVM is obviously being used to 
optimize all sorts of code, whereas OMR's optimizer is used in 
Java primarily. The challenges are somewhat different I think. 
For example, OMR is not very sophisticated when it comes to 
optimizing floating point operations as this is not so important 
in the Java world. Having said that OMR is part of a bigger 
compiler framework at IBM so maybe it has/had features that are 
not being used.

>
> also see the Terra project for Lua http://terralang.org/
> probably its more useful than Ravi cuz the last one try to 
> optimize Lua and Ravi at same time but Terra optimize only 
> Terra-parts with comparable performance as best BLAS/ATLAS-libs 
> do (see PDFs about it). for now Terra looks abandoned but 
> probably cuz nothing add to it.

Well, my opinion is Terra is a redundant language. It tries to 
implement a C like language with Lua like syntax. But LuaJIT can 
already generate machine code and interfaces with C easily. And 
if you need C then use C or Rust or even D ;-)

Sorry this may be OT now.