Re: harvard architectures - the d10v

Re: harvard architectures - the d10v

[David Taylor]

    From: Doug Evans <dje@transmeta.com>
    Date: Thu, 8 Feb 2001 13:30:46 -0800 (PST)

    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
    >space.
    >
    >Comments?

    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

I wonder if the @ syntax that Per proposed would conflict with the
array syntax.  I suspect it would, but I haven't thought much about
it.  There is precedence for using : -- segment registers on the x86
family.  But, would that conflict / cause parsing problems with other
things (.e.g, C++ uses :: and C has a ternary operator)?

x/x <expression-involving-?:-and-address-spaces>

    - there could be a default address space,
      or target could specify that "x/x 0x12345678 is an error

or the address space could be "sticky" -- that is, an address given
without an address space qualifier could use the most receently
specified address space.

    - users of targets without address spaces would see no change
    - I would treat the address space names as target specific

with probably some "standard" names that most targets would use...

One could even imagine both raw and virtual names (bad choice of words
-- would absolute and relative be better?).  For example, if you had
multiple processes, and suppose the data spaces were data1, data2,
data3...  then data might mean the data space of the 'current' process
(whatever 'current' means in this context).

    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.

I would argue that even with a single address space you'd still want
it to be a struct (even if the address space part is identical for all
addresses), otherwise you'd have bit rot potentially setting in
whenever someone who normally only worked on a single address space
environment modified gdb.

Flip side, if it was only a struct on selected targets, then old
unconverted targets would continue to work.

The solution would probably be to initially allow it to be an integral
type on targets without multiple address spaces -- but convert some of
the most popular targets (e.g., Sparc/Solaris native, x86/Linux
native, and x86/Windows native) to the new regime.

Also, we need to have two perspectives here:

. longer term -- where do we want to go -- and I would put changing
CORE_ADDR into a struct into that category as it would require a fair
bit of work.

. shorter term -- People are porting gdb to environments with multiple
address spaces *NOW*.  In the immediate future what do we want to be
the behavior of existing commands and such.  And what should be done
immediately, if anything, to get GDB to work reasonably well in such
environments.

Re: harvard architectures - the d10v

[Eli Zaretskii]

> From: Doug Evans <dje@transmeta.com>
> Date: Thu, 8 Feb 2001 13:30:46 -0800 (PST)
> 
> 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.

Are we introducing segments into GDB?  Because if we are, I can think
about a few more possible applications, for x86 for example.

harvard architectures - the d10v

[Andrew Cagney]

So a meta question, how should GDB behave when it comes to a harvard
architecture?

I've this feeling that at present we've lots of people all trying to get
GDB to work on harvard architectures and each, in a vacuum, is
determining how it should behave.  The unfortunately consequence is that
when the discussion is finally dragged, kicking and screaming, out onto
a public forum, no one agrees.  People refuse to discuss details because
their harvard architecture is all hush, hush.  By the time the issues
are raised, it is all too late and the real problems are simply not
fixed.

The ironic part to all this is that, long ago, GDB was targeted at the
d10v (it is the extreme games version of a harvard architectures). At
the time it was decided that the d10v hacks should to be accepted into
gdb because that way there was at least a working implementation out
there in a public forum.  The tool you all need to facilitate public
discussion are available yet everyone refuses to use it!

``But the d10v is a hack''?  So?  The point of the d10v, wasn't to
provide a reference implementation (anything but!) but rather to provide
a vehicle through which a reference implementation could be developed. 
The really important thing is to remember that this implementation has
been 

So, who out of all of you would like to steer this to resolution?  The
first thing I think needs to be done is for people to agree to the
correct interaction and document it.  That way if people ever want to
re-open the debate about what the behaviour should be they can simply
turn to the gdb.texinfo documentation.

	Andrew

--

Anyway, onto more serious matters.  One thing I do remember as a problem
was:

	gdbtypes.h:builtin_type_ptr

it isn't constructed correctly (at the time I didn't know what I was
doing ...).  It should be cloned into:

	builtin_type_data_ptr;  (void*)
	builtin_type_func_ptr;	(void(*)())

