From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11589 invoked by alias); 10 Jul 2005 14:41:54 -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 11548 invoked by uid 22791); 10 Jul 2005 14:41:47 -0000 Received: from mr2-n.kom.tuwien.ac.at (HELO mr.tuwien.ac.at) (128.131.2.110) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 10 Jul 2005 14:41:47 +0000 Received: from ahab.auto.tuwien.ac.at (ahab.auto.tuwien.ac.at [128.130.60.8]) by mr.tuwien.ac.at (8.12.10/8.12.8) with ESMTP id j6AEfdvs025605; Sun, 10 Jul 2005 16:41:40 +0200 (MEST) Received: from ahab.auto.tuwien.ac.at (localhost.localdomain [127.0.0.1]) by ahab.auto.tuwien.ac.at (8.12.11/8.12.11) with ESMTP id j6AEfdZL013550; Sun, 10 Jul 2005 16:41:39 +0200 Received: (from mkoegler@localhost) by ahab.auto.tuwien.ac.at (8.12.11/8.12.11/Submit) id j6AEfdCH013545; Sun, 10 Jul 2005 16:41:39 +0200 Date: Sun, 10 Jul 2005 14:41:00 -0000 From: Martin Koegler To: Paul Schlie Cc: gcc@gcc.gnu.org Subject: Re: named address spaces (update) Message-ID: <20050710144139.GB5569@ahab.auto.tuwien.ac.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2005-07/txt/msg00343.txt.bz2 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