RFA: distinguish between pointers and addresses
Jim Blandy
jimb@zwingli.cygnus.com
Tue Apr 11 14:24:00 GMT 2000
> > + 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 :-)
I've changed it to:
For example, the Mitsubishi D10V is a 16-bit VLIW processor whose
instructions are 32 bits long@footnote{Some D10V instructions are
actually pairs of 16-bit sub-instructions. However, since you can't
jump into the middle of such a pair, code addresses can only refer to
full 32 bit instructions, which is what matters in this explanation.}.
Is that better?
> > + 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.
Yep.
> I think the changes look ok.
Okay. Thanks for looking them over!
More information about the Gdb-patches
mailing list