Copyedits only; no technical content added. Changes:
- subject-verb agreement: "idea of registers were introduced" -> "was"
- "operate as the speed" -> "operate at the speed"
- fixed ungrammatical "typing as apart from X, Y is Z" (now "typing:
apart from X, Y is Z")
- comma after "x30" in list; replaced misleading claim "x31 is also
not available" with "x31 has a special role (explained later)".
x31 is not unavailable -- it encodes SP or XZR depending on
instruction context, which the earlier phrasing obscured
- "hundreds of instructions each potentially has" -> "each potentially
with" (agreement)
- "an mnemonic" -> "a mnemonic" (/n/ is a consonant sound)
- "a concrete examples" singular/plural typo
- de-duplicated back-to-back "For example" in Mixing Register Types
Rejected: leaving the "x31 is not available" line alone -- it's an
intro chapter, but "not available" reads as "doesn't exist", which
will contradict later chapters that use SP and XZR. Kept other
simplifications (informal "that big of" phrasing, stylistic comma use)
untouched.
Part of #33.
The v6.S listing in the hello_world chapter introduces the PUSH_P,
PUSH_R, POP_P and POP_R macros without explicitly telling the reader
what the _P and _R suffixes stand for. For a reader reading the
chapter in order, the mapping is derivable: the book established
stp = "store pair" about 260 lines earlier, and the _R suffix falls
out by parallel with str. But a reader who jumped straight to v6.S
without reading the stp explanation (as Atcold did in issue #33) has
no such anchor and is left guessing.
One sentence at the "The push and pop macros simply save typing"
paragraph closes the gap: it names the _P / _R suffixes, connects
them to the already-taught stp / str convention, and costs a skimmer
nothing. The macro names themselves are unchanged; they were already
fine for an in-order reader, and renaming would have churned every
.S file in the book.
Closes#22.
The alignment chapter's hex dump examples (e.g. "0011 eeff ccdd aabb"
for a little-endian long initialized to 0xaabbccddeeff0011) are correct
under the default hexdump(1) output convention: bytes grouped into
16-bit little-endian words, each word printed most-significant byte
first. But the chapter never told the reader which convention was in
use, so a reader reproducing the example with xxd or hexdump -C (both
byte-oriented, showing raw memory order) would get a different-looking
result and conclude the book had an endianness bug. That is exactly
what issue #22 reported, and it is also part of what the #33 filer
flagged as "there are no instructions about how to do such a thing"
for hex dumps in this chapter.
Fix: one new subsection "A Note on Hex Dumps" placed before Example 1,
stating the convention explicitly and warning xxd / hexdump -C users
that the bytes within each pair will appear swapped relative to the
examples. The examples themselves are unchanged; they were already
self-consistent under the word-oriented convention.
Rejected alternative: rewriting all the examples in byte-oriented
(xxd) form. That would have matched what most modern readers reach
for, but would also have required regenerating every hex dump in the
chapter and losing continuity with any reader who already absorbed
the current notation. A single explanatory paragraph is less invasive
and teaches the distinction, which is useful in its own right.
No test coverage applies; this is prose.
