Almost all embedded firmware is written in C or C++ today, and yet every embedded engineer still reads assembly. It appears in the startup code that runs before main(), in interrupt handlers that must finish in a few cycles, in the disassembly window when a crash has to be understood, and in the listing files that show what the compiler actually did with a loop.
Where assembly is still written
Reset vectors and the first instructions after power-on, which set up the stack pointer and memory before any C can run. Context switches in a real-time operating system, which save and restore every register. Cycle-exact bit-banging of a protocol on a microcontroller with no hardware peripheral for it. DSP inner loops that need the multiply-accumulate and zero-overhead loop instructions the compiler will not always find. Everything else is C, with compiler intrinsics filling most of the remaining gaps.
From source to object code
The assembler translates mnemonics into machine code one instruction at a time and produces an object file: machine code arranged in sections (typically .text for code, .data for initialised variables, .bss for zeroed variables), a symbol table and relocation records that say which addresses are not yet known. The linker then combines object files, places sections at real addresses according to a linker script that describes the target’s flash and RAM, resolves the relocations and writes the final image, usually as ELF for debugging and as a raw binary or Intel HEX file for programming.
Reading what the compiler did
Most toolchains can emit a listing that interleaves C source with the generated assembly (for GCC, -S or objdump -S). Reading it answers the questions that matter in embedded work: did the loop get vectorised, did the volatile variable really get read every time, how much stack does this function use, and why is the interrupt handler 200 instructions long. The map file from the linker answers the other question: where did all the flash go.
Toolchains today
GCC and the LLVM-based Clang cover ARM Cortex-M and -A, RISC-V, and most other cores; vendor toolchains from Arm, IAR, Texas Instruments and Microchip remain common where certification or the last few percent of code size matter. The instruction set reference for the target processor is the one document worth keeping open.