Long time friend and colleague David Hemmendinger made the following remarks via e-mail about my article "Separate But Equal", but was perhaps too shy (that's hard to believe, David) to post them as comments:
"I think of IBM's channel architecture as another example of the control/data separation, similar to what you describe in the MSS. As to other examples -- the idea is fundamental to hardware design; standard digital design rules keep control logic and datapaths separate."
Dr. Hemmendinger might be more insightful than he knows here. The NCAR MSS that I described did in fact, at least at the time, make use of IBM I/O channels; the high-end storage devices it managed were controlled by an IBM mainframe. But the mainframe accessed those devices primarly for purposes of data migration and management of meta-data. The NCAR MSS switched I/O architecture (which it was using at least a decade before switched I/O became wide-spread) allowed its supercomputer clients to access the I/O devices directly.
Apart from the NCAR MSS, IBM's I/O channel architecture has been around at least since the late 1960s, and so may be one of the earliest examples of this pattern. I remember writing simple channel programs for tape drives in the mid-1970s during my IBM 360/370 assembler period. IBM's I/O Subsystem (IOS) was another first for me as well: it was the earliest example I can recall of using object oriented design and implementation for a real-time application, although the terms "object oriented" and "real-time" didn't really exist way back then. The example of the IOS has stuck with me for decades.
His second comment is spot on too: the separation of control and data is a standard pattern in digital hardware design.
Thanks, David!
Sources
Chip Overclock, "Separate But Equal", January 2007
Subscribe to:
Post Comments (Atom)
2 comments:
The separate but equal stuff can be problematic in some cases too. For example the FTP separate control and data connections cause havoc with firewalls and NAT.
I designed an RPC mechanism for the NCAR MSS software (replacing the OSF DCE RPC library used by the old MSS software) that utilizes shared connections for control and data to minimize these types of network security hassles, as well as minimize the resource usage (i.e. file descriptors) required.
This is one of the reasons that applications built as web services make so much sense: because everyone always has a web browser and an HTTP hole in their firewall, its possible to tunnel everything though HTTP and use the web browser as the platform for the client side.
Post a Comment