You'd be surprised how often knowing assembly can come in useful - I certainly never expected it. I work in the healthcare sector, which is infamous for having tons of legacy software. At least a couple times a year I end up finding it useful to load some ancient binary into radare2 or Ghidra for debugging, extracting data, or just adding a jmp to avoid a problematic syscall. I'm by no means an assembly expert, but know enough to get the job done.
Yup. I've not used assembly at work, but it's come in useful at home. A couple of times, I've had to insert or adjust JMP commands to get legacy software to function.
Small embedded systems. There are microcontrollers that cost like 3 cents in bulk. 8-bit machines with a few kilobytes of PROM and perhaps just 64 bytes of RAM. While such machines often do have C compilers (of a sort) for them, old-school optimization techniques sometimes come into play.
I used to enjoy that stuff, but these days if it seems like a job requires any significant assembly, I just turn it down. I hate worrying about every single byte of memory, it takes all the fun out for me, but I do know those who love figuring out a tough problem and always having to be efficient with every bit and byte.
There are tough problems at every layer of the stack. Granted, the problems look very different, but they’re no less challenging. I think that is one of the great things about being a software developer - wherever you look, there are interesting things to explore. I studied assembly some 20+ years ago and have barely seen it since, though I’ve worked on a lot of complex technical problems since then.
That's me. I love figuring out more memory-efficient or less-cycle-use ways to do the same thing on my microcontrollers. Save x bytes here to add new feature y. Maybe it's nostalgia for an era of programming I missed out on (80-90s DOS game development)? Or it just scratches some itch in my brain.
Heh, different strokes for different folks. For me, the closer I am working to the metal, the more I enjoy the work. I especially enjoy squeezing every drop out of the system, so worrying about every byte, and minimizing cycles, is part of the fun.
Anything where you get crash reports back from the field. It is very valuable to be able to read assembly code and map registers to their purpose, and then perhaps back to the source code that generated the assembly. Debuginfo will sometimes give you some of that, but is unreliable, incomplete, and can be hard to match up to the stripped binary you're looking at. Recognizing values that are likely to be stack vs uninitialized or poisoned vs corrupted vs nullptr or offsets to nullptr... it can turn a crash report from absolutely cryptic into something that gives you the lead you need.
(Also, if you are dealing with something with mass deployment, it's good to recognize the single-bit flips that are hallmarks of bad RAM. But don't assume too much; bit flips are also the sign of bit flag manipulations.)
According to friends reading is still fairly prevalent for Windows and other products at Microsoft. Kind of a requirement to succeed in jobs with a C/C++ product where you might only have memory dumps to debug. It's also expected to some extent if you are a performance guru in some areas.
Any sort of performance engineering will likely require competence with assembly, although direct programming in assembly may be relatively rare in such roles.
Portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains. See also the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...
Why wouldn’t it be?
Compilers haven’t advanced tremendously in the past two decades in terms of optimizations and don’t have much new to add to high performance SIMD numeric kernels.
Yeah. I'm going to be helping to work on expanding CI for OpenBLAS and have been diving into this stuff lately. See the discussion in this closed OpenBLAS issue gh-1968 [0] for instance. OpenBLAS’s Skylake kernels do rely heavily on intrinsics [1] for compilers that support them, but there's a wide range of architectures to support, and when hand-tuned assembly kernels work better, that's what are used. For example, [2].
FWIW I've found that compilers' code generation around intrinsics is often suboptimal in pretty obvious ways, moving data around needlessly, so I resort to assembly. For me this has just been for hobby side projects, but I'm sure people doing it for stuff that matters run into the same issue.
Not always the case. You're not writing it all the time but you still have to write it. For example the trampoline I use to jump from the boot stage to the kernel entry point is common-mapped between the two memory spaces and performs the switch inside of it, and then calls the kernel. That's all in assembly.
Developing hardware diagnostic utilities can be another area.
The kinds of utilities that come built into ROM, or that you run from a CD or USB drive, where you test memory and disk by writing different bit patterns to them, reading them back, and checking if they match, probing the hardware, processor and peripherals, etc.
Apparently there's been some renewed interest in the Game Boy Advance as a platform for indie development (as well as other retro platforms). Programming on those requires some assembly knowledge, though I'm not sure you could call that a job.
Some software packages written in assembly during the 70s and 80s are still in production today, and may be difficult and expensive to replace.
I did some contract work for a steel plant in 2018. The primary control system for the plant was written in assembly. They were in the middle of doing a full rewrite, but in the meantime, they had to do maintenance and bugfixing for the in-production system in assembly.
> What sort of jobs are there these days that use assembly? Is anybody still using it directly
I use assembly on the regular in my embedded systems work. It lets you get away with using a lower-spec (and therefore cheaper) microcontroller than you could otherwise.
I've worked at a place where the core system was still 10% or so assembly (it was written in the 1970s). I'm not sure if it needed much modification but it was absolutely business critical.
Writing it from scratch is not nearly as common as reading it and understanding it. I think pretty much every systems programmer will have to stare at disassembly output from time to time.
It's the difference between being a script kiddie and an actual hacker/cracker. Any web search will turn up thousands of links on hardware hacking at all levels.
That's not really what I'm asking, though. Parent claimed "high-level malware development" happens in ASM, but as far as I know a good chunk of sophisticated malware (stuxnet, wannacry, etc.) are written in plain ol' C or C++, so I categorically disagree that the differentiator between "script kiddie" and "leet haxor" is in whether or not someone writes assembly.
But I'm interested in reading about malware written in assembly and was hoping for a diving board into that particular pool.
> as far as I know a good chunk of sophisticated malware (stuxnet, wannacry, etc.) are written in plain ol' C or C++, so I categorically disagree that the differentiator between "script kiddie" and "leet haxor" is in whether or not someone writes assembly.
Indeed. It's also useful to differentiate between malware and exploits (although the former often includes the latter). Exploits it's common to use assembly when finding and developing the exploit, but unless you're severely byte constrained you're just gonna use tools to generate your shellcode instead of hacking it out by hand. Even then there are tons of pre-written shell code snippets you can reuse from places like metasploit. The number of jobs where you're paid to write an exploit are small unless you can get on an elite team in a government agency (or contractor). Malware on the other hand is mostly just written in higher level languages like C
Check out the legendary Poc||GTFO articles: https://pocorgtfo.hacke.rs/ they are a treasure trove for this sort of information.
High level hacking requires assembly because you're trying to reverse engineer opaque APIs that aren't meant to be interfaced with. What other way is there to do that other than trying to examine what things are being moved to which memory addresses
These are pretty non-specific, but these are area I know about already for others who may have the same question as me:
1. Compiler development
2. Security research (malware analysis/reverse engineering) - although not much if any writing assembly, just reading
3. Kernel development - again mostly just reading assembly, not writing it. Bulk of code written in C (or potentially a very recent development, rust)
4. Driver development - mostly C but some devices can involve assembly