I'm going to port a large C++-Project to x64 (some parts of it are written about 15 years ago) and I found that the 64-bit compiler does not support inline assembly, so I have to change the code. I would like to know if there are more differences or incompatibilities between both compilers. Or the better question would be are there parts of 32-compiler which 64-compiler does not suport.
Relevant articles:
The forgotten problems of 64-bit programs development
Seven Steps of Migrating a Program to a 64-bit System
Collection of Examples of 64-bit Errors in Real Programs
Related
I See this question, and I would like to know if I could do something similar with D.
More specifically, I am developing from a Linux machine, with x86_64 processor.
I am targeting
Linux machines with x86_64 processor (not the biggest problem)
Macs with x86_64 (should be doable...)
Windowes with x86_64 - This is where the cross platform issues come into play. As a part time developer without any access to windows machine, and reluctancy to get one, I am more interested in platform independant coding than porting to windowes.
Windows with i686 (32 bit) - is that even possible to compile code for both 64 bit and 32 bit targets?
Project is currently on a Linux machine, and uses entirely the standard Phoboes library, and the import part is, it heavily uses LuaD and some C source compiled to *.o files.
D makes it very easy to write portable source code, as the standard library provides abstractions for many OS-specific APIs. Otherwise, the same answers for C++ will generally apply to D, although currently all implementations compile D to native code.
You can generate Windows binaries by running a Windows D compiler under Wine. In theory, cross-compilation should be possible with GDC and LDC, but I don't know how mature it is with either toolchain.
If D.NET project succeeded you would have an answer. Current state is that there is no D compiler which targets JVM or CLR, or any other VM. All current D compilers compile into the native machine code. I dreamed of starting a project to make D compiler which targets JVM, but unfortunately have no time for such (enormous) project.
Almost 30 years after MASM 6.0, It is still being used for educational purposes worldwide.
The 16 bit MASM is what is being taught.
I use linux and am quite pained that not a single MASM assembler is available.
1.Wine does not work
2.DOSBOX does not run the linker
3.I don't have an windows XP cd to run in a VM
4.My only windows computer is windows 8.1, which does not support MASM
People suggest NASM but the syntax is not same as a 16 bit MASM assembler.
Is it illegal to make a MASM for linux, or any windows 7 and above??
I was thinking about coding a simple one for educational purposes myself.
I don't quite understand the difference between the following C/C++ compilers: GCC, MinGW, Cygwin and MSVC. Are the MinGW and Cygwin implementations of GCC or something entirely different? If I intend to compile for Windows, do I ever need anything other than the MSVC (Visual Studio) compiler?
GCC for Windows is mostly useful for makefiles and code written with gcc-specific non-portable syntax.
cygwin is not a compiler, it's a set of libraries that create a Linux-like environment inside Windows, and common linux tools compiled with those libraries.. It is useful for code written with Unixisms (expect files to behave a certain way, or assume the directory separator is /, or assume Linux paths).
If you have pure Windows code, you'll be happiest with Visual C++ (MSVC). Or, if that doesn't optimize well enough, the Intel C++ compiler.
Visual C++ also works well for portable ISO-conformant code... but Microsoft is a little behind the curve on implmenting C++11 and C++14 features. So that's another reason you might want to use gcc (or clang).
I am teaching myself/reading up about assembly. Most of the books on assembly refer to x86- all the register names in the code begin with "e" and not "r" (as they would in x86-64). However, I use 64-bit Linux and I was wondering if these books have any value because they are not referring to x86-64.
So in short- is it really worth me using these resources to learn x86-64. Or reworded differently, besides the difference in register naming convention- are there any other differences between the two which could make learning from x86 materials difficult?
64 bit Linux allows running 32bit applications, so you still can create 32 bit applications on your computer. This way, the books and example 32 bit code are fully useful.
The only single problem you might have is if the assembly application dynamically link to some 32 bit shared library. In order to fix this you should install 32 bit compatibility layer.
The assembly programs that use only Linux system calls works fine without this layer, which is actually set of shared libraries compiled for 32 bit.
BTW, in my opinion, writing 32 bit code is still better if you want your programs to be useful for more people. There are still many 32 bit computers around and they will not disappear soon.
It's indeed a bit easier to learn assembly on 32bit since the calling conventions and stack management are simpler.
On 64bit you need to worry about ABI. Not only that but the conventions are not the same for every OSes. For instance, the ABI rules on Mac OS X are different than those on Windows (the registers are not the same and on Windows it only uses 4 registers).
You can compile your assembly code using -arch i386 with the assembler (as). With clang or gcc you can use -m32 (at least on Mac OS X, since I haven't used it on Linux proper). You won't be able to link modules that have different bitness (32bit vs 64bit).
Once you're ready to switch or compile your program for 64bit you will have to make sure that when you handle the stack you need to push 64bit words instead of 32bit ones but that kinda goes with saying.
Does developing applications for SPARC, IBM PowerPC require separate compliers, other than x86 and x86-64 targets?
If true, how easily could x86, x64 binaries in Linux be ported to SPARC and PowerPC? Is there a way to simulate these environments using virtualization?
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.
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.
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.
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:
http://llvm.org/
http://wiki.qemu.org/Main_Page