Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!eagle!allegra!alice!rob
From: r...@alice.UUCP
Newsgroups: net.unix-wizards
Subject: Blits and terminal paging
Message-ID: <2568@alice.UUCP>
Date: Fri, 3-Feb-84 02:32:22 EST
Article-I.D.: alice.2568
Posted: Fri Feb 3 02:32:22 1984
Date-Received: Wed, 8-Feb-84 03:14:45 EST
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 87
I have been implicated in the TTY paging discussion in some private mail,
so here is how the (to you) unobtainable Blit affects my world view:
Bart Locanthi and I built the Blit to provide cheap high-performance
interactive graphics in our time-shared Unix computing environment.
I think that, looking back, we are both surprised at how it turned out,
and particularly that it is so popular and useful. The surprise is
because the important decisions, from a systems point of view, were
made in almost complete ignorance of how the terminal would be used.
We were at least as lucky as we were capable.
The Blit runs much like an extension of the Unix kernel, off-loading
the expensive computation required for high-performance interaction,
but staying tightly coupled (at least in function; it can run over
1200 baud telephone lines) to the Unix host.
Many people, perhaps most, ask why we didn't just make the Blit a personal
computer. The answer is that we didn't want personal computers,
but the question can be rephrased as, "Why don't you turn it into
a personal computer?" and the answer becomes more interesting, and
unexpected:
The division of function enforced by the architecture of a
programmable terminal separated by an RS-232 line forces some
design decisions that would not be made otherwise. We were
lucky in that many of those decisions result in better
interaction, simpler function and much simpler software
than what would develop were the same functionality provided
on the host.
This is hard to defend in a brief note, because the reasons are many
small things rather than a couple of obvious advantages, but one
exemplary effect is that the operating system running in the terminal
(sic) has a much simpler structure than Unix -- in fact, it is a real-time
system; getting such good interaction from Unix would require a fair
bit of real-time functionality in the Unix kernel. We were able to
avoid that morass altogether.
So where does terminal paging come in? The Blit is the interaction
box, but is tightly coupled to Unix. In (at least the research version
of) the Blit software, the tty driver runs in the terminal itself,
connecting directly to the bare I/O system in the kernel. As a result,
characters can be echoed locally (by the terminal) although the terminal
is running full-duplex -- the Blit interprets the stty structure itself
-- and Unix programs are completely unaware that the tty driver is
running in the terminal.
This architecture has enabled us to write a Unix tty driver that
employs high-quality interactive computer graphics. The Blit lets
you copy text from window to window, edit text on the screen and
retransmit it (unlike csh history, this works for any command and
on output as well as input), and interactively control when the
terminal scrolls. The default is to never scroll without an explicit
command, but if you want it to always scroll, just say so with the mouse.
All this is achieved without adding special-purpose code to the kernel,
although it does depend on the IPC mechanisms of the current research
Unix system.
Although the Blit is renowned for its windowing, this high-level
support for interactive text manipulation is closer to the original
spirit of the terminal, and, I feel, at least as important.
This is probably a religious issue; the terminal feels so different
that many users don't run this new software on their Blits, but they
will in time. Paper terminals aren't too common any more.
So discussing whether paging belongs in the kernel is skirting
the real issue. Paging is only an instance of control over the
contents of the display, and convenient though it may or may not be,
it opens the door to a bewildering array of features that do
not belong in the Unix kernel, but that
fit perfectly into a different architecture: one that admits
that interaction is important. I never used display editors until
my terminal had a mouse, because two-dimensional output is too
clumsy to manipulate with one-dimensional input. Since all the
interaction with Unix involves text in one form or another, the
obvious step is to develop the interactive components of the
system until the `text editor' merely couples the general text-
editing capabilities to files on disk.
Such integration is difficult, of course, and I offer no solace
to those without Blits. But I encourage those who would hack the
kernel for more interaction to at least be aware of what they
should be trying to achieve, and how much they can realistically
accomplish.
Rob Pike
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!seismo!rlgvax!guy
From: g...@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Blits and terminal paging
Message-ID: <1659@rlgvax.UUCP>
Date: Sat, 4-Feb-84 18:57:20 EST
Article-I.D.: rlgvax.1659
Posted: Sat Feb 4 18:57:20 1984
Date-Received: Thu, 9-Feb-84 06:53:56 EST
References: <2568@alice.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 53
> Many people, perhaps most, ask why we didn't just make the Blit a personal
> computer. The answer is that we didn't want personal computers,
> but the question can be rephrased as, "Why don't you turn it into
> a personal computer?" and the answer becomes more interesting, and
> unexpected:
> The division of function enforced by the architecture of a
> programmable terminal separated by an RS-232 line forces some
> design decisions that would not be made otherwise. We were
> lucky in that many of those decisions result in better
> interaction, simpler function and much simpler software
> than what would develop were the same functionality provided
> on the host.
Actually, the question I'd ask is "why is the Blit different from a
personal computer?" I consider it to be as different from what is called
a "terminal" as it is from a personal computer. In a lot of the type of
software one runs on a very intelligent terminal, there is a lot of computation
involved in interacting with the user. A word processor, for instance, must
recompute line endings and possibly even page breaks as the user types; a
graphics editor must move, rescale, and otherwise modify figures; and so
forth. Most "smart" terminals provide little more than forms fill-in
capability and some local reformatting of text, but for "dumb" and "smart"
terminals, and even a lot of "intelligent" terminals, the only processing
done in the terminal is the limited rearrangement of text already formatted
at the host.
> This is hard to defend in a brief note, because the reasons are many
> small things rather than a couple of obvious advantages, but one
> exemplary effect is that the operating system running in the terminal
> (sic) has a much simpler structure than Unix -- in fact, it is a real-time
> system; getting such good interaction from Unix would require a fair
> bit of real-time functionality in the Unix kernel. We were able to
> avoid that morass altogether.
Many desktop workstations running UNIX are now coming out; they may have
modified UNIX specifically so that it can provide this sort of real-time
response. There is nothing in the structure of UNIX that absolutely requires
it to be oriented to multi-user time-shared operations; to some degree, that
is merely a policy decision made by the UNIX scheduler. The simplicity of
the Blit OS is probably due to its not having to provide all the features
of a multi-user system supporting a file system and similar services.
This does, however, raise an interesting discussion about what the
appropriate architecture for "desktop computing" is; what operations should
be performed in a centralized host and what operations should be performed
in the desktop computer (which I count the Blit as, based on the assumption
that in a text editor the reformatting of text under insertions and deletions
is done in the Blit and that in graphic applications the movement of
figures is also done in the Blit).
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy