Re: CISC to RISC translator?

Mikael Larsson <Mikael.Larsson@lu.erisoft.se> wrote:
[...]
>I would say that translation from native CISC code to native RISC code
>would be quite feasible. The resulting RISC code would probably be
>more efficient than emulated code, though not as efficient as full native code,
>i.e. compiled from a high level language to native code. I have even heard
>rumours about DEC making such a translator for converting VAX code to
>Alpha code.
>
>Could anyone explain to me why this isn4t possible or where the main
>difficulties are? Does anyone have any references to the work by DEC?
>If it can be done, in what steps should it then preferrably be performed?
>I4ve heard of disassemblers. What is the output format of a disassembler?
>Could the output of a disassembler be used as input for generating code
>for another architecture? Does anyone know of any tools that could be used
>to build a code translator?


There is no reason that you couldn't, in theory, build a compiler
that takes M68K machine language as source and produces code for
(just about) any other language. However, if you want to do straight
recompilation, i.e. given a binary for one machine, produce a binary
for another machine, here are some gotchas:


    * self modifying code: it's still out there in the form of
        overlays, dynamicly linked object modules, run-time generated
        trampolines, copy protection via encryped code segments, etc.


    * the target of an indirect branch: where are you going? It would
        seem that you could detect and emulate standard idioms such as
        jump tables and base register plus range-limited offset, but as
        the idea is to emulate the target cpu exactly, it seems likely
        that there are situations where you just can't intuit the intent
        of the code.


I suppose in such situations you could just start interpreting
instructions until you get back to some (unmodified) place that
you've compiled for.


A second option is run-time recompilation of basic-blocks. Now you
can monitor memory writes and flush blocks that get overwritten. You
still have a problem if the write is farther down in the current basic-
block, however. In such situations, you'd have to abort the current
basic-block and start a new one immediately. I imagine there are
special cases that could be detected like overwriting the target of the
branch at the end of the block.


I've been thinking about such things off and on for a while now.
I have not, however, been able to find anyone publishing on the
topic; it seems like everyone who does any work on the subject
goes off and sells a product making the whole thing a trade secret.




richard~
--------
richard@atheist.tamu.edu
--

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