Jens Mueller wrote:
> Moritz Maxeiner wrote:
> > On Monday, 18 March 2013 at 14:51:00 UTC, Jens Mueller wrote:
> > >Moritz Maxeiner wrote:
> > >>On Monday, 18 March 2013 at 13:50:29 UTC, Jens Mueller wrote:
> > >>
> > >>I'll to that, then. I'm currently working on the D API, but I'll
> > >>try
> > >>to get the copied deimos compatible project started in the next
> > >>couple of days.
> > >
> > >Sounds good. I'm going to write the documentation this evening.
> > 
> > Awesome, thanks.
> 
> Took longer than expected.
> http://jkm.github.com/phobos/deimos.html
> I will post this on digitalmars.D whether it is possible to add it to
> the official site and to collect feedback.

Updated documentation http://jkm.github.com/d-programming-language.org/deimos.html

Jens

On Friday, 22 March 2013 at 08:34:11 UTC, Jens Mueller wrote:
> Updated documentation
> http://jkm.github.com/d-programming-language.org/deimos.html

NIice, but conforming to the following would create too much work for me:

"For each file a proper module declaration has to be provided"

Since files in llvm-c appear and dissappear across different LLVM versions, you would eventually have to keep files around that are many LLVM versions old.

In llvm-d I use three files for the three main purposes: types, constants and functions. With ctfe having compatibility is trivial in that setup, with many more files that would be increasingly more work. Especially so since there are llvm-c headers with only few lines of code and creating an entire D module for that purpose seems wasteful and hurts maintainability or me.

"So far, each C header file was renamed to a D module. Next the contents of each module will be adjusted. In general following the advices from interfacing to c is recommended.

The D files should try to do as least modifications as possible to simplify updates of the C headers. This includes leaving comments intact."

Again, by cutting out everything but the actual code dealing with updates/new versions of LLVM becomes a lot easier. Dealing with the copyright issue can be done in compliance with LLVM's license by including LLVM's license note and copyright note in the documentation, in this case the README.md.

If I can make a deimos-llvm project the way I described it previously (by simply stripping out the shared lib code) I'll do it, because the changes would be few and maintaining both projects would be trivial; but if all deimos projects *have* to conform to these - in my case harmful - conventions, you might be better off with asking someone else to take over your deimos-llvm project.

Moritz Maxeiner wrote:
> On Friday, 22 March 2013 at 08:34:11 UTC, Jens Mueller wrote:
> >Updated documentation http://jkm.github.com/d-programming-language.org/deimos.html
> 
> NIice, but conforming to the following would create too much work for me:
> 
> "For each file a proper module declaration has to be provided"
> 
> Since files in llvm-c appear and dissappear across different LLVM versions, you would eventually have to keep files around that are many LLVM versions old.

Really. I thought the C API was expected to be more stable.
Also it's not yet clear how to manage multiple versions of the same
library in Deimos. But your feedback helps sharpening which issues
should be addressed by Deimos. Thanks.

> In llvm-d I use three files for the three main purposes: types, constants and functions. With ctfe having compatibility is trivial in that setup, with many more files that would be increasingly more work. Especially so since there are llvm-c headers with only few lines of code and creating an entire D module for that purpose seems wasteful and hurts maintainability or me.

I just did LLVM 3.1 and I get
$ find llvm -name '*.d' | xargs wc -l                                                                      0
    45 llvm/c/initialization.d
  2607 llvm/c/core.d
    97 llvm/c/object.d
    63 llvm/c/linktimeoptimizer.d
   523 llvm/c/enhanceddisassembly.d
    56 llvm/c/analysis.d
   136 llvm/c/executionengine.d
    38 llvm/c/transforms/vectorize.d
    72 llvm/c/transforms/ipo.d
    82 llvm/c/transforms/passmanagerbuilder.d
   125 llvm/c/transforms/scalar.d
   294 llvm/c/lto.d
    47 llvm/c/bitwriter.d
   166 llvm/c/disassembler.d
   115 llvm/c/targetmachine.d
    67 llvm/c/bitreader.d
   286 llvm/c/target.d
  4819 total

