LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices



Reply
 
Search this Thread
Old 03-04-2010, 04:23 PM   #16
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453

Quote:
Originally Posted by resetreset View Post
To learn ASM, it really would be best if you got hold of an old DOS machine
...
My advice then would be even more intimidating - buy a 8051 class controller and program it in assembly from scratch.
 
Old 03-04-2010, 05:11 PM   #17
MTK358
LQ 5k Club
 
Registered: Sep 2009
Posts: 6,443
Blog Entries: 3

Original Poster
Rep: Reputation: 714Reputation: 714Reputation: 714Reputation: 714Reputation: 714Reputation: 714Reputation: 714
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.
 
Old 03-04-2010, 05:38 PM   #18
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,142

Rep: Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127
Quote:
Originally Posted by MTK358 View Post
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:
Code:
Parameter #N <--- N*4+4(%ebp)
...
Parameter 2 <--- 12(%ebp)
Parameter 1 <--- 8(%ebp)
Return Address <--- 4(%ebp)
Old %ebp <--- (%esp) and (%ebp)
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.
 
Old 03-04-2010, 05:40 PM   #19
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,241

Rep: Reputation: 189Reputation: 189
BTW, intel syntax may make more sense.
Use gcc -S --masm=intel to generate it.
 
Old 03-04-2010, 05:44 PM   #20
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by johnsfine View Post
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.
...
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.
 
Old 03-04-2010, 06:01 PM   #21
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,396
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
Quote:
Originally Posted by Sergei Steshenko View Post
My advice then would be even more intimidating - buy a 8051 class controller and program it in assembly from scratch.
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.
Old 03-04-2010, 06:10 PM   #22
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by theNbomr View Post
..
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.

--- rod.
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.
 
Old 03-04-2010, 06:21 PM   #23
MTK358
LQ 5k Club
 
Registered: Sep 2009
Posts: 6,443
Blog Entries: 3

Original Poster
Rep: Reputation: 714Reputation: 714Reputation: 714Reputation: 714Reputation: 714Reputation: 714Reputation: 714
@johnsfine

I don't understand what %ebp is.
 
Old 03-04-2010, 06:30 PM   #24
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,142

Rep: Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127
Quote:
Originally Posted by Sergei Steshenko View Post
IBM architectures like very much the concept of link register instead of stack.
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.

Quote:
BTW, intel syntax may make more sense.
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.
 
Old 03-04-2010, 06:32 PM   #25
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,142

Rep: Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127
Quote:
Originally Posted by MTK358 View Post
I don't understand what %ebp is.
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.

Last edited by johnsfine; 03-04-2010 at 06:50 PM.
 
Old 03-04-2010, 06:35 PM   #26
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,241

Rep: Reputation: 189Reputation: 189
Quote:
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.
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).
 
Old 03-04-2010, 06:54 PM   #27
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by johnsfine View Post
...
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.
...

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.
 
Old 03-04-2010, 06:55 PM   #28
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,142

Rep: Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127
Quote:
Originally Posted by smeezekitty View Post
Well the %<reg> does not make alot of sense in AT&T sytax.
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.

Quote:
Also the operand order makes more sense as it is the same as natural mathematics (e.g. AX = 5 == mov ax,5).
That is well into a religious rather than objective question. I continue to believe neither order is fundamentally better (I'm also an atheist).
 
Old 03-04-2010, 06:59 PM   #29
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by johnsfine View Post
IBM has a very long track record of being good at marketing computers and not so good at designing them.

...
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.
 
Old 03-04-2010, 07:12 PM   #30
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,142

Rep: Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127
Quote:
Originally Posted by MTK358 View Post
Wonderful tutorial!
The more I look, the more I disagree with that.

Quote:
I currently wrote 2 32 bit asm programs form the book and they worked!
"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.

Quote:
I still don't know enough to even really understand what you are talking about with x86_64, but I might understand later.
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.

Quote:
Originally Posted by Sergei Steshenko View Post
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.
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.

Last edited by johnsfine; 03-04-2010 at 07:26 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ASM or C++? Hb_Kai Programming 16 01-20-2010 10:12 AM
Is ASM dangerous? MrCode Programming 37 11-18-2009 09:29 AM
ASM x32 vs ASM x64 Tegramon Programming 3 02-27-2008 03:26 PM
I/O in ASM Mercurius Programming 10 11-16-2006 08:02 PM
ASM question zWaR Programming 2 06-26-2004 12:42 PM


All times are GMT -5. The time now is 08:13 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration