Re: Super Serial Card Question?

["Michael J. Mahon" <mjmahon@aol.com>]

Eric Smith wrote:
> I wrote about how horrible the x86 instruction set is, then...
>
> > Fortunately the 386 introduced a much cleaner 32-bit flat addressing
> > model, and the Athlon 64 and Opteron [*] have done a good job of
> > extending it to a 64-bit model with more general registers.
>
>
> Michael J. Mahon wrote:
>
> > By all rights, we should be entering an age of "virtual architectures",
> > where both new and legacy code files are translated for execution on
> > the fly, and dynamically optimized to the host architecture, whatever
> > it is.
>
>
> The technology (and I don't just mean IA64, but in general) isn't yet able
> to do that without significant performance penalty.  It's not clear that
> it will ever be possible.  If you do the translation in software, there
> will always be a penalty, and if you throw enough transistors at it to
> do it in hardware, it won't match the performance you could get if you
> kept a fixed architecture and used those transistors to speed it up
> rather than using them for dynamic translation.

I agree that doing it in hardware is not the way to go.

The software overhead for translating/optimizing dynamically is
highly dependent on the software techniques used, and the degree
of re-use (including looping) in the code.

It is even possible to save the results of translation/optimization
back to disk, so that, once done, it need not be repeated--unless
predicates included in the translated code indicate that retranslation
or reoptimization is appropriate.

Very sophisticated approaches are known, and are applicable to this
problem.  Optimization should, for example, be driven by profile data
which is acquired in real time as the unoptimized (or even interpreted)
code is running.  (I specifically mention interpretation, because a very
large fraction of code is either never executed (error cases) or is
executed only once (initialization/termination code), and so might
never merit translation.

The fact that most dynamic systems are still quite rudimentary is
no indication of what is possible.  If 10% of the effort going into
fancy microarchitectures to "interpret" old (x86) code were to be
spent on dynamic translation software, we'd be there by now.  ;-)

I personally know of systems that implemented simple prototypes of
this scheme that behaved with no apparant slow-down as new code
localities were executed, and significant net improvements while
executing within a locality.  In other words, it "made up in the
straightaways considerably more than it lost in the curves".

This approach is particularly applicable to modern object-oriented
code, which consists of very small fragments of separately compiled
code that is dynamically linked at run time.  Only dynamic methods
can capture the actual "localities" of such code for optimization.

> That said, however, all recent Intel and AMD implementations of the
> x86 architecture actually ARE doing a fair bit of dynamic translation
> internally.  They're translating the x86 instructions into simpler
> internal micro-ops, which are not part of the visible architecture.
> (This is true dynamic translation, not just a microprogramed execution
> unit.)

Exactly my point--and the hardware translation is rather unsophisticated
and uninformed by long execution windows or profiles.

I also note that such repeated translation (into caches) is not
distinguishable from interpretation, and can be considered as simply
a more optimal way to interpret looping code.

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."