I assume you are referring to those files that are under 100 lines.

> "So far, each C header file was renamed to a D module. Next the contents of each module will be adjusted. In general following the advices from interfacing to c is recommended.
> 
> The D files should try to do as least modifications as possible to simplify updates of the C headers. This includes leaving comments intact."
> 
> Again, by cutting out everything but the actual code dealing with updates/new versions of LLVM becomes a lot easier. Dealing with the copyright issue can be done in compliance with LLVM's license by including LLVM's license note and copyright note in the documentation, in this case the README.md.
> 
> If I can make a deimos-llvm project the way I described it previously (by simply stripping out the shared lib code) I'll do it, because the changes would be few and maintaining both projects would be trivial; but if all deimos projects *have* to conform to these - in my case harmful - conventions, you might be better off with asking someone else to take over your deimos-llvm project.

I'm not the one to decide this. Probably this is the reason why I'm
writing the documentation because there is de facto no clear decision on
what needs to be done to warrant Deimos inclusion.
Assuming I can spend some time on deimos-llvm would you switch? I mean I
have 3.1. Adding 3.2 is possible. But I would need you to use it and
check that it works for your higher level API.

Jens

On Friday, 22 March 2013 at 17:16:26 UTC, Jens Mueller wrote:
> Moritz Maxeiner wrote:
>> On Friday, 22 March 2013 at 08:34:11 UTC, Jens Mueller wrote:
>> >Updated documentation
>> >http://jkm.github.com/d-programming-language.org/deimos.html
>> 
>> NIice, but conforming to the following would create too much work
>> for me:
>> 
>> "For each file a proper module declaration has to be provided"
>> 
>> Since files in llvm-c appear and dissappear across different LLVM
>> versions, you would eventually have to keep files around that are
>> many LLVM versions old.
>
> Really. I thought the C API was expected to be more stable.
> Also it's not yet clear how to manage multiple versions of the same
> library in Deimos. But your feedback helps sharpening which issues
> should be addressed by Deimos. Thanks.

Afaict in the rang from 3.1 to 3.3svn it has happened two times:
- The "Enhanced Disassembly" header exists in 3.2, but has vanished in the trunk.
- The "Linker" header has been added in 3.2 and it is also an example of the short files. It contains only a single function "LLVMLinkModules" and a single enum for one of the that function's parameters.

> Assuming I can spend some time on deimos-llvm would you switch? I mean I
> have 3.1. Adding 3.2 is possible. But I would need you to use it and
> check that it works for your higher level API.

I could add support for it via a version flag. E.g. set -version=DEIMOS_LLVM or something similar. That way someone using llvm-d can choose to either use the included C bindings or use your deimos compatible ones. My only concern would be that the LLVM C function signatures would have to be translated in the same, or at least a compatible way in both my C bindings and the deimos ones, so using either of them would just be a matter of which import statement to use.
Since I've translated them pretty much strictly according to the "interfacing with c" guideline that's probably the case already, but I'd have to try it out first.

A couple of more things I forgot to mention:

- You will need to additionally add bindings for all the LLVMInitialize"TARGET_NAME"{TargetInfo,Target,TargetMC,AsmParser,AsmPrinter,Disassembler} functions. They reside inside the target libraries and not inside llvm-c, which is why only translating the C API won't get you them. The LLVMInitializeNativeTarget function , which is necessary to use LLVM for jitting - otherwise you'll only have access to interpreting, which is horribly slow - uses them, but it is a static inline function and as such does not get exposed because LLVM builds with the option to hide all inline functions. That is not a problem for C, as this function gets defined in the header, but for D it is a big problem, because you cannot access LLVMInitializeNativeTarget. You need to recreate it in D by using all the functions it references. Of course, you'll also have to accomodate the fact that these referenced functions may or may not be compiled in depending on which target where selected when compiling LLVM.
I have done so in llvm.c.functions of llvm-d so if you want you could use that as a reference.
- When supporting multiple LLVM versions, we need to use the same method. I currently use a version flag, specifically "-version=LLVM_X_Y" for LLVM X.Y release (including the trunk) and set two variables, a string "LLVM_VersionString" (for some C bindings internal stuff) and a float "LLVM_Version" (for static ifs). The relevant module is llvm.c.versions.
- It would be nice if deimos-llvm had a module that publically imports all other modules, e.g. "all" or "llvm".

