Transitive, a start-up specialising in software that translates software for one chip so it can run on another, plans to release software this quarter so programs for Sun Microsystems’ Sparc chips can be used on Intel Xeon chips.
Sparc-on-Intel Translator Due in Weeks
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This is very interesting, because there is still virtually no commercial software from ISVs for Solaris x86 available. So the Opteron workstations from Sun could only be used as development machines. With the possibility of translation similiar to Apples Rosetta, the user finally can start to use Solaris software for SPARC on these machines and if they are not satisfied with the performance, they can put more pressure on ISVs for supporting their software for Solaris x86.
True, two that come to mind, that are on SPARC but not x86 are Framemaker and Acrobat Reader.
The problem, howevwer with translation is this; whether the vendor will actually eventually port or will they turn around and say, “hey, it works well enough on the translation layer, who cares about porting it!”.
No I don’t think this is a valid excuse, just as little, as for developers for MacOS X software, not to provide Intel binaries. This is especially valid for ressource hungry software like software for EDA, CAE, CAM … So running this software with translation software is a proof of concept, but for production, native software is still required.
Regards,
Anton
Given Adobes past actions in regards to porting (exampl being frammaker on Linux), I am very skeptical as to whether they’re willing to port anything or any substantial value to Solaris, let alone any other platform.
Good news but it would be even better to be able to translate x86 to (insert favourite processor here).
I find it strange and somehow funny that all modern x86 CPUs are essentially RISCs dressing as ugly x86-CISCs for the sake of backwards compatibility.
If we could get past this stage assembly code would both look nicer and run faster. That’s at least my guess…
While I dislike the x86 ISA too (at least x86-64 has 16 registers) Transmeta tried to translate x86 to a VLIW which was custom designed to emulate x86 (having a compatible FPU for example) and they still performed quite poorly on the benchmarks..
Sure Transmeta’s failure doesn’t mean that it is impossible but it seems nearly impossible.
Also remember that the RISC should have a FPU which is capable of handling at least 80-bit floating operations mode: otherwise it would be very slow in non-SSE FP operations..
AFAIK OoO x86 is faster on general integer code because it usually decode/commit less instructions even if issue rate is the same.
Floating point code is weaker because of x87 legacy (Hope it will be kicked off in a future).
PPC970 processor has some quirks in microarchitecture so it can’t stand against x86 in despite of the fact what 970 is even more complex conceptually than recent P6-derivatives.
Other RISC vendors (SUN =) are lagging behind with their products.
Of course in embedded world the situation is different.
Edited 2006-08-18 14:39