Re: physmem, simple containers

[Benno]

On Thu Jan 29, 2004 at 11:31:16 +0100, Niels M?ller wrote:
>Stefan G=F6tz <address@hidden> writes:
>
>> > into its virtual address space.  It's just most convenient to do this=
> 1:1
>> > for two reasons.
>>=20
>> There are at least two scenarios where this is not possible. First, it
>> won't be too long before people stick more than 3 GB of RAM into their
>> 32-bit machines. Second, PCI devices can map their control registers
>> into 'physical' memory space at addresses above 3 GB (e.g. my network
>> adapter).
>
>Uhuh. I'm getting C64 flashbacks. 64K of RAM, overlayed with basic ROM
>(8K), kernal (sic) ROM (8K) and memory mapped I/O circuits (4K), so
>that usually only 44K of RAM were mapped into the address space. Then
>there were two I/O registers at address 0 and 1, part of the CPU,
>where you could flip bits to switch out one or both of the ROMS, and
>also the I/O-block, to get access to 64K - 2 bytes of RAM. (Then the
>C128 was even more perverted. It had more of the memory bank switching
>things, and it also had two cpu:s, from *different* architectures, z80
>and 6502, which one could switch between).
>
>> It's not a problem to request this memory from sigma0 but you
>> obviously can't map it 1:1 (but maybe you do not intend to manage this
>> memory with physmem anyway).
>
>I/O ports and other memory mapped hardware should not be managed by
>physmem. Not sure how it should be managed instead, though, probably
>by the device driver core "deva". Also not sure if all modern CPU
>architectures use "ports" like on x86, or if some use memory mapped
>I/O registers.

To my knowledge x86 is really the only major architecture with "ports".
So most architectures use memory mapped I/O registers.

Benno