Printable View
i don't know if this question is valid or not.tried on google but i didnt get a solution.
does a compiler generate different machine codes for different cpus?
like does it generate different binary codes for intel and amd for the same program?
if so how does the compiler know what cpu the computer has?
then does a compiler generate different codes for different operating systems?
> does a compiler generate different machine codes for different cpus?
Yes.
> like does it generate different binary codes for intel and amd for the same program?
Possibly.
GCC for example will generate default code which will run on anything better than a 386.
Or you can have one of any number of machine specific flags which will generate more optimal code for a particular CPU variant.
> if so how does the compiler know what cpu the computer has?
You read the box the compiler came in (or the web page) to see what target(s) it supports.
> then does a compiler generate different codes for different operating systems?
The compiler probably doesn't care about your OS.
All the OS magic is usually hidden inside say libc, where the actual OS specific API's (say to open a file) reside.
To that end (creating an image that will run on a particular OS) is really a linker issue, not a compiler issue.
I tried on google and got a few links that looked like they might answer the question. Granted, they did not appear to answer the question directly, but it is pretty easy to infer the answer. (Like, if an alien wanted to know whether every country in the world used US dollar as the primary medium of exchange and after searching found a currency converter tool online, the alien would infer that there are currencies besides the US dollar, even though the currency converter did not provide an FAQ that explicitly stated this.)Quote:
Originally Posted by theju112
I think you need to be more persistent with your searching. Just because there is no FAQ with your exact question does not mean that you should immediately turn to this forum for help with the excuse that you tried to search but failed.
This is complicated... The answer is...
It depends on the compiler.
Cross-platform compilers will generate different code for different CPUs and different code again for different OSs.... But you have to tell it which. It can't possibly know at run time so it's up to the end user to select software that is compatible with their CPU/OS...
For Windows...
On 32 bit OSs Intel and AMD both run on the same x86 instruction sets. That was the AMD's whole idea... to make an Intel compatible CPU and they went right out and did it better than Intel.
On 64 bit Windows there are 2 code sets... IA64 whitch is specific to the Itanium processor from Intel and X64 (aka amd64) which is for both Intel and AMD 64 bit processors.
GENERALLY (as in there are exceptions)... Code produced by 16 bit compilers (Turbo C, some early GCC versions, etc) will not run on a 64 bit OS; windows will tell you it's not a valid PE image. 32 bit x86 code will run on both Intel and AMD in both 32 and 64 bit OSs, but this may not always be the case. 64bit x64 code only runs on 64 bit Intel and AMD systems and most compilers will not create 64 bit code on 32 bit systems because there would be no way to test it. 64 bit IA64 code only runs on 64 bit Itanium based server systems.
so you think im an alien(just joking).i know my all my posts sound like out of this world.it'll be that way till i am thrown out of here.:redface:Quote:
Originally Posted by laserlight
seriously i searched a lot...just wanted to save some time and wanted to be sure. will be careful next time.
thanks salem.i had read that libc contains library routines and headers but i didnt know apis would be in there. im not so familiar with APIs, all i know is that an api is used for performing specific functions on behalf of the programmer.Quote:
All the OS magic is usually hidden inside say libc, where the actual OS specific API's (say to open a file) reside.
To that end (creating an image that will run on a particular OS) is really a linker issue, not a compiler issue.
but your answer explains enough.
Quote:
Originally Posted by theju112
Welcome to my ignore list...
??? What on earth are you babbling Laser? Last time I checked in here, you were helpfull guy with posts containing knowledge that benefit the readers.Quote:
Originally Posted by laserlight
For me the original post appeared to be a valid question, related to C and containing greatly more interesting things to consider than the "snprintf's returnvalue may vary depending the operating system, and thus you should always handle both the negative and positive (larger than given buffer size) return values" - posts. Furthermore, now when Salem did answer to this question, this thread does benefit reader. It contains now some valuable information, which is much harder to find than the "thou shall not use void main, thou shall not use gets, ..." type of advieces these forums tend to be flooded with.
Aliens and currencies... For god's sake, couldn't you have used the time writing that took to produce something constructive instead?
so is your answer. i am not ready for all this sir.Quote:
Originally Posted by CommonTater
this is the first time im hearing IA64.
2 code sets in windows?is this something related to cisc and risc?
Sorry, when I learned assembler, I found that no one use assembler to write driver because each assembler just comparable with some type of processor (for example: you need an assembler A to write program for AMD and assembler B to write program for INTEL), they always write driver on some high language, (maybe the most is C) --->so my answer is: when you write a program, when compile it, each processor will have different binary code.
And how about different OS, I think obvious that different(and very different too @@)( except language like java that I don't know). for example, when you write on C on Windows, C will use some API functions of windows and if you use C on Linux, of course C will use other function--> so binary code will be different.
I have read somewhere, they tell that, slogan of java is "write once, run anywhere",It seems that binary code of two different OS are same!!! (but every java program, they run on "Java virtual machine", so maybe, this thing make two programs different :D
all information above maybe.... very wrong :">
For future reference, posts such as these belong in the Tech Board. As for your questions, you are going to need to understand the difference between compilation and linking. Additionally, you are going to want to look at Instruction Set Architecture (ISA) and the ELF and PE file formats.Quote:
Originally Posted by theju112
After reading through this information, you should be able to ask more informed questions, and hopefully have the required knowledge to narrow your search terms to prevent not being able to find the answer by yourself.
thanks for that maz . but youll probably change your mind if you read my other posts.Quote:
Originally Posted by Maz
but as you pointed out i asked the question because i had a difficult time searching for the answer.
I don't know who you are, but your post was neither informative, funny, or even the slightest bit justified.Quote:
Originally Posted by Maz
All the information is wrong and should be ignored. Please check your facts more thoroughly before posting replies.Quote:
Originally Posted by hqt
please please wait wait wait......i am just fooling around.Quote:
Originally Posted by CommonTater
please continue posting answers.
though we always end up on the wrong sides,i value your answers.
if you still want to add me to your ignore list,im helpless.
Not actually true... on 32 bit code, both Intel and AMD run the same basic x86 instruction sets and their code is interchangeable. Assemblers like MASM and POASM see no difference between them.Quote:
Originally Posted by hqt
On 64 bit code you have two instruction sets... IA64 and x64 (aka amd64)... IA64 is specific to the Intel Itanium server chip... x64 code will run equally well on both Intel and AMD processors, provided the OS is compiled as 64 bit code.
Windows 64 bit versions run x86 code through an emulator (stupidly named WOW64) but do not run 16 bit IAPX code at all.
The Java run time environment is OS specific... the token code interpreted by the runtime is not.Quote:
And how about different OS, I think obvious that different(and very different too @@)( except language like java that I don't know). for example, when you write on C on Windows, C will use some API functions of windows and if you use C on Linux, of course C will use other function--> so binary code will be different.
I have read somewhere, they tell that, slogan of java is "write once, run anywhere",It seems that binary code of two different OS are same!!! (but every java program, they run on "Java virtual machine", so maybe, this thing make two programs different :D
all information above maybe.... very wrong :">
ah :) I don't joke anything or tell something just for funny. but after some my stupid post about pointer, I see that I may... very stupid, so I don't trust information that I have learnt by myself :(Quote:
All the information is wrong and should be ignored. Please check your facts more thoroughly before posting replies.
andrew wait.hqt has a point there.Quote:
Originally Posted by hqt
java slogan "write once, run anywhere".thats a really good point for my question about different os.
this is a bit compilcated
Er..Quote:
Originally Posted by hqt
1. Get some new sources of information.
2. Write in a way such that right information is not interpreted as wrong.
It applies to any language if you follow the standards and use a standard compliant compiler.Quote:
Originally Posted by theju112
this forum is good but theres too much distraction and bad language for a technical forum.i quit. if possible somebody delete my account.
ok thats all folks.
One of the best ways around this problem is to invest in a few books (or at minimum downloadable tutorials) and to actually study from authoritative sources... The operative term being "actually study"...Quote:
Originally Posted by hqt
When learning C read the page, type up the examples and play with them, change them break them, improve them until you understand what is going on... then move to the next page...
For information about hardware standards such as USB, X86, IA64, SATA... there are hundreds of them... locate and download the standards documents themselves and read them.
We all get stuff wrong... I do it all the time... but that is part of how we learn.
Certainly making the occasional mistake does not make one stupid...
Stupid happens when you don't learn from your mistakes.
No it isn't.......Quote:
Originally Posted by theju112
As now both Tater and manasij have pointed out the runtime environment is OS specific, the language is not. Any scripting language is not compiled and is interpreted by it's run time environment so it can be executed on a machine. This interpretation is very much so OS/ISA specific.Quote:
Originally Posted by manasij7479
... on the target platform.Quote:
Originally Posted by manasij7479
C's source code if written to cross-platform standards (eg C-99) can be recompiled on different platforms (Windows, Linux, Mac, etc.) but you aren't goint to run a Windows program on Linux or a Linux program on windows without adding an OS-specific emulator layer to do so. Even on windows64 32 bit windows code is run through an emulator layer called WOW64.
This is what the java runtime is... it's an OS specific interpreter for the Java language. It takes Java standard "token code" (look it up) and translates it for the underlying OS...
I believe that is what manasj is talking about. The actual source code can be moved between different platforms, just like the java source code can move between target systems.Quote:
Originally Posted by CommonTater
Then my previous post should be construed as agreement :DQuote:
Originally Posted by AndrewHunter
Hmm ... I don't think I agree with quite a bit of the stuff posted here.
Let's see. A compiler compiles code to a specific target. A target is typically a combination of instruction set (+ extensions) and executable format, with the ABI of whatever libraries you use mixed in for good measure. A compiled executable can thus run wherever there is an environment compatible with its target.
Let's explore in greater detail what that means.
Executable format is basically Linux (and others) using ELF (used to be a.out), Windows (and OS/2) using PE, and Mac using MachO. I will not go into these any further.
Instruction set means what the CPU (or interpreting software) understands. There are some fundamentally different ISAs, like the x86 family, ARM (iPhone and most other smart phones), IA64, and MIPS (some game consoles, e.g. PSX I think). Most ISAs also have optional parts, e.g. Thumb for ARM, or the various SSE sets for x64.
Any CPU may understand more than one ISA, actually. For example, the Itanium2 CPUs have hardware emulation capability which allows them to understand 32-bit x86 code. x64 CPUs still have legacy modes so that they can execute 16-bit, 32-bit or 64-bit code. More specifically, an x64 CPU can be in legacy mode, where it can execute 16-bit or 32-bit code, or in long mode, where it can execute 32-bit or 64-bit code. Switching between the two big modes needs a reboot, but switching between the two sub-modes is as easy as a context switch, which allows 32-bit and 64-bit apps to run side-by-side in a 64-bit OS.
In addition, you can emulate CPUs in software, if the host CPU is fast enough. That's what all the console emulators do (e.g. a GameBoy emulator would emulate a Z80 CPU), but also some other applications: PearPC emulates a PowerPC CPU to let legacy Mac apps run on Intel Macs. Dosbox emulates a 16-bit x86 CPU. Even virtualization hosts, such as VMWare, do a bit of emulation.
A compiler must target a specific instruction set. Nowadays, a typical target would be x86-64 code. But then you might want to use those fancy SSE3 and SSE4 instructions too. You can tell the compiler to use these as well, but then your code won't run on older 64-bit CPUs anymore. You have various options. You can forget about these instructions, sticking to the base instruction set. You can require that a new enough CPU is used. Or you can compile multiple versions, one with these instructions and one without, and then write code to detect the CPU at runtime (x64 has the handy CPUID instruction for this) and choose the correct version of the code. Some compilers can generate the switch automatically.
That leaves ABI. ABI is basically: "what libraries/directly accessible hardware does the target environment have, and how do I access them". Back in DOS times, many things were done by directly accessing hardware, reading and writing I/O registers. If those registers change, that's breaking the ABI. Even though the OS can understand the executable, and the CPU run the code, it won't do the right thing.
Nowadays hardware access is limited to the OS, and you just access libraries provided by the OS. Of course, the library you want must actually exist, containing the functions you want to call, and use the calling convention you expect. That last part is important: for example, Windows and Linux typically have different rules for how arguments are passed to functions. Get this wrong, and your code will misbehave. An x64 CPU has no problem executing 32-bit code, but you also need the 32-bit libraries. (That, by the way, is 99% of what WoW64 (Windows on Windows64) does - it doesn't actually emulate anything. It just is a bunch of 32-bit libraries that calls the 64-bit OS routines while translating arguments.)
Now, the WINE project does two things: First, it implements a PE loader for *nix, which enables Windows executables to be loaded, thus solving the executable format interoperability. Second, it provides libraries ABI-compatible with the Windows libraries, which enables Windows executables to run, thus solving the ABI interoperability. Note that WINE doesn't emulate a CPU: you have to run it on a x86 CPU. This is why WINE is not an emulator: it doesn't provide a complete environment, only parts.
Finally, bytecodes like JVM bytecode (Java compilation target) and MSIL (C# compilation target) are basically hypothetical CPU ISAs. The specifications also specify library calling conventions and executable formats (Java .class files and JAR archives, .Net assemblies), thus completing the abstract execution environment. Virtual machines, then, are basically emulators for these environments. Since emulators provide an abstraction between the host and the emulated platform, Java and C# programs can in principle run anywhere after being compiled. Because the abstract execution environment is defined in a way that allows high-performance VMs, this is even reasonably fast, unlike emulators for real CPUs, which tend to eat up a lot of performance. (Of course, such emulators also typically have to emulate a bunch of other hardware.)