I have not used FASM so I can't comment on it, but there are quite large differences between assemblers in general. Each is essentially a (non-optimizing) compiler for a different extension language. Writing your own assembler that literally just assembles is trivial, but writing raw assembly instruction by instruction is tedious and not especially practical. If you're serious about writing it, you'll want macros and other forms of metaprogramming; as a programmer, the entire point of your existence is to automate tedious, repetitive tasks, and better assemblers help with that. Programming your own assembler is a natural progression of metaprogramming if you stick with assembly long enough, but first you should learn with using an existing one so you can begin to understand your own workflow well enough to know what tools you want for reducing repetition and where the existing one falls short.
Here’s an archive.org mirror of the broken “Why no one should use the AT&T syntax ever, for any reason, under any circumstances” link: https://web.archive.org/web/20251128060318/https://outerprod...
Anyone noticing some pretty heavy skill atrophy from all the Claude/Codex use in the last few months?
I feel like this is a great way to get back to basics and keep the eng skills sharp. Maybe I should try something similar...
I wouldn't call it "atrophy" unless you were already reading and writing Asm regularly.
Why would one choose NASM over FASM? The makers of KolibriOS (an OS written entirely in assembler) chose FASM but the reason eludes me.
To me all assemblers look alike and it would even be feasible to write one's own just for the heck of it.
I have not used FASM so I can't comment on it, but there are quite large differences between assemblers in general. Each is essentially a (non-optimizing) compiler for a different extension language. Writing your own assembler that literally just assembles is trivial, but writing raw assembly instruction by instruction is tedious and not especially practical. If you're serious about writing it, you'll want macros and other forms of metaprogramming; as a programmer, the entire point of your existence is to automate tedious, repetitive tasks, and better assemblers help with that. Programming your own assembler is a natural progression of metaprogramming if you stick with assembly long enough, but first you should learn with using an existing one so you can begin to understand your own workflow well enough to know what tools you want for reducing repetition and where the existing one falls short.
Using GDB to debug Asm is... certainly a choice.
Why? Back in the day, after the pain of debugging on Timex, and MS-DOS debug, the confort of Turbo Assembler debugger felt really nice.
Gdb is an excellent debugger for assembly, even when the original code was written in C
I would automatically type
(gdb) x/4i $pc
when opening a coredump out of habit.
But using nasm, then looking as gas style assembly in the debugger might be a bit more jarring.
What's the better choice?
Setting a breakpoint in the debug registers DB0 through DB7 and dumping registers and memory in your own debug exception handler.