Re: Machine language and assembler translators?

vtsikoza@yahoo.com (Vit)
30 Jun 2005 09:59:04 -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)
Re:Machine language and assembler translators? Robert.Thorpe@antenova.com (Robert Thorpe) (2005-07-22)
Re: Machine language and assembler translators? peter.jinks@manchester.ac.uk (Pete Jinks) (2005-07-22)
Re: Machine language and assembler translators? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-07-26)
[5 later articles]
| List of all articles for this month |

From: vtsikoza@yahoo.com (Vit)
Newsgroups: comp.compilers
Date: 30 Jun 2005 09:59:04 -0400
Organization: http://groups.google.com
References: 05-06-103 05-06-105 05-06-126
Keywords: translator

Sorry, but I do not quite catch what you mean :(


> For subarchitectures, different branches of what is fundamentally the
> same architecture, though, it may be more useful.


Agreed, but it's a too narrow area, and I feel that the initial
problem has been established in a wider context...


> Now, consider that much of the advantage of RISC depends on the
> compilers generating optimal code for the specific processor.


Since I agree with the above, then my comment for the following:


> not just at the architecture level but for what is sometimes called the
> subarchitecture.


is: It is easier to tune the compiler's back-end for better
performance on a subarchitecture level (and all its varieties that
exist) than to develop such a side tool as target code converter to
loose the performance even in the smallest extent... The statement is
that when for a given low-level code both hi-level source code and the
compiler's sources are available, it is better to tune the compiler
and recompile. Creating a converter makes sense only if its multiple
usage is guaranteed, that is, if having a lot of hand-written assembly
code or loosing the compiler's sources are the case. If there is just
SOME code to be tuned to SOME slightly different architecture, well,
than it is a particular problem, and it's up to you budget if convert
it manually or develop an automatic converter for a single run...


Vit
http://www.excelsior-usa.com


Post a followup to this message

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