This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Various memory sizes
On Mon, Dec 15, 2008 at 04:17:34PM -0500, Gobaan_Raveendran@amis.com wrote:
>
> Hello Everyone,
>
> I am working on an architecture with multiple types of memory and I am
> wondering about memory allocation. For the purpose of this explaination,
> we'll assume I am working with an embedded processor that has both 32 bit
> (named X) and 64 bit memory (named Y), 64 bit longs, and uses word
> addressing for both. Now given the following code
>
> int main ()
> {
> long array [5] = {1,2,3,4,5};
> return 0;
> }
>
> the compiler should determine increment based on the length of a long,
> however, if the data is in Y memory this is one, while if the data is in X
> memory the increment is two. The same problem holds for the offset of local
> variables and parameters that are longs etc.
>
> Given that I spent the last little while implementing a prototype that
> dealt with the named address space branch, I was able to quickly hack in
> some language hooks that allowed me to perform corrections to the increment
> for arrays based on their address space, and I may be able to extend this
> for other types as well. However, I think a correct & general
> implementation may change BITS_PER_UNIT and BITS_PER_WORD in order to
> generalize it for each address space (or at the very least introduce new
> macros that extend the behavior).
The problem as I've been finding in the named address branch, is at the end of
the day, you have to find all of the assumptions about Pmode, ptr_mode,
POINTER_SIZE, copy_to_addr_register, etc.
In terms of your code fragment, the named address spec also only allows named
address spaces for static memory. It assumes that stack based objects are all
in the generic address space. The compiler really believes there is only one
stack and that it can push/pop/reload at will.
One thing that I've thought about in terms of named address spaces is whether
you could use it to put in __little and __big to allow a user to encode that a
particular data item is little endian or big. However, you get back to the
stack issue again.
> I am just wondering about any other similar work, the feasibilty of either
> extension(my work is mainly a proof of concept), any input on how I should
> continue or comments on the mistakes of my assumptions.
In an ideal world, there should be a hook that allows a compiler to place each
variable in a particular named address space. However in doing so, you would
need to make sure that void */char * generally can point to any address space.
Otherwise it breaks a lot of C that requires void * be a universal pointer.
You might want to look at what other (non-GCC) compilers do for different
address spaces. I suspect that by and large, they just put the named address
stuff as special types of static, and use generic address spaces for auto
variables.
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com