Wednesday, November 08, 2017

The Kernel

(photo credit: Dale Courte)

The Kernel - which is the only name it ever had, long predating the use of the term in the context of Linux - was a tiny little real-time operating system kernel written in PDP-11 assembler language circa 1980 by Dayton Clark when he was a graduate student in computer science at Wright State University. The Kernel was used in the infamous CS431 Advanced Programming course, which later became CEG431 Real-Time Software Design when the degree program split into seperate Computer Science and Computer Engineering majors. CS431 was developed by Wright State professors Bob Dixon and Joe Kohler. Over the span of the ten week quarter, students had to complete a complex multi-threaded application which used the Kernel to synchronize and communicate among several threads, each of which controlled interrupt driven I/O devices, some of which supported DMA. It was all written in PDP-11 assembler and ran in a total of eight kilobytes of core memory on a PDP-11/05. The course culminated in an oral exam featuring a dump analysis. You had to pass the oral exam to pass the course.

CS431 was required for undergraduate computer science/computer engineering majors to graduate, and for graduate students to take upper division graduate courses. Students either loved it or hated it. Area employers, who for the most part were heavily into defense-related embedded development in the neighborhood of the ginormous Wright-Patterson Air Force Base, loved it. And perhaps for that reason, some students came to love it in retrospect.

Around 1982 through 1985, the code was substantially cleaned up, refactored, and documented by John Sloan and David Hemmendinger, both of whom, along with Dale Courte and others, all graduate students, went on to teach the course. The kernel was split into two source files, the pure code System part, and the impure data Control Block part, to expedite burning the pure portion into EEPROM. It supported process creation and destruction, counting semaphore wait and signal, and asynchronous message passing. It did so in only a handful of PDP-11 machine instructions.

Besides being used pedagogically, the Kernel made its way into a number of other research projects, including SLICK (which supported message passing among a network of LSI-11 microprocessors), TASK4TH (a FORTH-based LSI-11 workstation for real-time data acquisition and robotic control), and FPS (a functional programming system). The Kernel was ported to a number of other microprocessor targets, re-written in C and C++, and, rumor has it, used by former students in their own production systems in the commercial and defense sectors. My alter ego John Sloan wrote a technical report describing the Kernel in detail, as well as suggesting techniques for debugging embedded applications that use it, which was always a challenge.

It is tempting to say that the Kernel is of historical interest only. But tiny little microkernels taking only a few machine instructions have come into vogue as minuscule microcontrollers become embedded in everything. The Kernel was more than a tool used to teach a class. It has informed my career for the past thirty-five years.
(2017-11-08: To facilitate the efforts of far future - and, it must be said, extremely hypothetical - cyberarcheologists, the source code for the Kernel, the technical report, and other related material, have been stored in a repository on GitHub: .)

Monday, October 30, 2017

xkcd: Digital Resource Lifespan

Today's excellent (as usual) xkcd cartoon by Randall Munroe reminds us of the ephemerality of digital information.

Once again, this being a topic I have raised over and over in this blog, I'd like to mention that the definitive work on this topic is
Jeff Rothenberg, "Ensuring the Longevity of Digital Documents", Scientific American, vol. 272, no. 1, January 1995 .
A digital copy of Rothenberg's article can, at least at the moment, be found at .
It's well worth reading. And appropriately terrifying, given the season.

It's not just the digital media itself that has a (sometimes remarkably short) lifespan, but also the technology - both hardware and software - to read the media, and even the specifications that describe the format and encoding of the media. I've seen a vase from ancient Greece inscribed with art and symbols that are perfectly legible millennia later. I've been up close to a first edition of a book written by Galileo in the early 18th century. We can still read the letters John Adams and his wife Abagail wrote to one another during the time of the American war of independence. I have CD-ROMs that are just a few years old which are no longer usable. And trying to read the eight-inch floppy disks for the CP/M file system that have the text of my master's thesis in WordStar format? Good luck. (The thirty-four year old hardbound version on acid-free paper is completely legible.)

The only way to insure the longevity of digital information is to continuously refresh it onto new media using current technology. This becomes less and less practical as the amount of digital information continues to grow an a rate that can only be described as alarming.

Friday, October 27, 2017

You Cannot Cheat What You Do Not Measure

The international edition of the German magazine Spiegel has a two part article about the three graduate students who uncovered the huge emissions fraud by Volkswagen. This is of interest to motorheads and techies alike. The case is another great example of measurement dysfunction (and its kin incentive distortion, moral hazard, perverse incentives, unintended consequences, etc.) albeit on a enormous scale.