www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tiny D suitable for embedded JIT

reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
Now that D has a better C option I was wondering if it is 
possible to create a small subset of D that can be used as 
embedded JIT library. I would like to trim the language to a 
small subset of D/C - only primitive types and pointers - and 
remove everything else. The idea is to have a high level assembly 
language that is suitable for use as JIT backend by other 
projects. I wanted to know if this is a feasible project - using 
DMD as the starting point. Should I even think about trying to do 
this?

The ultimate goal is to have JIT library that is small, has fast 
compilation, and generates reasonable code (i.e. some form of 
global register allocation). The options I am looking at are a) 
start from scratch, b) hack LLVM, or c) hack DMD.

Regards
Dibyendu
May 23 2018
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar 
wrote:
 Now that D has a better C option I was wondering if it is 
 possible to create a small subset of D that can be used as 
 embedded JIT library. I would like to trim the language to a 
 small subset of D/C - only primitive types and pointers - and 
 remove everything else. The idea is to have a high level 
 assembly language that is suitable for use as JIT backend by 
 other projects. I wanted to know if this is a feasible project 
 - using DMD as the starting point. Should I even think about 
 trying to do this?

 The ultimate goal is to have JIT library that is small, has 
 fast compilation, and generates reasonable code (i.e. some form 
 of global register allocation). The options I am looking at are 
 a) start from scratch, b) hack LLVM, or c) hack DMD.

 Regards
 Dibyendu
I've recently been looking into how QEMU works and it uses something called TCG (Tiny Code Generator). QEMU works by taking code from another platform/cpu and translates it to TCG, which then gets "jitted" to the instructions for the host. From what I understand, TCG is fairly small. I think it aims to be simple rather than highly optimized, unlike LLVM which allows more complexity for the sake of performance. TCG: https://git.qemu.org/?p=qemu.git;a=blob_plain;f=tcg/README;hb=HEAD
May 23 2018
parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Wednesday, 23 May 2018 at 20:08:53 UTC, Jonathan Marler wrote:
 I've recently been looking into how QEMU works and it uses 
 something called TCG (Tiny Code Generator).  QEMU works by 
 taking code from another platform/cpu and translates it to TCG, 
 which then gets "jitted" to the instructions for the host.

 From what I understand, TCG is fairly small.  I think it aims 
 to be simple rather than highly optimized, unlike LLVM which 
 allows more complexity for the sake of performance.

 TCG: 
 https://git.qemu.org/?p=qemu.git;a=blob_plain;f=tcg/README;hb=HEAD
Thank you for pointing me to this - I wasn't aware of it. I already use something similar - a little more complex product that supports floating points too - NanoJIT. However to my knowledge most of these products do register allocation locally within a basic block - and spill registers when jumping across blocks. This basically results in unacceptable performance in any code that has branching or loops. I could enhance NanoJIT but its written in a way that makes changes difficult (i.e. too many low level optimizations in the code). It seems there is a lack of something in between LLVM and these implementations - either you get all powerful optimizations or you get very little ... my intention is to create something that is small but also has at least some form of global (actually per function) register allocator. I thought of hacking DMD as it favours speed of compilation and simplicity - but what I am not sure about is how easy / difficult it would be to modify DMD (mostly remove stuff). Regards Dibyendu
May 23 2018
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar 
wrote:
 Now that D has a better C option I was wondering if it is 
 possible to create a small subset of D that can be used as 
 embedded JIT library. I would like to trim the language to a 
 small subset of D/C - only primitive types and pointers - and 
 remove everything else. The idea is to have a high level 
 assembly language that is suitable for use as JIT backend by 
 other projects. I wanted to know if this is a feasible project 
 - using DMD as the starting point. Should I even think about 
 trying to do this?

 The ultimate goal is to have JIT library that is small, has 
 fast compilation, and generates reasonable code (i.e. some form 
 of global register allocation). The options I am looking at are 
 a) start from scratch, b) hack LLVM, or c) hack DMD.

 Regards
 Dibyendu
I don't know if this does exactly what you want, but have you seen it? https://forum.dlang.org/thread/bskpxhrqyfkvaqzoospx forum.dlang.org
May 23 2018
parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Thursday, 24 May 2018 at 02:39:18 UTC, Joakim wrote:
 I don't know if this does exactly what you want, but have you 
 seen it?

 https://forum.dlang.org/thread/bskpxhrqyfkvaqzoospx forum.dlang.org
Hi - thanks I hadn't seen it. It is based on LLVM - I already use LLVM and it isn't a small / or fast compiling JIT engine. Regards
May 24 2018
prev sibling next sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar 
wrote:
 The ultimate goal is to have JIT library that is small, has 
 fast compilation, and generates reasonable code (i.e. some form 
 of global register allocation). The options I am looking at are 
 a) start from scratch, b) hack LLVM, or c) hack DMD.
I have been looking at DMD code (mainly the backend stuff) for this ... I think it will be too difficult for me to try to modify it :-( Regards Dibyendu
May 24 2018
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 24 May 2018 at 20:22:15 UTC, Dibyendu Majumdar wrote:
 On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar 
 wrote:
 The ultimate goal is to have JIT library that is small, has 
 fast compilation, and generates reasonable code (i.e. some 
 form of global register allocation). The options I am looking 
 at are a) start from scratch, b) hack LLVM, or c) hack DMD.
I have been looking at DMD code (mainly the backend stuff) for this ... I think it will be too difficult for me to try to modify it :-( Regards Dibyendu
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
May 24 2018
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
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
May 29 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
May 29 2018
parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
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
May 31 2018
parent reply a11e99z <black80 bk.ru> writes:
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.
Jul 24
parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
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.
Jul 26
prev sibling parent reply MrSmith <mrsmith33 yandex.ru> writes:
On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar 
wrote:
 Now that D has a better C option I was wondering if it is 
 possible to create a small subset of D that can be used as 
 embedded JIT library. I would like to trim the language to a 
 small subset of D/C - only primitive types and pointers - and 
 remove everything else. The idea is to have a high level 
 assembly language that is suitable for use as JIT backend by 
 other projects. I wanted to know if this is a feasible project 
 - using DMD as the starting point. Should I even think about 
 trying to do this?

 The ultimate goal is to have JIT library that is small, has 
 fast compilation, and generates reasonable code (i.e. some form 
 of global register allocation). The options I am looking at are 
 a) start from scratch, b) hack LLVM, or c) hack DMD.

 Regards
 Dibyendu
You may like the project of a compiler I am doing https://github.com/MrSmith33/tiny_jit TLDR: fully in D. No dependencies. Currently for amd64 + Win64 calling convension. P.S. Sorry for late response.
May 28 2018
next sibling parent dell support <satanicendeavour gmail.com> writes:
On Monday, 28 May 2018 at 19:24:58 UTC, MrSmith wrote:
 On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar 
 wrote:
 [...]
You may like the project of a compiler I am doing https://github.com/MrSmith33/tiny_jit TLDR: fully in D. No dependencies. Currently for amd64 + Win64 calling convension. P.S. Sorry for late response.
I read your comment, I have a solution for you can take A help of https://dellsupports.org/ to solve the problem.
May 29 2018
prev sibling parent Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Monday, 28 May 2018 at 19:24:58 UTC, MrSmith wrote:

 You may like the project of a compiler I am doing 
 https://github.com/MrSmith33/tiny_jit
 TLDR: fully in D. No dependencies. Currently for amd64 + Win64 
 calling convension.
Cool - I will keep an eye on it. Regards
May 29 2018