I actually got paid a salary for learning & programming in IBM mainframe assembler (BAL or Basic Assembly Language) in 1970, for an insurance company. The CPU memory was so small (32K, yes 32,768 bytes) that the only way we could squeeze enough functionality was to write in assembler, with overlays (no virtual memory). Debugging consisted of manually toggling hex data and instructions at the control panel. What a blast!<p>It was a lot of fun, but terribly inefficient programmer productivity. I would not want to go back :o) Dereferencing registers prepared me for C pointers later.
Maybe too much content? 1000+ pages, many architectures... Probably too much content for a beginner book?<p>Btw, a great book imho is "Assembly Language Step By Step - Programming with Linux - 3rd ed" (<a href="https://musho.tk/l/d2d56a34" rel="nofollow">https://musho.tk/l/d2d56a34</a>).<p>The great things is that it is an easy read and really starts from the basic and explains how the i386 architecture works, and then explains how to program it using assembly.<p>The sad thing is that afaik the author is quite old and probably is not going to release a 4th edition, meaning that the book will stay on intel i386.
The fact that the document targets multiple architectures is great, most ASM tutorials online target solely x86 and as such give a very partial view of how assembly is written and how CPUs work, and on top of that x86 ASM is really quite a mess.<p>I've skimmed the document and it seems rather thorough and doesn't shy away from all the nasty details (which is a good thing for an ASM tutorial), the only criticism I have so far is that the assembly listings are a bit hard to read, additional whitespace and basic syntax highlighting (at least to isolate the comments) would make it a bit easier on the eyes I think, for instance: <a href="https://svkt.org/~simias/up/20180717-151848_asm-listing.png" rel="nofollow">https://svkt.org/~simias/up/20180717-151848_asm-listing.png</a>
This seems to the same text as the author's Reverse Engineering for Beginners (<a href="https://beginners.re/" rel="nofollow">https://beginners.re/</a>)<p><a href="https://news.ycombinator.com/from?site=beginners.re" rel="nofollow">https://news.ycombinator.com/from?site=beginners.re</a>
At one point when I was considerably younger I started learning 32-bit x86 assembly as my very naive career goal was to become the next Linux Torvalds. I managed to construct a multiboot-compliant 32-bit kernel that could load tasks from a ext2 ramdisk image passed to the bootloader and multitask up to around 64 processes. I figured out how to use the CR3 register and craft page tables, enter into kernel syscalls using software interrupts, handle CPU faults, page faults, double faults etc. It was quite the learning experience until it eventually crumbled under my lack of skill and foresight. In short, I got more or less about as far as most amateur, self-taught, lone OS developers get before losing interest and giving up.<p>Fast forward a couple of decades, and I found myself reverse engineering CP/M for the Z80 processor in order to create a virtual Z80-based system that ran inside Unreal Engine. I started with Udo Munk's wonderful Z80pack system, adapted a public domain Z80 CPU emulator which was written in C to C++, and did minimal reimplementation of the Z80pack terminal and disk I/O devices. Since the systems were implemented as "actors" in UE4 it's possible to spawn and run quite a few concurrently as long as you limit the CPU speed of each instance somewhat.<p>The resulting virtual system in UE4 is able to run original CP/M ports of Rogue and Zork (<a href="https://i.imgur.com/gnOCp3e.png" rel="nofollow">https://i.imgur.com/gnOCp3e.png</a>), various Z80 instruction exercisers (<a href="https://i.imgur.com/kwNuq5X.png" rel="nofollow">https://i.imgur.com/kwNuq5X.png</a>), a Z80 C compiler and and even Wordstar 4 (<a href="https://i.imgur.com/Q6307w3.jpg" rel="nofollow">https://i.imgur.com/Q6307w3.jpg</a>) and Microsoft BASIC.<p>Learning assembly can be a lot of fun - it can really teach you quite a bit about systems architecture that you otherwise might not get if you're always programming in high-level languages only.
My god, 1000+ pages. What a great submission though. I wonder what kind of things keep such people motivated to write one fuckin' thousand and eighty two pages about assembly!? This is nuts.
Old school, but I've always enjoyed this gentle introduction:<p><a href="https://chortle.ccsu.edu/AssemblyTutorial/index.html" rel="nofollow">https://chortle.ccsu.edu/AssemblyTutorial/index.html</a>
Amazing. One of my fondest memories is when, at age 10-11, I "played" Core War [0] with an older friend of mine (he was 20-21 back then, and a CS student at one of the best CS universities in Italy, Pisa). I loved to learn how to program in a game-like environment. I still remember several things, ~30 years later.<p>[0]: <a href="https://en.wikipedia.org/wiki/Core_War" rel="nofollow">https://en.wikipedia.org/wiki/Core_War</a>
DiffPDF 2.1.3 finds only two tiny (if weird) differences in the appearance of the two versions of the books (<a href="https://yurichev.com/writings/AL4B-EN.pdf" rel="nofollow">https://yurichev.com/writings/AL4B-EN.pdf</a> and <a href="https://beginners.re/RE4B-EN.pdf" rel="nofollow">https://beginners.re/RE4B-EN.pdf</a>) besides the title, author and build date: two page references at pages 1075 and 1078.<p>Since both sites appear to be owned by the book's author this is most likely just a change that has not yet been pushed to github (or mentioned in the author's sites), but it would be better if the author clarified it (would that be you, dennis714?)
I got interested in assembly fairly early on my programming career by playing wargames(io.smashthestack.org anyone?). Writing exploit payloads was very fun. After that in my career i have only written assembly to vectorize some code using neon.<p>I think the best reason to learn assembly is not to write rather be able to read compiler output.
This is a great resource. I don't think it is for beginners, it is a bit overwhelming. But as a programmer who has to dive into asm every few months (on a variety of architectures!), this will be a very helpful reference to help me reset my frame of mind for the particular architecture.
I've never had a desire to learn about Assembly, but I thought the first few pages of this book were kinda interesting, and I might end up learning more than I had ever cared to.
This isn't for beginners. What beginner's assembly text covers multiple architectures and assembly flavors?<p>My recommendation for beginner's assembly on linux is to write toy code in C and then view the disassembly in gdb or objdump. You have options to switch to Intel syntax from GAS/AT&T if you want.<p>I'm generally against using windows for anything, but Visual Studio has decent disassembly debug options where you can step through the native assembly code. You could also look at IL code ( which is very similar to native assembly ) and learn assembly concepts that way. ildasm and ilasm are great tools for that.<p>Assembly is so low level and can be intimidating to write from scratch in the beginning. It's better for beginners to write code in a higher level language like C and then read the compiler generated assembly code. Once they are comfortable with a disassembly of a "hello world" program, then write more complicated code and understand the disassembly. Then try to edit and compile the disassembled code. Once you are comfortable, then write your own assembly code from scratch.<p>Edit: Also, if you have time and the will, watch the nand2tetris lectures and try their projects. It'll give you a hands-on general overview of hardware to assembly to VM to OO. How native assembly works with hardware. How VM interacts with native assembly. How you go from OO to VM? It's a very limited but educational overview of code flow from object oriented code all the way to circuitry ( software circuitry ).