This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposal: GCC core changes for different address spaces
- From: Etienne Lorrain <etienne_lorrain at yahoo dot fr>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 25 Apr 2005 11:55:49 +0200 (CEST)
- Subject: Re: Proposal: GCC core changes for different address spaces
Paul Schlie wrote:
> My impression is that there are 3 fundamental types of memory references:
>
> - literal-code (call/goto code-label/ptr)
> - literal-data (mem static-const-symbol/ptr)
> - runtime-data (mem non-static-const-symbol/ptr)
>
> As such it seems likely sufficient to simply enable the memory reference
> to these data classes to be identifiable during target specific linking
> and code generation to enable a broad class of Harvard memory architecture
> machines to be supported in addition to unified memory Von-Newman
> machines.
I see a lot more address space than that in generic processors, not only
embedded systems with EEPROM.
For ia32, there is the IO port memory space, and it seem logical for me
to do:
struct UART_str {
unsigned char buffer;
unsigned char flags;
unsigned short speed;
} __attribute__ ((section(IOPORT)));
You have also the "Machine State Registers" (MSR) and the performance
counters (PeMo) stuff. I would add segment relative address (cs, ds, fs,
gs based address space) are separate - but just for my own set of problems.
For PowerPC, you have the "Special Function Registers", accessed
with mtspr/mfspr assembly instruction, and the "Device Control Register",
accessed with mtdcr/mfdcr assembly instruction. Those regiters form
complex data structure which are worth describing by C structures and
bitfields if you do not want hundred of pages of #defines for masks
and addresses. Note that the real reason they are in an orthogonal data
space is that they shall not be cached like standard memory.
I see also PCI space as a different memory space, you can have 32 or
64 bits address space behind a pair of address/data "registers", and
also PCI malloc-able area when you are looking for a free address range
to map a device.
That is not exactly what is being discussed here, I do not know how
it fits the problem - but these are different address space, and having
an address in one of those "memory space" is a valid concept, having
some debug information for the debugger to display bits and enums
in a human understandable form would be nice.
Etienne.
__________________________________________________________________
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails !
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/