On 30/05/2018 11:59 AM, Dibyendu Majumdar wrote:
> On Thursday, 24 May 2018 at 22:14:50 UTC, Jonathan Marler wrote:
>> Sad to hear. Was interested to see if this was feasible.  I don't have much experience with the backend but if you're still up for the task, take a look at `dmd/glue.d`.  I don't know how much of the glue layer this includes but it would be a good start.  DMD does have a common "glue layer" shared by DMD, LDC and GDC, so you'd basically need to find the API to build this glue layer and that's what you would use.
>>
>> https://github.com/dlang/dmd/blob/master/src/dmd/glue.d
> 
> Hi - not really as I don't know what this does. In any case my understanding is the interface between the front-end and GDC/LDC is at the level of ASTs.
> 
> Regards

The input is the AST, the output to the backend is some form of IR in essence.

It just maps one understanding of the code to another form, that's all.

On Wednesday, 30 May 2018 at 00:05:52 UTC, rikki cattermole wrote:
>>> https://github.com/dlang/dmd/blob/master/src/dmd/glue.d
>> 
>> Hi - not really as I don't know what this does. In any case my understanding is the interface between the front-end and GDC/LDC is at the level of ASTs.

>
> The input is the AST, the output to the backend is some form of IR in essence.
>
> It just maps one understanding of the code to another form, that's all.

Okay - I was trying to understand if there was some sort of IR that is intermediate stage before codegen - but I couldn't see this. Also the code is quite hard to follow without enough documentation of what's going on. Plus lots of global state I think which is fine for a command line tool but not a JIT engine. But really I looked only for a short while so please correct me if I am wrong.

I decided to use a cut-down version of Eclipse OMR - the backend is much smaller than LLVM, although not as small as I would like. But I hope to create a more trimmed version in due course. (https://github.com/dibyendumajumdar/nj)

Regards

On Thursday, 31 May 2018 at 19:16:28 UTC, Dibyendu Majumdar wrote:
> On Wednesday, 30 May 2018 at 00:05:52 UTC, rikki cattermole wrote:
>>>> https://github.com/dlang/dmd/blob/master/src/dmd/glue.d
>>> 
>>> Hi - not really as I don't know what this does. In any case my understanding is the interface between the front-end and GDC/LDC is at the level of ASTs.
>
>>
>> The input is the AST, the output to the backend is some form of IR in essence.
>>
>> It just maps one understanding of the code to another form, that's all.
>
> Okay - I was trying to understand if there was some sort of IR that is intermediate stage before codegen - but I couldn't see this. Also the code is quite hard to follow without enough documentation of what's going on. Plus lots of global state I think which is fine for a command line tool but not a JIT engine. But really I looked only for a short while so please correct me if I am wrong.
>
> I decided to use a cut-down version of Eclipse OMR - the backend is much smaller than LLVM, although not as small as I would like. But I hope to create a more trimmed version in due course. (https://github.com/dibyendumajumdar/nj)
>
> Regards

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?
- (too few infos about ORM) did ORM implement different types of GC or just support?
- with what lib you fill more comfort to work: LLVM or ORM?
- what lib do best optimization? (probably LLVM)

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.

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.