My advice then would be even more intimidating - buy a 8051 class controller and program it in assembly from scratch.

I got stuck at the functions part. There are just a few things there that don't seem to make sense in their description of C-style function calls.

Such as?

I like their first sentence:
You cannot write assembly-language functions without understanding how the computer’s stack
works.

So if you don't understand the basic concept of the stack, you can't do anything interesting in asm. If you do understand the basic concept of the stack, there shouldn't be anything hard in their description of C-style function calls.

Some better pictures of what the stack looks like at each point would make the discussion a little easier to read. But the text pictures they gave weren't bad, such as:
Using ebp in that typical way is not required by the calling standard. But it helps keep you and the debugger from getting confused, so it is probably a good beginner practice until you start writing asm functions so performance critical that you can't spare the time or the register that way.

BTW, intel syntax may make more sense.
Use gcc -S --masm=intel to generate it.

Well, IIRC, IBM architectures like very much the concept of link register instead of stack. Again, IIRC, IBM architecture don't even have a dedicated stack pointer register, though many registers may be used as load/store pointers with auto increment/decrement.

Gee, I thought that was the original intent; at least to use the 64-bit Linux as a cross assembler host. Really, that isn't a terrible idea, although you could choose any number of microcontroller style CPUs, or even a 16-bit DOS box, which at least allows you to load the target code easily (especially if it is an emulated target, on the 64-bit Linux host), but also provides a friendly debugger (debug).
Somebody said it is good to start with small projects, and I agree that chewing on the AMD ABI for starters is a bit much for a newbie. Depends whether the objective is to get the experience or to build a repertoire of code. I have written many lines of code for microcontrollers and for real-mode x86 CPUs, and rarely ever wrote a full program in assembler. Almost always, assembler was done in units of functions. I don't think I've ever written a line of assembler, even inline C code, for a Linux target.
I just read a big stack of job applications for a Linux hacker-type, and none of them had any assembler on their resumes. And I wouldn't expect very many, if any at all. On the other hand, if I was looking for a programmer for small embedded systems, experience in assembler of some sort should be de rigueur.
I learned assembler before learning C, and I am convinced that this made learning C quite simple, even as my first really practical programming language. Much of the idiom of C falls right out of assembler concepts.
It used to be easy to find books on assembler language for all kinds of CPUs. McGraw Hill had a nice series that covered a wide range of CPUs back in the day, but nowadays I rarely see assembler taught in books. Not only is Google your friend for that, it is probably your only friend. Too bad for that.

--- rod.

1 members found this post helpful.

Exactly.

...

Interestingly enough, ATLAS ( math-atlas.sf.net ) runs test code written in "C" in order to learn optimal number of registers to be used; some pieces of it are written in assembly, i.e. final code may include some pieces written in assembly to facilitate fast calculations.

@johnsfine

I don't understand what %ebp is.

IBM has a very long track record of being good at marketing computers and not so good at designing them.

Anyway, we seem to be mainly talking about x86 here. I don't think the OP wants to learn abstract asm, especially not first. After learning x86 asm, maybe it is useful to look at some of the common and/or obscure ways that computer architectures might differ from x86.

Another distraction! Intel syntax does not make much sense. It is a major pain.

Mainly it just reverses source and destination operand sequence. Nothing is right or wrong about either sequence. You just would prefer not to get confused by learning both at once.

But Intel sequence also puts way too much data typing on the data side. Asm is not supposed to be a high level language. In the underlying machine language, data type is represented by the opcode, not by the operand. Asm should reflect that. For trivial programs where asm is a foolish choice compared to C, the operand typing in Intel syntax may seem cute or even helpful. But it is still counter intuitive and reduces understanding. In tasks where there is a good reason to use asm, it is even worse because the data typing syntax becomes useless, bulky and unreadable.

You don't understand what registers are?

Or you don't understand that ebp is a register?

Or you don't understand that there is a conventional use of that register to point to a specific spot in the current stack frame?

Or what?