that would at least allow the POINTER_TO_ADDRESS and ADDRESS_TO_POINTER
to be called when converting to/from generic pointers.

Anyone?

	Andrew
From taylor@cygnus.com Thu Feb 08 12:38:00 2001
From: David Taylor <taylor@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Doug Evans <dje@transmeta.com>, Kevin Buettner <kevinb@cygnus.com>, Nick Duffek <nsd@cygnus.com>, Michael Snyder <msnyder@cygnus.com>, Jim Blandy <jimb@cygnus.com>, GDB Discussion <gdb@sources.redhat.com>
Subject: Re: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 12:38:00 -0000
Message-id: <200102082037.PAA07784@texas.cygnus.com>
X-SW-Source: 2001-02/msg00083.html
Content-length: 3403

    Date: Thu, 08 Feb 2001 11:47:53 -0800
    From: Andrew Cagney <ac131313@cygnus.com>

    So a meta question, how should GDB behave when it comes to a harvard
    architecture?

That's a very broad question.

A vauge approximate answer is

"As the d10v behaves, but without the bugs and without the kludges."

[Of course that doesn't say "what is a bug" nor "what is a kludge".]

For the d10v there are in several files the line

  if (GDB_TARGET_IS_D10V

(Although I believe that the number of such files is diminishing over
time.)

    I've this feeling that at present we've lots of people all trying to get
    GDB to work on harvard architectures and each, in a vacuum, is
    determining how it should behave.  The unfortunately consequence is that
    when the discussion is finally dragged, kicking and screaming, out onto
    a public forum, no one agrees.  People refuse to discuss details because
    their harvard architecture is all hush, hush.  By the time the issues
    are raised, it is all too late and the real problems are simply not
    fixed.

    The ironic part to all this is that, long ago, GDB was targeted at the
    d10v (it is the extreme games version of a harvard architectures). At
    the time it was decided that the d10v hacks should to be accepted into
    gdb because that way there was at least a working implementation out
    there in a public forum.  The tool you all need to facilitate public
    discussion are available yet everyone refuses to use it!


    ``But the d10v is a hack''?  So?  The point of the d10v, wasn't to
    provide a reference implementation (anything but!) but rather to provide
    a vehicle through which a reference implementation could be developed. 
    The really important thing is to remember that this implementation has
    been 

Part of the sentence appears to be missing.

    So, who out of all of you would like to steer this to resolution?  The
    first thing I think needs to be done is for people to agree to the
    correct interaction and document it.  That way if people ever want to
    re-open the debate about what the behaviour should be they can simply
    turn to the gdb.texinfo documentation.

I'm certainly interested in this discussion, have opinions on much of
this, and am willing...  but I don't have much care who "steers" it --
so long as the discussion occurs.

	    Andrew

    --

    Anyway, onto more serious matters.  One thing I do remember as a problem
    was:

	    gdbtypes.h:builtin_type_ptr

    it isn't constructed correctly (at the time I didn't know what I was
    doing ...).  It should be cloned into:

	    builtin_type_data_ptr;  (void*)
	    builtin_type_func_ptr;  (void(*)())

Don't forget the existing msym_text_symbol_type.

    that would at least allow the POINTER_TO_ADDRESS and ADDRESS_TO_POINTER
    to be called when converting to/from generic pointers.

    Anyone?

	    Andrew

Currently, GDB and to a lesser extent the binutils/gas/ld toolsuite,
deal with Harvard Architectures by adding extra bits to allow them to
treat the system as having a unified address space.

For example, for the d10v:

. data memory starts at 0x2000000
. instruction memory starts at 0x1000000
. all addresses are byte addresses

Converting between pointers and addresses generally seems to involve

. or'ing in or masking off some high bits
. shifting the low bits by some amount
From taylor@cygnus.com Thu Feb 08 12:51:00 2001
From: David Taylor <taylor@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Harvard Architecture issues -- addresses vs pointers
Date: Thu, 08 Feb 2001 12:51:00 -0000
Message-id: <200102082050.PAA07793@texas.cygnus.com>
X-SW-Source: 2001-02/msg00084.html
Content-length: 1059

I will refer to things as:

. a user address
. an internal gdb address
. a target pointer

For most targets, all three are the same thing.

GDB clearly currently distinguishes between the last two -- an
internal gdb address vs a target pointer, with the former living in a
CORE_ADDR.

I would maintain that while, long term, a user address should be
separated from the other two, that gdb does not currently do so.  And
that if you peruse the code, modulo an occassional bug, you'll become
convinced that currently, gdb treats user addresses and internal gdb
addresses as the same thing.

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
space.

Comments?
From dje@transmeta.com Thu Feb 08 13:06:00 2001
From: Doug Evans <dje@transmeta.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: David Taylor <taylor@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>, Nick Duffek <nsd@cygnus.com>, Michael Snyder <msnyder@cygnus.com>, Jim Blandy <jimb@cygnus.com>, GDB Discussion <gdb@sources.redhat.com>
Subject: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 13:06:00 -0000
Message-id: <14979.2615.608456.807316@casey.transmeta.com>
References: <3A82F7E9.D4641BD1@cygnus.com>
X-SW-Source: 2001-02/msg00085.html
Content-length: 2155

Andrew Cagney writes:
 > So a meta question, how should GDB behave when it comes to a harvard
 > architecture?

Is "Harvard Architecture" really the best name for this?
Seems to me it includes only a small subset of the total set of
architectures that have multiple address spaces for different uses.

 > I've this feeling that at present we've lots of people all trying to get
 > GDB to work on harvard architectures and each, in a vacuum, is
 > determining how it should behave.  The unfortunately consequence is that
 > when the discussion is finally dragged, kicking and screaming, out onto
 > a public forum, no one agrees.  People refuse to discuss details because
 > their harvard architecture is all hush, hush.  By the time the issues
 > are raised, it is all too late and the real problems are simply not
 > fixed.

At best, this is a wee bit presumptious.
[but never let that stop a good argument :-)]

 > The ironic part to all this is that, long ago, GDB was targeted at the
 > d10v (it is the extreme games version of a harvard architectures). At
 > the time it was decided that the d10v hacks should to be accepted into
 > gdb because that way there was at least a working implementation out
 > there in a public forum.  The tool you all need to facilitate public
 > discussion are available yet everyone refuses to use it!

