From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15865 invoked by alias); 24 Dec 2002 02:42:48 -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 15856 invoked from network); 24 Dec 2002 02:42:47 -0000 Received: from unknown (HELO stardust.solidas.com) (217.13.28.68) by 209.249.29.67 with SMTP; 24 Dec 2002 02:42:47 -0000 Received: from solidas.com ([62.92.117.112]) (authenticated) by stardust.solidas.com (8.11.6/8.11.6) with ESMTP id gBO2gXE17331 for ; Tue, 24 Dec 2002 03:42:34 +0100 Message-ID: <3E07C993.5040405@solidas.com> Date: Tue, 24 Dec 2002 02:21:00 -0000 From: "Svein E. Seldal" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: [RFC] Gcc and multiple memory spaces (former Gcc and harvard architectures (towards AVR)) References: <3DFF4948.3060009@solidas.com> In-Reply-To: <3DFF4948.3060009@solidas.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg01398.txt.bz2 After some helpful pointers by Robert Dewar, I'm going to rephrase my questions. It seems like I have used the wrong terms, so I'm trying to clear things up by explaining my intentions better this time. I would really like gcc to have support for several memory-spaces. Because some targets, like the AVR, has more than one memory-space; one for code (I-space) and one for data (D-space). And these spaces cannot normally intermix. The I-space is used by the CPU core to fetch new instructions, while the D-space is used for data storeage. While the I-space is normally reserved for storing code, it is possible to store data there as well in some targets. And these targets usually has different sets of opcodes to access these spaces; one set for D-space access, and one set for the special I-space access. The AVR target (for one) has a very low memory (D-space), while it has reasonable amounts of flash (I-space). It would be an advantage if const variables, strings. etc. could be placed into flash (I-space). While it is possible to do so by using the 'progmem' attribute, it is impossible to get gcc to natively handle this information. This is caused by the simple fact that gcc is only capable of handling one memory space, which happens to be the runtime memory (D-space). If users are to read from the flash (I-space), they have to fiddle around with manual assembly. This gives several obvious drawbacks: Strings that are placed into flash, are not collected. const structs in flash are a mess, because you have to access the members manually (using assembly), etc. Very errorprone! I've spoken to the AVR maintainers about this feature, but they cannot implement this because it has global gcc implications. Please see http://gcc.gnu.org/ml/gcc/2002-12/msg01194.html for a description of my suggestion. It seems to me that this would imply the following changes/additions to gcc: a) Implement attributes which places data in the appropriate memoryspace (ala the AVR-target's 'progmem' attribute) b) Implement the ability to declare attributes on pointers (not just pointer storeage), which would make it possible to have pointers to locations in other memoryspaces. c) Rewrite the target-specific parts of gcc where the memory accesses are translated into assembly. -- Take the AVR as an example. It uses different opcodes for accessing the D-space from the I-space. This implies that gcc must be able to generate the appropriate code for the correct address-space/access form. FYI: The definitions of these memoryspaces are defined by the target architecture, never by the user in a runtime environment. Unfortunately, I'm not a skilled gcc programmer (yet) so I would need lots and lots of help to do it. But this is something I'm very keen on getting implemented into gcc. The AVR target suffers from this limitation, were it is the greatest drawback for using gcc in AVR systems. However I do not wish to burn too much energy trying to implement this feature is nobody wants it... Is this idea realistically implementable into gcc? What does the SC say about this? Isn't this food for their tables? Please give me feedback on the issue if you have some. Merry Christmas, Svein