

The Art of Assembly Language Programming (Linux edition) [book] - gnosis
http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/Linux/index.html

======
spacemanaki
I think this is the free version of the first edition of this:
<http://www.nostarch.com/assembly2.htm>

Many of the reviews on Amazon bemoan the choice of "High Level Assembly" in
that book, does this edition use HLA? How does it compare?

Any HNers who've read the second edition care to comment on it? The author
responded in the reviews on Amazon and his defense seemed reasonable to me:
many students won't become professional assembly language programmers, so why
make them struggle more than is necessary.

[http://www.amazon.com/review/R3C06U180STE19/ref=cm_cr_rdp_pe...](http://www.amazon.com/review/R3C06U180STE19/ref=cm_cr_rdp_perm?ie=UTF8&ASIN=1886411972&nodeID=&tag=&linkCode=)

Edited to add: I answered my own question, I think this does use HLA.
[http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.art...](http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/Linux/HTML/Foreword.html#63)

~~~
gnosis
The title of this book is misleading. It should really be titled "The Art of
My Own Language, which I call HLA"

HLA is not assembly, but a high level language of the author's own invention.

I didn't realize that it was HLA and not assembly which was taught in the
book. If I had, I wouldn't have posted the link.

~~~
silentbicycle
While you're at it, any alternative recommendations?

I'm still a novice at writing assembly (more interested in code gen and
instruction set design than coding assembly by hand), but I've found these
helpful:

    
    
       * http://asm.sourceforge.net/resources.html
       * http://www.intel.com/products/processor/manuals/
       * http://news.ycombinator.com/item?id=1662430 (good resource, link to HN discussion)

~~~
gnosis
If you're going to be writing assembly on Linux, you should decide which of
the two major syntaxes to learn:

    
    
      - AT&T (gas, gcc inline assembly)
      - Intel (nasm, fasm, yasm, but also gas)
    

Some links to help you decide:

Pro-gas: <http://www.deater.net/weave/vmwprod/asm/ll/README.gas_sucks>

Anti-gas: <http://x86asm.net/articles/what-i-dislike-about-gas/>

Neither/both: [http://www.ibm.com/developerworks/linux/library/l-gas-
nasm/i...](http://www.ibm.com/developerworks/linux/library/l-gas-
nasm/index.html)

Neither: <http://webster.cs.ucr.edu/AsmTools/WhichAsm.html>

If you decide to go with AT&T/gas, check out _"Programming from the Ground
Up"_ , by Jonathan Bartlett:

<http://download.savannah.gnu.org/releases/pgubook/>

If you decide to go with Intel/nasm, see _"PC Assembly Language"_ by Paul A.
Carter:

<http://www.drpaulcarter.com/pcasm/>

Also, the following tutorial is focused on DOS/8086, but it's really unique in
that it's very interactive, and provides you with a fully functional assembly
interpreter and 8086 simulator:

<http://www.btinternet.com/~btketman/tutpage.html>

I highly recommend it for getting a quick feel for the basics, though some of
the DOS/8086 specific stuff in it won't apply to Linux.

------
dpcan
Are there any Assembly programmers here? What is still done in ASM? Is it
mostly for writing device drivers and such?

It's been YEARS since I've worked in it, and I used to use it for some
practical things like controlling the Mouse cursor in DOS and some routines
for buffering graphics, stuff I don't need it for at all anymore.

I'd love to also know some practical things I could use Assemble Language
programming for in today's world.

~~~
gnosis
Assembly language is very important in the fields of reverse engineering and
malware analysis.

In both fields the researchers rarely have the source code for the target
software at hand, and so they usually have to disassemble the binary or run it
under a debugger and step through the raw assembly language code to understand
it.

Malware itself is often crafted in assembly language. And this is another
reason why understanding assembly is essential for malware analysis.

Assembly is prominent in the demoscene, where squeezing every last bit of
performance out of a system and doing so in a limited amount of space
(nowadays often a self-imposed limitation, at least on a typical desktop) is
important.

Assembly is also almost always the language used to write the bootloaders for
operating systems. A number of operating systems have even been written
entirely in assembly language.

It's also relatively popular on many embedded devices and microcontrollers,
where you might not have the luxury of using a high level language, and where
size and speed considerations are paramount.

Even in programs written in a high level language, critical sections are often
rewritten in assembly language for the sake of getting maximum performance.

The importance of small and fast languages like assembly is likely to increase
now that Moore's Law (arguably) no longer applies, and now that devices with
small computers in them are starting to proliferate.

~~~
Impossible
I'm not sure how popular assembly is in the modern demo scene on "normal"
platforms (modern PCs, not retro platforms or embedded\mobile stuff.) The
modern demo scene is mostly about cool GPU tricks written in HLSL or GLSL,
which have huge advantages for both performance and space (see rendering the
world with 2 triangles -
[http://www.iquilezles.org/www/material/nvscene2008/nvscene20...](http://www.iquilezles.org/www/material/nvscene2008/nvscene2008.htm)).
It would be cool if the demo scene started focusing more on pushing CPUs
instead of GPUs, but that would require adoption of really exotic graphics
techniques that for some reason run better on a multicore CPU instead of a
GPU, or a focus on something other than graphical effects, like simulation or
audio processing. I agree that if you go back 10 or 15 years ago a lot of work
was done in ASM, but GPUs have severely reduced that if not killed it
outright.

Game engines still use a little assembly, sometimes a lot on the PS3, but
often it's written with compiler intrinsics in C or C++. It also tends to be
low level SIMD math code for physics, particles, audio or animation, which is
stuff your average game programmer never touches.

~~~
cageface
Professional audio apps use a lot of SIMD but almost always via compiler
intrinsics. It's rare that somebody will actually drop down into raw assembly.
Thanks to mobile you can't afford any more to assume that x86 is the only
instruction set that matters so an extra shim via a library like iOS's
Accelerate makes a lot more sense than raw asm.

