Re: Machine language and assembler translators?

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

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