Define "everyone".
Define "refuses".

 > ``But the d10v is a hack''?  So?  The point of the d10v, wasn't to
 > provide a reference implementation (anything but!) but rather to provide
 > a vehicle through which a reference implementation could be developed. 

I don't know that the d10v was all the good a reference implementation
or that one is even needed for the task at hand.

 > So, who out of all of you would like to steer this to resolution?  The
 > first thing I think needs to be done is for people to agree to the
 > correct interaction and document it.  That way if people ever want to
 > re-open the debate about what the behaviour should be they can simply
 > turn to the gdb.texinfo documentation.

I'm not in a position to steer anything gdb-wise.
But I do have an interest in seeing this resolved.
From kevinb@cygnus.com Thu Feb 08 13:14:00 2001
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Harvard Architecture issues -- addresses vs pointers
Date: Thu, 08 Feb 2001 13:14:00 -0000
Message-id: <1010208211432.ZM6398@ocotillo.lan>
References: <200102082050.PAA07793@texas.cygnus.com> <taylor@cygnus.com>
X-SW-Source: 2001-02/msg00087.html
Content-length: 546

On Feb 8,  3:50pm, David Taylor wrote:

> 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
> space.

I agree with David.
From per@bothner.com Thu Feb 08 13:14:00 2001
From: Per Bothner <per@bothner.com>
To: David Taylor <taylor@cygnus.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Subject: Re: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 13:14:00 -0000
Message-id: <m2wvb0dg5p.fsf@kelso.bothner.com>
References: <200102082037.PAA07784@texas.cygnus.com>
X-SW-Source: 2001-02/msg00086.html
Content-length: 1954

