Assembly... BUH BUM BAAHH

[TheSocialistAvenger]

The "choose a language" thread just reminded me: I never learned assembly! I know it's not practical for anything at all, even less so for the little programs I write, but I really wanna.

So could anyone point me towards some good introductory material? (Book or web or anywhere.) Just something to get started and see what it's all about?

Also, I have a question about compatibility. How cross platform is assembly code? I'm on a mactel so I guess that I would use i86 assembly and the gas compiler, so would that be the same as linux assembly or does apple have its own assembly quirks? Is there an ANSI/ISO assembly like there is for C?

[adlaiff6]

Not practical? Certainly not, as long as you never touch a microcontroller or embedded system in your life, or try to write firmware drivers, or try to speed up your speed-critical C, or want to really really understand what you're doing, or....

Assembly is pretty non-cross-platform. It doesn't respect Windows/Mac/Linux boundaries at all, but if you try to run x86_64 (or <insert favorite platform here>) code on an x86 (or <insert second favorite>), it will break thoroughly (with the correct kernel, it'll actually tell you "Illegal Instruction").

[EvanED]

Not practical? Certainly not, as long as you never touch a microcontroller or embedded system in your life, or try to write firmware drivers, or try to speed up your speed-critical C, or want to really really understand what you're doing, or....

Basically, here's I think what it comes down to. If you want to program things on a regular basis, assembly is very useful as a mechanism for learning how the processor operates. It's very difficult to understand what is going on behind the scenes without learning assembly along the way.

Reading assembly is also useful all too often if you are in a debugger and things are not behaving in a way you expect.

But in terms of who being a good assembly programmer is applicable to: basically, if you want the title 'systems programmer', you might very well have to get intimate with assembly (though very possibly not as well; the amount of assembly in, say, Linux or Windows is a tiny percentage); if you want the title 'application programmer', you won't.

