This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]