I've been meaning to solidify my memory of common x86 instructions for a while, but I never got around to it because I get distracted by the bazillion other more advanced instructions. This guide is nice because it covers a few common instructions in a complete-enough manner but not excruciating details like the Intel manual.
Unless you're looking at handwritten and/or deliberately obfuscated code, the "more advanced" instructions are unlikely to be encountered; the bulk of compiler-generated general-purpose code will be moves, ALU ops, pushes, and pops along with the usual control flow calls, returns, and jumps.
I deal with a lot of manual SIMD code in C with <nmmintrin.h> etc, but being a C programmer, I've forgotten how some of the "normal" instructions work. Also the advanced instructions are useful to at least be familiar with when you're working with disassembly, or studying how compilers optimize code.
"Credits: This guide was originally created by Adam Ferrari many years ago,
and since updated by Alan Batson, Mike Lack, and Anita Jones.
It was revised for 216 Spring 2006 by David Evans."
Sure, but the principles are the same. The mnemonics are the same, the registers discussed are still around (there are more registers now, but the ones in TFA didn't go anywhere), addressing modes are the same, the stack still grows downward, the MASM syntax and directives are still the same, and the code still runs on modern hardware. Perhaps most importantly, the mindset you use while writing code in x86[_64] assembly language is still the same.
Actually, my experience has been that once you learn the ropes of programming in one assembly language[1], picking up any other assembly language is just a matter of perusing the proper reference manual(s) to find an architecture overview, useful instructions, calling convention(s)/ABI, and the syntax accepted by your assembler. While a tutorial for some new-to-you assembly language may be convenient, it's typically not necessary so long as you've got the manuals (which you really should have if you plan on writing programs in or compilers to an assembly language, regardless of any tutorials or textbooks you might have).
[1]: You can cut your teeth with any assembly language, really. However, I feel like it might be a little easier to start with a CISC instruction set architecture, because they tend to be designed with human programmers in mind, while other types of ISA (RISC, EPIC, etc.) are typically designed with "automatic programmers" (compilers) in mind.
That’s exactly why I think it’s better to learn x64. Besides generally useful concepts, mnemonics and addressing modes, you’ll at the same time learn something useful in practice, and should be able to start applying those concepts right away.
Well, not completely useless, at least for now. However, these days it’s much less useful than amd64.
PCs: Steam hardware survey currently says “Windows 64 bit: 87.64%, Windows 32 bit: 8.08%”
Some person from MS said 2 years ago “no less than 92.8 percent of the new PCs sold worldwide and running Windows are powered by a 64-bit of the company’s operating system”
Macs: the OS doesn’t support 32-bit hardware since 10.7 Lion.
What else runs x86, servers? Microsoft just stopped making 32-bit server OSes, Windows Server 2008 was the last one of them. Don’t know what’s happening in *nix world, but I’d be surprised to learn 32-bit OSes still popular there, servers typically have lots of RAM.
I think I see where you're coming from. It's pretty much a matter teaching the most common thing, since common implies widely-applicable which implies most useful in practice. I think that's a fair point, and should certainly be a consideration to anyone planning to teach any topic in comp sci. However, having taken a semester-long course on 16-bit (8086) assembly language back in college (with MASM running in DOSBox on OSX, of course ;) ), I've never found any need for any further coursework or tutorial-style texts/articles/whatever in order to later write 32-bit x86 or amd64 (or even ARM, PPC, 68k, or 6502) assembly language. Just the reference manuals were enough, because the mindset is largely the same. I feel as though it's broadly similar to other programming paradigms, where if you learn a procedural language, there's no real need to study another before starting to code.
> What else runs x86...?
Well, as far as I know, every amd64 machine can run 16- or 32-bit x86 machine code. So, I'd say pretty much all of your examples of amd64 machines run x86 :p
If you want to teach concepts and make it easier to understand and complete assignments, then yes, 16-bit assembly is fine.
Much easier than both modern x86 and amd64 instruction sets.
IMO modern x86 CPUs are not designed for humans. For example, x87 FPU is deprecated, by default no modern compiler emits those instructions because SSE2 is typically faster even for scalar values. While making compiled programs faster, it also makes reading and writing floating-point assembler code harder compared to the legacy x86.
> every amd64 machine can run 16- or 32-bit x86 machine code
Only when running on bare metal. Modern operating systems restrict which code you can run on them. For example, in Windows 64, in kernel mode you can’t even use x87 FPU instruction set.
Another is this one by Paul Carter, who taught Computer Science at the University of Central Oklahoma for 10 years, including PC assembly language programming. You can get both a free PDF and a physical copy of it from here:
and it uses only free software such as NASM and GCC.
The book covers 32-bit protected mode programming in assembly. It also covers interfacing assembly and C code.