(This is way over-simplified. For instance, where do compilers fall? A lot of those people need to understand assembly really well even if they are writing in another language. But as a first level approximation, it shouln't be *horrible*.)

You also have to be very careful if you start thinking "oh, this is performance critical; I'll write it in assembly." Compilers any more are very good at optimization; to pull a number out of my ass, I'd guess 90% of the time they are probably better than 3/4 of the people who have both the know-how and the will to actually do the above. CPUs nowadays do so much behind the scenes that's completely magical it's astonishing, and it's extremely difficult to even predict how a change will affect performance, let alone figure out an optimal or near-optimal way of doing something.

The huge exception to the previous paragraph is stuff like SSE. To my knowledge, compilers don't even try to vectorize stuff using SIMD instructions unless the code is fairly heavily annotated. I could be totally wrong here.

Assembly is pretty non-cross-platform. It doesn't respect Windows/Mac/Linux boundaries at all...

For instance, stuff like the system calls change. If you want to print something to the screen, the way you do that will be entirely different between Windows and Linux for instance, and probbaly entirely different still to a Mac.

[iw]

Not practical? Certainly not, as long as you never touch a microcontroller or embedded system in your life, or try to write firmware drivers, or try to speed up your speed-critical C, or want to really really understand what you're doing, or....

Basically, here's I think what it comes down to. If you want to program things on a regular basis, assembly is very useful as a mechanism for learning how the processor operates. It's very difficult to understand what is going on behind the scenes without learning assembly along the way.

Reading assembly is also useful all too often if you are in a debugger and things are not behaving in a way you expect.

But in terms of who being a good assembly programmer is applicable to: basically, if you want the title 'systems programmer', you might very well have to get intimate with assembly (though very possibly not as well; the amount of assembly in, say, Linux or Windows is a tiny percentage); if you want the title 'application programmer', you won't.

I see it like this: there's no good reason not to learn assembly.

[grim4593]

Assembly is great for something like programming microcontrollers. Its tiresome to write assembly if there is an alternative. If you get a bunch of nested loops and jumps around your code you will feel like stabbing things. It can take you a long time to write some code in assembly that you can get the same functionality with one line in C.

[TheSocialistAvenger]

You also have to be very careful if you start thinking "oh, this is performance critical; I'll write it in assembly." Compilers any more are very good at optimization; to pull a number out of my ass, I'd guess 90% of the time they are probably better than 3/4 of the people who have both the know-how and the will to actually do the above.

Yeah, this is what I was thinking when I said it's not practical to learn. I realize that there is a real machine inside of my shiny plastic box and I know that somebody had to break out assembly to make it all work. But as a hobbyist programmer, drivers and microcontrollers never crossed my mind when making my first statement.

But the part about learning about the hardware is the main reason I'm asking. Though I guess if it's as bad as this thread indicates, a shallow introduction will be a bit hard to come by. I think I'm going to try to get a beginning assembly book for windows and maybe just try to pair that with apple's online docs which are far too dense to learn from on their own (for me anyway).

Thanks for the replies. Anyone know any good books?

[EvanED]

I see it like this: there's no good reason not to learn assembly.

Well, there is often a very good reason to not learn assembly, which is that the effort you put into learning it could be directed towards more useful endeavors. I'm not saying that ASM isn't useful, just that, depending on the person's current knowledge and goals, there are often things that are more useful.

Of course, if you want to learn assembly just because (which is what it certainly seems this thread is about), then that's a very good reason to do so.

[aldimond]

With assembly you can do this: http://www.muppetlabs.com/~breadbox/sof ... eensy.html

That's why you should learn assembly.

[adlaiff6]

You can also break RFID and give a talk at Black Hat and at Google.

[circumlocuted]

I too went a long time before learning assembler, but I am glad I did.

Haven't you ever wondered what an array actually looks like?
Like how the computer sees it?

Or how the computer sees loops or function calls?

I definently think it is important.

[iw]

It's also useful for figuring out if a certain buffer overflow is exploitable, too.

[torne]

If you do want to learn, I'd recommend learning a rational RISC assembly first (ARM is especially easy, and is cheap to simulate if you don't have a suitable system like the GBA). x86 assembly bears a *mild* resemblance to stabbing oneself in the face. With lasers.

Though x86 does have the delightful property that it's possible to write useful programs using only a text editor. Just create a file called "foo.com" in the editor of your choice and type away! (in real-mode x86 assembled instructions, to be executed under DOS or a DOS emulator of some kind). There are quite a few instructions that can't be represented using printable characters, but you can work around this without much hassle most of the time.

[pete]

Though x86 does have the delightful property that it's possible to write useful programs using only a text editor. Just create a file called "foo.com" in the editor of your choice and type away! (in real-mode x86 assembled instructions, to be executed under DOS or a DOS emulator of some kind). There are quite a few instructions that can't be represented using printable characters, but you can work around this without much hassle most of the time.

Technically that wouldn't be assembly, that would be machine code (and insane). Remembering that a MOV command is B4 hex or ALT-180 is hardly practical.

A better route would be to run "debug foo.com" under windows/dos, type "a" and type away.

[evilbeanfiend]

im sure there must be an emacs mode to do that sort of thing

[EvanED]

im sure there must be an emacs mode to do that sort of thing

I think this statement is a tautology.

[phlip]

im sure there must be an emacs mode to do that sort of thing

I think this statement is a tautology.

I have a feeling you could spambot that statement anywhere and not be found out...

"I'm looking for a way to run Linux on my Internet-enabled blowdryer."
"im sure there must be an emacs mode to do that sort of thing"

"Raptors are taking over the world."
"im sure there must be an emacs mode to do that sort of thing"

"Turquoise bicycle shoe fins actualize radishes greenly."
"im sure there must be an emacs mode to do that sort of thing"

See? Fits everything.

Back on topic... I agree that x86 assembly is crazy, and also insane... just be glad you're not working under DOS (yay, segmented memory!)
ARM I've only just started learning recently, but what I've seen seems sane so far...
But some assembly language is probably worth learning if you enjoy that sort of thing... certain aspects of plain C make a lot more sense after knowing how it all works behind the scenes... arrays, structs, pointers, local vars on the stack...

