On Friday 04 January 2002 11:20 am, Dan Sugalski wrote:
> At 11:10 PM 1/3/2002 -0500, Bryan C. Warnock wrote:
> >The other obvious answer is that we don't, because it's just to
> > difficult, if not impossible, to do, and do well.  So is it worth the
> > effort to pursue?
>
> FWIW, I've heard of at least one product out there that does this, though
> at the machine code level. (It'll turn your x86 binaries to Alpha ones,
> for example) It's supposed to do some optimizations as it goes, and there
> were reports of x86->other->x86 translations ending up with code that was
> faster than the original.

I don't know if it was a Microsoft product, but it was for software for 
Windows NT on Alpha.  Windows allowed the execution of x86 NT software on 
the Alphas, albeit at an even slower crawl than what they normally ran.  
This program was basically a JIT that would convert the x86 code to the 
corresponding Alpha code, and redirect future calls to that point.  IIRC, I 
believe it may have even been able to freeze the Alpha code to disk, but 
it's been about five years since I looked at it.  In either case, since it's 
usually the same threads that are constantly exercised, you'd get close to 
native speed for the application after a while.

This largely worked because you were still targetting the same OS, so the 
issues with system calls and data were essentially a noop.

> Still, Brian's original point was well taken--there's a lot more to a
> machine than just its CPU. The hardware and OS are darned important too,
> and much tougher to emulate. (Not that I'd mind someone whipping up an
> Atari 800 emulator--I'd have to dig out the old M.U.L.E. and Archon
> disks....)

Hmm, you don't google much, do you, Dan?

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Reply via email to