Thought this was the perfect place to share a project I've been working on for a few years: https://asm-editor.specy.app
It's an interactive online IDE for many assembly languages, currently M68K, MIPS, RISC-V and X86 (I need to improve X86). It has a ton of features that are made to teach assembly programming, and it can be embedded in other websites.
This article made me realize that, at my home, out of 7 full-fledged computers, that is, notebooks, servers or desktops, there's not a single X86 machine.
Maybe there are a couple old dell notebooks somewhere in the garage, but I am not even sure they still boot.
The silent and really unheralded disappearance of Wintel from my home surprised me a few weeks ago as well. It wasn't a conscious decision, they just got slowly replaced by macbooks, and an ARM based NAS... etc. Kind of like how I also realized I no longer have an optical disc reader... despite still having spindles of very old stuff.
And this is kind of sad in the context of this post. Because I have always wanted to dive deeper into assembly, and there are loads of material to study X86 assembly out there.
But being able to run it only in a virtual machine, it is a little bit demotivating.
Well, there are some chinese folks selling newly built PC-XT compatible machines on the internet. Maybe I could go this way. And probably, pure, original 8086 assembly is a lot more fun than overly complicated X86_64 with lots of extensions.
I found using qemu to be quite simple and pretty decent. I guess it depends on what you are looking to do- really low level bootloader/OS type stuff or actually explore the instruction set and maybe build something useful. Learning about the BIOS interface was actually quite enlightening, but in general ARM and RISC-V is much less complex.
There's always arm assembly. It's a differen ISA of course, but a lot of the concepts transfer pretty nicely. You could also look at something like the Zimaboard or similar machines.
Please provide a PDF version or make your page printable. Even when clicking your ad bar/banner down, a "print to PDF" in Chrome renders a crippled view with parts of the text covered, because of the remains of that ad bar/banner.
I did not know that pointer indexing registers had direct low byte access, like `si/esi` (in 16/32bit when I last time used assemblers directly) that comes with `sil` as `ax/eax` analogy to `al`. Are there really opcodes for that that were added in the later evolution of x86_64? Seems I need to double check the specs of the platform again... out of plain curiosity!
It wasn't possible on the 386. Ken Shirriff discusses how the Intel 80386's register file was built at https://www.righto.com/2025/05/intel-386-register-circuitry..... Only four of the registers are built to allow 32-, 16- or 8-bit writes. Reads output the entire register onto the bus and the ALU does the appropriate masking. The twist is for the legacy 16-bit upper half-registers - themselves really a legacy of the 8080, and the requirement to be able to directly translate 8080 code opcode-for-opcode. The output of these has to be shifted down 8 bits to be in the right place for the ALU, then these bits have to be selected.
AMD seem to have decided to regularise the instruction set for 64-bit long mode, making all the registers consistently able to operate as 64-bit, 32-bit, 16-bit, and 8-bit, using the lowest bits of each register. This only occurs if using a REX prefix, usually to select one of the 8 additional architectural registers added for 64-bit mode. To achieve this, the bits that are used to select the 'high' part of the legacy 8086 registers in 32- or 16-bit code (and when not using the REX prefix) are used instead to select the lowest 8 bits of the index and pointer registers.
From the "Intel 64 and IA-32 Architectures Software Developer's Manual":
"In 64-bit mode, there are limitations on accessing byte registers. An instruction cannot reference legacy high-bytes (for example: AH, BH, CH, DH) and one of the new byte registers at the same time (for example: the low byte of the RAX register). However, instructions may reference legacy low-bytes (for example: AL, BL, CL, or DL) and new byte registers at the same time (for example: the low byte of the R8 register, or RBP). The architecture enforces this limitation by changing high-byte references (AH, BH, CH, DH) to low byte references (BPL, SPL, DIL, SIL: the low 8 bits for RBP, RSP, RDI, and RSI) for instructions using a REX prefix."
In 64-bit code there is very little reason at all to be using bits 15:8 of a longer register.
This possibly puts another spin on Intel's desire to remove legacy 16- and 32-bit support (termed 'X86S'). It would remove the need to support AH, BH, CH and DH - and therefore some of the complex wiring from the register file to support the shifting. If that's what it currently does.
Actually, looking at Agner Fog's optimisation tables (https://www.agner.org/optimize/instruction_tables.pdf) it appears there is significant extra latency in using AH/BH/CH/DH, which suggests to me that the processor actually implements shifting into and out of the high byte using extra micro-ops.
No BSWAP r16 exists. Why? in 32 bit mode, it was not needed, because you could simply use
XCHG r/m8, r8
with, say, cl and ch (to swap the endianness of cx).
In 64 bit mode, you can thus only the endianness of a 16 bit value for the "old" registers ax, cx, dx, bx using one instruction. If you want to swap the 16 bit part of one of the "new" registers, you add least have to do a 32 bit (logical) right shift (SHL) after a BSWAP r32 (EDIT:
jstarks pointed out that you could also use ROL r/m16, 8 to do this in one instruction on x86-64). By the way: this solution has a pitfall over BSWAP: BSWAP preserves the flags register, while SHL does not.
It might be similar to Matt Godbolt's experience with his "Compiler Explorer". Most of your users are not trying to set fire to the free system, and when somebody does, on purpose or by accident, you focus on being able to reliably recover, not prevent it. So e.g. maybe Clara T Vandal "cleverly" seizes control of a random Compiler Explorer build box, well, that box is no longer marked OK because of her changes, it gets automatically torn down and replaced, no real problem. Did Clara do 0.001¢ of Bitcoin creation without paying for it? Yeah, maybe, and Clara probably cost Matt 0.1 cents for the data centre fees but it's not a big deal.
Looking at the source code of the code-editor [1], it seems to be embedding https://onecompiler.com via the iframe and delegating code compilation and execution to it. So I guess it's a question to onecompiler, whether they sanitize input or not. :)
What I don't understand is why assembly feels so hard to learn in the first place?
I mean, isn't it just a simple language with a few function calls (instructions) and types (operand sizes) and fixed number of variables (registers) and a small number of control flow operators, and that's it? Why does it feel so mysterious?
1. You are primed to think that it is mysterious because that’s all you usually hear about assembly. (“Roller Coaster Tycoon was written in 100% hand crafted assembly… what an absolute wizard!!”)
2. The language’s textual format is odd - columns vs nested indentation. Actually really nice once you get used to it, but it’s definitely alien at first.
3. Mnemonics and directives have short, cryptic spellings. x86 in particular has arbitrary looking register names as well. RV, AArch64, m68k etc do better here.
4. Mnemonics are inconsistently overloaded and encode lots of stuff. SIMD instructions tend to look like a cat sat on your keyboard.
5. Manually laying out memory is technically simpler than the abstractions provided by higher level languages (structs and classes, fancy generic types, pointer syntax), but it’s fiddly and you have to deal with alignment.
6. You have to do a lot of bookkeeping yourself. It’s like malloc/free turned to 11.
7. Register allocation is a hard problem for computers. It’s kinda tough for humans, too.
8. Lots of books and online stuff discuss assembly for use with high performance code, tight compute kernels, raw hardware access, and fiddly CPU configuration for OS startup and virtual memory configuration. This requires even more specialized registers, arcane instructions, and bit fiddling. This stuff - along with reverse engineering and security research/attacks - gets lumped into what people think of as “assembly language”. The resulting concept surface therefore looks much larger than it actually is.
I highly recommend making a non-trivial program entirely in assembly at least once. I need to do it occasionally professionally but even when I don’t I usually have a hobby project or two cooking at home.
Becoming as proficient in asm as - say - C or Python is quite the lovely expression of craft. You feel like a wizard (see point 1) while simultaneously learning what’s really going on.
For people with a certain geeky disposition it pays lots of aesthetic, psychological, and professional dividends.
Simple languages are not necessarily easy languages to understand. See: brainfuck, APL, K, etc.
I think the problem with assemblers in particular is that the canonical definition is the byte code, not the human readable text. x86 is particularly annoying because no one agrees on the syntax of that text, there are hundreds of mnemonics, things are constantly being updated, and the practicing assembly programmer cares deeply about the execution semantics of the microarchitecture more than the specific sequence of instructions. Some of the language is also completely foreign to higher level programmers, like instruction pipelines, uops, instruction latency, and so on.
Rarely do you sit down and write this assembler by hand, you compile some C code and poke at it with vtune/uprof to measure hot sections of the code, break those down, and implement faster versions. It's fundamentally an iterative, experimental process.
It is simple until you need something complex - working on a team, call stack management, memory management (allocate, track, free), working on a team, event handling / non-synchronous interrupts, and working on a team.
For a little 8-bit microprocessor with program size < 8k it can be quite easy and even a joy. Anything else and your compiler will outperform you, better to inline hand-coded assembler as needed.
It's a (non mobile-optimized) web-based PvP assembly programming game. The syntax is highly inspired by x86 assembly and the game itself by Core War. There is also a small tutorial and a ranked ladder powered by Glicko-2.
The other one, is a clunky one from UNIX world point of view on x86 CPUs, follow the links on the sibling comment.
Rather clunky and most UNIX Assemblers were never as powerfull as other systems macro assemblers, since after UNIX System V, it was there only as an additional external tool pass for the C compilation steps, and even before that, the assembler was quite minimalist.
Then there is the whole brain twist of being used to op dest, src, and having to switch into op src, dest.
I prefer the Intel approach as it is more similar to dest = src, rather than src -> dest.
Intel's approach is also more common across various assembly languages.
dest/src order is not a big deal in absolute terms: The ISA designer picks an order, documents it, everyone follows their documentation, done. Intel picks one order for programming Intel, DEC picks another order for programming the VAX? Great, just look in the instruction set manual and you're set.
The silly thing is importing one order to another architecture that uses the opposite order. Now your users have to transpose operands for no reason. The really silly thing is messing up the operand order of the cmp instruction in the process. The VAX assembly language had a compare with the sane operand order, BTW.
It's always a great way to get a better understanding of things but at least just poking around assembly a bit once. You do not have to make a project or anything big, but do not be afraid to check it out.
I tried optimizing my CPU emulator dispatch in raw assembly to see if I could run a simple fibonacci program faster than C++. And I was not even close. In the end I merged it and made it a default-disabled dispatch option, because ... there has to be a way to make it faster!
I did manage to improve it once I figured out some of the various modes of accessing memory, and I even managed to cut the jump table down from 64- to 32-bit which should help keep it in memory. I made the jump table part of .text in order to make it RIP-relative. For the fibonacci sequence program, not many bytecodes are needed. I would greatly appreciate some tips on what can be improved there.
have you tried actually comparing what you have to what the c++ compiler generates? i don't have a lot of context here but I think it's possible that the difference is less due to the dispatch mechanism (i.e. how the next instruction is fetched) but due to the implementations of the instructions themselves.
one opportunity for optimization is mapping emulated registers to real x86-64 registers and basically never spilling them to memory (so that way if you have to add you don't have to first fetch then add, but just add directly). though that makes writing the emulator a lot more annoying.
Author here. The final part of this series is still sitting in my drafts.
It was nominally supposed to be about flow control instructions, but as it goes with those things, it spiralled and ended up touching on relocations, position-independent code, aslr... One on these days I'll clean it up and post it
I've found being able to read assembly more useful than writing it.
For those writing in compiled languages like C/C++ and particularly with an interest in performance it's been very helpful just to be able to read compiler output and see what it's generating. Takes the guesswork out of it, removing the uncertainty by simply being able to see what the compiler is actually doing. You can just write code and see the result, who knew!. It's actually helped my understanding of C++ in seeing the bigger picture.
Of course it's also much easier to learn just to read a little disassembly than actually write the stuff. I'm sure I'm not alone in that for me Compiler Explorer (https://godbolt.org) was my gateway into this. You can get quite far even if just knowing the basics (I'm no expert).
The software security community has a subsection that focuses on the security of compiled binaries, where understanding assembly has many uses. These uses include binary reverse engineering and proof-of-concept exploit development to demonstrate the severity of a vulnerability.
If these do sound interesting to you, I'd recommend looking into capture the flag (CTF) competitions, and trying reverse engineering or binary exploitation (pwn) challenges. PicoCTF [1] is an entry-level platform that hosts challenges and has references to learning resources - I believe there's a sequence on assembly in the learning resources.
Aside, I also find it useful to know assembly when debugging C/C++ code, as others have suggested.
Yeah I think the only things that really need assembly these days are vector/SIMD (e.g. writing a video codec), really low level stuff for interacting with hardware (writing an OS) or if you're actually working on CPUs (how I learnt).
It's kind of useful for understanding compiler output on godbolt, and occasionally for debugging code without debug info.
But I successfully wrote a ton of C++ for decades without knowing assembly. It's not really necessary.
Assembly is one of those things where setting your ambitions higher than is usually advised can be wise.
You could try writing a game (perhaps using Raylib) or a pixel art editor. Or maybe a little web application for your Homelab.
Simple C libraries (Raylib, libcurl, early win32 APIs) tend to be dead simple to use from assembly.
Most asm tutorials are either bare metal / OS or “we will talk directly to the kernel”, but there’s no reason you can’t interface with higher level libraries and make real apps and games. It’s simpler than it sounds because a whole lot of your code will just be moving things around between registers and memory in order to make function calls and bookkeep your program state.
In embedded systems using MCUs with very little memory (AVR comes to mind) assembly might be preferred over high level languages (very generously counting C as HLL here). It might even be fun (for truly launch-and-forget projects -- don't even think about maintaining such code) to forgo structured programming and get creative with control flow and self-modifying code.
As a systems engineer it's good to know _some_ x86-64 assembly as sooner or later you're facing a stack trace / register dump and will have to try to make sense of it. Personally, I would take it only further, if you're interested in building compilers.
I would also recommend TIS-100's "sequel", Shenzhen I/O. TIS-100 is a bit 'dry', with the puzzles being entirely abstract. In SI/O, you roleplay as a developer emigrating to China for work, so all the puzzles are framed as real products you are developing for your company. One of the earlier puzzles, for example, is programming the equipment for a lasertag place.
I second the Shenzhen I/O recommendation, because apart from only assembly programming, the game also has other constraints in the form of having to spacially arange various chips on a limited "enclosure" for the product you're building and connect them. It also rewards optimization both in terms of assembly and chip usage efficiency. Is a wonderful game, really.
I will reveal that I have played far more of Shenzhen solitaire than Shenzhen I/O itself. Zachtronics made a stand-alone version of the game[1], but there's also a fanmade version here:
Which I find more enjoyable, both because it's online so it's easier to reach from anywhere, and also because I feel like the version of the solitaire inside the game is a bit... heavy feeling. Like there's some sort of input delay? Anyhow, I must have around 3000 completed games of solitaire across my devices.
ax, bx, cx, dx are 16 bit registers referring to the lower 16 bits of rax, rbx, rcx, and rdx respectively. Bits 0..8 can be referred as al/bl/cl/dl, bits 8..16 as ah/bh/ch/dh.
In a 64 bit register, e.g., RAX, AL refers to the lowest 8 bits [0-7] and AH refers to the next 8 bits [8-15].
Together, AX refers to bits [0-15]. EAX refers to [0-31].
It's counterintuitive (or at least, inconsistent) that we have a name for bits [8-15] but not for [16-31] or [32-63]. My fuzzy understanding is that this came about from legacy decisions.
I came to the party way to late. A month ago, I found out asmjit was a thing, and now it's happily embedded in my app. But I don't know assembly! I tried to learn a few times since the early 2000s but the timing was never right. But hand written asm as a feature fits perfectly into my upcoming app, so now I am on a roll learning assembly! Here are some more resources I found so far:
I wish there were more articles and resources about modern ARM assembly. Not that I ever will or have programmed in Asm, but I like learning about it and imagining I will, and Intelisms feel so archaic and crusty in comparison.
It's currently 50% off and not only will you learn ARM, and some history about ISAs in general, but you'll learn more about how the computer itself works.
And if ARM isn't a hard requirement, an older edition that uses RISCV as the core ISA is a free download.
The first link was the textbook I used for my computer architecture course last semester and I concur. This was the first time our professor taught ARM instead of x86_64 because he believes ARM is the future.
I learned on the MIPS processor, computer organization / architecture one of the most challenging CS courses for me. I don't remember much but I definitely remember the mips pipeline...
This is my own channel, but I made a 10+ part series on modern ARM assembly you may find interesting. I used CPUlator for the demonstrations, which is a nice way to inspect the memory as well as the individual registers as you are running a program.
Thanks for your work on this. I’ve bookmarked several of these videos and used them as reference.
Learning assembly with a really good visualizer or debugger in hand is highly underrated; just watching numbers move around as you run your code is more fun than it has any right to be.
Any reason for ARM specifically? There are a lot of microcontrollers out there that fairly simple but without Intel's crustiness. Atmel, for instance. And if you decide to actually try experimenting with them you can get yourself set up for it for less than $100.
I'm learning AArch64 assembly in the process of writing a code generator for it. godbolt.org is a great resource for "how do I do this?" Write a short function, run it through godbolt.org, see the instructions generated, lookup the instructions in the spec:
The first HN link in my comment addresses that. The short version: learn the earliest asms first, then progressively learn the newer ones until you get to today, and none of the knowledge will be wasted. Kind of like fast-forwarding.
I wouldn't say you are wrong, but I would also postulate.
The smallest, simplest, 'useful' (in terms of useful enough that lots of devs did good work with it and thus it might also be 'popular') ASM sets are probably also sufficient to start with. Provided you've got a good guide to using them, and also ideally a good sheet for why given instructions are packed the way they are in binary.
I do agree you're more likely to find pointers to such resources in more classic architectures. They're also more likely to be easy to find free copies of useful literature.
Flip Jump is amazing. I understand the theory and how it works but it still amazes me that it does. Things like this is why I love the science in computer science.
I had quite entertaining session with ChatGPT and recursive fibonacci in nasm. We found out that C-version was twice as fast. So no returning back to year 1975.
"Higher language version is easier to optimize, because machine gets better idea what you are aiming at." said Lex Fridman et al.
correct, understanding the instruction set architecture you are working with is required for reasoning about the performance of a given algorithm in detail.
you will likely not be writing a lot of assembly by hand, however steering the compiler codegen in the right direction requires an understanding of what the compiler produces.
even outside of enhancing performance, knowledge of instruction sets is instrumental for security research and reverse engineering. for some fun but practical demonstrations, see work by Nathan Baggs on YouTube - it involves staring at a lot of disassembly.
i don't know where this misguided notion that assembly language is "1975" comes from. it's not like Cobol where a few large but important systems keep it alive. this is something that lies at the core of every interaction with computers that you have daily.
What? Did I just give you an example that it is true?
Natural language is the highest of course. We will return to assembly programming eventually, because those intermediate "highlevel" languages are not needed anymore between you and machine.
Thought this was the perfect place to share a project I've been working on for a few years: https://asm-editor.specy.app
It's an interactive online IDE for many assembly languages, currently M68K, MIPS, RISC-V and X86 (I need to improve X86). It has a ton of features that are made to teach assembly programming, and it can be embedded in other websites.
No Z80 or 6502?
Not yet* https://github.com/Specy/asm-editor/issues/25 And 6502 is a bit harder
With such a domain name, it should have been Z80 :)
This article made me realize that, at my home, out of 7 full-fledged computers, that is, notebooks, servers or desktops, there's not a single X86 machine. Maybe there are a couple old dell notebooks somewhere in the garage, but I am not even sure they still boot.
The silent and really unheralded disappearance of Wintel from my home surprised me a few weeks ago as well. It wasn't a conscious decision, they just got slowly replaced by macbooks, and an ARM based NAS... etc. Kind of like how I also realized I no longer have an optical disc reader... despite still having spindles of very old stuff.
And this is kind of sad in the context of this post. Because I have always wanted to dive deeper into assembly, and there are loads of material to study X86 assembly out there.
But being able to run it only in a virtual machine, it is a little bit demotivating.
Well, there are some chinese folks selling newly built PC-XT compatible machines on the internet. Maybe I could go this way. And probably, pure, original 8086 assembly is a lot more fun than overly complicated X86_64 with lots of extensions.
I found using qemu to be quite simple and pretty decent. I guess it depends on what you are looking to do- really low level bootloader/OS type stuff or actually explore the instruction set and maybe build something useful. Learning about the BIOS interface was actually quite enlightening, but in general ARM and RISC-V is much less complex.
There's always arm assembly. It's a differen ISA of course, but a lot of the concepts transfer pretty nicely. You could also look at something like the Zimaboard or similar machines.
If you just want to learn for the fun of it, check out RISC-V instead. It might give you that early days feeling.
I wrote one: https://www.nayuki.io/page/a-fundamental-introduction-to-x86...
Please provide a PDF version or make your page printable. Even when clicking your ad bar/banner down, a "print to PDF" in Chrome renders a crippled view with parts of the text covered, because of the remains of that ad bar/banner.
The print version is quite nice in Firefox with JS disabled.
Really nice. Love the format, thanks!
I did not know that pointer indexing registers had direct low byte access, like `si/esi` (in 16/32bit when I last time used assemblers directly) that comes with `sil` as `ax/eax` analogy to `al`. Are there really opcodes for that that were added in the later evolution of x86_64? Seems I need to double check the specs of the platform again... out of plain curiosity!
It wasn't possible on the 386. Ken Shirriff discusses how the Intel 80386's register file was built at https://www.righto.com/2025/05/intel-386-register-circuitry..... Only four of the registers are built to allow 32-, 16- or 8-bit writes. Reads output the entire register onto the bus and the ALU does the appropriate masking. The twist is for the legacy 16-bit upper half-registers - themselves really a legacy of the 8080, and the requirement to be able to directly translate 8080 code opcode-for-opcode. The output of these has to be shifted down 8 bits to be in the right place for the ALU, then these bits have to be selected.
AMD seem to have decided to regularise the instruction set for 64-bit long mode, making all the registers consistently able to operate as 64-bit, 32-bit, 16-bit, and 8-bit, using the lowest bits of each register. This only occurs if using a REX prefix, usually to select one of the 8 additional architectural registers added for 64-bit mode. To achieve this, the bits that are used to select the 'high' part of the legacy 8086 registers in 32- or 16-bit code (and when not using the REX prefix) are used instead to select the lowest 8 bits of the index and pointer registers.
From the "Intel 64 and IA-32 Architectures Software Developer's Manual":
"In 64-bit mode, there are limitations on accessing byte registers. An instruction cannot reference legacy high-bytes (for example: AH, BH, CH, DH) and one of the new byte registers at the same time (for example: the low byte of the RAX register). However, instructions may reference legacy low-bytes (for example: AL, BL, CL, or DL) and new byte registers at the same time (for example: the low byte of the R8 register, or RBP). The architecture enforces this limitation by changing high-byte references (AH, BH, CH, DH) to low byte references (BPL, SPL, DIL, SIL: the low 8 bits for RBP, RSP, RDI, and RSI) for instructions using a REX prefix."
In 64-bit code there is very little reason at all to be using bits 15:8 of a longer register.
This possibly puts another spin on Intel's desire to remove legacy 16- and 32-bit support (termed 'X86S'). It would remove the need to support AH, BH, CH and DH - and therefore some of the complex wiring from the register file to support the shifting. If that's what it currently does.
Actually, looking at Agner Fog's optimisation tables (https://www.agner.org/optimize/instruction_tables.pdf) it appears there is significant extra latency in using AH/BH/CH/DH, which suggests to me that the processor actually implements shifting into and out of the high byte using extra micro-ops.
> In 64-bit code there is very little reason at all to be using bits 15:8 of a longer register.
I disagree: there only exists BSWAP r32 (and by 64 extension BSWAP r64): https://www.felixcloutier.com/x86/bswap
No BSWAP r16 exists. Why? in 32 bit mode, it was not needed, because you could simply use
XCHG r/m8, r8
with, say, cl and ch (to swap the endianness of cx).
In 64 bit mode, you can thus only the endianness of a 16 bit value for the "old" registers ax, cx, dx, bx using one instruction. If you want to swap the 16 bit part of one of the "new" registers, you add least have to do a 32 bit (logical) right shift (SHL) after a BSWAP r32 (EDIT: jstarks pointed out that you could also use ROL r/m16, 8 to do this in one instruction on x86-64). By the way: this solution has a pitfall over BSWAP: BSWAP preserves the flags register, while SHL does not.
What about ROL r/m16, 8?
This would indeed work (and is likely the better solution), but in opposite to BSWAP and XCHG, it also changes flags.
Something similar, but you can play with the examples in the browser without any local setup https://shikaan.github.io/assembly/x86/guide/2024/09/08/x86-...
For full disclosure, I am the author - apologies for the shameless plug
It's cool. Do you sanitize the untrusted input? As far as I can see, it directly assembles with NASM and runs the binary.
It might be similar to Matt Godbolt's experience with his "Compiler Explorer". Most of your users are not trying to set fire to the free system, and when somebody does, on purpose or by accident, you focus on being able to reliably recover, not prevent it. So e.g. maybe Clara T Vandal "cleverly" seizes control of a random Compiler Explorer build box, well, that box is no longer marked OK because of her changes, it gets automatically torn down and replaced, no real problem. Did Clara do 0.001¢ of Bitcoin creation without paying for it? Yeah, maybe, and Clara probably cost Matt 0.1 cents for the data centre fees but it's not a big deal.
Looking at the source code of the code-editor [1], it seems to be embedding https://onecompiler.com via the iframe and delegating code compilation and execution to it. So I guess it's a question to onecompiler, whether they sanitize input or not. :)
[1]: https://github.com/shikaan/shikaan.github.io/blob/main/_incl...
Exactly this.
I have been planning on trying to glue up something with v86[1] as I did in OSle[2] but I did not get to it yet.
In that case, everything would run locally and sandboxes, so you would not have to care.
[1]: https://github.com/copy/v86
[2]: https://github.com/shikaan/osle
Thanks, I'll be using this.
What I don't understand is why assembly feels so hard to learn in the first place?
I mean, isn't it just a simple language with a few function calls (instructions) and types (operand sizes) and fixed number of variables (registers) and a small number of control flow operators, and that's it? Why does it feel so mysterious?
I can think of several reasons:
1. You are primed to think that it is mysterious because that’s all you usually hear about assembly. (“Roller Coaster Tycoon was written in 100% hand crafted assembly… what an absolute wizard!!”)
2. The language’s textual format is odd - columns vs nested indentation. Actually really nice once you get used to it, but it’s definitely alien at first.
3. Mnemonics and directives have short, cryptic spellings. x86 in particular has arbitrary looking register names as well. RV, AArch64, m68k etc do better here.
4. Mnemonics are inconsistently overloaded and encode lots of stuff. SIMD instructions tend to look like a cat sat on your keyboard.
5. Manually laying out memory is technically simpler than the abstractions provided by higher level languages (structs and classes, fancy generic types, pointer syntax), but it’s fiddly and you have to deal with alignment.
6. You have to do a lot of bookkeeping yourself. It’s like malloc/free turned to 11.
7. Register allocation is a hard problem for computers. It’s kinda tough for humans, too.
8. Lots of books and online stuff discuss assembly for use with high performance code, tight compute kernels, raw hardware access, and fiddly CPU configuration for OS startup and virtual memory configuration. This requires even more specialized registers, arcane instructions, and bit fiddling. This stuff - along with reverse engineering and security research/attacks - gets lumped into what people think of as “assembly language”. The resulting concept surface therefore looks much larger than it actually is.
I highly recommend making a non-trivial program entirely in assembly at least once. I need to do it occasionally professionally but even when I don’t I usually have a hobby project or two cooking at home.
Becoming as proficient in asm as - say - C or Python is quite the lovely expression of craft. You feel like a wizard (see point 1) while simultaneously learning what’s really going on.
For people with a certain geeky disposition it pays lots of aesthetic, psychological, and professional dividends.
Simple languages are not necessarily easy languages to understand. See: brainfuck, APL, K, etc.
I think the problem with assemblers in particular is that the canonical definition is the byte code, not the human readable text. x86 is particularly annoying because no one agrees on the syntax of that text, there are hundreds of mnemonics, things are constantly being updated, and the practicing assembly programmer cares deeply about the execution semantics of the microarchitecture more than the specific sequence of instructions. Some of the language is also completely foreign to higher level programmers, like instruction pipelines, uops, instruction latency, and so on.
Rarely do you sit down and write this assembler by hand, you compile some C code and poke at it with vtune/uprof to measure hot sections of the code, break those down, and implement faster versions. It's fundamentally an iterative, experimental process.
It is simple until you need something complex - working on a team, call stack management, memory management (allocate, track, free), working on a team, event handling / non-synchronous interrupts, and working on a team.
For a little 8-bit microprocessor with program size < 8k it can be quite easy and even a joy. Anything else and your compiler will outperform you, better to inline hand-coded assembler as needed.
x86 assembly has many addressing schemes and a significant amount of historical baggage, even from its inception.
It's up to the compiler/programmer to handle calling conventions.
Modern programmers also don't regularly encounter "unstructured programming" in higher-level languages these days.
All of these, and more, make it feel overwhelming, as anything they examine through their disassembler will contain all of these elements.
(2020) Discussion at the time (180 points, 38 comments) https://news.ycombinator.com/item?id=24195627
Great opportunity to share an older project:
https://www.AssemblyArena.com - an educational game for people who would like to learn and/or program in assembly.
It's a (non mobile-optimized) web-based PvP assembly programming game. The syntax is highly inspired by x86 assembly and the game itself by Core War. There is also a small tutorial and a ranked ladder powered by Glicko-2.
Source Code:
https://github.com/m2w4/assembly-arena
Thankfully Intel syntax.
Now I'm curious - what other syntaxes are there?
The other one, is a clunky one from UNIX world point of view on x86 CPUs, follow the links on the sibling comment.
Rather clunky and most UNIX Assemblers were never as powerfull as other systems macro assemblers, since after UNIX System V, it was there only as an additional external tool pass for the C compilation steps, and even before that, the assembler was quite minimalist.
Then there is the whole brain twist of being used to op dest, src, and having to switch into op src, dest.
I prefer the Intel approach as it is more similar to dest = src, rather than src -> dest.
Intel's approach is also more common across various assembly languages.
I think the schizophrenic notation 12(%ebp) is much worse than the dest/src switch.
dest/src order is not a big deal in absolute terms: The ISA designer picks an order, documents it, everyone follows their documentation, done. Intel picks one order for programming Intel, DEC picks another order for programming the VAX? Great, just look in the instruction set manual and you're set.
The silly thing is importing one order to another architecture that uses the opposite order. Now your users have to transpose operands for no reason. The really silly thing is messing up the operand order of the cmp instruction in the process. The VAX assembly language had a compare with the sane operand order, BTW.
Yes, that is the cherry on top, maybe.
AT&T
* https://imada.sdu.dk/u/kslarsen/dm546/Material/IntelnATT.htm
* https://en.wikipedia.org/wiki/X86_assembly_language
It's always a great way to get a better understanding of things but at least just poking around assembly a bit once. You do not have to make a project or anything big, but do not be afraid to check it out.
I would imagine that ARM1 would be more approachable than just about anything else.
I understand that there were only 14 different instructions in the original design.
"The 386 has about 140 different instructions, compared to a couple dozen in the ARM1 (depending how you count)."
https://www.righto.com/2015/12/reverse-engineering-arm1-ance...
I tried optimizing my CPU emulator dispatch in raw assembly to see if I could run a simple fibonacci program faster than C++. And I was not even close. In the end I merged it and made it a default-disabled dispatch option, because ... there has to be a way to make it faster!
If you are daring, you can find my puny attempt here: https://github.com/libriscv/libriscv/blob/master/lib/librisc...
I did manage to improve it once I figured out some of the various modes of accessing memory, and I even managed to cut the jump table down from 64- to 32-bit which should help keep it in memory. I made the jump table part of .text in order to make it RIP-relative. For the fibonacci sequence program, not many bytecodes are needed. I would greatly appreciate some tips on what can be improved there.
> I made the jump table part of .text in order to make it RIP-relative
Did you do this manually?
gcc changed to put jump tables in .rodata always which causes problems when .rodata is stored in ROM.
It does have the `-fno-jump-tables` option but that just disables jump tables rather than allowing you to control where they go.
have you tried actually comparing what you have to what the c++ compiler generates? i don't have a lot of context here but I think it's possible that the difference is less due to the dispatch mechanism (i.e. how the next instruction is fetched) but due to the implementations of the instructions themselves.
one opportunity for optimization is mapping emulated registers to real x86-64 registers and basically never spilling them to memory (so that way if you have to add you don't have to first fetch then add, but just add directly). though that makes writing the emulator a lot more annoying.
Author here. The final part of this series is still sitting in my drafts.
It was nominally supposed to be about flow control instructions, but as it goes with those things, it spiralled and ended up touching on relocations, position-independent code, aslr... One on these days I'll clean it up and post it
Please do!
I'd love to fool around in assembly but I can't think of anything interesting to do with it.
I've found being able to read assembly more useful than writing it.
For those writing in compiled languages like C/C++ and particularly with an interest in performance it's been very helpful just to be able to read compiler output and see what it's generating. Takes the guesswork out of it, removing the uncertainty by simply being able to see what the compiler is actually doing. You can just write code and see the result, who knew!. It's actually helped my understanding of C++ in seeing the bigger picture.
Of course it's also much easier to learn just to read a little disassembly than actually write the stuff. I'm sure I'm not alone in that for me Compiler Explorer (https://godbolt.org) was my gateway into this. You can get quite far even if just knowing the basics (I'm no expert).
The software security community has a subsection that focuses on the security of compiled binaries, where understanding assembly has many uses. These uses include binary reverse engineering and proof-of-concept exploit development to demonstrate the severity of a vulnerability.
If these do sound interesting to you, I'd recommend looking into capture the flag (CTF) competitions, and trying reverse engineering or binary exploitation (pwn) challenges. PicoCTF [1] is an entry-level platform that hosts challenges and has references to learning resources - I believe there's a sequence on assembly in the learning resources.
Aside, I also find it useful to know assembly when debugging C/C++ code, as others have suggested.
[1] https://play.picoctf.org
Yeah I think the only things that really need assembly these days are vector/SIMD (e.g. writing a video codec), really low level stuff for interacting with hardware (writing an OS) or if you're actually working on CPUs (how I learnt).
It's kind of useful for understanding compiler output on godbolt, and occasionally for debugging code without debug info.
But I successfully wrote a ton of C++ for decades without knowing assembly. It's not really necessary.
Assembly is one of those things where setting your ambitions higher than is usually advised can be wise.
You could try writing a game (perhaps using Raylib) or a pixel art editor. Or maybe a little web application for your Homelab.
Simple C libraries (Raylib, libcurl, early win32 APIs) tend to be dead simple to use from assembly.
Most asm tutorials are either bare metal / OS or “we will talk directly to the kernel”, but there’s no reason you can’t interface with higher level libraries and make real apps and games. It’s simpler than it sounds because a whole lot of your code will just be moving things around between registers and memory in order to make function calls and bookkeep your program state.
In embedded systems using MCUs with very little memory (AVR comes to mind) assembly might be preferred over high level languages (very generously counting C as HLL here). It might even be fun (for truly launch-and-forget projects -- don't even think about maintaining such code) to forgo structured programming and get creative with control flow and self-modifying code.
As a systems engineer it's good to know _some_ x86-64 assembly as sooner or later you're facing a stack trace / register dump and will have to try to make sense of it. Personally, I would take it only further, if you're interested in building compilers.
As an odd twist to the whole assembly vs. HLL dichotomy, sbcl is used by some as assembly playground: https://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-co...
FFmpeg uses assembly and they use it so extensively that they put up their own assembly tutorial: https://github.com/FFmpeg/asm-lessons
Maybe there is something to do there (I haven't checked).
Microcontroller and LEDs. And maybe buttons. Keep it to 8-bit and chances are you'll be able to navigate the ISA comfortably pretty quickly.
TIS-100 is a fun little game where you have a sort of pseudo-assembly and solve puzzles with it. I find it can help scratch that itch.
I would also recommend TIS-100's "sequel", Shenzhen I/O. TIS-100 is a bit 'dry', with the puzzles being entirely abstract. In SI/O, you roleplay as a developer emigrating to China for work, so all the puzzles are framed as real products you are developing for your company. One of the earlier puzzles, for example, is programming the equipment for a lasertag place.
I second the Shenzhen I/O recommendation, because apart from only assembly programming, the game also has other constraints in the form of having to spacially arange various chips on a limited "enclosure" for the product you're building and connect them. It also rewards optimization both in terms of assembly and chip usage efficiency. Is a wonderful game, really.
It also has a really cool solitaire game-in-game as an... addition? Ornament?
I will reveal that I have played far more of Shenzhen solitaire than Shenzhen I/O itself. Zachtronics made a stand-alone version of the game[1], but there's also a fanmade version here:
https://shenzhen-solitaire.tgratzer.com/
Which I find more enjoyable, both because it's online so it's easier to reach from anywhere, and also because I feel like the version of the solitaire inside the game is a bit... heavy feeling. Like there's some sort of input delay? Anyhow, I must have around 3000 completed games of solitaire across my devices.
[1]https://store.steampowered.com/app/570490/SHENZHEN_SOLITAIRE...
>> Additionally, the higher 8 bits of rax, rbx, rcx and rdx can be referred to as ah, bh, ch and dh.
Did you mean “ax, bx, cx, dx”?
ax, bx, cx, dx are 16 bit registers referring to the lower 16 bits of rax, rbx, rcx, and rdx respectively. Bits 0..8 can be referred as al/bl/cl/dl, bits 8..16 as ah/bh/ch/dh.
It's ambiguous, but I believe the comment you are replying to suggests that the sentence should read:
>> Additionally, the higher 8 bits of ax, bx, cx and dx can be referred to as ah, bh, ch and dh.
Those would be the lower 8 bits, no?
In a 64 bit register, e.g., RAX, AL refers to the lowest 8 bits [0-7] and AH refers to the next 8 bits [8-15].
Together, AX refers to bits [0-15]. EAX refers to [0-31].
It's counterintuitive (or at least, inconsistent) that we have a name for bits [8-15] but not for [16-31] or [32-63]. My fuzzy understanding is that this came about from legacy decisions.
This page has a helpful visualization at the top: https://www.cs.uaf.edu/2017/fall/cs301/lecture/09_11_registe...
It's neither. al is the lower 8 bits of ax (ah the higher 8 bits). ax is the lower 16 bits of eax. eax the lower 32 bits of rax.
Here's the AMD manual: https://docs.amd.com/v/u/en-US/40332-PUB_4.08
ax=ah:al eax=?:ax rax=?:eax
For FASM, I really like https://flatassembler.net/docs.php?article=manual.
There are a couple of great books out there as well that I have used. I cannot recall their names right now. :(
This is the kind of introduction I was looking for! I'm currently learning a bit more about this instruction set, so that's perfect.
Also, there are so many great resources in the comments.
I came to the party way to late. A month ago, I found out asmjit was a thing, and now it's happily embedded in my app. But I don't know assembly! I tried to learn a few times since the early 2000s but the timing was never right. But hand written asm as a feature fits perfectly into my upcoming app, so now I am on a roll learning assembly! Here are some more resources I found so far:
https://news.ycombinator.com/item?id=22279051
https://sonictk.github.io/asm_tutorial/#introduction/setting...
https://cs.brown.edu/courses/cs033/docs/guides/x64_cheatshee...
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
https://learn.microsoft.com/en-us/cpp/build/x64-calling-conv...
Here's a really good free one:
OpenSecurityTraining2 Architecture 1001: x86-64 Assembly
https://p.ost2.fyi/courses/course-v1:OpenSecurityTraining2+A...
They also have RISC-V and many other for debuggers and reverse engineering tools (ida/ghidra for example)
Spectacular post, are you planning to add sections on reverse engineering executables because this definitely looks pretty close
(i am the author) not to this series, but the very first post on the blog is an example of a simple reverse-engineering exercise: https://gpfault.net/posts/ripping-sprites-from-super-cyborg....
From the profile picture I thought that was junferno for a second.
I wish there were more articles and resources about modern ARM assembly. Not that I ever will or have programmed in Asm, but I like learning about it and imagining I will, and Intelisms feel so archaic and crusty in comparison.
https://shop.elsevier.com/books/computer-organization-and-de...
It's currently 50% off and not only will you learn ARM, and some history about ISAs in general, but you'll learn more about how the computer itself works.
And if ARM isn't a hard requirement, an older edition that uses RISCV as the core ISA is a free download.
https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/books/H...
Highly recommended.
The first link was the textbook I used for my computer architecture course last semester and I concur. This was the first time our professor taught ARM instead of x86_64 because he believes ARM is the future.
I learned on the MIPS processor, computer organization / architecture one of the most challenging CS courses for me. I don't remember much but I definitely remember the mips pipeline...
This is my own channel, but I made a 10+ part series on modern ARM assembly you may find interesting. I used CPUlator for the demonstrations, which is a nice way to inspect the memory as well as the individual registers as you are running a program.
All runs in the browser:
https://youtube.com/playlist?list=PLn_It163He32Ujm-l_czgEBhb...
Thanks for your work on this. I’ve bookmarked several of these videos and used them as reference.
Learning assembly with a really good visualizer or debugger in hand is highly underrated; just watching numbers move around as you run your code is more fun than it has any right to be.
I really like Justine Tunney’s blinkenlights program. (https://justine.lol/blinkenlights/)
A version of that for AArch64 / RISC-V would be really cool.
Any reason for ARM specifically? There are a lot of microcontrollers out there that fairly simple but without Intel's crustiness. Atmel, for instance. And if you decide to actually try experimenting with them you can get yourself set up for it for less than $100.
I'm learning AArch64 assembly in the process of writing a code generator for it. godbolt.org is a great resource for "how do I do this?" Write a short function, run it through godbolt.org, see the instructions generated, lookup the instructions in the spec:
https://www.scs.stanford.edu/~zyedidia/arm64/encodingindex.h...
It'll be my keynote presentation at the D conference next month.
The first HN link in my comment addresses that. The short version: learn the earliest asms first, then progressively learn the newer ones until you get to today, and none of the knowledge will be wasted. Kind of like fast-forwarding.
I wouldn't say you are wrong, but I would also postulate.
The smallest, simplest, 'useful' (in terms of useful enough that lots of devs did good work with it and thus it might also be 'popular') ASM sets are probably also sufficient to start with. Provided you've got a good guide to using them, and also ideally a good sheet for why given instructions are packed the way they are in binary.
I do agree you're more likely to find pointers to such resources in more classic architectures. They're also more likely to be easy to find free copies of useful literature.
I'm not sure how "useful" or "good" the work is. But some one instruction computers have a considerable amount of tooling already in place.
i.e. https://esolangs.org/wiki/FlipJump
Flip Jump is amazing. I understand the theory and how it works but it still amazes me that it does. Things like this is why I love the science in computer science.
And subleq even has a c-compiler and operating system, just wow. https://en.wikipedia.org/wiki/One-instruction_set_computer#S...
I think AsmGrid has a great overview of X86 and AArch64 instructions:
For x86 encodings, there’s also http://ref.x86asm.net/index.html and of course the venerable https://sandpile.org/.
Felix Cloutier's page has always been my go-to
https://www.felixcloutier.com/x86/
I haven’t seen this site before. Thanks for sharing it.
wow, that's great. thanks for sharing!
Let's learn RISC-V assembly!
- https://en.wikipedia.org/wiki/RISC-V_assembly_language
- https://asm-docs.microagi.org/risc-v/riscv-asm.html
- https://riscv-programming.org/
- https://github.com/riscv-non-isa/riscv-asm-manual
AArch64/Arm64 assembly:
https://mariokartwii.com/armv8/ch11.html
I remember a book on amd64 assembly which used GNU/Linux and NASM as the base. It has exercises to follow your progress:
http://www.egr.unlv.edu/~ed/assembly64.pdf
I had quite entertaining session with ChatGPT and recursive fibonacci in nasm. We found out that C-version was twice as fast. So no returning back to year 1975.
"Higher language version is easier to optimize, because machine gets better idea what you are aiming at." said Lex Fridman et al.
Why 1975, when high level programming exists since 1958?
Also I should note that until early 1990's, C compilers were quite bad, that is why we wrote what would be now AAA games, in straight Assembly.
Ive heard this for thirty years and it is as wrong now as it was then.
Yes you need to be good at assembly (especially data oriented architecture), yes it takes forever, but that is no excuse to spew falsehoods.
correct, understanding the instruction set architecture you are working with is required for reasoning about the performance of a given algorithm in detail.
you will likely not be writing a lot of assembly by hand, however steering the compiler codegen in the right direction requires an understanding of what the compiler produces.
even outside of enhancing performance, knowledge of instruction sets is instrumental for security research and reverse engineering. for some fun but practical demonstrations, see work by Nathan Baggs on YouTube - it involves staring at a lot of disassembly.
i don't know where this misguided notion that assembly language is "1975" comes from. it's not like Cobol where a few large but important systems keep it alive. this is something that lies at the core of every interaction with computers that you have daily.
What? Did I just give you an example that it is true?
Natural language is the highest of course. We will return to assembly programming eventually, because those intermediate "highlevel" languages are not needed anymore between you and machine.