On Friday, 15 March 2013 at 17:40:36 UTC, Moritz Maxeiner wrote:
> Hi, I would like to announce llvm-d, which provides LLVM bindings for D.

Greetings,

I hope you don't mind a bit of a support request, but I'm having difficulties getting it to work:

https://gist.github.com/Zshazz/c7dbd6eee0b6b242252b

The code is from http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html but with slight updates (and obviously fixing syntax to work in D).

This is running on Manjaro Linux (a derivative of Archlinux) and using DMD v2.062.

Thanks for your time.

Moritz Maxeiner wrote:
> On Friday, 22 March 2013 at 17:16:26 UTC, Jens Mueller wrote:
> >Moritz Maxeiner wrote:
> >>On Friday, 22 March 2013 at 08:34:11 UTC, Jens Mueller wrote:
> >>>Updated documentation http://jkm.github.com/d-programming-language.org/deimos.html
> >>
> >>NIice, but conforming to the following would create too much
> >>work
> >>for me:
> >>
> >>"For each file a proper module declaration has to be provided"
> >>
> >>Since files in llvm-c appear and dissappear across different
> >>LLVM
> >>versions, you would eventually have to keep files around that
> >>are
> >>many LLVM versions old.
> >
> >Really. I thought the C API was expected to be more stable.
> >Also it's not yet clear how to manage multiple versions of the
> >same
> >library in Deimos. But your feedback helps sharpening which issues
> >should be addressed by Deimos. Thanks.
> 
> Afaict in the rang from 3.1 to 3.3svn it has happened two times:
> - The "Enhanced Disassembly" header exists in 3.2, but has vanished
> in the trunk.
> - The "Linker" header has been added in 3.2 and it is also an
> example of the short files. It contains only a single function
> "LLVMLinkModules" and a single enum for one of the that function's
> parameters.

I see.
I need to think about to handle the different versions.

> >Assuming I can spend some time on deimos-llvm would you switch? I
> >mean I
> >have 3.1. Adding 3.2 is possible. But I would need you to use it
> >and
> >check that it works for your higher level API.
> 
> I could add support for it via a version flag. E.g. set
> -version=DEIMOS_LLVM or something similar. That way someone using
> llvm-d can choose to either use the included C bindings or use your
> deimos compatible ones. My only concern would be that the LLVM C
> function signatures would have to be translated in the same, or at
> least a compatible way in both my C bindings and the deimos ones, so
> using either of them would just be a matter of which import
> statement to use.
> Since I've translated them pretty much strictly according to the
> "interfacing with c" guideline that's probably the case already, but
> I'd have to try it out first.

I would like that. Probably the signatures are already the same. There is not much freedom when translating them.

Jens

Moritz Maxeiner wrote:
> A couple of more things I forgot to mention:
> 
> - You will need to additionally add bindings for all the LLVMInitialize"TARGET_NAME"{TargetInfo,Target,TargetMC,AsmParser,AsmPrinter,Disassembler}
> functions. They reside inside the target libraries and not inside
> llvm-c, which is why only translating the C API won't get you them.
> The LLVMInitializeNativeTarget function , which is necessary to use
> LLVM for jitting - otherwise you'll only have access to
> interpreting, which is horribly slow - uses them, but it is a static
> inline function and as such does not get exposed because LLVM builds
> with the option to hide all inline functions. That is not a problem
> for C, as this function gets defined in the header, but for D it is
> a big problem, because you cannot access LLVMInitializeNativeTarget.
> You need to recreate it in D by using all the functions it
> references. Of course, you'll also have to accomodate the fact that
> these referenced functions may or may not be compiled in depending
> on which target where selected when compiling LLVM.

