I wanted to try learning Assembler, I wonder if you know of any good tutorials or hints?

I have an x86_64 CPU running (obviously) Linux.

This is a good starting point:

http://mirrors.zerg.biz/nongnu/pgubook/

Download the latest version 1.0. It is not specifically for 64bit machines but the basics are - IMHO - pretty good explained.

I don't, so this is just advice on some side issues, not an answer to your main question.

Do you know C or C++ or any other high level languages that can call functions that have a C interface?

The mess needed for I/O in asm and the bigger mess needed to be a whole program in asm are major roadblocks in the path to learning to write programs in asm.

My advice is don't learn how to write programs in asm. Learn how to write functions in asm. Writing programs in asm is nearly useless anyway and also ineffective for leveraging your asm skills to be a better programmer in other languages.

Learning to write functions in asm may be directly useful for writing performance critical functions. It is even more useful for improving your ability to design and debug high level language programs.

I hope that is running x86_64 Linux. You could be running 32 bit x86 Linux on an x86_64 CPU.

Most asm tutorials are for 32 bit or even 16 bit x86 asm. It will be harder to find tutorials on x86_64 asm. But x86_64 asm is better to learn. It is a better machine language and more relevant.

There are pdf files on the AMD web site that do a very good job of documenting x86_64 machine/assembly language. If you are a very naturally skilled programmer, you could learn directly from those.

At a slightly lower skill level, you might be able to take a 32 bit asm tutorial together with x86_64 reference documentation and translate each step of the tutorial to 64 bit before trying it. That may sound like serious extra work, but I think it might actually improve the learning process, because it forces you to really understand each step rather than just copy code from the tutorial.

If you are less naturally skilled, you might need to really learn 32 bit x86 asm, before you even start on x86_64, simply because it will be easier to find a beginner introduction to 32 bit than 64 bit.

@johnsfine

I do know C and some C++, and I am running 64-bit Linux, not 32-bit Linux on a 64-bit CPU.

As an HW guy I disagree. We, humans, are still bare under our clothes, and a computer is just bare metal under its BIOS and OS.

I see it very important for overall correct understanding of things to know what is exactly happening after HW reset - there is no OS.

Knowing assembly and bare metal helped me a lot during my VLSI development years - it's quite interesting to create a simulation environment for a CPU (based) chip.

But I agree that most of programming nowadays is done far above assembly level.

And a good practical issue is being able to switch from assembly as early as possible in the SW stack to be developed.

You may start "from a different end" - compile your C/C++ with -O0 and get annotated (assembly + C/C++) listing. Then "decipher" every assembly instruction.

The disadvantage is that in such a manner you'll get to know only one architecture.

For example, PowerPC architecture is radically different from x86.

OTOH, 'gcc' supports a lot of architectures, and using a virtual machine like QEMU you can even run (step by step if interested) programs compiled for different architectures in such a manner.

You're not going to convince me of any of that and I wouldn't expect I can convince you of my viewpoint. I don't intend to try.

But maybe you'll believe the focused learning aspect of it: Learning works better when you focus on a reasonable size subset of the topic and then after really learning that subset use the knowledge as part of your tool set when focusing on the next subset. Asm for C callable functions is a good subset to learn first and almost everything you learn in that subset will be useful if you later decide to learn the wider and more obscure topics of asm for whole programs or asm for raw machines without OSes.

I was thinking of making nearly that same suggestion, but I was too lazy to look up the gcc switches for generating annotated assembly code. Once you have those switches, I agree the -O0 is useful at first, but I think it quickly becomes very limiting. You can learn a lot more reading the annotated assembly code after the optimizer has improved and scrambled things.

Anyway I agree that looking at the asm code generated by compiling C code is a reasonable starting place for learning asm and/or a useful tool to be added to other methods of learning asm.

One small bit of knowledge you need for C callable functions that you don't need for programming a raw machine and might not need for writing whole programs, is the x86_64 ABI.

The x86_64 ABI is very confusingly documented by AMD. I wouldn't advise a beginner to even try to understand that. I approach that ABI in two ways:
1) The common simple subset of the ABI that is easy to understand and frequently needed is worth knowing.
2) All other cases are best dealt with on the rare occasions you need them by using/trusting GCC. Declare a function with exactly the signature for which you want to understand the ABI, then write and compile a C call to that function and look at the generated code.

The common simple case is where every calling arg and the return value (if any) is one of:
* a pointer
* a reference
* an integer of some size from 1 to 64 bits.
Then the ABI is: The first up to six calling args go in registers rdi, rsi, rdx, rcx, r8 and r9 (the rest go on the stack); The return is in rax. Registers rbp, rbx and r12-r15 are preserved by the callee (saved and restored if used).
Notice a whole 64 bit register is used for each integer, no matter how small. Even a 1 bit integer, if it is a separate calling arg takes a whole register.

