Re: On I/O and memory address space

["John R Pierce" <pierce@hogranch.com>]

> >as long as you keep them to 256B apiece, I see no reason why BIOSes
> >should have any trouble with them.  If it's the resource consumption
> >issue that you're worried about (the fact that one of your cards will
> >eat three times the amount of I/O space used by a typical LAN or SCSI
> >device), then you need to take the larger issues of system
> >configuration into account.  How much total I/O space will be
> >available for *all* PCI devices on the platforms you're targeting?
> 
> 
> 
> As for now, I am targetting for x86 platform. PCI spec does not specifically
> put any limit on the total amount of I/O address space on a system except
> that an I/O address is 32 bits, but I do not know how much BIOS (or
> different BIOS's) really allocate. It also depends on the CPU limitations.

A PC I/O address is SIXTEEN bits.

Further, legacy ISA decoding practices makes a mockery of this.  Most legacy
ISA I/O devices only decoded TEN bits, and many used the high order 6 bits for
additional register selects.  On original AT machines, any address with (A9,A8)
== (0,0) was assumed to the motherboard, leaving only 0x100, 200, and 300 for
peripherals. These spaces are full of legacy devices that are hard coded
(serial ports at 3F8, 2F8, 3E8, 2E8; printer ports at 378, 278; CGA/EGA/VGA at
3Bx,3Cx,3Dx; sound blasters at 22x, 388, 201; FD controllers at 3F2-3F5; IDE
ports at 1Fx, 17x).  To further complicate things, various semi-standard
devices used some mighty squirrely techiques... 8514a derived graphics
controllers used 2E8 with most all the 10 bit 'alias' decodes (AE8, 12E8,
1AE8...FAE8) for registers.  The ProAudioSpectrum series of sound cards used
388 and all of its aliases up to FF88.

As a result of this morass of backwards compatibility, PCI I/O devices have to
be squeezed in between these spaces, at addresses that alias to 0xx, such as
10xx.  Grabbing 3 blocks of 256 would be difficult.  

Since the only reason for I/O decoding is simplifying real mode software (bios
initialization, perhaps DOS based diagnostics and bringup code), I'd think
going to a index / data scheme would be the way to go for I/O ports, and use a
linear BAR for the actual protected mode drivers (windows95, NT, unix etc all
support and prefer linear high address decoding).
€P=