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.
Thread beginning with comment 501678
To read all comments associated with this story, please click here.
The headaches of Legacy Design.
by Snial on Fri 30th Dec 2011 09:54 UTC
Snial
Member since:
2011-12-30

On a non-x86 architecture it's easy and simple, you just map the memory addresses used for I/O out of user-space.

If we look at it a different way, I/O access is merely equivalent to an extra address bit, that is, you need an extra IO signal on a CPU, which could have been used to provide an extra address bit.

So, specific I/O instructions not only complicate work for the instruction set, compilers and device driver portability, but reduce memory space by a factor of two: and on the original 8-bit 8080 from which the x86 inherits its I/O model; the extra 64Kb would have been really valuable.

An I/O address space also doesn't really help even as an address space because virtually all practical computers from the 8-bit era onwards contained both I/O addressed hardware and memory-mapped hardware.

Video memory (actually an output device) was a common example. It was also true of the early 80s x86 PCs where addresses from 0xA0000 to 0xFFFFF were reserved for I/O, because the 1024 addresses provided by their (incompletely decoded) I/O slots weren't enough even then, 30 years ago.

So as you note, I/O portability is a problem for x86 PCs too since some I/O will be memory-mapped.

So why did Intel do this? Two reasons spring to mind: Firstly, the early Intel processors were really seen as embedded systems for controlling I/O, having a separate I/O signal reduced hardware (though this isn't convincing, you would still need additional decoding to handle more than 1 chip).

Secondly, and more probably, Intel were really memory chip producers and were new to processor design; employing people with no prior experience in computer architecture to design their early processors. Consequently, they simply copied I/O concepts from old minicomputers such as the pdp-8 and HP2100 without quite understanding why these machines had such features.

Hope this helps! (Julian Skidmore, designer of the DIY 8-bit computer FIGnition).

Reply Score: 6

blahbl4hblah Member since:
2011-05-29

Whoa! I just looked at the project that you mentioned...That is offing awesome!

Reply Parent Score: 2

Brendan Member since:
2005-11-16

Hi,

On a non-x86 architecture it's easy and simple, you just map the memory addresses used for I/O out of user-space.


Just map the memory addresses used for I/O... and then spend weeks trying to figure out why something only works sometimes, just to find out you used the wrong explicit barrier/fence.

If an (out-of-order execution) CPU can't tell the difference between a memory mapped IO read/write and a normal RAM read/write, then it can be a nightmare for developers, tool-chains, etc.

If an (out-of-order execution) CPU has special instructions to access IO ports (and therefore can easily tell the difference between IO and RAM), then it can enforce strong ordering for these instructions and avoid the nightmare.

Of course if a CPU never supports out-of-order execution and/or enforces strong ordering for everything; then the problem mostly disappears (but so does a significant amount of potential performance).

- Brendan

Reply Parent Score: 2

axilmar Member since:
2006-03-20

I don't think there is a big problem, because modern hardware provides all the means (disabling caches, memory barriers etc) to solve such issues.

Reply Parent Score: 2

Vanders Member since:
2005-07-06

Just map the memory addresses used for I/O... and then spend weeks trying to figure out why something only works sometimes, just to find out you used the wrong explicit barrier/fence.


If you're writing an operating system then that's exactly the sort of thing you need to think about. You may as well have said "Just use I/O ports and then spend weeks trying to figure out why something doesn't work, just to find you were sending the wrong command byte."

Reply Parent Score: 2

viton Member since:
2005-08-09

and on the original 8-bit 8080 from which the x86 inherits its I/O model; the extra 64Kb would have been really valuable.

IN/OUT is a special instructions with shorter encoding. external HW can be very simple like dedicated bit decoder in ZX-Spectrum. (8 bits -> 8 devices)

With 16bit register pairs, >64k is done via bank switching anyway.

Edited 2011-12-31 04:53 UTC

Reply Parent Score: 2

Anachronda Member since:
2007-04-18

Consequently, they simply copied I/O concepts from old minicomputers such as the pdp-8 and HP2100 without quite understanding why these machines had such features.

Can't speak for the HP2100, but the PDP-8 didn't really have ports, per se. It had a single opcode, IOT, that caused I/O to happen. The remainder of the instruction was used to select a device and an operation. A device could do any combination of:

- Reading the value from the accumulator
- Clearing the accumulator
- ORing a value into the accumulator
- Skipping the next instruction

On later models like the PDP-8/e, the processor essentially halts and allows the I/O device access to the control points within the processor. An IOT on those systems can do pretty much anything the processor can.

Reply Parent Score: 1

tylerdurden Member since:
2009-03-17

Hmmm.

You seem to have it backwards, port mapped I/O does not affect memory addressing since the CPU sees 2 different address spaces for all intents and purposes. that is one of the reasons why it was a common place design choice among early micros which had limited addressing capabilities.

Also since early micros from intel were mostly used as embedded controllers, it also made sense to segregate memory and I/O maps, since I/O devices tend to be much slower than memories. So they dealt with the latencies by adding complexity to the CPU, whereas memory mapped CPUs translated that complexity to the chipset.

Yes, under a modern 32+ bit address space with the levels of integration designers have access to (MMUs etc), either port or memory mapping I/O really has no much advantage over the other. But at the time, Intel actually knew what they were doing and port mapping made perfect sense.

Edited 2012-01-02 00:30 UTC

Reply Parent Score: 2