Re: Non-uniform address spaces

[Jim Blandy <jimb@codesourcery.com>]

Michael Eager <eager@eagercon.com> writes:
> For an example, the SPEs in a Cell processors could be configured
> to distribute pieces of an array over different SPEs.
>
>> How do you declare such an array?  How do you index it?  What code is
>> generated for an array access?  How does it relate to C's rules for
>> pointer arithmetic?
>
> In UPC (a parallel extension to C) there is a new attribute "shared"
> which says that data is (potentially) distributed across multiple processors.
>
> In UPC, pointer arithmetic works exactly the same as in C: you can
> compare pointers, subtract them to get a difference, and add integers.
> The compiler generates code which does the correct computation.

All right.  Certainly pointer arithmetic and array indexing need to be
fixed to handle such arrays.  Support for such a system will entail
having the compiler describe to GDB how to index these things, and
having GDB understand those descriptions.  

If those were fixed, how do the other CORE_ADDR uses look to you?
Say, in the frame code?  Or the symtab code?

> The C standard doesn't require objects to be contiguous or to be
> stored entirely in a single memory space.

Actually, my mentioning the C standard there was a red herring; we're
talking about how CORE_ADDR is used in GDB, and CORE_ADDR has no
necessary relation to anything in the C standard.

But just for the murky glory of language lawyering: it seems to me
that the standard does require objects to be contiguous.  6.2.4
para. 20:

  Any number of derived types can be constructed from the object,
  function, and incomplete types, as follows:

  — An array type describes a contiguously allocated nonempty set of
    objects with a particular member object type, called the element
    type.

And 6.3.2.3, para. 7:

  A pointer to an object or incomplete type may be converted to a
  pointer to a different object or incomplete type. ... When a pointer
  to an object is converted to a pointer to a character type, the
  result points to the lowest addressed byte of the object. Successive
  increments of the result, up to the size of the object, yield
  pointers to the remaining bytes of the object.

Now, the implementation could do all sorts of magic under the covers
that takes these apparently contiguous objects and scatters them
around memory in some useful way.  And that lower level is exactly the
level at which CORE_ADDR operates, so your point stands.