Hi there LLVM is a great idea, congratulations. Do you mind if I give you a little bit of constructive criticism from the point of view of a developer who would like to use LLVM as a back-end? I will write this email from the point of view of MS Windows, but the same applies to MacOS and Linux. LLVM is difficult/awkward to use in a real-world environment/situation. To solve this problem, take a hint from the developer of the popular SQLite: http://www.sqlite.org/download.html On that page, you can see that sqlite.org provides a precompiled sqlite DLL for MS Windows. That is great, because it means that a developer can simply grab the compiled DLL, and start using it, incorporating it into their project, without having to go through all of the difficulty of compiling SQLite (or LLVM) themselves, and without having to make their program awkwardly invoke the LLVM command-line tools. Furthermore, an LLVM DLL should go "all the way". Your "llc" tool is supposed to be a back-end tool, but it is more like an almost-back-end tool, because it generates assembly language to a text file, rather than a native code executable program file. So we need a precompiled LLVM DLL that can be invoked, passing in LLVM bytecode, and it should generate a native code ready-to-execute MS Windows .EXE or .DLL file. This would make it more practical to use in a real-world situation. GCC needs to be cut out of the back-end picture. Currently, it is impossible to use LLVM as a back-end without GCC because GCC is still required to convert the assembly language .S text file into a native machine code .EXE or .DLL file. It is fine that you are using GCC as an example front-end, but unfortunately you are also using it in the back-end as well. A back-end that is totally free of GCC is needed. Thanks for reading. Mark
On Sat, 2008-05-10 at 19:42 +1000, kr512 wrote:> On that page, you can see that sqlite.org provides a > precompiled sqlite DLL for MS Windows. That is great, > because it means that a developer can simply grab the > compiled DLL, and start using it, incorporating it into > their project, without having to go through all of the > difficulty of compiling SQLite (or LLVM) themselves, and > without having to make their program awkwardly invoke the > LLVM command-line tools.Apparently the APIs in the LLVM docs missed your attention. They're sneaky that way because, you know, they just form the bulk of available documentation. The command-line tools are convenience wrappers around the APIs, not the other way around.> Furthermore, an LLVM DLL should go "all the way". Your > "llc" tool is supposed to be a back-end tool, but it is more > like an almost-back-end tool, because it generates assembly > language to a text file, rather than a native code > executable program file.I'm sure the LLVM lead (Chris, was it?) will gratefully accept any such functioning, tested code you can supply that generates the native object format you prefer. This is, after all, how open source projects work for the most part.> So we need a precompiled LLVM DLL that can be invoked, > passing in LLVM bytecode, and it should generate a native > code ready-to-execute MS Windows .EXE or .DLL file. This > would make it more practical to use in a real-world > situation.So... here's a thought. Why don't you do that one-time work and host the compiled package up on a web page somewhere as a service to this open source community that will so eagerly embrace it? You will certainly not be criticized for it and will likely instead have your name sung to the heavens by the myriad of Windows developers who've wanted to use LLVM but haven't had the opportunity because of the barrier of source code distribution.> GCC needs to be cut out of the back-end picture. Currently, > it is impossible to use LLVM as a back-end without GCC > because GCC is still required to convert the assembly > language .S text file into a native machine code .EXE or > .DLL file.So... your world doesn't include "gas" or "nasm" or any other such assembler? You know. The "gas" that GCC itself uses to assemble the .S files? The "nasm" that's freely available on a bewildering variety of native platforms? That's a mighty strange world to be living in, pardner.> A back-end that is totally free of GCC is needed.Again I'm sure that Chris (?) will gladly accept any functioning, tested source that implements this tossed into the pot that is the open source project LLVM. -- Michael T. Richter <ttmrichter at gmail.com> (GoogleTalk: ttmrichter at gmail.com) So much of what we call management consists in making it difficult for people to work. (Peter Drucker) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080511/59406b9b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080511/59406b9b/attachment.sig>
On May 10, 2008, at 4:42 AM, kr512 wrote:> > Hi there > > LLVM is a great idea, congratulations. Do you mind if I > give you a little bit of constructive criticism from the > point of view of a developer who would like to use LLVM as a > back-end? > > I will write this email from the point of view of MS > Windows, but the same applies to MacOS and Linux. > > LLVM is difficult/awkward to use in a real-world > environment/situation. To solve this problem, take a hint > from the developer of the popular SQLite: > http://www.sqlite.org/download.html > > On that page, you can see that sqlite.org provides a > precompiled sqlite DLL for MS Windows. That is great, > because it means that a developer can simply grab the > compiled DLL, and start using it, incorporating it into > their project, without having to go through all of the > difficulty of compiling SQLite (or LLVM) themselves, and > without having to make their program awkwardly invoke the > LLVM command-line tools.Question: have you actually downloaded and built a copy of LLVM? I'm going to guess that the answer is no, because otherwise you would have realized that LLVM is, in fact, already built as a set of libraries. The tools (llc, lli, opt, etc.) are just thin wrappers around these libraries. They're only meant for use by LLVM developers. Client applications are expected to use the LLVM APIs. For examples of using it programmatically, see http://llvm.org/docs/tutorial/> > > Furthermore, an LLVM DLL should go "all the way". Your > "llc" tool is supposed to be a back-end tool, but it is more > like an almost-back-end tool, because it generates assembly > language to a text file, rather than a native code > executable program file. > > So we need a precompiled LLVM DLL that can be invoked, > passing in LLVM bytecode, and it should generate a native > code ready-to-execute MS Windows .EXE or .DLL file. This > would make it more practical to use in a real-world > situation. > > GCC needs to be cut out of the back-end picture. Currently, > it is impossible to use LLVM as a back-end without GCC > because GCC is still required to convert the assembly > language .S text file into a native machine code .EXE or > .DLL file. >Not true. Two things are required: an assembler and a linker. GCC uses both behind the scenes (gas and ld). The invocation of GCC in the example docs you cited is purely for convenience. It could equally well be replaced with invocations of gas and ld. As a side note, there IS an assembler included with the MS toolset: MASM. It's called ml.exe in recent versions, or ml64.exe for the 64- bit variant. I have no idea if we currently generate MASM-syntax assembly. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4260 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080510/a2e7c0cc/attachment.bin>