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