Assembly Nights (2021)

If "historical" UNIX is one's focus, then need to be able to read (and edit) ATT assembly

The author claims Intel syntax is ubiquitous. True. But so is "historical" UNIX

Long rants about asm syntax are old, tired tropes. Perhaps they are entertaining to beginning programmers but today such rants achieve nothing except to put the sanity (and hence the judgment) of their authors into question

The existing ATT syntax assembler in "historical" UNIX source trees will not be translated it into Intel syntax

By all means, _use_ Intel syntax^1

But if "historical" UNIX is one's focus, comfort with _reading and editing_ ATT syntax, despite all of its alleged flaws, will continue to be useful

1. The author's own footnote:

"You can tell GCC to use Intel syntax for its inline assembly with -masm=intel. This doesn't work with Clang; complain to them. (Or just don't use inline assembly; it's usually not a great idea anyway.) For objdump, pass -Mintel. And for gdb, put set disassembly-flavor intel in your ~/.gdbinit."

Perhaps some HN readers might like this:

https://raw.githubusercontent.com/pirate/assembly-repl/main/...

https://github.com/pirate/assembly-repl

(requires clang)

Literally came here to post this, thank you

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.

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.

It's very common to use GDB with Asm, but only when combined with some plugins. Nowadays this is mostly done when reverse engineering software, or when testing low-level memory corruption exploits.

The screenshots of this popular gdb plugin are a good example: pwndbg.re/stable/features

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.

I've been writing a lot of assembly over recent months (the runtime routines for a lisp compiler, and of course debugging the generated assembly my compiler emits itself).

Mostly all I do is run a backtrace from the segfaults, and otherwise single-step through the code to verify my assumptions.

GDB has sufficed pretty well, though I admit I spent a long time writing the stop&copy garbage collector, and tracing through it trying to understand why I was getting segfaults.

I'm sure there are better tools, but for simple debugging it was sufficient.

What's the better choice?

We had better tools 30 years ago when pure assembly work was more common. You'd often run in the debugger by default.

Yet GDB lives on

I wouldn't call it "atrophy" unless you were already reading and writing Asm regularly.