Re: Generating Java Bytecode

>[Crying UNCOL.]


For those of you not familiar with the idea of UNCOL (Universal
Computer Object Language), you can think of it as:


A set of virtual machine instructions. Compilers for M
language emit those virtual machine codes. Back-ends for
N machiens consume those virtual machine codes and produce
native machine code. To move M compilers to your new
machine, simply write a N+1'th back end.


Thus, the complexity of supporting M languages on N machines
is M+N, rather than M compilers for machine 1, another M
compilers for machine 2, and so on for a total complexity of
M*N.


It's clear that you can build *some* UNCOL for all Turing-equivalent
machines. Indeed, the VM could even be some Turing machine. However,
you rapidly find yourself approaching the pragmatic problem of
performance. A good rule of thumb is


If the UNCOL has very few operations, then it is difficult to
express high-level operations and thus difficult to peform
substantial optimization. For example, a languate may
guarantee that two pointer parameters can never alias each
other, but that information is lost at the level of "add",
"mov", etc.


It is, of course, possible to work around such problems by
adding primitives to the UNCOL. However, since many
languages have quite different operations (backtracking,
immutable memory, synchronization, etc.) the UNCOL will
become quite large and the task of building a translator for
the UNCOL is potentially as large as porting a translator
for each of the M languages. Thus, nothing has been saved.


The small UNCOL is often referred to as an "intersection"
language because it contains only the features that appear in
all languages. The large one is often referred to as a
"union" lnaguage because it contains the union of all
features in all languages.


The bottom line is that an UNCOL of this form *necessarily* involves
some performance loss. The only remaining questions are "how much"
and "how much will you tolerate"? John [our moderator] and I have
discussed this offline and while we disagree on the details (I'm more
optimistic about how well you can do and about how much loss people
will tolerate), I have to admit that history is on his side.


This is a classic paper:


%A M. E. Conway
%T Proposal for an UNCOL
%J CACM
%V 1
%N 10
%D OCT 1958
%P 5-8


;-D on ( The virtual guy ) Pardo


[These days I believe that you can probably generate adequately fast
machine code for typical computational stuff. The unaddressed
problems are all around the edges, e.g. memory management, file
systems, window systems, libraries, etc. Thought experiment: design
an intermediate code that will handle both Cobol and Scheme
effectively. Don't forget picture formats, decimal arithmetic,
built-in file sorting, garbage collection, property lists. Extra
credit: ALTER, the report writer, and closures. -John]




--

Return to the comp.compilers page.
Search the comp.compilers archives again.