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.
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).
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.
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.
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.
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
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).
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.
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.
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...