David Taylor <taylor@cygnus.com> writes:

> Currently, GDB and to a lesser extent the binutils/gas/ld toolsuite,
> deal with Harvard Architectures by adding extra bits to allow them to
> treat the system as having a unified address space.

The problem of multiple address spaces is a more general problem:

* We want to be able to use a single debugger to debug a distributed
program running as mutiple processes.

* Likewise, with the programs running on separate hardware with
different architectures.

* We want to be able to debug normal machine code as well as
an interpreter ("virtual machine code").

* We want to debug programs that have separate data and instruction
spaces.

The cleanest solution would be to define CORE_ADDR as a struct:

struct core_addr {
  struct address_space *target;
  uint64_t addr;
};

typedef struct core_addr CORE_ADDR;

struct address_space {
  pointer to table of functions that take a core_addr;
  ... address-space-specific data, such as process id ...;
};

#define ADDR_ADDRESS_SPACE(ADDR) ((ADDR)->target)
#define ADDR_VALUE(ADDR) ((ADDR)->target)

This would be the Right Thing, but it might be a lot of work
to convert Gdb.  Perhaps not - I don't know.  An interim step
might be using certain high-order bits of an integer as an
index into a table of address spaces:

typedef unit64_t CORE_ADDR;

struct addr_space normal_addr_space = { ... };
struct addr_space *(addr_space_table[256]) = {
  normal_addr_space,
  normal_addr_space,
  ...
};

#define ADDR_ADDRESS_SPACE(ADDR) addr_space_table[(ADDR) >> 56]
#define ADDR_VALUE(ADDR) (ADDR_ADDRESS_SPACE(ADDR)->addr_value(ADDR))

Something like the above can probably be implemented very easily,
without breaking any "normal" architectures.  You can then relatively
cleanly implement support for multiple address spaces in this framework
- just plud in new addr_spaces in the addr_space_table.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/
From taylor@cygnus.com Thu Feb 08 13:18:00 2001
From: David Taylor <taylor@cygnus.com>
To: Doug Evans <dje@transmeta.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>, Nick Duffek <nsd@cygnus.com>, Michael Snyder <msnyder@cygnus.com>, Jim Blandy <jimb@cygnus.com>, GDB Discussion <gdb@sources.redhat.com>
Subject: Re: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 13:18:00 -0000
Message-id: <200102082118.QAA07810@texas.cygnus.com>
X-SW-Source: 2001-02/msg00088.html
Content-length: 1105

    From: Doug Evans <dje@transmeta.com>
    Date: Thu, 8 Feb 2001 13:05:59 -0800 (PST)

    Andrew Cagney writes:
     > So a meta question, how should GDB behave when it comes to a harvard
     > architecture?

    Is "Harvard Architecture" really the best name for this?
    Seems to me it includes only a small subset of the total set of
    architectures that have multiple address spaces for different uses.

It could have multiple address spaces for a variety of reasons -- for
example, the Sony Playstation 2, if I recall correctly, has 5 total
processors in it of 2 (or is it 3?) different types.  Each has its own
memory.

Are there issues people wish to discuss beyond the issues that arise
as a result of multiple address spaces?

     > ``But the d10v is a hack''?  So?  The point of the d10v, wasn't to
     > provide a reference implementation (anything but!) but rather to provide
     > a vehicle through which a reference implementation could be developed. 

    I don't know that the d10v was all the good a reference implementation
    or that one is even needed for the task at hand.
From per@bothner.com Thu Feb 08 13:21:00 2001
From: Per Bothner <per@bothner.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Harvard Architecture issues -- addresses vs pointers
Date: Thu, 08 Feb 2001 13:21:00 -0000
Message-id: <m2snlodftt.fsf@kelso.bothner.com>
References: <200102082050.PAA07793@texas.cygnus.com>
X-SW-Source: 2001-02/msg00089.html
Content-length: 670

David Taylor <taylor@cygnus.com> 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.

I agree.  We need soem syntax to specify address space literals.
I might suggest '@' followed by an address-space name.  (I'm
not sure if this conflicts with the array "repeat" operator.)

