RFA: distinguish between pointers and addresses

[Andrew Cagney]

Jim Blandy wrote:

> Index: gdb/doc/gdbint.texinfo

> + For example, the Mitsubishi D10V is a 16-bit processor that uses 32-bit
> + instructions.@footnote{Some D10V instructions are actually pairs of
> + 16-bit instructions, but you can't jump into the middle of a pair, so
> + they're effectively 32-bit instructions, for the sake of this
> + discussion.}  If the D10V used ordinary byte addresses to refer to code
> + locations, then the processor would only be able to address 64kb of
> + instructions.  However, since instructions must be aligned on a
> + four-byte boundary, the low two bits of any valid instruction address
> + are always zero --- byte addresses waste two bits in every address.  So
> + instead of byte addresses, the D10V uses word addresses --- byte
> + addresses shifted right two bits --- to refer to code.  Thus, the D10V
> + can use 16-bit words to address 256kb of code space.

Perhaphs ``the Mitsubishi D10V is a 16-bit VLIW processor that has a
32-bit instruction word''.
(The 32 bit instruction can be issued as a single operation or two sub
operations processed sequentially or in parallel but that sort of detail
is distracting :-)

> + However, this means that code pointers and data pointers have different
> + forms on the D10V.  The 16-bit word @code{0xC020} refers to byte address
> + @code{0xC020} when used as a data address, but refers to byte address
> + @code{0x30080} when used as a code address.
> +
> + (The D10V also uses separate code and data address spaces, which also
> + affects the correspondence between pointers and addresses, but we're
> + going to ignore that here; this example is already too long.)

Thats the other half of the problem - segmented archtectures.  The D10V
cheats and maps segment:offset onto CORE_ADDR.  That is another problem
again.

I think the changes look ok.

	Andrew