> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> I see a lot more address space than that in generic processors, not only
> embedded systems with EEPROM.
- Almost, but they aren't "memory spaces" in the sense that programming
languages expect them to be, as they impose implied restrictive semantics
that are not understood by the languages/compilers. Therefore are truly
distinct. For example, what do these declarations mean? At what addresses
would you expect them to be allocated to? The problem is that it matters,
as they aren't truly memory spaces which correspond to distinct classes
of objects which the language already understands.
EEPROM static int * x;
IOPORT complex y;
And may already be satisfied by defining target specific functions which
map logical program values to specific semantics, satisfy all examples
below even if it requires the specification of target specific assembly
I/O routines to act as an interface; so it's not clear if anything further
is required. i.e. : (write_i_o dest value), or may be specified somewhat
more naturally in C++ by overloading operators, to understand what to do
when an IO type object is written for example.
Which is very different from saying for example that a back end should
be able to map (independently of the language) code into one address
space, literal data into another, and runtime allocated variables into
a third for example, which only requires that such declarations and
corresponding references be visible during code generation (which can't
be satisfied without internal cooperation from the complier with the
target specific code generator).
> 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.
