Re: named address spaces (update)

[Martin Koegler <mkoegler@auto.tuwien.ac.at>]

On Thu, Jul 07, 2005 at 09:45:04PM -0400, Paul Schlie wrote:
> James E Wilson writes:
> >> On Sun, 2005-07-03 at 07:31, Martin Koegler wrote:
> >> * need to rewrite recursivly each element of type (which my contain
> >> structures, unions, ...) if a address space is set
> >>   In http://gcc.gnu.org/ml/gcc/2005-04/msg01438.html, this was rated as
> >> bad idea.
> >
> > It is possible I was wrong.  Conceptually, this doesn't seem much
> > different than existing type qualifiers const/volatile, for which case
> > we must already have a solution.  Maybe similar treatment will work for
> > named address spaces?

Address spaces are similar to the const/volatile type qualifier. Const
and volatile flags are present in each tree expression (not only in the type).
For expressions and decls I store them in a similar way.

Only for types, I do not store the address space of the value, as this is the
more complicated way. For each structure, it must be made sure that, that all elements
are declared in the same address space. Also the propgation of the address space
from structures to their elements (and subelements) must be done in some way.

Implementing a correct propagation (including the correct handling of the variant
handling), will need more time, than I currently have.

> > Otherwise, these answers all seem very reasonable.
> 
> Is there any reasonable solution to the problem which presents itself when
> attempting to pass address space qualified pointers as arguments to, or
> being returned from, a function; as it seems that unless there's a mechanism
> by which "C" can either select overloaded functions as a function of it's
> qualified argument and/or return value types, or automatically generate
> variants of a given function as may be required based upon it's arguments
> memory space designation; it's not clear how named address spaces can be
> truly useful if references to them can't be effectively utilized by
> functions? (but hopefully I'm misunderstanding something)
> 
> For example (for the sake of argument):
> 
> ROM const int = 5;  // which may require a specific load inst to access.
> RAM1 const int = 6; // which may require a different load inst to access.
> RAM2 int;           // which may require yet a different load/store inst.
> 
> RAM2 int* foo(RAM2 int* x, ROM const int* y)
> {
>   *x = *y;   // loads from ROM const int* y.
>    return x;
> }
> 
> RAM2 int* foo(RAM2 int* x, RAM1 const int* y)
> {
>   *x = *y;    // loads from RAM1 cons int* y.
>    return x;
> }
> 
> Which represents only 2 of several possible permutations of
> ROM RAM1 RAM2 address space argument combinations, which seems both
> painful and error prone to have to replicate, and presumes that the
> compiler is capable of resolving their selection at compile time, as
> may be necessary for the correct code generation of unique address
> space argument reference access?

According to my understanding, in C, a parameter can only have one
address space and may not have any overloader variants. So you will 
need different function names to deal with the different address spaces.

In some situations, not all permutations are neccessary, as one address
space may be part of another, in which case it is possible to create the
functions only for the bigger address space.

Overloading (and automatic generation of permutations) will require the
C++ frontend.

mfg Martin Kögler