[mrcheesypants]

So I'm in the same spot as the OP and I was wondering how does one start learning assembly?

[pete]

Well, it's been years since I used ASM and I only did DOS stuff (mainly inline routines for faster putpixels and such). I learnt it by finding a book at my cousin's university (he's 10 years older than me) and making a ton of photocopies. No idea what the book was called though.

What I can do is provide a "Hello world" example to illustrate the difference between assembly and machine code (the part after the "-d 100" is the machine code equivalent of the "-a" bits). Not very usefull since it uses interrupt 21h (the DOS interrupt) to do everything.

@evilbeanfiend: I'm sure vi could do it better

[EvanED]

@evilbeanfiend: I'm sure vi could do it better

Now, I think this is, uh, whatever the opposite of a tautology is.

[Rysto]

That'd be a contradiction.

[EvanED]

That'd be a contradiction.

Yes... and no. In logic, a tautology is a preposition that can be proved no matter the premises. A contradiction is an incompatibility between two prepositions. There is only one preposition here; thus there can't be a contradiction.

By a more popular definition it might fit. Personally, I think "oxymoron" is closer to being the right word, but it too doesn't have the right shade of meaning. You could say self-contradiction, but that sounds stupid.

[Amnesiasoft]

x86 assembly bears a *mild* resemblance to stabbing oneself in the face. With lasers.

I always thought that was z80 assembly. So does that make z80 the equivalent of stabbing oneself in the face with laser guns that shoot swords, followed by stuffing yourself in a blender?

[bitwiseshiftleft]

x86 assembly bears a *mild* resemblance to stabbing oneself in the face. With lasers.

I always thought that was z80 assembly. So does that make z80 the equivalent of stabbing oneself in the face with laser guns that shoot swords, followed by stuffing yourself in a blender?

Z80 assembly is sane compared to x86. There's no x87 to futz with, and there are far fewer addressing modes. And basically all the complaints you can level against z80 also hold for x86. (Not enough registers, no target register for most instructions, random set of legal registers, weird CISCy instructions, etc.)

[EvanED]

I'm just surprised that with the ISA changes to AMD64 they only added 8 more registers (given that they were adding any).

Sane architectures have 32, and architectures with 64 have been around for at least a decade or two I think. I'm not really a HW guy.

[Rysto]

Heck, the Itanium has 128 registers.

[djn]

I have written a boot loader in 16-bit x86 ASM. It does indeed have a certain resemblance to laser-enhanced facestabbing. But not anywhere near as much as writing a working VM system (in, and I'm eternally grateful for this, 32-bit mode). On a short deadline, with the results graded on a "we don't like the way you've done this"-basis.

Just for fun, the course notes referred to a book that had been impossible to get in norway for a few years.
Interesting course overall, but responsible for some of the most intense coding nights ever, and with some real problems in the student/teacher feedback cycle.


Generally speaking, though, I like assembler. It's refreshingly imperative, and there's just less things to keep in mind.
Oh, and it's fairly easy to do unix system calls from assembly code, which makes it possible to do actually useful things without too many problems. See this.

Rysto: I'm not sure if I'd call the Itanium "sane", though.

[adlaiff6]

Itanium

LOL

[djn]

Itanium

LOL

Now, now. Just because it's insanely hard to write for, offers no benefit over the traditional (and much nicer) architectures, and doesn't sell anywhere near what intel has hoped for, there is no reason to laugh at it.

Hoestly, I'm sort of sad when I think about it. It killed Alpha, it killed MIPS (for the high-performance role), it has almost killed PA-RISC. As a side effect of this, Irirx is dead, Tru64 Unix is dead, and the OSes ported solely to it (OpenVMS, HP-UX) are a shade of what they used to be.
And it's not even that good!

[torne]

Though x86 does have the delightful property that it's possible to write useful programs using only a text editor. Just create a file called "foo.com" in the editor of your choice and type away! (in real-mode x86 assembled instructions, to be executed under DOS or a DOS emulator of some kind). There are quite a few instructions that can't be represented using printable characters, but you can work around this without much hassle most of the time.

Technically that wouldn't be assembly, that would be machine code (and insane). Remembering that a MOV command is B4 hex or ALT-180 is hardly practical.

Yah, it's assembled bytes, which might be called machine code, depending on your particular opinion as to whether that term is meaningful

It's not insane, it's a fun challenge! Doing it with just an editor, the assumption is that you only use printable characters (things you can type without doing ALT-foo), so you don't need to remember that many opcodes - makes it less impractical. When I used to do this in competition, the rules were to only use bytes 0x20 to 0x7E, which is the US-ASCII printable range. A popular challenge was to write a flying-through-space starfield simulation that way, or Life, or some other graphical toy.

Sadly you're stuck with .COM, since all DOS/Windows formats of EXE require nonprintable characters in their headers (as does ELF and even a.out).

As for how to learn, I picked up ARM assembly from a course resembling http://www.cl.cam.ac.uk/teaching/current/CompDesign/ (this is from a later year than the one I took, but hey, Dr. Moore's pretty great). I already knew a couple of other assemblys, but it should be fine for new folks too...

[pete]

Though x86 does have the delightful property that it's possible to write useful programs using only a text editor. Just create a file called "foo.com" in the editor of your choice and type away! (in real-mode x86 assembled instructions, to be executed under DOS or a DOS emulator of some kind). There are quite a few instructions that can't be represented using printable characters, but you can work around this without much hassle most of the time.

Technically that wouldn't be assembly, that would be machine code (and insane). Remembering that a MOV command is B4 hex or ALT-180 is hardly practical.

Yah, it's assembled bytes, which might be called machine code, depending on your particular opinion as to whether that term is meaningful

It's not insane, it's a fun challenge! Doing it with just an editor, the assumption is that you only use printable characters (things you can type without doing ALT-foo), so you don't need to remember that many opcodes - makes it less impractical. When I used to do this in competition, the rules were to only use bytes 0x20 to 0x7E, which is the US-ASCII printable range. A popular challenge was to write a flying-through-space starfield simulation that way, or Life, or some other graphical toy.

Sadly you're stuck with .COM, since all DOS/Windows formats of EXE require nonprintable characters in their headers (as does ELF and even a.out).

As for how to learn, I picked up ARM assembly from a course resembling http://www.cl.cam.ac.uk/teaching/current/CompDesign/ (this is from a later year than the one I took, but hey, Dr. Moore's pretty great). I already knew a couple of other assemblys, but it should be fine for new folks too...

Apologies. I had visions of people typing "mov" into a text editor and expecting it to do something, no disrespect intended. That does sound like a fun challenge now that I understand what you meant. Hell, it'll probably keep me occupied for months/years/forever. Thanks

[necroforest]

That'd be a contradiction.

Yes... and no. In logic, a tautology is a preposition that can be proved no matter the premises. A contradiction is an incompatibility between two prepositions. There is only one preposition here; thus there can't be a contradiction.

By a more popular definition it might fit. Personally, I think "oxymoron" is closer to being the right word, but it too doesn't have the right shade of meaning. You could say self-contradiction, but that sounds stupid.

In my one math class (that dealt with set theory and proofs), we defined a tautology as a logical statement that is always true and a contradiction as one that is always false. I.e, pv~p is a tautology and p^~p is a contradiction.

[Xanthir]

Unless you are designing a compiler, or doing something for which there is simply nothing *but* low-level code (like coding a microprocessor), there is absolutely no reason to ever learn assembly.

Seriously.

People who like to code assembly to make their code faster? Don't know what they're talking about. The complexity of the simplest instructions on a modern processor is absolutely staggering. A well-written compiler knows how to deal with memory latency and threading and such that require you to know timings of various commands to the microsecond and how everything interacts as it busses back and forth across the processor and the cache. Sometimes your code actually gets faster when you add more instructions. Or when you swap two unrelated lines.

Assembly coders are like audiophiles, or wine tasters. They *think* they know what they're doing, and make sure everyone else thinks so as well. But when you actually sit down and test them, the vast majority of the time they are making the code worse in all but the most trivial of situations.

After all, why do you think all processors are RISC (Reduced Instruction Set) rather than CISC (Complex) like they all used to be? I mean, there was even a chip with a factorization command built in! Now, you're lucky to get a MOV instruction - it's likely that you're actually just using a mask for an XOR against 0x0000 0000. It's all because humans aren't supposed to program assembly anymore. Compilers are. A reduced instruction set means the chip is easier to work with and makes it simpler to optimize instructions, which means the Machine Mind can optimize your code better for you.

If you want to learn assembly just for fun, to see what the computer is like 'down there' (which is interesting in its own right), I suggest downloading SPIM, an emulator for the MIPS32 instruction set. Still a RISC, but not quite as bad as modern day ones are. It's what I learned with, and it's pretty cool.

[EvanED]

Unless you are designing a compiler, or doing something for which there is simply nothing *but* low-level code (like coding a microprocessor), there is absolutely no reason to ever learn assembly.

What? I can name several reasons to learn ASM right off the top of my head:

1. Interest
2. You want to learn how computers work better
3. You want to understand what the compiler is doing behind the scenes so you can better give the compiler optimization opportunities
4. You need to debug a program that is acting wrong enough that source level debugging isn't working (yes, this occasionally happens)
5. You are looking at security, and need to dip down to the low levels to figure out if something is an exploit
6. You want to write programs that work with programs (an extension of the compiler idea)

After all, why do you think all processors are RISC (Reduced Instruction Set) rather than CISC (Complex) like they all used to be? I mean, there was even a chip with a factorization command built in! Now, you're lucky to get a MOV instruction - it's likely that you're actually just using a mask for an XOR against 0x0000 0000.

Well, to be fair, I wouldn't call x86 RISC, and what is at the core of almost every desktop computer made today?

It's definitely not as CISCy as some older stuff, and the back end of at least Intel's chips have essentially been RISC for a while, but I would say that saying you're lucky to get a MOV is just wrong.

[adlaiff6]

5. You are looking at security, and need to dip down to the low levels to figure out if something is an exploit

5b. You are trying to exploit something. >_> <_<

[shill]

Assembly coders are like audiophiles, or wine tasters.

What? Audiophiles and wine tasters have no objective way of measuring anything. Assembly coders have these things called 'profilers' that tell them exactly which code is taking how much time. You ought to spend some time on http://www.masmforum.com, specifically "The Laboratory" section. Have a good talk with Mark Larson or hutch.

[iw]

5b. You are trying to exploit something. >_> <_<

How else can I get Total Disclosure street cred??

[b0b]

I think that today, the only people who use assembly are those who write C compilers. Am I wrong?

Given the short shelf life and complexity of most new applications, few organizations have the resources to write anything substantial in assembly. A decent C compiler can spit out code that rivals hand assembly in speed. The size of the memory footprint isn't nearly the issue it once was.

[Rysto]

I believe that 3D game engines have to use some assembly to take advantage of some of x86's more advanced floating point and matrix operations. Same goes for those poor saps who do choose to do any kind of numerical computation in C.

Operating system and embedded programmers will still dip into assembly on occasion, although the trend is to write as much C as possible and mostly use only inline assembly.

And, of course, anybody who's writing any kind of compiler to machine code(not just C) will be writing assembly.

[b0b]

And, of course, anybody who's writing any kind of compiler to machine code(not just C) will be writing assembly.

Do such things still exist? I thought that all compilers these days spit out byte code or a high level language, and that C was the only one that actually goes down to machine code.

[Rysto]

JVMs, for one, compile Java bytecode to machine code for speed.