This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: harvard architectures - the d10v

David Taylor writes:
>I feel that a user address should always mean the same thing.
>And that, for example,
>    x/x 0x12345678
>    x/i 0x12345678
>should both read the same set of bytes from the target.  That the
>interpretation of 0x12345678 -- as a specific location within a
>specific address space -- should not depend upon whether the user
>typed /x or /i.  That it should not be the case that one returns
>something from the data space and the other from the instruction

Agreed.  The way I would extend this is to name the address space
you want the address to refer to.  Without claiming this is
the best syntax/wording/etc., maybe something like

x/x insn:0x12345678
x/i insn:0x12345678
x/x data:0x12345678
x/i data:0x12345678

- there could be a default address space,
  or target could specify that "x/x 0x12345678 is an error
- users of targets without address spaces would see no change
- I would treat the address space names as target specific

Implementation-wise, this would get translated to a CORE_ADDR
that had two parts: address space id, and address.
Obviously, you really don't want to fake the encoding of this
by still have CORE_ADDR be an integral type as you have to
worry about address calculations over/underflowing to a different
address space.  An integral CORE_ADDR may not even be big enough to hold
all the possiblities.  Ergo, CORE_ADDR becomes a struct.
A simplistic count of the number of places in the source that has to
change is about 1400 (make CORE_ADDR a struct, and process the output
of make -k).  That's a lot.  I have heard "hallway discussions"
where people have been thinking about making CORE_ADDR a struct,
and it seems (though I'm by no means certain) like "the right thing to do".
Targets without address spaces could probably keep CORE_ADDR as
an integral type.  You'd just need to write an appropriate set
of cover macros for definition/manipulation.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]