Well, in ASM you have to target a certain CPU and architecture, but in C, you do not. Why is this? How come C is able to address different registries, but you have to specifically program code for a certain machine in ASM?
Well, in ASM you have to target a certain CPU and architecture, but in C, you do not. Why is this? How come C is able to address different registries, but you have to specifically program code for a certain machine in ASM?
Is this a homework question?
Anyway, give it a thought for a minute. Do you see anything in C that is specific to any architecture or CPU? For one, the C language does not have any registers, which vary by CPU, but rather variables which are a higher-level concept that is supported on all CPU's that can run C code.
No, I don't go to school. This was just one of my 'late night laying in bed questions'. Doesn't C address registers? Don't all programs? I thought higher level languages kept the registry information away from its users view. Did I miss a vital piece of programming knowledge?Originally Posted by christop
Yes, all programs that run "on the metal" (as opposed to interpeted) have to address a specific CPU's registers or memory in ways that are specific to that CPU. A C program can be cross-platform at the source code level, meaning it has to be compiled once for each different CPU that it is going to run on. The C compiler hides all those details.
So if I create a 'hello, world' program and compile it on my Intel 32bit machine, the same compiled program will not run on a 64bit machine, or even a machine with an AMD processor? I'm pretty confused? Does anyone have any documentation on this?
And what about when it comes to AT&T syntax?
Last edited by inu11byte; 08-05-2012 at 10:41 PM.
Some 64-bit CPU's are backwards-compatible with 32-bit programs, such as the Intel and AMD CPU's. Those all can be considered the same type of CPU for most purposes.
AT&T syntax has nothing to do with C. You can get assembly output from some compilers, but it's up to those compilers what syntax they produce. For example, GCC can compiler C to assembly language that the GNU assembler can read and assemble, but I don't know what assembly syntax it uses off the top of my head, and it probably also varies by CPU.
Edit: well, not probably but definitely varies by CPU. After all, Motorola 68000 assembly has much different syntax than x86 assembly.
If you want documentation, read your compiler's documentation.
Last edited by christop; 08-05-2012 at 10:54 PM.
> So if I create a 'hello, world' program and compile it on my Intel 32bit machine, the same compiled program will not run on a 64bit machine
You compile hello.c with a 32-bit x86 compiler and run it on a 32-bit x86 machine, and it outputs "hello world".
You compile hello.c with an ARM compiler and run it on an ARM machine, and it outputs "hello world".
You compile hello.c with a MIPS compiler and run it on a MIPS machine, and it outputs "hello world".
etc etc
The source code remains the same, you use the appropriate compiler for your target machine and the output is the same.
You can't take the executable with you, but you can take the source code wherever you like and recompile it as you go.
Different compilers will generate different assembler instructions, but the net effect from a user perspective is the same (a string is printed in the console).
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Alright, I'm still not getting it. I'm sure once I get it, I'll look back and see how stupid I have been.
Here's and example:
shouldn't run on a 64bit processor that it's backward capable. How does C generate code that address registries, and can bypass this limitation and be able to address/work on both 64bit and 32bit machines?Code:push ebp
If a 64 bit x86 machine (and its OS) supports 32 bit x86 programs (which the Intel and AMD CPU's do), the 32 bit x86 program will run on it. The 32 bit x86 program will also run on a 32 bit x86 machine, obviously.
Beyond that, I don't know what you're asking.
A working 64 bit compiler would do the right thing. It's that simple, and it isn't really a limitation. Imagine I gave you a recipe. I don't care what brand of range you use to cook.
> How does C generate code that address registries
You use the appropriate compiler!
Different compilers will generate different assembler code for the SAME source code.
A C program doesn't give a damn about register names, it's all hidden in the compiler.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
But how is it possible that people can make a program (.exe) and have it run on multiple architectures? How can someone compile a program and have it run when it would need to store it's values in different registries? I might be retarded... You're so sure on your answer, but I just don't get it.
The C source has to be compiled for each target. If I want a program to run on x86, x86-64, ARM, and MIPS, I would compile it with compilers that target each of those architectures (GCC can target those and many more architectures, for example). The compiled code (machine code) that runs on each architecture is different.
Woah. And here I was thinking compiling an Exe file would run on all windows machines... But that's not the case, correct? How do people make bots/botnets that infect windows machines and target both 64bit and 32bit systems? Thanks for all of your replies, they've been great.
Much of the point of C is that the compilers for C take some code as input that is platform independent, and produce as output something that is platform specific. It's a complicated and lossy translation from C to assembly.
The C language is there is there to remove the burden of having to write different code for every platform, in theory. Some compilers even output assembly and then a further step turns that into machine code.
Assembly is machine specific because every processor does things differently and/or has a different subset of instructions.
32-bit Windows programs run on a 64-bit Windows machine by the operating system effectively running them inside an emulator.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
