High Level Assembly Language Programming Book

Randall Hyde's book is now out in it's second edition.

Your computer has little dohickies in it that know how to read and respond to commands that are, in turn, stored in (and read from) other dohickies.

These instructions are collectively known as "machine language." If you do an programming at all, you probably know this. A form of this very low level language that is designed to be somewhat more readable by humans is known as Assembly Language.

Higher level languages allow programmers to avoid messy details like the kind of hardware their program may run on, and higher level languages allow access to powerful commands and functions, some stored in libraries that have been developed with a great deal of thought to solve general problems. Lower level languages such as Assembly don't allow this kind of power and flexibility, but they do allow detailed control over what the program is doing, and they allow compactness and speed. Ultimately, everything you do on the computer, in any application or written in any language is converted into machine language before anything happens.

So writing programs in Assembly language is like going to your basement and fiddling with dials and piping and other things to operate your furnace, while higher level programming, or just using applications, is like using the thermostat. More or less.

And yes, people still do write in Assembly Language. And now, if you want to try this out for yourself, there is a great new book available to help you out. This is the second edition of Randall Hyde's "The Art of Assembly Language."

In particular, this book teaches and documents a form of Assembly Language called "HLA" or "High Level Assembly." This is an evolved form of Assembly that serves as a front end to lower level code for X86 machines. It has a handful of higher-level features that bring very onerous tasks under control. The book, The Art of Assembly Language, is written by the developer of HLA, so you are getting the information directly from the horse's mouth, as it were.

Happy programming.

More like this

I just heard that John Backus died last saturday. John Backus was one of the most influential people in the development of what we now know as software engineering. In the early days of his career, there was no such thing as a programming language: there was just the raw machine language of the…
My first computer language was PL/1, but soon after I learned, among other languages, Basic, and I really liked Basic and I still do. Basic is linear, and I think in linear constructs when I do any kind of computer program. This is probably, in part, because user interfaces are the last thing I…
Scratch Programming Playground: Learn to Program by Making Cool Games is a brand new offering from No Starch Press. Never mind all the other programming books for kids, this is the best so far. It helps that the Scratch Programming environment is so easy to use and allows such creative…
Ah yes, I remember it well. "Hammurabi, Hammurabi, I beg to report to you, In Year 1, 0 people have starved. 101 people came to the city The population is now 124 We harvested 4.5 bushels per acre We planted 998 acres of wheat But rats at 300 bushels of wheat You now have a surplus of 1443 bushels…

But do enough people still program in assembly that I should leave it on my resume?

For the geek cred, you should burn it in to your resume like ROM!

Also, with this book, there will be a Renaissance. A little in-line HLA is like speed for your otherwise adequate but not too crispy application.

And much like the dials/pipes : thermostat analogy it's often better to leave it alone if you don't know what you're doing.

Things a compiler does better than most humans: register allocation, inlining, code motion.

Things library writers (ie glibc) do better than most humans: memory management, string manipulation, buffering.

Things humans do better than the compiler: some alias analysis leverging implicit knowledge of how the pointers are used.

And if you don't know many of the terms above, you might want to be careful before "fiddling with the pipes."

I hadn't heard of this HLA and I read the Wikipedia page.
Based on that, I can't understand what anyone would use the HLA for. People do (professionally) write assembly occasionally, but those situations are quite limited these days. Some low-level system stuff mostly, like system boot-up, low-level kernel code and some very few tighly optimized library functions. I work very closely to people who do maintain a piece of software that has some assembly in it. That code changes so infrequently and it's so small that I'd call it a bad business decision to use some additional compiler for that (plus it's ARM, so HLA (x86) is not even an option). I reckon this is true for all assembly code out there. I don't see any significant advantages of HLA over C combined with plain assembly.

Oh, and if you want to try some old-skool MS-DOS assembly yourself, click Start->Run on Windows (works at least on XP or older) and type in cmd. Then on the command prompt type the following (Press enter after each line:)

debug
a100
mov dx,110
mov ah,9
int 21
ret

e110 "Hello World!",a,d,"$"
nhello.com
rcx
20
w
q
hello

Note the one empty line after "ret". You press enter there too. Also note the "$", it's a dollar sign, not an S. (Why on Earth did Bill choose the dollar sign as a string termination character anyways?) Replace "ret" with "jmp 100" for some extra fun. (You can break the loop by pressing Ctrl-C.)

