Let's say I've got a collection of source code written for second-generation sparc processors, and some of the C code is architecture-dependent. How can I compile this code for x86 and ARM processors? I initially thought it'd be easy to use GCC and cross compile, but that seems to be too simple. Am I at least on the right track? Thanks!
You can compile it by using compilers that target the required platforms, on whatever host you like. If you're cross-compiling or not doesn't matter.
What matter is that if the code contains non-portable things, you're going to have to fix those manually. No compiler can do that for you.
For instance, if you assume that the code is running on a big-endian architecture, you're going to have to find all such places and fix them (since x86 and, typically, ARM too are both little-endian). Have fun.
Related
is Program compiled by amd64 compiler executable and possible to run,work properly in x86 cpu??
I wanna know whether it's possible
and also im trying to develop some program in Qt
but I'm wondering at that why there is no qmake.exe that supports MSVC2017 32bit compiler
No. But a program written without reference to specific architecture dependent features (i.e anything written using standard c, c++, etc) can be compiled using different flags for different target architectures.
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html
If you are interested in why, looking at the spec for x86 or x86-64 will give you a sense of the answer. An architecture specification is alot more than a list of supported machine instruction. They have different memory architecure, different flags, different cpu modes, etc. And in addition to all this, specifications have hardware specific implementations (chips support different features). When you compile a executable binary, all of these differences must be taken into account.
I came across two guides for making a simple kernel in C.
http://wiki.osdev.org/Bare_Bones
https://github.com/arjun024/mkernel
The first one develops a kernel for i686 architecture, while the second one develops for i386.
The main part I'm finding confusing is, we used a cross compiler to compile and link the first one, but didn't use any for second. So if compiling and linking the second one is possible without using a cross compiler, why are we using a cross compiler in the first?
A cross compiler is a compiler used to compile to a different platform or architecture. As said in the comments above, the osdev wiki has a lot of information on it. But in general, you don't need a crosscompiler only if you compile to the same platform as your host machine. If your host is x86_64, and you're making an operating system targeted to x86_64, you don't need a cross compiler. Otherwise, if you're on an x86_64 machine and are compiling for x86 (32 bit) or arm, you do need a cross compiler.
That having said, Michael Petch is completely correct in his comment that using a cross compiler usually is a very safe option, eliminating some problems related to host machines. Though I have never experienced these problems myself, they are valid concerns.
I understand that when the C compiler compiles code, it compiles it into machine code that is specific to the processor that it was compiled on. Is it possible to compile my C program on an Intel machine for example, and have it run on an AMD one without needing to recompile it on a machine with an AMD processor?
In fact both common Intel and AMD processors are based on X86 architecture. Although C program cannot be compiled once and run "everywhere", but Intel and AMD processors are really the same place in this sense.
For example you don't really worry about a single executable (say a game installer) wont be able to run on your windows machine regardless of it's Intel or AMD inside.
It's other architectures (different instruction set) such as Mac/ARM/68k etc you need to worry about recompiling
I am getting the following error while trying to compile some code for an ARM Cortex-M4
using
gcc -mcpu=cortex-m4 arm.c
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
arm.c:1: error: bad value (cortex-m4) for -mtune= switch
I was following GCC 4.7.1 ARM options. Not sure whether I am missing some critical option. Any kickstart for using GCC for ARM will also be really helpful.
As starblue implied in a comment, that error is because you're using a native compiler built for compiling for x86 CPUs, rather than a cross-compiler for compiling to ARM.
GCC only supports a single general architecture type in any given compiler binary -- so, although the same copy of GCC can compile for both 32-bit and 64-bit x86 machines, you can't compile to both x86 and ARM with the same copy of GCC -- you need an ARM-specific GCC.
(As auselen suggests, getting a pre-built one will save you quite a lot of work, even if you're only using it as a starting point to get things set up. You need to have GCC, binutils, and a C library as a minimum, and those are all separate open-source projects that the pre-built versions have already done the work of combining. I'll recommend Sourcery CodeBench Lite since that's the one my company makes and I do think it's a fairly good one.)
As the error message says -mcpu is deprecated, and you should use the other options stated. However "deprectated" simply means that its use may not continue to be supported; it will still work.
ARM Cortex-M4 is ARM Architecture V7E-M, so you should use -march=armv7-m (the documentation does not specifically list armv7e-m, but that may have been added since the documentation was last updated. The E is essentially the difference between M3 and M4 - the DSP instructions, so the compiler will not generate code that takes advantage of these instructions. Using ARM's Cortex-M DSP library is probably the best way to use these instructions to benefit your application. If your part has an FPU, then other options will be needed enable code generation for that.
Like others already pointed out, you are using a compiler for your host machine, and you need a compiler for generating code for your target processor instead (a cross compiler). Like #Brooks suggested, you can use a pre-built toolchain, but if you want to roll out your own cross-compiler, libc and binutils, there is a nice tool called Crosstool-NG. It greatly simplifies the process of building a cross-compiler optimized to generate code for a specific processor, so you're not stuck with a generic prebuilt toolchain, which usually builds code for a family of compatible processors (e.g. you could tune the toolchain for generating ASM for your specific target, or floating point code for a hardware FPU which is specific to your processor, instead of using only software floating point routines, which are default to most pre-built toolchains).
see i have written one program for big endian now i dont have big endian machine but i want to check whether my program will works correctly or not on big endian so how can i check that on my little endian pc.?
Is there any online virtual big-endian compiler ?
note : i have googled about this but did not get anything.
qemu can virtualize all sorts of architectures, amongst then big endian ones.
Qemu is useful as an emulator/virtualizer, i.e. for running the program, but you'll need something to compile it in the first place.
Once you have chosen a big-endian architecture supported by qemu, for example PowerPC, you'll need a cross-compiler which runs on your PC but produces binaries for this architecture (e.g. PowerPC).
If you're very lucky, your distribution contains some binaries. However, in most cases, you might be forced to compile binutils, glibc and gcc yourself.