[LLVMdev] Re: gcc4 or gcc3?

[Reid Spencer]

On Mon, 2006-08-07 at 18:34 -0400, Hendrik Boom wrote:
> In a paper called something like "slim binaries" a few years ago, the
> author claimed that they were more efficient than conventional
> machine-level executables.  That they consisted of was extremely compact
> intermediate code.  Apparently the time taken to generate machine code
> from the intermediate code was dwarfed by the time that would have been
> taken to read the executable machine code from disk (slow I/O and all
> that).  What's more, storing the intermediate code took a lot less space
> than the machine code, so it was a win there, too.  Now the compression
> techniques they used were quite dependent on the details of the source
> language they used (Oberon), so it's not clear how much these techniques
> translate to other systems.   But it's quite possible that the technique
> could be quite effective for a company that has to make its software
> run compatibly on multiple architectures.  It's certainly something I've
> considered, and llvm seems a useful tool for building it.
> 
> I believe the guy that did the slim binaries trademarked the name, but as
> far as I know has done nothing with it since.  I've  tried to email him
> unsuccessfully.

I actually plan to do something like this with HLVM (http://hlvm.org/).
At this point it is unclear whether the implementation will be in HLVM
or LLVM. One issue with LLVM bytecode is that it isn't *that* much
smaller than native code (depends on target). Assuming the bytecode was
already optimized, translating to native code should be, as you
suggested, relatively quick. In fact, LLVM's JIT already does this. If
your front end produces target-independent bytecode then its possible to
transport just the bytecode and run it anywhere the LLVM JIT runs .. or
even statically compile it to a target that is supported.  Note that the
C Backend makes many targets available that are not otherwise supported
by LLVM.

Reid.