Re: D10V_MAKE_IADDR / D10V_MAKE_DADDR / GDB_TARGET_IS_D10V

[Michael Meissner <meissner at cygnus dot com>]

On Mon, Jul 24, 2000 at 12:14:35PM -0500, Jim Blandy wrote:
> 
> I think ADDRESS_TO_POINTER and POINTER_TO_ADDRESS should make all that
> D10V stuff unnecessary.  Check out my previous post to
> gdb-patches@sourceware, which I've included at the bottom; it explains
> what I think needs to be done.  Please call me if you've got
> questions.
> 
> Furthermore, since the actual processor that needed these macros was
> secret, I used the D10V as my example when I documented the macros in
> gdbint.texinfo.  There's a whole section explaining how to use them,
> not just the usual per-macro descriptions: see the section called
> `Pointers Are Not Always Addresses'.  So it's all explained in a
> several different ways.

One thing that you may want to keep in mind is that it may not just be text
vs. data.  I once wrote a C compiler for a machine that 4 different pointer
formats (pointers to 16-bit words, pointers to bytes, and 2 different bit
pointers).  The original machine in the family did not have byte addressing at
all, and so when they hacked in byte addressability, the byte pointer was the
word pointer shifted left one bit (losing the top bit, which was an indirection
bit, and not used for the address itself).  IIRC, there are DSP chips that have
two different memory banks that use different instructions to reference each
different bank.  Of course, without type information, it makes:

	(gdb) x/10i 0x1234

rather difficult (though given the text/data duality of the d10v, I would argue
that x/i be treated as a text pointer and x/[dxo] be treated as a data
pointer).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482