On Jan 29, 2009, at 7:38 AM, Joern Rennecke wrote:
> The difference is that the front end does not work on source
code, but
> Java bytecode, which seems closer to intermediate representation
than
> to a "high-level, non-intermediate language".
I think it is clear that Java bytecode, which can even be executed
directly by some microprocessors, is not a "compiler intermediate
representation."
That is beside the point. It is not a high level language. Hence,
when you use gcc to compile Java bytecode to Target Code, this is not
an eligible compilation process.
When you use a non-GPL-compatible java frontend to compile Java
source to
bytecode and then use GCC to compile this to Target Code, it is not
an eligble compilation process either, because you used a non-GPL-
compatible
frontend.
This issue is also somewhat confusing to me. It is a moot point,
because LLVM is GPL compatible, but is LLVM .ll language considered a
target code, intermediate representation, or a "high-level, non-
intermediate language"? It is not clear to me how LLVM .ll files are
different from .c files that are used as intermediates between bison
and a C compiler.
LLVM .ll files are a fully documented language and people write them
by hand all the time. It is quite arguably much higher level that
machine code (having concepts like "call with arguments", a type
system, etc), and is fully specified (http://llvm.org/docs/
LangRef.html). It seems quite possible to argue that it is a "high-
level, non-intermediate language" (at least at least as much as C is).
Is the wording intended to allow LLVM .ll files as "high-level, non-
intermediate language", or are they considered an IR? What is the
dividing line? It seems that this is a very important issue for the
entire license.
-Chris
