Arbitration and Translation

A while back Jake Oshins answered a question on NTDEV about bus arbitration and afterwards I asked him if he could write a couple of posts about it for the blog. Here is part 1.

History Lesson

In the history of computing, most machines weren’t PCs.  PCs, and the related “industry standard” server platforms, may constitute a huge portion of the computers that have been sold in the last couple of decades, but even during that time, there have been countless machines, both big and small, which weren’t PCs.  Windows, at least those variants which are derived from Windows NT, (which include Windows XP and everything since,) was originally targeted at non-PC machines, specifically those with a MIPS processor and a custom motherboard which was designed by in-house at Microsoft.  In the fifteen years that followed that machine, NT ran on a whole pile of other machines, many with different processor architectures.

My own career path involved working on the port of Windows NT to PowerPC machines.  I wrote HALs and worked on device drivers for several RS/6000 workstations and servers which (briefly) ran NT.  When I came to Microsoft from IBM, the NT team was just getting into the meat of the PnP problem.  The Windows 95 team had already done quite a bit to understand PnP, but their problem space was really strongly constrained.  Win95 only ran on PCs, and only those with a single processor and a single root PCI bus.

Very quickly, I got sucked into the discussion about how to apply PnP concepts to machines which were not PCs, and also how to extend the driver model in ways that would continue to make it possible to have one driver which ran on any machine, PC or not.  If the processor target wasn’t x86, you’d need to recompile it.  But the code itself wouldn’t need changing.  If the processor target was x86, even if the machine wasn’t strictly a PC, your driver would just run.

In order to talk about non-PC bus architectures, I want to briefly cover PC buses, for contrast.  PC’s have two address spaces, I/O and memory.  You use different instructions to access each.  I/O uses “IN, OUT, INS, and OUTS.”  That’s it.  Memory uses just about any other instruction, at least any that can involve a pointer.  I/O has no way of indirecting it, like virtual memory indirects memory.  That’s all I’ll say about those here.  If you want more detail, there have been hundreds of good explanations for this.  My favorite comes from Mindshare’s ISA System Architecture, although that’s partly because that one existed back when I didn’t fully understand the problem space.  Perhaps there are better ones now.

In the early PC days, the processor bus and the I/O bus weren’t really separate.  There were distinctions, but those weren’t strongly delineated until PCI came along, in the early ‘90s.  PCI was successful and enduring because, in no small part, it was defined entirely without reference to a specific processor or processor architecture.  The PCI Spec has almost completely avoided talking about anything that happens outside of the PCI bus.  This means, however, that any specific implementation has to have something which bridges the PCI spec to the processor bus.  (I’m saying “processor bus” loosely here to mean any system of interconnecting processors, memory and the non-cache-coherent I/O domains.  This sometimes gets referred to as a “North Bridge,” too.)

The processor bus then gets mapped onto the I/O subsystem, specifically one or more root PCI buses.  The following diagram shows a machine that has two root PCI buses (which is not at all typical this year, but was very typical of PC servers a decade ago.)  The specific addresses could change from motherboard to motherboard and were reported to the OS by the BIOS.

Read more: A Hole In My Head

Posted via email from jasper22's posterous