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
Related
I have been developing code for an older device which has an NXP i.MX28 single core CPU which is ARM-based. The device runs Embedded Linux.
I am now upgrading to a better device which has an NXP i.MX6UL quad core processor, of course ARM-based also, and also running Embedded inux.
Is it normal that the same toolchain which I was using for the for building the code for the i.MX28 will also work for the i.MX6UL, even though the i.MX6UL is more advanced with more cores etc.?
I have built my code now for a test with the same compiler and even run it on a Rasberry Pi which seems to run ok. The Rasberry Pi uses a Broadcom BCM2711 SoC with an ARM Cortex-A72 processor which again is a different CPU.
I therefore must ask, will any ARM toolchain build code and be able to run on any type of ARM device regardless?
CPUs differ by the core architecture (incl. instruction set) and set of peripherals. Difference in the peripherals is solved by drivers and HALs. Difference in core arch is solved by the toolchain.
If the toolchain "knows" new arch it will emit the corresponding assembly code, that will run on the new CPU. So, compilers will not produdce the same assembly, but the same source code will run after rebuild, that's the idea of high-level languages.
Problems emerge when old code contains an inline assembly, or uses some specific DSP instructions or libraries
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.
C is a compiled language that compiles to native CPU instructions, as you know.
But if C compiles differently to each CPU, then why don't basic Windows programs work on a Mac, for example (considering they both have a processor from the Intel 386 family)?
A good example of that is the printf function in C, that would compile differently on
Windows and on a Mac OS X, even if they both sit on the same kind of processor (Intel 386).
I'm not actually sure that it really compiles differently under each OS, but the fact that a simple Windows application that outputs "Hello World!" to the Console Window won't open on a Mac, kind of make it seem like it compiles slightly differently.
I know for sure that GUI compiles differently because it calls system functions to draw on the screen, but why printf compiles differently on each OS? I thought it was CPU dependent, not OS dependent, and from what I know a Windows PC and a Mac both having an Intel 386 CPU means they both have the same instruction set.
So can you guys explain this, please?
The C standard specifies the language and a very API and expected behaviour of a very minimal run-time library to support it.
It specifically does not specify the specifics of object-file format produced by the compiler - necessarily so - as we'd expect object files produced by C compiler to link with other libraries provided by the platform, and for the system linker to link them.
Taking your example of two systems with CPUs running on hardware with the same architecture (Windows and MacOSX) - the way dynamic linking on these platforms works under the hood is quite different, as are the object files produced by the compiler. Even with systems using the same CPU, there may also be ABI differences as well.
I have a small C program that I wish to port from Linux to Windows. I can do this with the MinGW compiler, and I have noticed that it has two different prefixes, amd64 and i586. I am on an i686 computer and I was wondering if I compile my C program using and amd64 architecture, will it run on my i686 machine? And vice-versa?
UPDATE:
Is there a compiler that compile C code to run on ANY architecture?
If you compile your code for i586 (actually what is commonly called x86) it should work fine on AMD64 (x86-64) processors, since x86-64 processors can execute "legacy" 32 bit code, as long as the OS supports this - and mainstream OSes usually do; Windows support for 32 bit applications in particular is really good, since most applications installed on the average Windows system are still 32 bit.
The contrary instead does not hold true, since the x86-64 instruction set is (loosely speaking) an expansion of the x86 architecture, so any non-64 bit x86 processor wouldn't know how to interpret the new machine code (and even if it knew it, it wouldn't have the resources to run it).
As for the edit, you can't generate machine code that runs natively everywhere; the usual solution in such cases is to use pseudo-compiled languages that output an intermediate-level machine code that needs an architecture-specific VM installed to be run (the classic example here is Java and .NET). If instead you use a language compiled to "native code", you have to generate an executable for each target platform.
The C language was used to write UNIX to achieve portability -- the same C language program compiled using different compilers produces different machine instructions. How come Windows OS is able to run on both Intel and AMD processors?
AMD and Intel processors(*) have a large set of instructions in common, so it is possible for a compiler or assembler to write binary code which runs "the same" on both.
However, different processor families even from one manufacturer have their own sets of instructions, usually referred to as "extensions" or whatever. Ignoring the x87 co-processor, the first time I remember this being a marketing point was when everything suddenly went "with MMX(TM) technology". Binary code expected to run on any processor either needs to avoid extensions, or to detect the CPU type before using them.
Intel's Itanium 64-bit architecture was completely different from AMD's x86-64 architecture, so for a while their 64bit offerings were non-compatible (and Itanium was nothing like x86, whereas x86-64 extended the instruction set by adding 64bit instructions). Intel blinked first and adopted x86-64, although there are still a few differences: http://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64
Windows probably uses the common x86 or x86-64 instruction set for almost all code. I wouldn't be surprised if various drivers and codecs are shipped in multiple versions, and the correct one selected once the CPU has been interrogated.
(*) Actually, Intel make or have made various kinds of processors, including ARM (Intel's ARM processors were called XScale, but I think they've sold that business). And AMD make other processors too. But we know which Intel/AMD processors you mean :-)
AMD are Intel compatible, otherwise they would never have gained a foothold in the market place.
They are effectively clone compatible.
As you suspect, the main stream Intel and AMD processors have the same instruction set.
Windows does not run on ARM or PowerPC chips, for example, because it is somewhat dependant on the underlying instruction set.
However, most of Windows is written in C++ (as far as I know), which should be portable to other architectures. Windows NT even ran on PowerPC and other architectures.
Intel's 80x86 CPUs and AMD's 80x86 are "mostly the same sort of", but some things are completely different (e.g. virtual machine extensions - SVM vs. VT-x) and some things (extensions) may or may not be supported. However, some things are different on different CPUs from the same manufacturer too (e.g. some Intel chips support AVX2 and some don't).
There are multiple ways to deal with the differences:
only use the common subset so the same code runs on all 80x86 CPUs (e.g. treat it like an 8086 chip).
use a subset of features that is common to a range of CPUs so the same code runs on all 80x86 CPUs in that range. This is very common (e.g. "this software requires an 80x86 CPU (and OS) that supports 64-bit extensions").
use install-time tests. For example, there might be 4 different copies of software (compiled for 4 different ranges of CPUs) where the installer decides which copy makes sense for the computer the software is being installed on.
use run-time tests. For example, code can use the CPUID instruction to do if( AVX2_is_supported() ) { set_function_pointers_so_AVX2_is_used(); } else {set_function_pointers_so_AVX2_is_not_used(); }. Note: Some compilers (Intel's ICC) can automatically generate code that does run-time tests.
These aren't mutually exclusive options. For example, the installer might decide to install a 64-bit version (and not a 32-bit version), and then the 64-bit version might check which features are supported at run-time and have different code to use different features.
Also note that different parts of an OS can be treated separately. For example, an OS could have 6 different boot loaders, 4 different "HALs", 4 different kernels, and 3 different "kernel modules" to support virtualisation; where some of these things might do run-time tests and some might not.
Do Intel and AMD processor have the same assembler?
Almost all assemblers for 80x86 support almost all extensions (from all CPU manufacturers - e.g. Intel, AMD, VIA, Cyrix, SiS, ...). In general; it's up to the programmer (or compiler) to make sure they only use things that they know exist. Some assemblers provide features to make this easier (e.g. NASM provides a CPU ... directive so that the programmer can tell the assembler to generate errors if it sees instructions that aren't supported on the specified CPU).
AMD and Intel use the same instruction set.
When you install windows on an AMD processor or an Intel processor, it doesn't "compile" code on the machine.
I remember many people being confused on this subject back during college. They believe that a "setup" means that it is compiling code on your machine. It isn't. Most if not all Windows application outside of the free realms, are given to you by binary.
As for portability, that isn't neccessarily 100% true. While C is highly portable, in many cases writing for a specific OS or system will result in the code only being able to compile/executed on that box. For example, certain Unix machines handle files and directories differently so it might not be 100% portable.
Do Intel and AMD processor have the same assembler?
An assembler assembles a program to be run on a processor, so your question is flawed. Processors DO NOT use assemblers.
If you mean can Intel and AMD processor run the same assembler? Then the answer is YES!!!
All an assemblers are, is a program that assembles other programs from structured text files. Visual Basic is an example of an assembler.