Do you even do any of the hex math when writing actual code in assembly?
I understand when you use something along the lines of a disassembler that requires you to actually see the addresses of the values. But even these are sophisticated enough to give you symbolic values instead.
A lot of my hobby programs are emulators or parsers for old file formats (think DOS-era games). Bitfields become important, and they're more convenient to express in hex than in decimal.
There are times where it feels convenient to express things in decimal and times where it seems better to use hex.
>Do you even do any of the hex math when writing actual code in assembly?
There are multiple reasons why it is useful or convenient to deal with data (whether memory addresses, data values, colors, etc.) in hex (including doing math on such hex values).
As I said in another comment in this thread, I have not done a lot of work in assembly language; but have done enough and read enough about it to know that it is useful, and not just a cool or retro thing that developers do.
The fact that two hex digits compactly represent a byte, the fact that one hex digit can represent a nibble/nybble [1], the fact that machine registers on devices attached to computers (such as printers, scanners, any other electro-mechanical equipment with a computer interface) are used to programmatically read and write data to and from those devices, and thereby get their status and manipulate and control them, are some of the reasons why hex and hex math and bit-twiddling in hex and binary is useful and still done.
Depends on what kind of applications you write in assembly (or even C), I guess.
I understand when you use something along the lines of a disassembler that requires you to actually see the addresses of the values. But even these are sophisticated enough to give you symbolic values instead.