Mention of elevators at Tech Square reminds me of visiting there
to see the Lisp machine. I was struck by cultural differences.
At the time we were using Jerqs, where multiple windows ran
like multiple time-sharing sessions. To me that behavior was a
no-brainer. Surprisingly, Lisp-machine windows didn't work that
way; only the user-selected active window got processor time.
The biggest difference was emacs, which no one used at Bell
Labs. Emacs, of course was native to the Lisp machine and
provided a powerful and smoothly extensible environment. For
example, its reflective ability made it easy to display a
list of its commands. "Call elevator" stood out amng mundane
programmering actions like cut, paste and run.
After scrolling through the command list, I wondered how long
it was and asked to have it counted. Easy, I thought, just
pass it to a wc-like program. But "just pass it" and "wc-like"
were not givens as they are in Unix culture. It took several
minutes for the gurus to do it--without leaving emacs, if I
remember right.
Doug
This question comes from a colleague, who works on compilers.
Given the definition `int x;` (without an initializer) in a source file the
corresponding object contains `x` in a "common" section. What this means is
that, at link time, if some object file explicitly allocates an 'x' (e.g.,
by specifying an initializer, so that 'x' appears in the data section for
that object file), use that; otherwise, allocate space for it at link time,
possibly in the BSS. If several source files contain such a declaration,
the linker allocates exactly one 'x' (or whatever identifier) as
appropriate. We've verified that this behavior was present as early as 6th
edition.
The question is, what is the origin of this concept and nomenclature?
FORTRAN, of course, has "common blocks": was that an inspiration for the
name? Where did the idea for the implicit behavior come from (FORTRAN
common blocks are explicit).
My colleague was particularly surprised that this seemed required: even at
this early stage, the `extern` keyword was present, so why bother with this
behavior? Why not, instead, make it a link-time error? Please note that if
two source files have initializers for these variables, then one gets a
multiple-definition link error. The 1988 ANSI standard made this an error
(or at least undefined behavior) but the functionality persists; GCC is
changing its default to prohibit it (my colleague works on clang).
Doug? Ken? Steve?
- Dan C.
Jon Steinhart:
One amusing thing that Steve told me which I think I can share is why the
symmetry of case-esac, if-fi was broken with with do-done; it was because
the od command existed so do-od wouldn't work!
=====
As I heard the story in the UNIX room decades ago (and at least five
years after the event), Steve tried and tried to convince Ken to
rename od so that he could have the symmetry he wanted. Ken was
unmoved.
Norman Wilson
Toronto ON
> From: Clem Cole
> when she found out the elevators were hacked and controlled by the
> student's different computers, she stopped using them and would take
> the stairs
It wasn't quite as major as this makes it sound! A couple of inconspicuous
wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran
the Knight displays) into the elevator controller, and run onto the terminals
where the wires from the 'down' call buttons on the 8th and 9th floors went.
So it wasn't anything major, and there was really no need for her to take the
stair (especially 8 flights up :-).
The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from
Knight TV keyboards; typing 'ESC E' called the elevator to the floor
that keyboard was on (there's a table, 'ELETAB', which gives the physical
floor for each keyboard).
The machine could also open the locked 9th floor door to the machine room
(with an 'ESC D'), and there some other less major things, e.g. print screen
hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run
out of the 'keyboard multiplexor'); it may have been something the AI Lab
built from scratch.
Noel
> When Bernie Greenberg did EMACS for Multics, he had a similar issue. I
> recall reading a document with an extensive discussion of how they dealt
> with this ... If anyone's really interested in this, and can't find it
> themselves, I can try looking for it.
I got a request for this; a Web search turned up:
https://www.multicians.org/mepap.html
which covers the points I mentioned (and more besides, such as why LISP was
chosen). I don't think this is the thing I remembered (which was, IIRC, an
informal note), but it does seem to be a later version of that.
Noel
> From: Otto Moerbeek <otto(a)drijf.net>
> I believe it was not only vi itself that was causing the load, it was
> also running many terminals in raw mode that killed performance.
I'm not familiar with the tty driver in late versions of Unix like 4.1 (sic),
but I'm very familiar with the one in V6, and it's not the raw mode _itself_
that caused the load (the code paths in the kernel for cooked and raw aren't
that different), but rather the need to wake up and run a process on every
character that was the real load.
When Bernie Greenberg did EMACS for Multics, he had a similar issue. I recall
reading a document with an extensive discussion of how they dealt with this,
especially when using the system over the ARPANET. IIRC, normal printing
characters were echoed without waking up the process; remotely, when using
the network. If anyone's really interested in this, and can't find it themselves,
I can try looking for it.
Noel
> From: Clem Cole <clemc(a)ccc.com>
> So, unless anyone else can illuminate, I'm not sure where the first cpp
> that some of us using v6 had originated.
I recall a prior extensive discussion about 'cpp'. I looked, and found it
(March 30, 2017) but it was a private discussion, not on TUHS (although you
were part of it :-). Here are clips of what I wrote (I don't want to re-post
what others wrote) from what I wrote, which tell most of the story:
There were a series of changes to C before V7 came out, resulting in the
so-called 'phototypsetter C compiler' (previously discussed on TUHS), and they
included the preprocessor. There's that series of short notes describing
changes to C (and the compiler), and they include mention of the preprocessor.
[Available here: http://gunkies.org/wiki/Typesetter_C for those who want to see
them.]
The MIT 'V6' Unix (which was, AFAICT, an augmented version of an early version
of PWB Unix) had that C compiler; and if you look at the PWB1 tree online, it
does have the C with 'cpp':
http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/c/c
I did a diff of that 'cpp' with the MIT one, and they are basically identical.
----
I went looking for the C manual in the V6 distro, to see if it mentioned the
pre-processor. And it does:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/c/c5
(Section 12, "Compiler control lines", about half way down.) So, I'm like,
'WTF? I just looked at cc.c and no mention of cpp!'
So I looked a little harder, and if you look at the cc.c in the distro (URL
above), you see this:
insym(&defloc, "define");
insym(&incloc, "include");
insym(&eifloc, "endif");
insym(&ifdloc, "ifdef");
insym(&ifnloc, "ifndef");
insym(&unxloc, "unix");
The pre-processor is integrated into 'cc' in the initial V6. So we do have a very
early version of it, after all...
----
So, 'cc' in V5 also included pre-processor support (just #define and #include,
though):
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c
Although we don't have the source to 'cc' to show it, V4 also appears to have
had it, per the man page:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/cc.1
"If the -p flag is used, only the macro prepass is run on all files whose name
ends in .c"; and the V4 system source:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys
also has .h files.
No sign of it in the man page for cc.1 in V3, though.
This all makes sense. .h files aren't any use with[out] #include, and without
#include, you have to have the structure definition, etc in multiple source
files. So #include would have gotten added very early on.
In V3, the system was apparently still in assembler, so no need.
-----
Also, there's an error in:
https://ewe2.ninja/computers/cno/
when it says "V6 was a very different beast for programming to V7. No c
preprocessor. The practical upshot of this is no #includes." that's
clearly incorrect (see above). Also, if you look at Lions (which is pure
early V6), in the source section, all the .c files have #include's.
Noel
Do we really need another boring old editor war? The topic
is not specific to UNIX in the least; nor, alas, is it historic.
Norman Wilson
Toronto ON
(typing this in qed)
