Re: WIP: Register doco

[Jim Blandy <jimb at redhat dot com>]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> So "hardware" is as problematic as "physical"?  What you're telling me
> is that I should avoid all such terms, right?

I'm saying that they're unhelpful terms in drawing a distinction
between cooked and raw registers, and that a better approach would be
to provide examples of how the distinction allows GDB to cleanly
describe one or two well-known architectures.

In situations where the contrast being drawn is obvious, "hardware"
and "physical" are fine terms.  For example, if one were writing about
how stubs return from exceptions they've trapped, one could talk about
the necessity to restore the values of the "hardware registers" from
the stub's working copy.  There it's clear.

But in the present discussion, neither the raw and the cooked
registers are closer to the "hardware" --- they both describe entities
that have some reality in the "hardware".  So the term isn't helpful.
It's a public placeholder for a private intuition.  It lets the writer
think they've made their point, while leaving the reader in the dark.

> If this section needs an example then (given MarkK's observation about
> the i387) then either d10v's two stack pointers or the SH's bank
> registers.  Neither of these are especially complicated.

But... but the IA-32's FP and MMX hair is, like, the canonical
motivation for the cooked/raw distinction.  You've said repeatedly
that a GDB developer needs to understand this distinction.  That makes
it a *good* example, right?  I think it's one of the best ---
especially since it's something familiar to a lot more people than the
d10v and the SH.