And thats why you write in 32bit assembler...
Infact i have never seen 64 BIT asm written by hand.

0 members found this post helpful.

I'll disagree with that as well:

1) If it is worth writing in asm, it is probably performance critical enough to be worth writing in 64 bit.

2) If it is worth writing in asm, the ABI is a minor enough part of the task, that even if you needed a test compile of throw away C code to find out ABI details, that would be an insignificant extra workload.

3) Functions worth coding in ASM tend to take most args as pointers anyway, and that is where the ABI is simplest.

Most times I need to understand the x86_64 ABI are for debugging C++ code, not for writing asm code. Debuggers frequently give you wrong info about what is in local variables at any given moment, so it helps to understand asm and the ABI to know what is really going on. You don't usually get to pick 32 vs. 64 bit ASM in such situations. It is whichever needs to be debuged. For the ABI, if you know the basics you can usually guess the rest from context. If you can't fit your ABI knowledge to the specific code, on occasion you need to compile the throw away code mentioned above to nail down the answer to any obscure ABI question (usually involving small structs passed or returned by value).

http://talkback.zdnet.com/5208-17923...sageID=1463368
M$ - not really valid but i will post anyway http://social.technet.microsoft.com/...9-84b6547f7f92
if 2 out of 20 use 64 bit, and ASM is known for its poor portability, where does that leave you?
With 10% of users able to use your program?
Why is there always a flame war in programming?
Maybe because programmers are set in their ways?

Assembly is better to learn how the processor functions, C/C++ is better to write programs, imho.
And MTK358 is not asking if it's a sensible thing to do but how to start with it.

To learn ASM, it really would be best if you got hold of an old DOS machine, and some books from DOS days on ASM programming such as Michael Abrash's books (if you're interested in gfx programming).

Johnsfine, could you share a little bit of your knowledge about 64-bit asm on this thread? I'd love to learn.

Which implies the question of whether to start with 64 bit asm, 32 bit asm, or 16 bit asm.

Do you start with 32 because there are more and better tutorials available for 32 than 64?

Probably there are more and better tutorials available for 16 bit x86 than for 32.

You should balance the availability of tutorials against other factors:

x86_64 is a better machine language: When you work with it, you don't need to focus as much on the oddities of the architecture. You can focus more on the problem at hand and/or generic (architecture independent) aspects of asm programming.

16 bit x86 is an even worse machine language than 32 bit. To work well in it, you must focus even more on the oddities of the architecture than in 32 bit. Oddities are thing like (but not limited to) which addressing modes can be used with which registers.

I also argued that 64 bit x86 makes more sense to use than 32 bit. Even though the initial question wasn't whether asm itself was sensible to use, you get pretty directly from asking how to start learning asm, to whether 32 bit vs. 64 bit is better to learn first, which ought to depend on whether 32 bit vs. 64 bit is more sensible to use.

I disagree (doing that a lot here). DOS means 16 bit x86 asm. Probably the tutorials are better. But the topic is worse. I programmed more in 16 bit x86 than I ever will in 32 and 64 bit x86 combined and even now I might still remember 16 bit x86 better than I know 32 bit or 64 bit. I'm not speaking from ignorance here: 16 bit x86 is a terrible programming language! It was my language of choice for many years because it was the only choice to write the best possible programs to run on the commonly available platform. Once that was no longer true, there was no reason to continue using it.

Legacy graphics are also a pointless thing to learn. CPUs are faster now. More powerful, generic, layered approaches to graphics are not practical.

I already shared a bit about an important subset of the ABI. I don't have the time, and probably not the writing skill, to write a better x86_64 tutorial.

If you want to learn, try any or all of:
1) Search for an x86_64 asm tutorial. Something must exist and maybe better than what I recall seeing.
2) Read the instruction set documentation from AMD. That's all I needed to do to learn x86_64 asm.
3) Compile various C functions to asm code and read the asm code and figure out how it implements the function of the C code. If you get stuck, post the C and asm and I probably will find the time to explain.

Wonderful tutorial!

I currently wrote 2 32 bit asm programs form the book and they worked!

I still don't know enough to even really understand what you are talking about with x86_64, but I might understand later.

The main purpose I want to learn asm is to have a better understanding of how the CPU and Linux works, not to write serious applications with it.

@resetreset

DOS? No way! Because one of the main purposes of learning asm for me is to get a better idea of Unix, and besides, a lot of Linux asm tutorials online say that Linux asm is a lot simpler and have examples to prove it.