Do you happen to know why these functions are not declared in the header files. I mean when using the C interface in C I wouldn't even know that these functions exist.

> I have done so in llvm.c.functions of llvm-d so if you want you
> could use that as a reference.
> - When supporting multiple LLVM versions, we need to use the same
> method. I currently use a version flag, specifically

Yes. Handling different version of the same library hasn't been addressed by Deimos.

> "-version=LLVM_X_Y" for LLVM X.Y release (including the trunk) and
> set two variables, a string "LLVM_VersionString" (for some C
> bindings internal stuff) and a float "LLVM_Version" (for static
> ifs). The relevant module is llvm.c.versions.

That's an option.

> - It would be nice if deimos-llvm had a module that publically imports all other modules, e.g. "all" or "llvm".

I think I leave this up to a higher layer API.
Deimos should provide an API that resembles the C api whenever possible.

Jens

On Saturday, 23 March 2013 at 04:34:53 UTC, Chris Cain wrote:
> On Friday, 15 March 2013 at 17:40:36 UTC, Moritz Maxeiner wrote:
>> Hi, I would like to announce llvm-d, which provides LLVM bindings for D.
>
> Greetings,
>
> I hope you don't mind a bit of a support request, but I'm having difficulties getting it to work:
>
> https://gist.github.com/Zshazz/c7dbd6eee0b6b242252b
>
> The code is from http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html but with slight updates (and obviously fixing syntax to work in D).
>
> This is running on Manjaro Linux (a derivative of Archlinux) and using DMD v2.062.
>
> Thanks for your time.

No problem at all. There is an example quoted in the README and how to compile it, so without further information form your side I don't know what the problem is. To get the example from the README working:
- Download/Clone the github repo into a folder (let's say llvm-d)
- cd into that folder
- execute rdmd -L-ldl sample/multithreaded.d

The need for the -dl flag is only for POSIX platforms and will be gone with the next commit as I have included a lib pragma.

If the above doesn't help could you please tell me what exactly you have done and at which point you have the problems?

-- Moritz

On Saturday, 23 March 2013 at 09:30:07 UTC, Jens Mueller wrote:
> Moritz Maxeiner wrote:
>> A couple of more things I forgot to mention:
>> 
>> - You will need to additionally add bindings for all the LLVMInitialize"TARGET_NAME"{TargetInfo,Target,TargetMC,AsmParser,AsmPrinter,Disassembler}
>> functions. They reside inside the target libraries and not inside
>> llvm-c, which is why only translating the C API won't get you them.
>> The LLVMInitializeNativeTarget function , which is necessary to use
>> LLVM for jitting - otherwise you'll only have access to
>> interpreting, which is horribly slow - uses them, but it is a static
>> inline function and as such does not get exposed because LLVM builds
>> with the option to hide all inline functions. That is not a problem
>> for C, as this function gets defined in the header, but for D it is
>> a big problem, because you cannot access LLVMInitializeNativeTarget.
>> You need to recreate it in D by using all the functions it
>> references. Of course, you'll also have to accomodate the fact that
>> these referenced functions may or may not be compiled in depending
>> on which target where selected when compiling LLVM.
>
> Do you happen to know why these functions are not declared in the header
> files. I mean when using the C interface in C I wouldn't even know that
> these functions exist.

I suspect it is because of LLVM's internal structure. Each supported target is presented by its own directory and they are afaict mutually independent from one another, "so their initialiation routines should be part of them themselves" I would guess, but I don't know, sorry.
Also, when using the C interface in C there is little need to know them because they get encapsulated in LLVMInitializeAllTargets and LLVMInitializeNativeTarget.

>
> I think I leave this up to a higher layer API.
> Deimos should provide an API that resembles the C api whenever possible.

Okay, I'll put one into llvm-d one then.

-- Moritz