How is a tword ten bytes instead of 20?

Question

So I was trying to find out the sizes of zword and yword when I stumbled upon this helpful thread which had the list of all sizes, but one thing confused me. It says in the edit that a tword is 10 bytes, but that.., doesn't really make sense to me. A word is two bytes, so a tword should be 10 words AKA 20 bytes, no? I found it even more weird that an oword was indeed 8 words/16 bytes, so an oword is actually larger than a tword. Is there an explanation for this odd choice of naming?

Answer 1

In NASM, all the things larger than 1 byte are *WORD, e.g. yword for the size of a YMM vector. (@Michael noted this in comments; sounds like an intentional pattern to me.)

This leads to the silly name of TWORD, a ten-byte thing made of words? Don't think too hard about breaking the name down into its parts, but that's probably your best bet if you can't help it.

TBYTE used by MASM / TASM (and GAS .intel_syntax according to objdump -drwC -Mintel) makes more sense as a meaningful / sensible name. NASM certainly wanted a T in the name for some consistency with existing assemblers.

Alternatively, @fuz suggests that T stands for "temporary", as the primary intended use-case for x87's extra precision vs. IEEE binary64 double is as temporaries during computations. Usually (for that use case) they can just live in registers, but sometimes you might want to spill them. And of course you can use them as long double extended precision with (significantly) worse load/store performance than double, or have constants in that format. See also Bruce Dawson's Intermediate Floating-Point Precision article for more real-world x87 and compiler stuff, part of an excellent series.

---

NASM has directives like resb / resd / rest / ... / that reserve space (for use in the BSS), and db / dd / dt / .... They only have 1 character for the size, and other than Byte and Word it's basically a size code. And unlike MASM, there's no DWORD directive you can use as an alternative to DD, so the "size code" is relatively more important, and the thing it's stuck onto is more regularized.

Of course NASM does already have to parse BYTE and WORD as operand-size codes, so it's hard to imagine TBYTE would have actually made the parser measurably harder to write or maintain. (As one answer on the Q&A linked in the question shows, the disassembler or something in NASM has a switch where each string is fully separate, not %cWORD for sizes > 2, but parsing could still be different.)

This seems like a plausible theory behind NASM's designer(s) wanting to stick to the *WORD pattern, but I have no information on it and didn't go looking for any mailing list docs. IDK if NASM was designed collaboratively in public, or if it was pretty much the original author. Either way I'm guessing it seemed like a good idea to someone in the early days of designing the syntax.

---

FASM apparently supports both TBYTE and TWORD names for the same size, but NASM only supports TWORD. Adding a new reserved / special keyword to the language could perhaps have broken backwards compat with code that inadvisably used TBYTE as a symbol name, or maybe NASM developers just never even wanted to change.