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.
Chip Overclock, "Separate But Equal", January 2007