views:

76

answers:

4

Does developing applications for SPARC, IBM PowerPC require separate compliers, other than x86 and x86-64 targets?

If true, how easliy could x86, x64 binaries in Linux be ported to SPARC and PowerPC? Is there a way to simulate these environments using virtualization?

A: 

Use Java or LLVM, or try QEMU to test other CPUs.

It's easy if your code was written to be portable, it's not if it wasn't. Varying sizes of data types per platform and code that depends on it, inline assembly, etc. will make it harder.

Home page for LLVM and QEMU:

Gary
Pointer arithmetic is normally portable. Classing it together with assembly language is ridiculous.
Jerry Coffin
heh, I'm not experienced in this stuff. It's a problem for 32-bit vs 64-bit right?
Gary
This seems fine, choosing a portable lanuage, if there isn't already a large body of code that needs to run on the new platform, i.e., if rewriting or if starting from scratch, then one might have a choice of language, but when legacy code, it might not be possible.
Craig S
Why the downvote?
Gary
+1  A: 

No, virtualization is not the answer. Virtualization takes your hardware platform and creates an independent "virtual" machine of the same hardware. So when running on x86, you use virtualization to create a second x86 machine.

To simulate a completely different hardware architecture, you would want to look into emulation.

How easy / hard it is to port software from one architecture to another architecture depends completely on how the software was written. If it uses something particular to one architecture but not the other (for example, x86 can handle non-aligned memory accesses while SPARC does not) you are going to need to fix things like that. Another example that could make it difficult to port would be if the software has assumed a specific endian-ess of the hardware.

R Samuel Klatchko
+1  A: 

SPARC, IBM PowerPC require separate compliers, other than x86 and x86-64 targets?

I hate to be really snippy, but given that IBM PowerPC and SPARC do not support the x86 or x86-64 command sets (i.e. talk totally separate machine langauge), where did you even get the idea they would be compatible?

Is there a way to simulate these environments using virtualization?

Possibly yes, but it would be REALLY slow, because you would have to either translate the machine code, or - well - interpret it. Hardware virtualiaztion would not work, given that the CPU architectures are different. SPARC and PowerPC are not just "different labels for the same thing", they are really different internally.

TomTom
Hi Tom, appreciate your response, never mind snippy :). I knew that the CPU's are different, but my colleague suggested virtualization as answer, hence the question
maruti
Then your colleague is "wrong". Most virtualization relies on hardware support - which means "same chipset". THere are some that interpret / simulate the other CPU (Apple had one years ago when they moved from Motorola to PowerPc), but the overhead normally is significant - not really a solution.
TomTom
+5  A: 

First answer is, yes, to develop compiled code for Power Architecture or SPARC you need compilers that will generate code for those processors. A compiler that generates x86 or x86_64 code will not generate code that runs on Power Architecture or SPARC. You might find cross compilers running on x86 (32 or 64) that will generate Power or SPARC code, though. But the other thing to be aware of is the object file format (elf, xcoff, and so on). Instruction set is just part of the picture. You might get clearer answers if your provide more details of your particular starting point and goals.

Second, one normally doesn't talk of porting binaries. We port source code, which may include assembly language as well as C or other languages. The process for doing this includes compiler selection, after which you can begin an iterative process of compiling, porting, compiling, and linking the code for the new hardware. I'm omitting many details. Again, if you provide more specifics in your question, you might get more specific answers.

Third, as others have said, no, you can't use virtualization in the scenarios you allude to. You might find acceptable emulation solutions. Again, please provide more specifics if you can.

Craig S
Hi, specifics: we are looking for developing new components (C++) on Linux for a legacy windows app (c, C++). The API is in C and the requirement is Linux, Solaris and AIX. today our Dev Env is MS VS2008. Any feedback appreciated, thanks
maruti
So you have the source code for the legacy Windows app? This legacy app needs to run on the Linux, Solaris, and AIX or it runs on a Windows machine and you communicate with it remotely from the other platforms?
Craig S
legacy app (server) runs on windows and needs to communicate with new code on Linux, Solaris (clients). C, C++ API
maruti
OK, in this case it is fairly straight forward, in that no emulation is required. As long as you know the protocol for communicating between client and server, you just write new code for the Linux and Solaris clients in any language you want. The only portability issue, per se, is to make sure you stick with network byte order in any data you send over the network.
Craig S