Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!think.com!mintaka!spdcc!iecc!johnl From: johnl@iecc.cambridge.ma.us (John R. Levine) Newsgroups: comp.arch Subject: Re: Offloading I/O [was:Incremental sync()s ...] Message-ID: <1991Mar19.004440.757@iecc.cambridge.ma.us> Date: 19 Mar 91 00:44:40 GMT References: <19838@cbmvax.commodore.com> <1088@spim.mips.COM> Organization: I.E.C.C. Lines: 45 In article <1088@spim.mips.COM> mash@mips.com (John Mashey) writes: >7. Make the IOP smart enough to distinguish between "ordinary" >characters which should be echoed, and stuck in an input queue, >and other characters and/or sequiences, which demanded response from >the CPU. Funny you should mention that. We did something like that on the GEM system at Yale in about 1976. The CPU was an 11/45 running 6th edition Unix (or maybe 7th by then.) The IOP was an 11/05 running a terminal emulator I wrote in C. They shared a chunk of screen buffer memory for 16 screens, the IOP had a keyboard multiplexor for the keyboards in front of the screens, and there was a word at a time interface between the /45 and the /05 that looked on each end like a paper tape reader and punch. (Paper tape was the usual boot device in those days, by emulating its interface we could boot the /05 with the standard boot ROM.) The /45 passed characters to the /05 to draw on the terminals, and the /05 passed back characters that were typed on the keyboards. We defined a variety of control sequences to handle the various special devices that we attached, e.g. "send 8KB of screen buffer to the D/A converter" that we used for real-time music synthesis. We had a screen editor, about a second cousin once removed of the Rand editor, that ran on the 11/45. It used a special editor input mode in Unix. All printing characters and "easy" control characters, e.g. cursor motion, were echoed directly. Anything else was passed to the application so it could update the screen. It really worked well. We could run 8 to 12 editor users on a poor little 11/45 with 208KB of RAM, total, with pretty much instantaneous response, in spite of the fact that the 11/05 had to draw the characters on the screen in software, there being no hardware character generator. In our implementation, the special editing mode was actually on the Unix side, since the /05 had to pass it the characters anyway, but the /05's ability to handle the easy screen updates itself was critical. One might claim that we took the "salvation through suffering" mentioned in the original CACM Unix paper to extremes, but we got an awful lot of computing done on some rather small computers. For further details you can see my 1982 article in Software Practice and Experience. -- John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl Cheap oil is an oxymoron.