Am 01.06.2011 04:57, schrieb Cameron Zwarich:> What benefit do you get from having a backend here rather than an interpreter for LLVM IR?A backend that's self-sufficient and covers the entire Unixoid world. That cuts down on the number of binaries that one needs to provide for autoinstallers and such. Generated Perl could be used to bootstrap an LLVM IR interpreter, for example. Regards, Jo
Cameron Zwarich wrote:> What benefit do you get from having a backend here rather than an interpreter for LLVM IR?The same thing as an interpreter, just a native build (no need for an interpreter program, better speed, etc). This would be beneficial anywhere that "build once, deploy anywhere" functionality is desired, without resorting to using a higher-level language like C# or Java. Granted, the application that either interprets or compiles and links the resulting bitcode application would still be required on the system, much like a VM for this language; but for developers not familiar with such languages and either no particular desire or very little time to become familiar with them, this would be an excellent solution. That said, it seems like it ought to be possible to do the same thing by emitting bitcode for all supported platform/arch combinations and compressing them in an archive, then decompressing and either interpreting or JIT-compiling the appropriate bitcode for the platform. This would just be a more flexible means to that same end.
Hi Nate, I've successfully ported one bitcode from Linux to Mac to Windows. All were x86 and the program was text-based, but I'd say my LLVM Wrapper would be worth some effort in the future if I could just get some help. Currently it just wraps StdIO.h with its own functions. Here's some of what it would take to make portable bitcodes in C or LLVM Assembly: * Convert all preprocessor conditionals to regular conditionals so that both the #ifdef parts and the #else parts make it into the bitcode. Don't worry about bloat since the installer will be able to run constant folding and dead-code elimination to get rid of the unused parts. The constants will be supplied by the installer in the form of an external bitcode for linkage. The only exception to this rule would be the guard-defines in .h files. * Make sure that the code in the distribution bitcode is endian-agnostic 32-bit code. A sandbox will be needed on 64-bit systems or else a separate 64-bit bitcode package will still be required. * Make sure all external dependencies including LibC runtimes are accessed from the wrapper rather than the native code from the bitcode. All external libraries are system-specific. There are probably other requirements that I've either overlooked or forgotten but I'd like to have my wrapper expanded to do some more extensive functionality if somebody would like to join the project, let me know and I'll add you to the SourceForge project at http://sourceforge.net/projects/llvmlibc/ . --Sam ----- Original Message -----> From: Nate Fries <nfries88 at yahoo.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Cc: > Sent: Wednesday, June 1, 2011 4:25 PM > Subject: Re: [LLVMdev] Thinking about "whacky" backends > > Cameron Zwarich wrote: > >> What benefit do you get from having a backend here rather than an > interpreter for LLVM IR? > The same thing as an interpreter, just a native build (no need for an > interpreter program, better speed, etc). > > This would be beneficial anywhere that "build once, deploy anywhere" > functionality is desired, without resorting to using a higher-level language > like C# or Java. > Granted, the application that either interprets or compiles and links the > resulting bitcode application would still be required on the system, much like a > VM for this language; but for developers not familiar with such languages and > either no particular desire or very little time to become familiar with them, > this would be an excellent solution. > > That said, it seems like it ought to be possible to do the same thing by > emitting bitcode for all supported platform/arch combinations and compressing > them in an archive, then decompressing and either interpreting or JIT-compiling > the appropriate bitcode for the platform. This would just be a more flexible > means to that same end. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Am 01.06.2011 23:25, schrieb Nate Fries:> That said, it seems like it ought to be possible to do the same thing > by emitting bitcode for all supported platform/arch combinationsWait... is bitcode not platform-agnostic? I thought it is. > and> compressing them in an archive, then decompressing and either > interpreting or JIT-compiling the appropriate bitcode for the > platform. This would just be a more flexible means to that same end.Not sure how that is more flexible - care to elaborate? Regards, Jo
On 6/3/2011 3:19 PM, Joachim Durchholz wrote:>>>> compressing them in an archive, then decompressing and either >>>> interpreting or JIT-compiling the appropriate bitcode for the >>>> platform. This would just be a more flexible means to that same end. >>> Not sure how that is more flexible - care to elaborate? >> More flexible to the programmer, not to the system. There are many >> pieces of code where, to port between Windows, OS X, iOS, Android, and >> PC Linux/*BSD/etc would require a ton of preprocessor work. > > Ah I see. > > I'd avoid using control flow, unless the differences are really > minimal and the control flow is easy to understand. For anything > that's getting even slightly complicated, I'd use different bitcode > files. >Indeed. It's my attempt at meeting halfway, and it really offers nothing over using preprocessors besides the fact that it would result in a single all-functional bitcode without requiring distinct run-time checks.> Whether these are packed into a single zip file or available for > separate download is something that should be decided by the deployer > - sometimes, space is at a premium, sometimes, it's bandwidth or > latency. Let them decide what parts of the bitcode file tree they want > to distribute, and allow them to package them into zip files as they > see fit. > There are transparent zip filesystems that will allow you to access a > file inside a zip archive as if it were part of the normal file > system. (Java does this all the time, and this part of the Java > infrastructure works really well.)I was suggesting a method of storage, not necessarily of distribution. Indeed, the best method for a distribution system would be to transmit only the relevant bitcode.