I'm learning assembly.
I know that gcc supports at&t syntax but i want my program to run on intel processors.
So would it work on intel processors regardless the syntax or it must be intel syntax to work on intel platform!! i'm confused??
Thanks.
att vs intel syntax has been covered many times, here and other places.
Assembly language is a language defined by the assembler, the particular program used to convert the ASCII assembly language into machine code for the particular target you are interested in. Unlike say a C or C++ compiler where there is a standard that defines the language, you can have 7 assemblers for the same target processor and there is no reason to assume that the assembly languages have to be compatible in any way shape or form. It is the machine code the produce that matters and if that machine code matches the same target then use the tool you like the best for whatever reason.
For this case there was the intel format as defined by the intel documentation and supported by the intel assembler. And then supported sorta by other assemblers. The instructions were close or the same they might have had a compatibility mode and maybe they had their own directives. For example as86 (or was it asm86 or a86?) tasm, masm, and currently nasm. And then you had this AT&T syntax, someone somewhere (ATT?) decided to make an assembler with a goofy assembly language that specifically didnt match the intel documentation at all. And that became the Intel vs AT&T syntax thing. gnu assembler is well known for messing up existing assembly languages as well, and they apparently use AT&T with their own nuances thrown in. they might have an intel syntax switch you should check.
The question you should be asking is the target, and assemblers like gnu assembler for x86 are often capable of generating code for various flavors of x86, so you need to make sure it matches your computer (most likely does if you dont add any target type/specific options).
There is no reason to assume an AT&T syntax assembler (gnu assembler (gas or as)) would not work.
Related
The build system on my cross-platform project has a command line for Intel's Windows C++ that may or may not have /Qstd=c++0x as a result of detecting the compiler feature set. For most of the code base, this works well, however for a small number of CUDA files, I need to disable the more recent dialects of C++ to suit the constraints of the nvcc wrapper compiler.
How should I phrase something like /Qstd=c++98 or /Qnostd=c++0x at the end of the command line so that it overrides any earlier specifications of C++ dialect?
Edit: Having been educated that these flags are actually for the Intel compiler, I have found that appending /Qstd=c++98 is probably the right approach.
You can't for MSVC. Each MSVC version expects its own interpretation of something between two or three standards, and you're stuck with it.
The options you quote are for the Intel Compiler (see here). If possible, I'd suggest using the Intel Compiler then.
I do fail to see how disabling the recent dialects in the C++ compiler will please the nvcc wrapper compiler... Just don't write C++11 code, and you'll be fine right?
I just Likely know that in which platform operating system coded.
as per my knowledge.
Windows kernel written in C language.
Linux kernel is also written in C language.
but remain operating system in?
In which Platform C language is written?
Yes, the Windows kernel and Linux kernels are written in C. Most operating systems tend to be.
There are operating systems written in other languages though, the Chorus kernel for example is written in C++.
Most C compilers are also written in C. That has the advantage that once you managed to get the compiler running on the machine (generally by compiling it on another machine that already has a working compiler/cross compiler), the machine itself can compile updates to its own compiler without maintaining yet another compiler.
Most parts of the C compiler (like gcc) are written in C themselves. Of course you would need something to bootstrap your compiler such that it can compile itself. That would then be a lower type language like Assembler.
The C language is one of many languages that are considered to be Self Hosting - that is to say that the compiler can compile its own source code, which is written in the same language that the compiler is designed to compile.
You might also want to look into the process of Bootstrapping, which is the process used to get the first compiler for a particular language to run on a given platform - as others have noted, this can be by way of cross-compiling, or by writing the original compiler in a different language, though other techniques are possible.
First off, you might want to improve your question with actual sentences.
Second,
C is not written in a platform, it is written in another programming language.
Most compilers are written in assembler, a somewhat readable version of the actual machine codes sent to the processor.
I don't know if there are other compilers, written in some intermediary language but eventually, everything boils down to assembler code, which compiles to machine code.
I was looking at a question about atomic compare and swap and gcc intrinsics. I noticed that an answer quoted from the gcc manual (note the answer I looked at quoted from an earlier version of gcc but I've linked to the latest versions manual because I had checked to see if anything changed). However, when I looked at the text in the manual I saw that it appears to reference Itanium rather than x86:
The following builtins are intended to be compatible with those
described in the Intel Itanium Processor-specific Application Binary
Interface, section 7.4. As such, they depart from the normal GCC
practice of using the “__builtin_” prefix, and further that they are
overloaded such that they work on multiple types.
My question is why does gcc reference Itanium documentation and does that effect how the intrinsics work on x86? Are there any differences or is it safe to assume that even though the gcc manual references the Itanium manual that everything the gcc manual describes will work correctly on an x86 system?
My understanding is that a lot of gcc's ABI decisions (the egcs fork) were based on the ABI specs for the good ship Itanic. This included the name mangling conventions for C++ symbols. There was a large effort (Project Trillian) to have IA-64 Linux (and GCC) ready to go when the actual processor became available. The semantics are intended to be platform-independent, though they will be replaced by the __atomic builtins.
Okay. I want to learn how to assemble programs on my Mac (Early 2009 MBP, Intel Core 2 Duo). So far, I understand only that Assembly languages are comprised of direct one-to-one mnemonics for CPU instructions. After some Googling, I've seen a lot of terms, mostly "x86" and "x86_64". I've also seen MASM, NASM, and GAS, among others.
Correct me if I'm wrong:
x86 and x86_64 are instruction sets. If I write something using these instruction sets (as raw machine code), I'm fine so long as my program stays on the processor it was designed for.
NASM, MASM, and GAS are all different assemblers.
There are different Assembly languages. There's the AT&T syntax and the Intel syntax, for example. Support for these syntaxes differ across assemblers.
Now, questions:
As a Mac user, which instruction sets should I be concerned about?
Xcode uses GCC. Does this mean it also uses GAS?
If it does use GAS, then should I be learning the AT&T syntax?
Is there a book I can get on this. Not a tutorial, not a reference manual on the web. Those things assume to much about me; for example, as far as I know, a register is just a little bit of memory on the CPU. That's how little I really know.
Thanks for your help.
If you want to learn assembly language, start with the x86 instruction set. That's the basic set.
A good book on the subject is Randall Hyde's the Art of Assembly Language, which is also available on his website. He uses a high-level assembler to make things easy to grasp and to get going, but deep down it uses GAS.
I don't believe that XCode comes with any assembler, but you can for example find GAS in MacPort's binutils package.
If you just want to make programs on your Mac and you're not that interested in the life of all the bits in the CPU, you're much better off with a more high-level language like Python or Ruby.
"I'm fine so long as my program stays on the processor it was designed for." Not really. In many cases, assembler programs will also make assumptions about the operating system they run on (e.g. when they call library functions or make system calls). Otherwise, your assumpptions are correct.
Onto questions:
Current Macs support both x86 and x86-64 (aka AMD64 aka EM64T aka Intel64). Both 32-bit and 64-bit binaries can be run on recent systems; Apple itself ships its libraries in "fat" (aka "universal") mode, i.e. machine code for multiple architectures.
Use "as -v" to find out what precise assembler you have; mine reports as "Apple Inc version cctools-698.1~1, GNU assembler version 1.38". So yes, it's GAS.
Yes.
https://stackoverflow.com/questions/4845/good-x86-assembly-book
I'll answer the first question:
Macs use Intel chips now, and modern processors are 64-bit.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'd like to learn assembler. However, there are very few resources for doing assembler with OS X.
Is there anyone out there who has programmed in assembly on a Mac? Where did you learn?
And, is there any reason I shouldn't be doing assembly? Do I risk (significantly) crashing my computer irreparably?
If you're using a PowerPC Mac, look into gcc inline assembler. Otherwise, look into nasm. I can't give any decent references to PPC ASM (they're few and far between), but I suggest the following things to learn x86 asm:
The book Reversing by Eldad Eilam
Compile simple C source with gcc -S and read the assembly generated
Use Sandpile
Join #openrce on irc.freenode.net and use OpenRCE
Also, if you're not in kernel mode then there's no chance of screwing anything up, really, and even if you are in kernel mode it's hard to really destroy anything.
Edit: Also, get gcc and such from XCode not Macports or somesuch. You're in for a world of malformed Mach-O files if you don't. Not fun to diagnose file format issues when you're just starting asm hacking.
The assembler language is determined by the hardware platform, not the operating system. Given that OS X runs on Intel platform and is 64-bit, you should look for information on x64 (also called AMD64) assembler. Check the Wikipedia article (http://en.wikipedia.org/wiki/X86-64) for a lot of links to documentation about x64.
Also, the OS X tools documentation might contains a lot of information about x64 assembler. In particular, the Netwide Assembler (NASM - http://developer.apple.com/documentation/DeveloperTools/nasm/nasmdoc0.html) might have documentation on how to build OS X applications using assembler.
To start learning assembly, you might want to start with simple C programs and ask GCC to generate the assembler code for it using the -S option:
gcc -S hello.c -o hello.asm
You will then be able to understand how to call functions, pass arguments, etc.
Nasm/yasm are your best bet; gcc inline syntax is quite crippling and can be very painful to use at times, plus there are literally some things it cannot do. Nasm's macro syntax is also much much more useful, a godsend in a language like assembly that has no built-in templating features.
XCode (ie. GCC) has great support for writing assembler. It's a fun thing to learn (although you're unlikely to need it much), and the worst you can do is crash the program you're writing, same as in C. Just Google for 'gcc inline asm x86 tutorial' and you should find plenty of starting points. Don't worry that some will seem to be Linux specific, they'll generally work just as well in XCode.
(edit) ...assuming you have an Intel Mac of course; if not then replace 'x86' with 'ppc'.
here
I programmed assembly on a Mac. It was Motorola 680x0 assembler using MPW. I've touched on the PowerPC assembler a few times in CodeWarrior and ProjectBuilder. Now ProjectBuilder is called XCode, and there is Intel. The assembler is one of the many tools within XCode.
I originally learned assembler on the Apple II: the 6502 machine language monitor built in ROM, the Sweet16 mini-assembler, and others. Later, I used Intel 80186 assembler to speed up slow bits of C code, and work paid for a one day course on Intel 80186 assembler at a university. Later, I had to maintain some 680x0 assembly for the Mac. That was a long time ago.
I don't think there is any reason not to do assembly. Learning is great. Learn all you can. Drop into a low enough level debugger and look at the disassembled code.
My advice is:
Don't be scared.
There's no reason why you shouldn't; there is nothing you can do in assembly language that you can't do in a higher level language like C.
As far as tools go, you might want to install MacPorts and get the GNU assembler. That may or may not be the easiest way, but it's free and you can probably find tutorial documentation for writing Unix programs in GNU assembler somewhere on the net.
There are two three things you to know need for writing assembly language on a system with an operating system (as opposed to 'bare metal' assembly which is a world of its own):
How the instruction set works - loads of resources for Intel X86 if you have an Intel Mac, still reasonable set for PPC for example Mac OS X Internals.
How to assemble link your programmes - if you have the Developer tools installed you have GCC and associated tools
How to talk to the OS - here is where Mac assembly is a lot less well documented than Windows or Linux. It may be you have to write equivalent C programs and use 'gcc -S' to see what calling/stack restoration conventions are appropriate. It depends what you want to do but at a miniumum you need OS system calls for IO and memory allocation.
A good starting point is here.
If you've got Developer Tools installed, you can simply open Terminal and type as (GNU Assembler - part of Binutils).
For PPC try Lightsoft