I spent the first seven years of my programming career writing real-time software in assembly language that ran under operating systems that we also had to write ourselves (the hardware wasn't fast enough back then to do otherwise). It was an extraordinary challenge in a way that trying to figure out how to put together a good object-oriented design never quite seems to match.

Kevin: me too.

I think one component of the challenge has to do with what is going on in one's mind while designing the program. Essentially, one has to be running a model of the machine at the API level to which you are coding. For an OO system that is moderately high level and somewhat chunked around task oriented operations. For Assembler not quite so much. In fact one has to run a mental model of the CPU hardware and feed it with the assembly mnemonics. This is quite unintuitive and generally renders one almost incapable of conversing intelligently with other humans. The only worse design issue than that is designing the hardware itself in Verilog or VHDL. Those times I found myself viewing the antics of those around me in terms of toggling flip-flops.

PS typed on an iPad. Accuracy about 4x a well trained Dragon system. I expect to get better.

By GrayGaffer (not verified) on 14 Apr 2010 #permalink

Yup, I feel like I did the time warp (again!). I'm programming mutant cousins of the Motorola 6502 and the Zilog Z80 for various projects. Oh, for a machine that had more registers! It typically takes me over a month to write a mere 2000 lines of code - and that much code doesn't really do very much (it's often still under 4KB of memory).

No need to spend money on a real machine though; if you read Don Knuth's fascicles of his updated Art of Computer Programming, you can learn to program the next generation MIX machine (known as MMIX). Speaking of which - I should check out Knuth's web page and see what he's been up to lately. If you have access to the latest published version of the AoCP, you can easily install the MIX virtual machine (well, it's easy to do if you're running Debian Linux - I have no idea who else packages the software in their repositories). I do not recommend attempting to code for a Pentium class chip without previous experience - you simply won't get anywhere since too much knowledge of the hardware is required.

By MadScientist (not verified) on 15 Apr 2010 #permalink

Are people actually complaining that machine language is stupid because is too close to the machine? That is like saying you'd like to try skiing but only if you do not need to get close to the snow.

Back in the 80's, I had several years experience writing PDP-11 assembly code for a couple of real-time systems.

Today I still use a bit of assembly, mostly PPC, ARM, and MIPS, for bootstrapping embedded boards. Most boards require just a few hundred lines of assembly, and speed/size optimization is usually of little importance.

By LightningRose (not verified) on 15 Apr 2010 #permalink

a friend of mine once owned an ancient (1940's era?) Indian motorcyle. the right hand twist grip was the throttle, like current bikes. the left hand twist grip allowed (required) you to manually control spark advance. this gave you fine control over how your engine worked, if you could figure out how to do it. but it also distracted you from the bigger picture, like that SUV running the red light. the analogy should be clear.

still, some people (extremely few) do need asm, and others may want to play with it, which is cool. it is fun, to a point (i've written multitasking operating systems in asm, the fun diminshes rapidly). given that, high level approaches like HLA and good reference information for using them can only be a Good Thing.

nowadays i consider C programming the new assembly language. maybe C++ like a good macro assembler.

Oh the memories! The old Apple ][ with the 6502 chip, and later the mac toaster with the 68000. I even did a little bit on the PC - embedded in C - a context switcher for multi threading.

Nowadays it's java, SQL and XSLT.

You know, I don't really miss the old days at all :)

Relatively few people should professionally program in assembly, but many people should program in assembly educationally.

I think the two most important programming experiences to get in school (or learning on your own) are programing in a very abstract form (Lisp, Haskell, etc), and programming in a very concrete form (assembly). How can you understand the nature of software and hardware, without doing a few things that are impractical?

Assembly language is something that is definitely not necessary to learn this day in age, as most up and coming coders will being going in to some sort of applications programming, or web based fields. The further technology moves in to the future, the less and less relevant assembly becomes as portability becomes and much more important issue. Just look at how much of a comeback interpreted languages like Python and Perl are making these days. Virtual machine and framework based languages like Java and .NET are rapidly replacing the old standards in application programming as user end computing moves more and more in to an interactive web based environment. Sure, there will always need to be some good assembly language coders out there, every piece of hardware will still need low level functionality before it can begin to implement the higher level standards of today, and those languages themselves need some sort of base to run on whether the language is interpreted or compiled. So it all really depends on what context you're using it in. To someone writing compilers, it may be their bread and butter. To someone else writing Java programs to update your Facebook from a cell phone, assembly is just some abstract concept.

By David Riley (not verified) on 12 Aug 2010 #permalink

So, does this mean that there is no assembly code in use? Computer hardware knows how to read C now?

By Mr Pidgeon (not verified) on 12 Aug 2010 #permalink

u guys r fags 8===D-------------------------------------------------------------------------------

Actually, julio appears to be a student just back to school and playing with the school's computer. I'm in touch with the IT department there.

Julio: I recommend a class in basic computer use. There, you will learn that we can see you on the Internet.