Re: Machine language and assembler translators?

Hans-Peter Diettrich <DrDiettrich@compuserve.de>
23 Jun 2005 22:04:08 -0400

          From comp.compilers

Related articles
Machine language and assembler translators? jatinb@noida.hcltech.com (Jatin Bhateja, Noida) (2005-06-21)
Re: Machine language and assembler translators? vtsikoza@yahoo.com (2005-06-23)
Re: Machine language and assembler translators? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-06-23)
Re: Machine language and assembler translators? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-06-23)
Re: Machine language and assembler translators? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-06-26)
Re: Machine language and assembler translators? vtsikoza@yahoo.com (2005-06-30)
Re: Machine language and assembler translators? jcrens@earthlink.net (Jack Crenshaw) (2005-07-17)
Re: Machine language and assembler translators? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-07-22)
Re: Machine language and assembler translators? toby@telegraphics.com.au (toby) (2005-07-22)
[8 later articles]
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich@compuserve.de>
Newsgroups: comp.compilers
Date: 23 Jun 2005 22:04:08 -0400
Organization: Compilers Central
References: 05-06-103
Keywords: translator
Posted-Date: 23 Jun 2005 22:04:07 EDT

"Jatin Bhateja, Noida" wrote:


> Now my personal view is that all the above work can also be achieved
> by using a cross complier but for that we have to make the changes in
> the complier backend. Instead of doing that cant we make a tool which
> convert the assembly language of one architecture to another
> architecture machine language.


Of course it's doable, a JIT compiler does such a conversion on the
fly. But for good performance of the converted code a *virtual*
machine should be chosen for the input code, that maps well to
existing machines of every kind, instead of some *really* existing
machine.


> [Both machine language translators and assembler translators have
> been around approximately forever. It's straightforward except for
> self-modifying code, and incompatible byte order and data formats.
> -John]


sic!


DoDi


Post a followup to this message

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