[H-GEN] X86 Assembler Programming

[Paul Gearon]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Greg Black wrote:
> On 2003-11-10, irwa82 at froggy.com.au wrote:
>>I have decided that it would be interesting to look into assembler
>>programming. From what I have discovered nasm seems to be the program I
>>should be using.

I like the GNU assembler, GAS, because it's part of GCC.  However, NASM 
is fine, and it has the advantage of letting you write assembler that 
looks compatible with M$ operating systems.

To be perverse, you can even write your code using NASM syntax, and 
convert it to GAS syntax with intel2gas.  :-)

>>I was wondering if anyone knows of any good nasm specific or assembler in
>>general tutorials aimed at people that have never touched assembler and
>>have no clue.
> 
> 
> If this is an accurate description of yourself, then I'd
> strongly suggest starting with the assembly language for an
> easier CPU -- the Z80 would be my suggestion, but anything from
> that era without pipelines, caches, and all that modern stuff
> would be nice.  The bookshops have books -- read a few pages of
> them and see how you go.

Well I have a book on the Z80 CPU that I haven't opened in about 12 
years.  You're welcome to it if you want... but I wouldn't recommend it. 
  Firstly, the Z80 isn't all that much simpler.  You have a number of 
special purpose registers that can make things as complicated as any 
modern CPU.  Secondly, the Z80 will teach you principles, but there are 
no machines today which use them, so you'll only get to run your code on 
an emulator.

Modern CPUs are just fine, and provide the extra advantage that you can 
write code for today's systems.  You can ignore pipelines, caches, 
instruction re-ordering, and all that other stuff, as it won't make your 
code run any differently.  It *is* possible to write code that ignores 
these things that can run less efficiently (due to instruction cache 
misses, etc) but it's no big deal, particularly if you're just learning 
this stuff, and not using it in earnest.  Most of these things are 
completely invisible to the programmer, and optimise your code without 
your knowledge.  There are exceptions to this rule, such as Sparc 
delay-slots, or the groups of 4 instructions on Itaniums, but I'm 
assuming you're probably running on x86.

> And be aware that writing assembler, even for people who love
> it, is slow and tedious work.  It has few of the joys of
> programming in slightly higher level languages such as C and
> many frustrations all of its own.

For this reason I think that one of the best tools to use is gcc with 
the -S option.  This tells gcc to stop after it has converted C code to 
assembler.  You can then peruse the code to see how the compiler decided 
to convert your C into assembler.  There are occasions when I can't 
remember an idiom for something, and this is much easier than looking up 
a book.  :-)

A good example of this might be if you wrote a small program to add two 
numbers.  For a start, you'll want to get command line arguments and 
convert them to numbers.  Next, the addition is trivial in assembler, 
but then you'll want to send the output to printf.  Many assembler books 
just tell you how to allocate memory and write instructions, but they 
don't cover how to call into the standard libraries.  A 2 minute C 
program can do all of this for you, and you can see how the compiler did it.

This also ties in with Nick's suggestion of inline assembler in your C code.

> But it will teach you stuff
> that will make anything else you do with software seem both easy
> to do and much easier to understand.

Oh yeah.  Big time.

> I think everyone should learn assembler; and I don't think
> anyone should use it (unless they really are writing those few
> lines of code that must be done in assembler).

I have to agree with this.  A knowledge of assembler is vital for any 
real programmer.  However, you're nuts if you want to use it in your own 
code.  You need pretty compelling profile output before you should 
consider optimising with assembler... and then you really need to 
compare the performance of the optimised code with the original.  Other 
than the fact that compilers and CPUs can normally optimise better than 
you can, you're also making the code non-portable.  Reconsidering 
algorithms is normally a better idea anyway.

Having said all this, there's still a place for machine code.  I just 
finished some windoze code that writes binary code into a paused 
process's address space so it will load a dynamic library that re-writes 
function entry points.  Unfortunately there was no other way to perform 
this particular operation.  I'd have loved the luxury of an assembler 
for that code.  Hex programming for a CISC instruction set is painful.  :-)

-- 
Regards,
Paul Gearon

Software Engineer                Telephone:   +61 7 3876 2188
Plugged In Software              Fax:         +61 7 3876 4899
http://www.PIsoftware.com        PGP Key available via finger

Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam.
(Translation from latin: "I have a catapult. Give me all the money,
or I will fling an enormous rock at your head.")



--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/