Re: Bytecode an intermediate language?

rajnichugh@yahoo.com (Rajni) writes:
>Actually I am having a different doubt. From what I can understand
>from previous discussions on intermediate representations is that the
>representation to be chosen depends on the optimization techniques to
>be employed in compiler. But I can't get any concrete answer with
>respect to different representations. Does the choice of intermediate
>representation also depend on source language and portability.


Yes, of course. E.g., the IR of the Cacao JVM-to-native-code JIT
compiler is different from the IRs of gcc.


>[It's true, bytecodes are fine to output to an interpreter, but they're not a
>very good intermediate form. -John]


That depends on what you want to do. E.g., abstract interpretation in
Prolog is usually done by running the same virtual machine (bytecode)
instructions (usually some WAM derivative) as is used as IR for native
code compilation or interpretive execution (concrete interpretation),
but the VM instructions are modified to work on the abstract domain.


In general for any forward analysis or code generation task a VM
designed for executing the code might provide a good basis. For
backward tasks you need an IR that you can process backwards; VMs are
typically not designed for that.


In many cases you want to have additional data structures for analysis
or optimization, e.g., data flow or dependence edges. VMs typically
don't provide that, but these data structures are often easy to
reconstruct by executing the VM code with appropriately modified
semantics; so VM code can be a good choice as an IR format outside the
phases that need these additional data structures, in particular if
you have to marshal the IR to disk or to other processes.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html

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