From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5144 invoked by alias); 8 Jul 2005 01:55:58 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23380 invoked by uid 22791); 8 Jul 2005 01:45:30 -0000 Received: from sccrmhc14.comcast.net (HELO sccrmhc14.comcast.net) (204.127.202.59) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 08 Jul 2005 01:45:30 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc14) with SMTP id <2005070801450601400isrn3e>; Fri, 8 Jul 2005 01:45:10 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 08 Jul 2005 01:55:00 -0000 Subject: Re: named address spaces (update) From: Paul Schlie To: James E Wilson , Martin Koegler , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-07/txt/msg00291.txt.bz2 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? > > 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? (similar problems already exist for read-only data access if it is desired to be allocated to an address space which may require unique load/store access; but worse, as no present mechanism exists to differentiate static const data from allocated const data argument references for example.)