0x12345678@i

0x12345678@d

More generally:
        integer-expression @NAME
coerces the integer to a pointer in the named space.

This syntax could also be used for output.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/
From dje@transmeta.com Thu Feb 08 13:31:00 2001
From: Doug Evans <dje@transmeta.com>
To: David Taylor <taylor@cygnus.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Subject: Re: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 13:31:00 -0000
Message-id: <14979.4102.901998.291182@casey.transmeta.com>
References: <200102082037.PAA07784@texas.cygnus.com>
X-SW-Source: 2001-02/msg00090.html
Content-length: 1935

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
>space.
>
>Comments?

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.
From ac131313@cygnus.com Thu Feb 08 14:02:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Per Bothner <per@bothner.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Subject: Re: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 14:02:00 -0000
Message-id: <3A831664.2AB12A43@cygnus.com>
References: <200102082037.PAA07784@texas.cygnus.com> <m2wvb0dg5p.fsf@kelso.bothner.com>
X-SW-Source: 2001-02/msg00091.html
Content-length: 612

FYI,

Per Bothner wrote:

> The cleanest solution would be to define CORE_ADDR as a struct:
> 
> struct core_addr {
>   struct address_space *target;
>   uint64_t addr;
> };

Yes.  People have talked about doing this for longer than I can
remember.  Problem is, making CORE_ADDR an object is only a tiny part of
the solution and, to be honest, probably comes last in the long list of
things to change.  As a broad strategy, I'd expect all the prototyping
to be done using functions that take a CORE_ADDR and then, only at the
last moment, would someone push a button and change it to a struct.

	enjoy,
		Andrew
From ac131313@cygnus.com Thu Feb 08 14:06:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Doug Evans <dje@transmeta.com>
Cc: David Taylor <taylor@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>, Nick Duffek <nsd@cygnus.com>, Michael Snyder <msnyder@cygnus.com>, Jim Blandy <jimb@cygnus.com>, GDB Discussion <gdb@sources.redhat.com>
Subject: Re: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 14:06:00 -0000
Message-id: <3A831746.CAB9C621@cygnus.com>
References: <3A82F7E9.D4641BD1@cygnus.com> <14979.2615.608456.807316@casey.transmeta.com>
X-SW-Source: 2001-02/msg00092.html
Content-length: 1108

Doug Evans wrote:

>  > ``But the d10v is a hack''?  So?  The point of the d10v, wasn't to
>  > provide a reference implementation (anything but!) but rather to provide
>  > a vehicle through which a reference implementation could be developed.
> 
> I don't know that the d10v was all the good a reference implementation
> or that one is even needed for the task at hand.

Notice that I carefully avoided calling the d10v a reference
implementation.  It isn't and I'm not claiming that it is.  Rather it is
a working example.  The moment anyone refers to the D10V code they are
probably missing the point :-)

The thing to do with the d10v is look at how the user is able to
interact with it.  For instance, the user can cut addresses from one
part of the screen and paste them directly into new commands.  The user
can use 0 and have it mean NULL.  It is that sort of subtlety that the
d10v managed to resolve.

The one thing people shouldn't be doing is designing some new set of
implementations without looking at what has been before and seeing how
real people felt things should work.

	enjoy,
		Andrew
From per@bothner.com Thu Feb 08 14:13:00 2001
From: Per Bothner <per@bothner.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Subject: Re: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 14:13:00 -0000
Message-id: <m2ae7wddfn.fsf@kelso.bothner.com>
References: <200102082037.PAA07784@texas.cygnus.com> <m2wvb0dg5p.fsf@kelso.bothner.com> <3A831664.2AB12A43@cygnus.com>
X-SW-Source: 2001-02/msg00093.html
Content-length: 906

Andrew Cagney <ac131313@cygnus.com> writes:

> FYI,
> 
> Per Bothner wrote:
> > The cleanest solution would be to define CORE_ADDR as a struct:
> 
> Yes.  People have talked about doing this for longer than I can
> remember.

