So the PDP-7 code from Norman has a B interpreter. I know the history:
BCPL -> B -> NB -> C, but I don't recall seeing a decent decription of
the B language. Does anybody know of such a document? We'll need something
like this so we can use the interpreter once we get it working :-)
Cheers, Warren
I grabbed a copy as well. A quick grep showed something I had forgotten:
I ran a Source redistribution service.
David
>
> On Tue, 2 Feb 2016, Warren Toomey wrote:
>
>> This is temporarily at http://www.tuhs.org/Usenet/Usenet.tar.bz2 if
>> anybody else would like to grab it.
>
> Suitably grabbed :-) I know, I must finish my mirror some day (got a few
> health issues right now)...
>
At www.skeeve.com/Usenet.tar.bz2 is a copy of UUNET's archives of the
various USENET source newsgroups. I created this file on September 2 2004.
I made it for myself, since it was clear that uu.net would disappear
sometime soon...
It's 139 Meg - Warren maybe you can put it into the archives and everyone
else can get it from there? I think the person who hosts www.skeeve.com
has some monthly limits on data transfer and I don't want him blown
out of the water.
Thanks,
Arnold
> I'm still trying to get my around about how a program such as "egrep"
> which handles complex patterns can be faster than one that doesn't
> Is there a simple explanation, involving small words?
First, the big-word explanation. Grep is implemented as a nondeterministic
finite automaton, egrep as a deterministic finite automaton. Theory folk
abbreviate these terms to "NFA" and "DFA", but these are probably not
what you had in mind as "small words".
The way grep works is to keep a record of possible partial parsings
as it scans the subject text; it doesn't know which (if any) will
ultimately be the right one, hence "nondeterministic". For example,
suppose grep seeks pattern '^a.*bbbc' in text 'a.*bbbbbbc'. When
it has read past 3 b's, the possible partial parses are 'a.*', 'a.*b',
'a.*bb' and 'a.*bbb'. If it then reads another b, it splits the
first partial parse into 'a.*' and 'a.*b', updates the next two
to 'a.*bb' and 'a.*bbb', and kills off the fourth. If instead it
reads a c, recognition is successful; if anything else, all partials
are killed and recognition fails.
Egrep, by preprocessing the expression, produces separate code for
each of several possible states: "no b's", "1 b", 2 b's" and "3 bs".
When it's in state "1 b", for example, it switches on the next
character into "2 b's" or fails, depending on whether the
character is b or not--very fast. Grep, on the other hand, has to
update all the live parses.
So if egrep is so fast, why do we have grep? One reason is that
grep only needs to keep a list of possible progress points
in the expression. This list can't be longer than the expression.
In egrep, though, each state is a subset of progress points.
The number of possible subsets is exponential in the length
of the expression, so the recognition machine that egrep constructs
before attempting the parse can explode--perhaps overflowing
memory, or perhaps taking so long in construction that grep
can finish its slow parse before egrep even begins its fast parse.
To revert to the words of theory folks, grep takes time O(m*n) and
space O(m) worst case, while egrep takes time and space O(2^m+n).
(2^m is an overestimate, but you get the idea.)
That's the short story. In real life egrep overcomes the exponential
by lazily constructing the machine--not generating a state until it
is encountered in the parse, so no more than n states get constructed.
It's a complex program, though, for the already fancy preprocessing
must be interleaved with the parsing.
Egrep is a tour de force of classical computer science, and pays
off big on scanning big files. Still, there's a lot to say for
the simple elegance of grep (and the theoretical simplicity
of nondeterministic automata). On small jobs it can often win.
And it is guaranteed to work in O(m) memory, while egrep may need
O(n).
-------------------------------------------------
Ken Thompson invented the grep algorithm and published it in CACM.
A pointy-headed reviewer for Computing Reviews scoffed: why would
anybody want to use the method when a DFA could do the recognition
in time O(n)? Of course the reviewer overlooked the potentially
exponential costs of constructing a DFA.
Some years later Al Aho wrote the more complicated egrep in the
expectation that bad exponential cases wouldn't happen in everyday life.
But one did. This job took 30 seconds' preprocessing to prepare
for a fraction of a second's parsing. Chagrined, Al conceived
the lazy-evaluation trick to overcome the exponential and
achieved O(n) run time, albeit with a big linear constant.
In regard to the "short history of grep", I have always thought
my request that Ken liberate regular expressions from ed caused
him to write grep. I asked him one afternoon, but I can't remember
whether I asked in person or by email. Anyway, next morning I
got an email message directing me to grep. If Ken took it
from his hip pocket, I was unaware. I'll have to ask him.
Doug
A friend just sent me a pointer to this site, which appears not
to have been mentioned on this list before:
PDP 11/70 Emulator
http://skn.noip.me/pdp11/pdp11.html
The site lists these working guest O/Ses:
RL0 BSD 2.9
RL1 RSX 11M v3.2
RL2 RSTS/E v7.0
RL3 XXDP
RK0 Unix V5
RK1 RT11 v4.0
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
All, I've got the original PDP-7 cat working in my PDP-7 user-mode
simulator called "a7out". The cat.s source code and the a7out program are
in the Github repository in src/cmds and tools, respectively.
The repository is at https://github.com/DoctorWkt/pdp7-unix
The mailing list is at http://minnie.tuhs.org/pipermail/pdp7-unix/
I'm attaching the a.out assembly output as the as7 assembler in the
repository currently is not quite ready for cat.s.
To run the original cat, create a text file, e.g. echo hello > file1
$ ./a7out a.out file1
hello <- the output of the PDP-7 machine code
Cheers, Warren
P.S Thanks again to Norman for getting us the scans.
> Norman Wilson is going to try and get us some higher quality scans which
will help a great deal in deciphering some of the hard to read characters.
A second scan, high or low quality, is a tremendous help. Diffing them
is a really good way to spot trouble.
Doug
On Thu, Feb 25, 2016 at 01:43:03PM -0500, Robert Swierczek wrote:
> Do you know if anybody has taken up the challenge of transcribing and
> simulating the PDP-7 Unix source code you have uncovered in your
> post http://minnie.tuhs.org/pipermail/tuhs/2016-February/006622.html
> If not, I would love to get started on it as a project.
Hi Robert, yes there is a project underway to type it all in and bring it
up on SimH and hopefully on a real PDP-7. I've set up a mailing list for
the project, so let me know if you would like to join: I'll add you.
The repository is at https://github.com/DoctorWkt/pdp7-unix. I've started
on the S1 section (in scans/), and I've also started work on an assembler
and a user-mode simulator (in tools/)
Norman Wilson is going to try and get us some higher quality scans which
will help a great deal in deciphering some of the hard to read characters.
Cheers, Warren
> From: Random832
> They're 24 bits, aren't they?
Not according to the source:
typedef long daddr_t;
daddr_t s_fsize; /* size in blocks of entire volume */
short s_nfree; /* number of addresses in s_free */
daddr_t s_free[NICFREE];/* free block list */
(from param.h and filsys.h respectively).
> From: Ron Natalie
> The V6 block numbers were 24 bits.
Maybe you're thinking of the byte number within the file? The file length
was stored in an word plus a byte in the inode in V6:
char i_size0;
char *i_size1;
but the block number in the device was a word:
int s_fsize; /* size in blocks of entire volume */
int s_nfree; /* number of in core free blocks (0-100) */
int s_free[100]; /* in core free blocks */
"Use the source, Luke!"
Noel
> From: Will Senn
> Is there a good source of information about the Unix v6 filesystem
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5
> Also, is there a source for the history of the early Unix filesystems
> from v6 onward?
I don't know of one (although there is that article on the 4.2 filesystem),
but would love to hear of one.
I gather that V7 is basically V6 except the block numbers are 32 bits, not 16.
Noel
On Sun, Feb 21, 2016 at 09:21:14PM -0600, Will Senn wrote:
> Thanks for the link. The tools look useful. But, they appear to be extract from tape rather than create tape utils? I am away from a computer but will try them out later to make sure.
No, my bad. I thought they would make tapes, but I read the Readme files
and it doesn't look so. You could modify the mkfs.c tool that I wrote at
https://github.com/DoctorWkt/unix-jun72/blob/master/tools/mkfs.c
to write V6 filesystems. It shouldn't be too hard.
Cheers, Warren
Sometime back before the turn of the century, I remember
writing up a summary of the evolution of the UNIX file
system, starting with the earliest system I could find
information for (possibly the PDP-7 system) and running
through the printed manuals as things changed, up to
the Seventh Edition.
I think I've found it; I'll look it over and try to put
it somewhere on the web in the next day or two.
Norman Wilson
Toronto ON
> From: Will Senn
> Thanks for the link.
Sure. It's worth reading the entire V6 manual if you're going to be doing a
lot with it - lots of goodies hidden in places like that. Also the two BSTJ
Unix issues. (I think they are available online, now.)
> Supposing I created a byte faithful representation of a V6 filesystem
> on my mac, would I then be able to load the file in simh as an RK05 and
> mount and access its files and directories from a V6 instance?
That's really a SIMH question, and I don't use SIMH; I use Ersatz11. That is
certainly how Ersatz11 works; I just FTP'd the RK05 distro images over, set
them up as the files that 'implemented' various RK05 drives, and (modulo a
few teething Ersatz11 configuration issues) away it went.
Noel
> From: Random832
> That's the superblock. Look in ino.h.
Oh, right you are. Thanks for catching my mistake! (I don't have anything
like the same familiarity with V7 as I do with V6; never did any system
hacking on the former.)
Now that you mention it, I do seem to remember this kludge; IIRC, a later
Unix paper described the V7 inode layout. I never looked at the actual code,
though. Now that I do, it looks like iexpand() (in iget.c) is not exactly
portable! On a machine with a different byte order for the bytes within a
long, that ain't gonna work...
Noel
Hi all, Norman Wilson has kindly scanned in some PDP-7 Unix
source code that he has kept hidden away. I've just added
it into the Unix Archive at:
http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/
I've updated the Readme with the details. The files are 0*.pdf.
I'm not sure if there's enough there to bring up a kernel and
some applications. I'll leave that to someone who knows PDP-7
assembly programming :-)
Many thanks Norman!
Cheers, Warren
Of some possible intertest to the denizens here...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
---------- Forwarded message ----------
Date: Mon, 15 Feb 2016 07:11:44 +1100 (EST)
From: Dave Horsfall <dave(a)horsfall.org>
To: Applix List
Subject: APPLIX-L On this day... (Wirth, Feynman)
We gained Niklaus Wirth, otherwise known as Mr ALGOL (and thereby freeing
us from the chains of FORTRAN), back in 1934; you can either call him by
name, or call him by value (non-programmers are not expected to understand
this computer joke).
Upon the other paw, we lost Richard Feynman, back in 1988; he was the
bloke who sorted out those NASA management liars, over that little O-ring
incident... Well, that's what happens when the suits ignore the
engineers.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
John von Neumann halted in 1957; without him, we probably would not have
had computers as we know them (CPU-buss-memory etc).
--
Dave Horsfall
Unit 13, 79 Glennie St
North Gosford NSW 2250
0490 095 371
> There is a Henry Spencer <henry(a)spsystems.net>, who about a year ago or
> so posted to the IETF TLS list and posted to comp.compilers a decade
> ago.
I believe that's The Henry Spencer, all right. SP Systems is what
called (perhaps still does) himself when consulting.
I've already dug up and sent Warren another contact address for Henry,
gleaned from a mutual friend.
Norman Wilson*
Toronto ON
(Not to be confused with Norman D. Wilson, civil engineer,
after whom Wilson Avenue in Toronto is named)
One half of Unix, and what more can I say?
Well, I'll bet not many people know that he shares a birthday with Alice
Cooper...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Ken kindly tells me that both stories are right, though clearly
my impression that my query prompted Ken to write grep is wrong:
i dont see any differences between our stories.
you asked and i dug around and found it.
Would we have greps today, had that little incident not occurred?
Doug
All, I've spent some time working on the UTZoo Usenet Archive postings
from https://archive.org/download/utzoo-wiseman-usenet-archive
I've reformatted each group's postings into mbox format so I could run
them through the mailman archive tool. The results are here:
http://www.tuhs.org/Usenet/ You can now browse by group/year/month/thread.
I'll drop an index.html file in there tomorrow with a description of
each newsgroup. There are still some blemishes to fix up, as the archiver
failed to recognise the headers on some articles and they end up "posted"
in February 2016.
Other newgroups archives are here: https://archive.org/search.php?query=usenet. I might pull out some other Unix relates groups (aus.sources etc.) and
add them. Are there any other Usenet archives around?
Cheers, Warren
P.S If anybody is still trying to recover the old 2.11BSD patches, you may
find some of them lurking in http://www.tuhs.org/Usenet/comp.bugs.2bsd/
