Re: p-code compilers

Aaron F. Stanton wrote:
>
> I'd like to throw an additional wrench into the fray if I could:
>
> It seems to be a sort of consensus that translators go from a high
> level language to another, while a compiler goes from a high level
> language to a low level one. (This is oversimplifying, I know, but
> bear with me.) A low level language seems to be one that is more-or-
> less directly executable by a processor, or is interpreted by a
> virtual machine.




But there are exceptions to this rule as well. A counter example is
our TowerJ compiler which takes Java bytecode as input and emits C
code that dovetails with our own Java runtime. I have no doubt that
this is a full compiler as it performs full call tree and flow control
analysis on a global or partitioned basis.


Bytecode is sufficiently low level that we also perform "structual
analysis" to recover loop and branching info that is used by the
back-end compiler for optimization purposes. (This structural
analysis, which is can be though of as a mild decompilation, has a
huge impact on runtime performance.)


My preference is to reserve the word "translator" for a straight
forward mapping process that is or could be performed in a single pass
and not worry to much about the input or output target forms.


--
Robert "Rock" Howard rock@twr.com
CTO, Tower Technology Corporation http://www.twr.com
1501 W. Koenig Lane, Austin, TX 78756 Tel (512) 452-9455
Server-Side Java(tm) Performance Experts Fax (512) 452-1721

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