So I've been doing a bit of reading on 1A and 4ESS technologies lately, getting
a feel for the state of things just prior to 3B and 5ESS popping onto the scene,
and came across some BSTJ references to the programming environments involved
in the 4ESS and TSPS No. 1 systems.
The general assembly system targeting the 1A machine language was known as
SPC-SWAP (SWitching Assembly Program)[1](p. 206) and ran under OS/360/370, with
editing typically performed in QED. This then gave way to the EPL (ESS
Programming Language) and ultimately EPLX (EPL eXtra)[2](p. 1)[3](p. 8)
languages which, among other things, were used for later 4ESS work with cross-
compilers for at least TSS/360 by the sounds of it.
Are there any recollections of attempts by the Bell System to rebase any of
these 1A-targeting environments into UNIX, or by the time UNIX was being
considered more broadly for Bell System projects, was 3B/5ESS technology well on
the way, rendering attempting to move entrenched IBM-based environments for the
older switching computation systems moot?
For the record, in addition to the evolution of ESS to the 5ESS generation, a
revision of TSPS, 1B, was also introduced which was rebased on the 3B20D
processor and utilized the same 3B cross-compilation SGS under UNIX as other 3B-
targeted applications[4]. Interestingly, the paper on software development
in [4](p. 109) still makes reference to Programmer's Workbench as of 1982,
implying that nomenclature may have still been the norm at some Bell Labs sites
such as Naperville, Illinois, although I can't tell if they're referring to
PWB as in the branch of UNIX or the environment of make, sccs, etc.
Additionally, is anyone aware of surviving accessible specimens of SWAP
assembly, EPL, or EPLX code or literature beyond the BSTJ references and paper
referenced in the IEEE library below? Thanks for any insights!
- Matt G.
[1] - https://bitsavers.org/magazines/Bell_System_Technical_Journal/BSTJ_V58N06_1…
[2] - https://ieeexplore.ieee.org/document/810323
[3] - https://bitsavers.org/magazines/Bell_System_Technical_Journal/BSTJ_V60N06_1…
[4] - https://bitsavers.org/magazines/Bell_System_Technical_Journal/BSTJ_V62N03_1…
> Doug McIlroy was generating random regular expressions
Actually not. I exhaustively (within limits) tested an RE recognizer
without knowingly generating any RE either mechanically or by hand.
The trick: From recursive equations (easily derived from the grammar of
REs), I counted how many REs exist up to various limits on token counts,
Then I generated all strings that satisfied those limits, turned the
recognizer loose on them and counted how many it accepted. Any disagreement
of counts revealed the existence (but not any symptom) of bugs.
Unlike most diagnostic techniques, this scheme produces a certificate of
(very high odds on) correctness over a representative subdomain. The scheme
also agnostically checks behavior on bad inputs as well as good. It does
not, however, provide a stress test of a recognizer's capacity limits. And
its exponential nature limits its applicability to rather small domains.
(REs have only 5 distinct kinds of token.)
Doug
Hi folks,
I'm finding it difficult to find any direct sources on the question in
the subject line.
Does anyone here have any source material they can point me to
documenting the existence of a port of BSD curses to Unix Version 7?
I know that curses made it into 2.9BSD for the PDP-11, but that's not
quite the same thing.
There are comments in System V Release 2's curses.h file[1][2] (very
different from 4BSD's[3]) that suggest some effort to accommodate
Version 7's terminal driver. So I would _presume_ that curses got
ported to Version 7. But that's System V, right when it started
diverging from BSD curses, and moreover, presumption is not evidence.
Even personal accounts/anecdotes would be helpful. Maybe some of you
_wrote_ curses applications for Version 7 machines.
Regards,
Branden
[1] System III apparently did not have curses at all. Both it and 4BSD
were released in 1980. System V Release 1 doesn't seem to, either.
[2] https://github.com/ryanwoodsmall/oldsysv/blob/master/sysvr2-vax/include/cur…
[3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/include/curses.h
with my pedantic head on…
The “7th Edition” was the name of the Perkin Elmer port (nee Interdata), derived from Richard Miller’s work.
This was Unix Version 7 from the labs, with a v6 C compiler, with vi, csh, and curses from 2.4BSD (though we where never 100% sure about this version).
You never forget your first Unix :-)
-Steve
All,
I can't believe it's been 9 years since I wrote up my original notes on
getting Research Unix v7 running in SIMH. Crazy how time flies. Well,
this past week Clem found a bug in my scripts that create tape images.
It seem like they were missing a tape mark at the end. Not a showstopper
by any means, but we like to keep a clean house. So, I applied his fixes
and updated the scripts along with the resultant tape image and Warren
has updated them in the archive:
https://www.tuhs.org/Archive/Distributions/Research/Keith_Bostic_v7/
I've also updated the note to address the fixes, to use the latest
version of Open-SIMH on Linux Mint 21.3 "Virginia" (my host of choice
these days), and to bring the transcripts up to date:
https://decuser.github.io/unix/research-unix/v7/2024/05/23/research-unix-v7…
Later,
Will
Well this is obviously a hot button topic. AFAIK I was nearby when fuzz-testing for software was invented. I was the main advocate for hiring Andy Payne into the Digital Cambridge Research Lab. One of his little projects was a thing that generated random but correct C programs and fed them to different compilers or compilers with different switches to see if they crashed or generated incorrect results. Overnight, his tester filed 300 or so bug reports against the Digital C compiler. This was met with substantial pushback, but it was a mostly an issue that many of the reports traced to the same underlying bugs.
Bill McKeemon expanded the technique and published "Differential Testing of Software" https://www.cs.swarthmore.edu/~bylvisa1/cs97/f13/Papers/DifferentialTesting…
Andy had encountered the underlying idea while working as an intern on the Alpha processor development team. Among many other testers, they used an architectural tester called REX to generate more or less random sequences of instructions, which were then run through different simulation chains (functional, RTL, cycle-accurate) to see if they did the same thing. Finding user-accessible bugs in hardware seems like a good thing.
The point of generating correct programs (mentioned under the term LangSec here) goes a long way to avoid irritating the maintainers. Making the test cases short is also maintainer-friendly. The test generator is also in a position to annotate the source with exactly what it is supposed to do, which is also helpful.
-L
I'm surprised by nonchalance about bad inputs evoking bad program behavior.
That attitude may have been excusable 50 years ago. By now, though, we have
seen so much malicious exploitation of open avenues of "undefined behavior"
that we can no longer ignore bugs that "can't happen when using the tool
correctly". Mature software should not brook incorrect usage.
"Bailing out near line 1" is a sign of defensive precautions. Crashes and
unjustified output betray their absence.
I commend attention to the LangSec movement, which advocates for rigorously
enforced separation between legal and illegal inputs.
Doug
>> Another non-descriptive style of error message that I admired was that
>> of Berkeley Pascal's syntax diagnostics. When the LR parser could not
>> proceed, it reported where, and automatically provided a sample token
>> that would allow the parsing to progress. I found this uniform
>> convention to be at least as informative as distinct hand-crafted
>> messages, which almost by definition can't foresee every contingency.
>> Alas, this elegant scheme seems not to have inspired imitators.
> The hazard with this approach is that the suggested syntactic correction
> might simply lead the user farther into the weeds
I don't think there's enough experience to justify this claim. Before I
experienced the Berkeley compiler, I would have thought such bad outcomes
were inevitable in any language. Although the compilers' suggestions often
bore little or no relationship to the real correction, I always found them
informative. In particular, the utterly consistent style assured there was
never an issue of ambiguity or of technical jargon.
The compiler taught me Pascal in an evening. I had scanned the Pascal
Report a couple of years before but had never written a Pascal program.
With no manual at hand, I looked at one program to find out what
mumbo-jumbo had to come first and how to print integers, then wrote the
rest by trial and error. Within a couple of hours I had a working program
good enough to pass muster in an ACM journal.
An example arose that one might think would lead "into the weeds". The
parser balked before 'or' in a compound Boolean expression like 'a=b and
c=d or x=y'. It couldn't suggest a right paren because no left paren had
been seen. Whatever suggestion it did make (perhaps 'then') was enough to
lead me to insert a remote left paren and teach me that parens are required
around Boolean-valued subexpressions. (I will agree that this lesson might
be less clear to a programming novice, but so might be many conventional
diagnostics, e.g. "no effect".)
Doug
