Re: FW: Targeting dual Harvard architectures

[Jim Blandy <jimb at redhat dot com>]

Kevin Buettner <kevinb@redhat.com> writes:

> On Oct 29,  1:07am, Jim Blandy wrote:
> 
> > - At the moment, make_type_with_address_space is doing two jobs ---
> >   it's handling both the address space stuff, and the non-standard
> >   pointer type stuff (at the moment, only s/390 'mode32' pointers).
> >   You'd probably need to split that into two distinct functions, and
> >   give them better names.  Not sure here.
> 
> It may also be possible to (re)implement the @code, @data mechanisms
> using the address class methods.  That might be the cleanest since it
> would then be possible for an architecture to do whatever it wants
> with regard to adding more address spaces.  I.e. a dual Harvard
> architecture could have @code, @data1, and @data2 or even more
> suitable names which'd make more sense for that architecture.

Hmm.  Address spaces are mutually exclusive of each other --- but not
of address classes.  For example, there's no reason one couldn't have
a '@mode32 @code char *'.  But what combinations are permitted and
which are nonsensical should be up to the target.

Perhaps, instead of having gdbarch methods that turn a name into an
int, we should have gdbarch methods that take a name, and the old int
(initially zero), and return the new int.  That is, let them modify
the arch-specific flag set as needed, not just specify a new flag set.

That way, Ken's architecture could set aside a bitfield for the
spaces, and allocate other bits for whatever address classes the
architecture supports.  The gdbarch method itself would recognize that
'@code @data1 @data2 char *' is a nonsensical type, and report the
error, but would know that the (hypothetical) '@mode32 @code char *'
is okay.