Linked by Hadrien Grasland on Fri 30th Dec 2011 08:24 UTC
Hardware, Embedded Systems In the world of alternative OS development, portability across multiple architectures is a challenging goal. Sometimes, it may be intrinsically hard to come up with hardware abstractions that work well everywhere, but many times the core problem is one of missing information. Here, I aim at learning more about the way non-x86 architectures deal with CPU IO ports, and in particular how they prevent user-mode software from accessing them.
Permalink for comment 501806
To read all comments associated with this story, please click here.
RE: Memory mapped I/O and ports
by Anachronda on Sat 31st Dec 2011 20:58 UTC in reply to "Memory mapped I/O and ports"
Anachronda
Member since:
2007-04-18

This was carried out to the ultimate level with DEC VAX system - the high order 2 bits selected the system level - 00 - user, 01 - supervisor, 10 -interrupt, 11 device (as I recall).

You're actually mixing two different view of the VAX address space.

In a physical address, bit 29 typically selects I/O or memory. Bits 30 and 31 are typically used (at least in the microprocessor implementations) to encode the length of a transaction on the bus.

In a virtual address, bits 30 and 31 select the address space, where 00 is a user space growing up (i.e., code and data), 01 is a user space growing down (i.e., the user stack), 10 I'm fuzzy on, and 11 is system space. I/O typically winds up mapped into system space, although it's possible (with suitable privileges) to map regions of the other address spaces to I/O space.

Reply Parent Score: 1