Wow! I just looked at that online book you're reading to find the section up front where it talks about the registers. I didn't find it! There is a tiny mention of registers as part of the Chapter 2 description of a CPU. Then it goes straight into examples and discussions using the registers as if you knew what they were.

That highlights the flaw that the book seems like the author couldn't quite decide whether he is writing generic info about asm as an abstraction or he is writing about 32 bit x86 asm. In an abstract discussion of asm there is hardly anything you could say about registers that is universal enough to be true while specific enough to be useful. In 32 bit x86 asm, you can describe the actual registers.

In 32 bit x86, there are seven general purpose 32 bit registers: eax, ebx, ecx, edx, esi, edi and ebp. There is also one almost general purpose 32 bit register esp (the stack pointer) and one very special purpose 32 bit register eip (the instruction pointer). (There are also various other very special purpose registers and register like things, that aren't appropriate to mention at this level).

Most integer and pointer operations occur in the seven general purpose registers.

If you remove the e from the beginning of the name of any of those registers, you have the name of the 16 bit low half of the 32 bit register. There is no similar method for accessing the 16 bit high half of a 32 bit register.

For some registers in some contexts, you can access some 8 bit parts. That is best left for more advanced work.

Well the %<reg> does not make alot of sense in AT&T sytax.
Also the operand order makes more sense as it is the same as natural mathematics (e.g. AX = 5 == mov ax,5).

And that's the reason I suggest true "bare-naked" hardware to try assembly on - a good programmer should truly understand what a CPU is with all its gory details like zero/nonzero, carry/nocarry, etc. flags.

I'm not fond of that % either. But it isn't hard to understand and it is only a minor annoyance. Much in Intel syntax is far more annoyance for serious asm programming.

That is well into a religious rather than objective question. I continue to believe neither order is fundamentally better (I'm also an atheist).

I wouldn't agree. I.e. it is quite debatable what is better for what - stack or link register with an area to preserve registers.

There was time when compiler technology preferred stack machines, then the technology learned to deal with register rich machines.

And yes, "C" code looks unnatural translated into PowerPC assembly (or, at least, used to look unnatural in the nineties).

Modern PARROT VM is a register machine.

Disclaimer - I do not necessarily advocate register machines; in fact, I find stack machines more intuitive.

The more I look, the more I disagree with that.

"wrote" or "copied"?

Yes, I know what one mostly does with any tutorial is copy. But when it uses registers without explaining registers, that is too fundamental. It is just copying if you don't understand what you are copying.

The set of general purpose registers is possibly the most basic and important feature of a computer architecture. x86_64 has fifteen 64 bit registers in place of the seven 32 bit registers I described above. Replace the e with an r at the beginning of each register name to get the corresponding 64 bit register name. The old names with the e are also part of the x86_64 architecture and refer (with an important side effect) to the low half of the 64 bit register. The eight additional 64 bit registers are named r8 through r15.

The addressing modes in x86_64 are a slightly generalized version of the ones in 32 bit x86. The set of instructions themselves are almost identical.

It should have just been a reason to want a better tutorial.

But more fundamentally, learning bare-naked hardware asm programming requires learning too much at once.

Even with a sane overall architecture, there would be far too much to learn at once. Focused learning works better. You can learn about the general registers, the stack, some addressing modes, and some instructions and practice that knowledge with interesting C callable functions, then build on that knowledge with more aspects of asm programming. Even something as basic as the flags you mentioned can come after the first round.

x86 overall architecture grew all the way from the 8088 carrying obsolete baggage of legacy compatibility at every step. Programming bare x86 hardware requires knowing a massive amount of that legacy crap. That is too much to learn all at once.

One could certainly learn it the way I (and probably you) did. I learned all the 8088 stuff when the only x86 chips were the 8088 and 8086. I learned the 80286 stuff on top of that when it was new, and so on, learning each new layer as it became available and already knowing all the legacy crap it carried over.

If you want to start with bare hardware, you almost need to start that way. First learn to program the 8088 legacy features buried in the CPU and work forward.

But that is much less rewarding than learning the modern stuff first (and maybe only). If you ever need to write boot code you might need to learn some of the legacy crap, but most of it is obsolete and useless.