Universal Emulators Return 546
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?"
Not Vapor and not the arrival of Christ (Score:4, Insightful)
Not vapor (Score:4, Insightful)
I'll believe it ... (Score:1, Insightful)
Games Games Games (Score:5, Insightful)
no performance hit? (Score:1, Insightful)
Any program? (Score:5, Insightful)
Taos (Score:4, Insightful)
So, this idea reminds me of this project...
It could still be possible, we've got Java classes instantiated and running on many architectures, after all...
No performance hit? (Score:5, Insightful)
The only way I can imagine this happening is if the software reads your executable and then does a one-time translation into a native executable. That way the native executable wouldn't be emulating anything, it would be the real deal. But... the complexity of such software would be staggering.
Here's hoping it works!
Re:no performance hit? (Score:3, Insightful)
Arch or Library/API ? (Score:3, Insightful)
Is Transitive claiming to do BOT universally!? If so I am very skeptical, because even doing 1 of the 2 would be impressive.
Tortoises all the way down. (Score:5, Insightful)
I doubt it. (Score:1, Insightful)
Were cross-platform ports shown? (Score:5, Insightful)
Windows laptop running the Gimp image editor for Linux
Funny how those applications are already available for those platforms, hmmm? I'd like to have heard about something being shown that isn't already available natively.
Re:no performance hit? (Score:5, Insightful)
Doubtful, but possible.
Game piracy? (Score:2, Insightful)
From the article:
When some people think of "emulators", they also tend to think of the arcade and console game ROM piracy scene that goes along with it. The company may have dodged more bullets than it's letting on to us by not using that word.
Re:Any program? (Score:5, Insightful)
Now here's an interesting thought: MacOS X on x86. Or windows on PowerPC.
Re:Vaporware (Score:1, Insightful)
Re:Tortoises all the way down. (Score:3, Insightful)
Robby seems to think these claims are a bit outrageous.
Just think of how much work would be involved in something like this. Maybe it's a compiler and their own widget set. Emulate APIs? Not quite an emulator really. Perhaps its a java emulator? Who knows what twist is really there, but we know from past experience this is tricky stuff.
Boisterous claims are often given by boisterous men... neither of which have any solid value.
Had me until "no performance hit" (Score:5, Insightful)
so it is technicaly feasible that if you map out a fair amount of the pipelines of most of the popular chip sets, you could technicaly have a command chain to allow binaries the same calls through a sudo-emulation layer of the software.
fundamentaly possible, and even do-able.... but without a performance hit? no way. Each processor is geared towards a particular way of solving a physcial and mathmatical set of problems... some processors are designed for massive loads of database driven calculations (XEONs)... some for multimedia (G5)... some for science (PPC, Sparc?)... some for power savings (ARM)....
depedning on which archetecture your using, the performance will be greatly hindered if your trying to do something designed for a radicaly different chip. Such as trying to run some expansive G5 optimizied photoshop plug on a ARM chip.
"no performance hit" = total bullshit
Clearly vaporware (Score:5, Insightful)
This is vaporware. What they're claiming - "without any performance hit" - is impossible. Accomplishing the rest of what they claim is not impossible, but it's very difficult, and since the "without any performance hit" claim establishes conclusively that these people are bullshitters, I don't believe they can even come close to doing it.
Legal status (pretty OT) (Score:5, Insightful)
The reason you need a licence to use software is because your CPU makes a copy of the program (in RAM) and this would otherwise violate the programmer's copyright. I believe that the licensing terms are generally pretty strict, e.g. one copy, to RAM only. Therefore, I'm not sure you'd be permitted to take a copy of their program, mangle it and dump it back out to disk.
Does anyone know of any reason why this would be permitted, or how people intend to get round this problem?
I appear to have been reading too much groklaw.
huh? 24hrs early (Score:2, Insightful)
Why not ask "What do you think, vaporware or miracle?"
tomorrow?
Why speculate when you can... i dunno, wait 24hrs and inform yourself...
Re:Tortoises all the way down. (Score:5, Insightful)
Re:Remember... (Score:5, Insightful)
Actually, not. Emulating x86 on a PPC chip is easy.
What would be truly impressive would be running, say, Wolfenstein3d Mac on an x86 box, with reasonable speed. That would be far more difficult.
Reading the article, it sounds like a lot of hype, and I suspect the product behind it, even if it's pretty well done, will never live up to the hype.
Re:No performance hit? (Score:5, Insightful)
Actually, I could conceive a brilliant software engineer coming up with a universal translation mechanism that turns x86 assembler into functionally equivalent PowerPC assembler, or vice-versa, or to other platforms. I believe IBM had been funding research in thsi area for quite some years now.
What sets off the BS detector for me is the APIs. They consistently state that they can do this for any OS. You have to do API translation, and you'd have to do that per OS, and it's a staggering volume of work to get all the APIs translated (think Wine project, just trying to do windows->linux api on a single shared hardware platform). When my linux binary calls any given kernel, C library, or even other common library (readline?, pthreads?, opengl?, etc..), those calls all have to be translated to equivalent MacOS or Windows API calls.
Re:no performance hit? (Score:2, Insightful)
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.
So it's more or less a cross-decompiler with a compiler attached. This could perhaps convert from one CPU to another, but what about system libraries? This part is probably the most difficult, considering how much effort is put into the wine [winehq.org] project.Re:Easy refutation (Score:3, Insightful)
Re:Not Vapor and not the arrival of Christ (Score:1, Insightful)
did you fail the earth science regents exam?
Re:Tortoises all the way down. (Score:5, Insightful)
Re:Article is vapor-news (Score:3, Insightful)
Emulation programmers have been playing with dynarec cores for years now, but compatibility at a low level tends to suffer. Some software is expecting scanline-perfection because they're talking right to the hardware and are tuned to that performance. You'll notice the ABI/API compatibility only talks about various Unix variants and mainframes. So, dynarec PROBABLY won't have to worry about that so much in this case.
Kinda disappointing. I'd like to see what wrangling they could do with MacOS and Windows. Those would be much harder to pull off.
RTFA?! (Score:2, Insightful)
Did the person who posted the article read it?
As far as I can tell
I think the real problem is the confusion as to what the word "platform" means. It doesn't just refer to Windows vs. Linux vs. MacOS. It could refer to one compiler vs. another compiler. It could refer to one chip vs. another (as in this case). For example: the PowerPC chip vs. the Intel chip.
The article specificly talks about the xBox issue this software could solve:
"For example, Wiederhold said QuickTransit will allow the next-generation Xbox (which will have a Mac-like PowerPC chip) to run first-generation Xbox software (which was written for an Intel chip)."
Cheers,
--The Dude
Re:Tortoises all the way down. (Score:2, Insightful)
> hardware".
That's exactly what the guy you're replying to is suggesting. Where does the software house claim than they can enable a 300mhz pc to have more clock cycles in software? Is anyone claiming that? Bizarre. I guess that's Slashdot for you.
READ THE ARTICE (Score:3, Insightful)
"QuickTransit fully supports accelerated 3-D graphics and about 80 percent computational performance on the main processor."
Re:Games Games Games (Score:5, Insightful)
Re:I saw a beta test! (Score:1, Insightful)
Re:Not Vapor and not the arrival of Christ (Score:1, Insightful)
Re:Any program? (Score:4, Insightful)
In the case of the Pentium 4, the x86 decoders only operate on instruction data coming from the L2. The trace cache on the P4 caches RISCy micro-ops, which is the main benefit of the trace cache on the P4 -- skipping the relatively lengthy decode of x86 instructions.
So from a micro-architecture standpoint there is very little difference between CISC and RISC, since you just translate CISC->RISC. x86 still manages to be a big PITA because of weird things like shifts by zero which don't effect the flags.
CISC vs RISC is basically a done deal, with RISC "winning" along with it essentially not mattering anymore.
Claim-by-claim analysis (Score:2, Insightful)
Comment 1.
How does the operating system recognize that the application needs translation? I see three possibilities.
The first possibility is that the native operating system lets Transitive execute all applications, and Transitive decides whether to translate an application, or let the native operating system run the application unaltered. Integrating this functionality (properly) into an operating system would be extremely diffult, let alone multiple operating systems.
The second possibility is that the native operating system attempts to execute all programs, and only invokes Transitive if an unexpected application type is encountered. Due to the way that Windows only executes files according to file associations (".exe" = DOS/Windows executable, ".com" = micro-executable, ".bat" = batch file), this seems very unlikely, as Windows wouldn't even know how to execute "gimp" because it lacks an extension such as "gimp.exe".
Even if one was to rename "gimp" to "gimp.exe", Windows would attempt to load the "Windows Program Header" for the file, which would be invalid because it's a Linux application. Windows would then generate an error. Of course, Transitive could overwrite certain error handlers within the operating system to catch this kind of error, and then analyze the file using a "magic number" command to determine which operating system and what file type was under scrutiny. But then Transitive would have to overwrite these certain error handlers within all operating systems, a very unlikely proposition.
The third possibility is preconfigured "virtualization sandboxes". Virtualization software like VMWare assumes that for a virtualized system, all files and executables within that virtualized system will be executed according to the rules of that virtualized system. Ergo, if you're running a virtualized Linux system, any executable will be executed as a Linux application. Does Transitive require one to preconfigure foreign applications as existing within a predefined virtualized system? Either way, there's alot more to this than simply the "operating system recognizes that the application needs translation."
Comment 2.
This sounds like a fairly intensive process, given the number of operating systems and APIs out there.
Comment 3.
Does this mean that Transitive will take a Windows DirectX application and translate it to Linux OpenGL? Or does Transitive have it's own API, which is compatible with all video card drivers out there? For either claim, that's pretty impressive; a technology worth being bought out by nVidia or ATI. Considering the breadth and depth of all graphics libraries and versions available for numerous operating systems, that's phenomenally impressive.
Comment 4.
Re:Tortoises all the way down. (Score:2, Insightful)
The engine will likely allow template driven translations, and x86 linux to x86 windows could be byte for byte identical.
So it takes a moment to scan a file. We all run virus checkers in Windows every day, they scan our files and we dont notice.
THIS is the kind of comparisons it could feasibly say is 100%. Clicking on the Doom3 windows exe in linux loads up the preconverted translated file.
Now, different processor configs do work differently, and from the sounds of things they can't have done much work there. I think shying away from it by using Windows->Linux as their "test" operating system purely because they are the simplest.
This is like the Macintosh emulators that became available for the amiga. Both machines ran on 680x0 processors, and emulating a same period apple mac was a lot more usable than emulating an 8086.