I certainly did when I was at Cygnus ...

> Problem is, making CORE_ADDR an object is only a tiny part of
> the solution

Well, it seems like a prerequisite:  If you want to deal with multiple
addres-spaces, you have to have some way of representing that.

> As a broad strategy, I'd expect all the prototyping
> to be done using functions that take a CORE_ADDR

We're still talking about the problem of handling more than one
address space, right?  How do you want to represent that during
"prototyping"?  It need not be a struct - in fact the second half of
my message proposed a relatively generic alternative.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/
From ac131313@cygnus.com Thu Feb 08 15:06:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: Doug Evans <dje@transmeta.com>, Kevin Buettner <kevinb@cygnus.com>, Nick Duffek <nsd@cygnus.com>, Michael Snyder <msnyder@cygnus.com>, Jim Blandy <jimb@cygnus.com>, GDB Discussion <gdb@sources.redhat.com>
Subject: Re: harvard architectures - the d10v
Date: Thu, 08 Feb 2001 15:06:00 -0000
Message-id: <3A831EA7.7C3CEF72@cygnus.com>
References: <200102082118.QAA07810@texas.cygnus.com>
X-SW-Source: 2001-02/msg00094.html
Content-length: 897

David Taylor wrote:

>     Andrew Cagney writes:
>      > So a meta question, how should GDB behave when it comes to a harvard
>      > architecture?
> 
>     Is "Harvard Architecture" really the best name for this?
>     Seems to me it includes only a small subset of the total set of
>     architectures that have multiple address spaces for different uses.
> 
> It could have multiple address spaces for a variety of reasons -- for
> example, the Sony Playstation 2, if I recall correctly, has 5 total
> processors in it of 2 (or is it 3?) different types.  Each has its own
> memory.

True.  Multiple address spaces for a single thread.  Singleing out
harvard architecture was probably badness on my part.

> Are there issues people wish to discuss beyond the issues that arise
> as a result of multiple address spaces?

Please don't.  Lets fix one bug and then worry about the next.

	Andrew
From wung_y@263.net Thu Feb 08 16:49:00 2001
From: "Wang Yong" <wung_y@263.net>
To: <gdb@sources.redhat.com>
Subject: how to build
Date: Thu, 08 Feb 2001 16:49:00 -0000
Message-id: <NEBBLJICGIFMKMAIPNDOIELECBAA.wung_y@263.net>
X-SW-Source: 2001-02/msg00095.html
Content-length: 171

I want to run gdb on windows nt to debug MPC823 target. Does anyone 
know how to build this gdb. Should I build it on linux or cygwin and how
to configure? thx

Wang

Re: harvard architectures - the d10v

[Doug Evans]

Andrew Cagney writes:
 > Doug Evans wrote:
 > 
 > >  > ``But the d10v is a hack''?  So?  The point of the d10v, wasn't to
 > >  > provide a reference implementation (anything but!) but rather to provide
 > >  > a vehicle through which a reference implementation could be developed.
 > > 
 > > I don't know that the d10v was all the good a reference implementation
 > > or that one is even needed for the task at hand.
 > 
 > Notice that I carefully avoided calling the d10v a reference
 > implementation.  It isn't and I'm not claiming that it is.  Rather it is
 > a working example.  The moment anyone refers to the D10V code they are
 > probably missing the point :-)

I don't want to get into a debate over the pedantically correct
definition of a reference implementation.  And since you're the
one who brought the d10v up, I wonder who's the one missing the point. :-)

 > The thing to do with the d10v is look at how the user is able to
 > interact with it.  For instance, the user can cut addresses from one
 > part of the screen and paste them directly into new commands.  The user
 > can use 0 and have it mean NULL.  It is that sort of subtlety that the
 > d10v managed to resolve.

There may yet be subtleties involved, but I wouldn't put those
in that category.

 > The one thing people shouldn't be doing is designing some new set of
 > implementations without looking at what has been before and seeing how
 > real people felt things should work.

I'm with Per.  There's some infrastructure that's a prerequisite.