Slashdot Mirror
Universal Emulators Return
webmilhouse writes "Wired has an article about Transitive Corporation that claims their software "allows any software application binary to run on any processor/operating system" without any performance hit. That would allow any program written for Windows to run on Linux or Mac, and vice-versa, which Wired likened to digital alchemy. The Transitive software is supposed to be released today. What do you think, vaporware or miracle?"
Run the whole OS... The device drivers will just work by magic
-- You're too stupid to be an atheist.
that's not possible, just translating to another set of instructions takes some of the cpu's resources
According to TFA, this is a pre-compiler/translator, not an emulator. i.e. The entire program is recompiled for another platform using only the binary data as the source. This is theoretically possible and has been attempted many times, but such compilers often trip over levels of indirection that programmers add.
For example, a programmer might place the video address in a variable, then reference that for screen paints. Such a trick would be impossible to detect at compile time, and would only be properly handled by a true emulator.
Javascript + Nintendo DSi = DSiCade
When I can run Office 2003 natively inside Linux then we can talk.
Define 'natively'. Because Crossover Office can run Office 2003 on Linux just fine, today.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
...that they seemed to run only processor-native code. Even Linux-Quake: Linux IS ported to the Mac ;-)
And the example of the XBox: Xbox is essentially a PC anyway.
This looks more like the technique the WINE project is using: Run a program on it's native hardware platform on another OS by making library- and systemcall-wrappers.
If that is indeed the case, "translating the code page-wise" can be translated to "re-linking dynamically loadable code page-wise".
Just my 2 cents
Look, this thing is totally safe! Built it myself, you know. You just press that button like this and then turn that lev
If you can get it to install it will run but I dont know how well. At this time we dont support Office 2003 but we are working on it.
Free Unix? Free Windows. http://www.reactos.com
The marketing jargon goes a bit over the top, but it isn't impossible to translate code for one ISA to an intermediate form, optimize it, and then generate code for another ISA. I don't know that it's revolutionary either. Note that LLVM takes a similar approach, and has a very simple intermediate form. I hear someone on their team is working on a PPC front-end, and as for language front-ends, Java and C# is in the works.
Getting back to Transitives, in July 2001, they claimed to already be doing x86->MIPS translation, which bodes well for x86->PPC. However, doing things efficiently the other way around is tougher. And of course you need to support or translate a ton of the native OS API calls etc. It'll be interesting to see for Windows on Linux (for example) if they require a copy of Windows to run the binaries.
pb Reply or e-mail; don't vaguely moderate.
http://fabrice.bellard.free.fr/qemu/ Qemu needs work, but already has several different host-target CPU combinations complete (in the ARM x86 and PPC areas anyway).
http://pearpc.sourceforge.net/ PearPC fills in the gaps on PPC emulation where Qemu is lacking. (I run OS X 10.2 on my PC at work.)
DEC had several compilers that translate from executable to executable format. This trick was
done compiling Vax images on Alpha, and I believe it also was done for Solaris Sparc images on Alpha and
x86 images on Alpha, and has now been done at least for alpha images on IA64 (Itanium). Performance achieved there could be as high as 80% where the self-tuning aspects of the technology were used. (That is, every time you ran the image, more stuff got identified as code and compiled.) At least for Windows, though, it would be necessary to have emulations for all the NT functions, which led to a rat race trying to chase all the new DLL functions down, which would change frequently, with the apparent aim of keeping anyone from building an emulation of everything. The FX!32 product did pretty well even so and allowed many x86 binaries to be run on Alpha. Seems to me that the claimed performance may be a tad optimistic (80%) unless many tuning runs are done, but still quite usable. But I would be surprised to see more than a small subset of OSs supported, much as it would be pleasant to be able to run Alpha VMS on an Athlon 64 this way.
After reading this, the term Universal Emulator doesn't seem to apply. Here is the text from Transitive's Website:
Honk if you're horny.
From the forward to Hawking's "A Brief History of Time."
"Analyst Rob Enderle of the Enderle Group said Transitive benefits from the fact that most modern machines are fast enough to emulate each other without much affecting performance."
All I needed to know. This guy will say anything and if he appears in your press release (yeah, it's an "article" but certainly the material is in a press release), chances are you're straining for credible commentary.
Dynamite allows software that has been compiled for one processor/operating system to be run on another processor/operating system without any source code or binary changes. To do this, Dynamite provides a hardware virtualization technology that consists of four key components. First, an integration FUSE allows Dynamite to be easily integrated into the target system. Second, a dynamic binary translator tackles the challenge of moving from one instruction set architecture to another. Third, an operating system mapper translates operating system calls from the source system to the target system in situations where the source and target operating systems are different. Finally, a graphics subsystem mapper translates graphics system calls from the source to the target system in situations where the source and target graphics systems are different.
Integration FUSE. Dynamite is integrated with the operating system of the target system and runs like any other application. Unlike static translators that translate an applications binary once before run time, Dynamite translates instructions and operating system calls while an application is running. When a foreign application is started, the operating system recognizes that the application needs translation and automatically starts Dynamite. Depending on the requirements for the integration, Dynamite can be configured with a wide range of options, including the ability to build bridges between translated code and code running native on the target platform. This feature has been used, for example, to allow translated applications to call a native accelerated graphics library for the graphics chipset in the target platform, delivering higher quality and speed than other solutions. Integration options also provide for different optimization schedules and the ability to reconfigure the use of the translation code cache to better match performance to customer needs.
Dynamic Binary Translation. The dynamic binary translator in Dynamite is a breakthrough technology that uses a modular architecture consisting of three key components. The front-end decoder reads blocks of instructions from the foreign applications binary and decodes them into an intermediate representation. The intermediate representation allows Dynamite to understand the higher-level semantics and intent of the code.
The optimizing kernel reads the intermediate representation and optimizes the code. At first, simple optimizations are performed. In most applications, however, a 90/10 rules holds where 10% of the code is executed 90% of the time. The optimizing kernel looks for blocks of code that are executed often, spends increasing amounts of time improving the optimization of this code, and then stores this optimized code in memory. Each time a frequently used block of code needs to be executed, the highly optimized code stored in memory is used instead of optimizing that block of code again. Because the blocks of code that are executed change frequently, the optimizing kernel flushes old optimized blocks and generates new ones. The optimizing kernel produces superior code optimization compared to static binary translators or compilers. It optimizes code based on how an individual user is using that application and does not need to optimize code for the general case.
The back-end code generator outputs code for the target processor
Honk if you're horny.
For example, a programmer might place the video address in a variable, then reference that for screen paints.
I don't see how that could be a problem. There is a serious problem with self-modifying code and code generated on-the-fly. Basically, every time anything crosses the data/code boundary, it would have to be translated. A simple translator would only handle the data/code boundary that the program crosses when it's first loaded into memory from an executible file.
Then, there are thunks (in Win16/Win32 programming; small pieces of code generated dynamically to help call Win16 libraries from Win32 code and vice-versa). Then there are compressed executables. Encrypted executables for copy-protected games. Dynamically generated code for inner loops for high-performance computations, maybe. Code generated by applications that compile on-the-fly, like your average LISP system., or JVM. A binary translator would not be able to handle any of those, unless you try to detect a jump to data somehow, which may be prohibitively expensive on a PowerPC. Is it?
Do a Google search for PearPC. People have most certainly gotten MacOS X running on their x86 boxes.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
This product claims to translate the code block by block into native code, thusly not emulating another processor per se. Metaphysically we could say that the two are equivelent, but it's not built around the fake processor as a unit like the other popular emulators are.
Speak for yourself.
PearPC Community Page
PearPC Sourceforge Page
The graphic on Transitive's website shows only Unix/Linux operating systems. One of their steps, Operating System Mapping, says "QuickTransit supports operating system mapping between any two Unix/Linux-like operating systems, as well as mapping between mainframe and any Unix/Linux-like operating systems." Doesn't sound like Windows to me.
All of this is supposedly done on the fly, and not beforehand.
Quake and The Gimp wouldn't be my choices to show off flexibility. Quake is OpenGL on Linux and OSX, so there isn't any graphics magic going on. And the ability of BSD-based systems to run Linux binaries is old hat. The Gimp isn't exactly taxing on a CPU as far as user responsiveness goes.
Extraordinary claims require extraordinary proof. Press conferences for journalists aren't a conducive forum for proving anything. They are a good place to baffle 'em with bullshit, though.
-Charles
Learning HOW to think is more important than learning WHAT to think.
and
so yes, it does affect performance. You take a 20% hit. The "almost no performance hit" means, in this context, "computers are fast enough that no one will notice unless they're doing something crazy like video editing. Go back to surfing slashdot."
Wait; they got Enderle for a quote?
It's all bullshit.
Nobel Prize-winning physicist Stephen Hawking starts his book A Brief History Of Time with an anecdote about a scientist giving a public lecture on the nature of the earth, the solar system, and the galaxy. After his talk, an elderly woman rises from her chair and says "What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise." "Ah. And what is the tortoise standing on?" asks the scientist. "You're very clever, young man, very clever," retorts the old lady. "But it's turtles all the way down."
_ cu lture_media/ture_turtles.asp
http://www.imdiversity.com/villages/native/arts
We must be alert to the danger that public policy could become captive to a scientific-technological elite. - Eisenhower
See here: '99 Paper
Bye!
SeqBox
The reason you need a license for the software is because that software is copyrighted and in order to use or display copyrighted material you need to have a license for it.
This isn't true.
Copyright only prevents you from copying something. If the software publisher makes the copy and gives it to you, you can read that copy (e.g. play music from a CD) without requiring any other licence from them.
Computer software is in the interesting situation of requiring making a copy before use. As a previous poster pointed out, there is an additional section of copyright law to try to get round this.
Google found this page for me.
John
i think i remember reading that the xbox 2 development kits use powermacs with windows nt ported to powerpc. and mac os x was ported to x86 on a collaborative project with intel until jobs pulled the plug.
This isn't about running windows on a different processor. It is about running applications for windows in a different operating system with different hardware.
MS might care about that.
Like this, I think:
So nothing about Windows, and Mac only as OSX, I think. No mention in the Wired article of it being limited to *ix-like OSs. Which idiot calls this "universal"?Everything you say it's true, except the part about the Nobel Prize.
Professor Hawking has never won the Nobel Prize. You might want to confirm that up in the several bios available on the net.
The best cure for insomnia is realizing that it is already time to get up. EsteEncanto.com - Blog on technology, urban
There were several. One was the translation of VAX code to Alpha to run on Alpha-VMS. The other was FX!32 that translated x86 Windows binaries to Alpha binaries.
FX!32 worked most of the time but it rarely gave the expected speedup we expected.
Do a Google search for PearPC. People have most certainly gotten MacOS X running on their x86 boxes.
I have. PearPC has been great for firing up Safari and Mac IE on my AMD 64 3200+ box to test websites. It's no speed demon, though. It's sluggish even on my system. The PearPC folks state that performance is roughly 1/40th that of native.
Portable versions of Firefox, GIMP, LibreOffice, etc
Even with that, the feat is not possible. If one processor (let's say a CISC processor) has an instruction for a function in the target code, and the second processor (let make this one a RISC processor), does not, It will HAVE to take more clock cycles to accomplish the same task. To make open claims that there is no performance hit is simply ridiculous. The facts of how different processors handle the same or similar instructions make that impossible. I'll bet you they claim it can suck a golfball through a garden hose too.
What sets off the BS detector for me is the APIs. They consistently state that they can do this for any OS.
Actually, it seems to be primarily other people saying this. Read their site; they only claim to be able to do it for UNIX-like systems.
maybe it's just not funny?
Alasdair Rawsthorne has written a few technical reports on the technology behind this which includes some discussion on performance. See:
Machine Adaptable Binary Translation
The paper's a few years old, but I would definitely say this is not vaporware and I would expect them to have worked out most of their performance limitations since that time. Will it run as seamless as people here seem to expect? That remains to be seen. In the meantime, instead of immediately crying foul, read up on the subject and come to an informed conclusion. It looks promising. Search around, there's more up to date info.
Sounds about right. It took over 8 hours to do a minimal MacOSX 10.3 install on my 1.2Ghz athlon system (running SuSE9.1), and it takes about 5 minutes just to boot it up. Still, it's great for testing Safari compat even at a snails pace.
--
Power to the Peaceful
The Amiga did it first! Google the saga of Jim Drew and the Emplant board. The same types of claims were made. It could emulate the Sega Genesis, the PC and the Mac at full speed using some revalutionary Amiga-Fu.
Of course it was all B.S. then too.