Interesting. My "speak" program had a trivial lexer that
recognized literal tokens, many of which were prefixes
of others, by maximum-munch binary search in a list of
1600 entries. Entries gave token+translation+rewrite.
The whole thing fit in 15K.
Many years later I wrote a regex recognizer that special-cased
alternations of lots of literals. I believe Gnu's regex.c does
that, too. (My regex also supported conjunction and negation--
legitimate regular-language operations--implemented by
continuation-passing to avoid huge finite-state machines.)
We have here a case of imperfect communication in 1127. Had I
been conscious of the lex-explosion problem, I might have
thought of speak and put support for speak-like tables
into lex. As it happened, I only used yacc/lex once, quite
successfully, for a small domain-specific language.
Doug
Steve Johnson wrote:
I also gave up on lex for parsing fairly early. The problem was
reserved words. These looked like identifiers, but the state machine to
pick out a couple of dozen reserved words out of all identifiers was too
big for the PDP-11. When I wrote spell, I ran into the same problem.
I had some rules that wanted to convert plurals to singular forms that
would be found in the dictionary. Writing a rule to recognize .*ies
and convert the "ies" to "y" blew out the memory after only a handful of
patterns. My solution was to pick up words and reverse them before
passing them through lex, so I looked for the pattern "sei.*", converted
it to "y" and then reversed the word again. As it turned out, I only
owned spell for a few weeks because Doug and others grabbed it and ran
with it.
From the 2.11 BSD sources I understand that the PDP-11/70 MMU address
and data registers, KDSA and KDSD, start at 0172360 and 0172320
respectively [1]. Yet, when I read the register contents I don't get
what I would expect to see: increasing by 0200 memory values for KDSA
and the same constant value for KDSD [2]. I checked this by looking at
/dev/mem.
# od -o /dev/mem 0172360 | head -1
0172360 000002 000016 001403 012700 000400 000402 012700 000200
# od /dev/mem 0172320 | head -1
0172320 101016 005064 000026 005067 175456 016467 000006 175430
I get the same results when I examine the memory through SIMH:
sim> examine 172360
172360: 000002
sim> examine 172362
172362: 000016
sim> examine 172364
172364: 001403
sim> examine 172320
172320: 101016
sim> examine 172322
172322: 005064
The MMU kernel instruction registers, KISA and KISD, contain similarly
nonsensical values as do the registers located at a different memory
location (077320, 0772360) indicated in another source [3]. What am I
missing?
My goal is to access from the console the kernel's u area. According to
mem(4) and the symbols in /unix, this should be at address 0140000.
Indeed, accessing it through /dev/kmem I get the expected results for
e.g. u_comm and u_uid. However, I have been unable to find it in the
machine's physical memory, hence my question regarding the MMU's operation.
[1]
https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L346
[2]
https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L247
[3] https://gunkies.org/wiki/PDP-11_Memory_Management
Diomidis
This time looking into non-blocking file access. I realise that the term has wider application, but right now my scope is “communication files” (tty’s, pipes, network connections).
As far as I can tell, prior to 1979 non-blocking access did not appear in the Spider lineage, nor did it appear in the NCP Unix lineage. First appearance of non-blocking behaviour seems to have been with Chesson’s multiplexed files where it is marked experimental (an experiment within an experiment, so to say) in 1979.
The first appearance resembling the modern form appears to have been with SysIII in 1980, where open() gains a O_NDELAY flag and appears to have had two uses: (i) when used on TTY devices it makes open() return without waiting for a carrier signal (and subsequent read() / write() calls on the descriptor return with 0, until the carrier/data is there); and (ii) on pipes and fifo’s, read() and write() will not block on an empty/full pipe, but return 0 instead. This behaviour seems to have continued into SysVR1, I’m not sure when EAGAIN came into use as a return value for this use case in the SysV lineage. Maybe with SysVR3 networking?
In the Research lineage, the above SysIII approach does not seem to exist, although the V8 manual page for open() says under BUGS "It should be possible [...] to optionally call open without the possibility of hanging waiting for carrier on communication lines.” In the same location for V10 it reads "It should be possible to call open without waiting for carrier on communication lines.”
The July 1981 design proposals for 4.2BSD note that SysIII non-blocking files are a useful feature and should be included in the new system. In Jan/Feb 1982 this appears to be coded up, although not all affected files are under SCCS tracking at that point in time. Non-blocking behaviour is changed from the SysIII semantics, in that EWOULDBLOCK is returned instead of 0 when progress is not possible. The non-blocking behaviour is extended beyond TTY’s and pipes to sockets, with additional errors (such as EINPROGRESS). At this time EWOULDBLOCK is not the same error number as EGAIN.
It would seem that the differences between the BSD and SysV lineages in this area persisted until around 2000 or so.
Is that a fair summary?
- - -
I’m not quite sure why the Research lineage did not include non-blocking behaviour, especially in view of the man page comments. Maybe it was seen as against the Unix philosophy, with select() offering sufficient mechanism to avoid blocking (with open() the hard corner case)?
In the SysIII code base, the FNDELAY flag is stored on the file pointer (i.e. with struct file). This has the effect that the flag is shared between processes using the same pointer, but can be changed in one process (using fcntl) without the knowledge of others. It seems more logical to me to have made it a per-process flag (i.e. with struct user) instead. In this aspect the SysIII semantics carry through to today’s Unix/Linux. Was this semantic a deliberate design choice, or simply an overlooked complication?
> I am now writing code in assembly for the PDP-11. I remember reading
> somewhere that the output from "AS" (my caps) is a bit meagre. I can't find
> an option to produce a text listing. Is it possible from AS, using command
> options (I can't see one) or perhaps from "LD"?
>
> Paul
>
> *Paul Riley*
I had the same problem. As I was porting to a different mini I had to write a new assembler. As you have undoubtedly seen, early ‘as’ was written in assembler and not so easy to use as a base. Hence I used Richard’s Miller’s AS for the Interdata as a base (available on Tuhs):
https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/as
Later I discovered that the TUHS archive has source code for the original ‘as’ rewritten in C, a work by Roger Jaeger:
https://minnie.tuhs.org/Archive/Distributions/USDL/Mini-Unix/
Maybe adding a listing module to this version of ‘as’ is another possible route.
below...
On Thu, Jun 11, 2020 at 9:04 AM Paul Riley <pdr0663(a)icloud.com> wrote:
> Clem,
>
> Thanks for that. So this would compile on modern machines to a cross
> compiler for V6 also running on a modern machine? I note you say macro11,
> so not a Unix “as” style syntax, is that right?
>
Yes - the AT&T syntax was much simpler/less sugar than the DEC assembler.
But the differences are pretty easy to see. IIRC that assembler generates
DEC style linker objects and there is a companion linker that can create
DEC binary objects (*i.e.* 'obj' files) as well as traditional UNIX a.out
format. The entire tool suite was created originally to move code from
RT-11 to UNIX at Harvard and passed around the nascent USENIX community.
IIRC that version was forked from a BSD 2.x/NetBSD source repository and
folks were adding some fields/features in the DEC obj format that RSX
supported that RT-11 did not.
Go hunting and see what you find. My memory was that with the BSD 2.x
project, somebody added a DEC obj to UNIX binary (a.out) converter tool, so
that you could use ld(1) instead of using the DEC style linker that had
been included in the original.
It has been >>years<< since I was really familiar with any of this stuff.
A question about it came up last fall/winter on the simh mailing listing,
which is where I found the the URL.
FWIW: I offered the modern port, assuming you might want to run some of it
as a cross-systems on a newer OS with a modern compiler. But if you are
content running this on V6, then you might just want to go back to the
original. As I said, my memory is that's in the original USENIX Harvard
tape. All that should be Warner's archives if not other places on the
Internet.
Just remember that a big problem with the original code is that it will be
written in pre-'White Book' C (that many of us learned years ago - not
even ANSI of Second edition - this used Lesk's portable C library etc.).
It sometimes looks a little strange to modern eyes. Also if you go
looking, IIRC, someone at Harvard ported the DEC Macro RT-11 library to
UNIX v6. In the late 1970s, I remember tjk, Danny Klein, Tron McConnell
and I, plus some of the folks over in the bio-med group (whose names I have
forgotten) had to a number assembler codes that had been written for the
earlier RT-11 systems to Unix for one of the projects we had. Some of it
got re-written in C, but I do remember we managed to use the Harvard
assembler somehow for parts of it. If my memory is correct, early VMS and
messing with BLISS compatibility could have been mixed up in the project
somehow, but I've long forgotten the details of what we were doing at the
time.
Have fun.
Team,
I am now writing code in assembly for the PDP-11. I remember reading
somewhere that the output from "AS" (my caps) is a bit meagre. I can't find
an option to produce a text listing. Is it possible from AS, using command
options (I can't see one) or perhaps from "LD"?
Paul
*Paul Riley*
I'm seeding this URL to TUHS as one would expect them to be interested in
the work from Warren and friends. FWIW: I tried to browse their archives
and was not impressed (I couldn't find anything).
https://www.softwareheritage.org/
> Steve Johnson's position paper on optimising compilers may amuse you:
> https://dl.acm.org/doi/abs/10.1145/567532.567542
Indeed. This passage struck a particular chord:
"I contend that the class of applications that depend on, for example, loop
optimization and dead code elimination for their efficient solution is of
modest size, growing smaller, and often very susceptible to expression in
applicative languages where the optimization is built into the individual
applicative operators."
I don't know whether I saw that note at the time, but since then I've
come to believe, particularly in regard to C, that one case of dead-code
elmination should be guaranteed. That case is if(0), where 0 is the
value of a constant expression.
This guarantee would take the place of many--possibly even
most--ifdefs. Every ifdef is an ugly intrusion and a pain to read.
Syntactically it occurs at top level completely out of sync with the
indentation and flow of text. Conversion to if would be a big win.
Doug
Does anybody have any good resources on the history of the popularity of C?
I'm looking for data to resolve a claim that C is so prolific and
influential because it's so easy to write a C compiler.
Tyler
> It's another similar to the last two. I've uploaded a version to youtube until the conference has theirs ready. It's a private link, but should work for anybody that has it. Now that I've given my talk it's cool to share more widely.
> The link at the end is wrong. https://github.com/bsdimp/bsdcan2020-demos is the proper link.
> Please let me know what you think.
Watched it & liked it a lot!
I have one nit-pick in the section on early networking: BBN's VAX TCP did not allow the ‘/dev/net/host’ syntax. That particular semantic comes from UoI’s NCP Unix, where the 8-bit host number was encoded in the minor number of character special file ‘host’ - but it did not carry through to the BBN code.
Other systems used something similar. The Chaos network code made namei() break when it recognised the Chaos driver and left the remainder of the path for the driver to fetch & parse. I’m also being told that Greg Chesson experimented with using the given name of a Datakit channel device as the connection string for the switch, but that this approach was abandoned early on.
In my view, exposing the host names through integration in the Unix file name space makes a lot of conceptual sense, but it unfortunately falls down on the practicalities, with the host name set being hard to enumerate (it is large, distributed and not stable - even back then).
A question mark is hard pin-pointing the start of Unix networking to V4 / 1974. Yes, that is the earliest evidence we currently have. However, Sandy Fraser says that Spider came into operation in 1972 and it must have connected to something. Maybe that something was a lab-bench test setup, but it could have been a computer - maybe even one running Unix.
There is another candidate for earliest Unix networking as well. The tech memo’s from Heinz Lycklama include one on the Glance terminal. That memo includes a section on the network used, referencing a 1973 report by D.R. Weller, "A High-Speed I/O Loop Communication System for the DEC PDP-11 Computer”. That computer appears to be an 11/45 running Unix and the loop is not Spider (nor the Pierce loop discussed in 1970/71 BSTJ). I have an off-list question outstanding to better understand this.
> On 6/6/20, Paul Ruizendaal <pnr at planet.nl
> > wrote:
> >
> > In my view, exposing the host names through integration in the Unix file
> > name space makes a lot of conceptual sense, but it unfortunately falls down
> > on the practicalities, with the host name set being hard to enumerate (it is
> > large, distributed and not stable - even back then).
> >
> With a proper dynamic VFS architecture, there is no reason why a
> resolver with a filesystem API has to bother supporting enumeration at
> all. All it needs to be able to do is respond to open() and stat()
> calls, returning ENOENT when resolution fails.
That is an intriguing thought. In Research Unix terms it would be a virtual directory that was not readable or writable, but still explorable (i.e. only the x bit set).
Maybe enumeration is only impractical for the networks that were designed to be ‘large’, such as Arpanet and Datakit. It would have been feasible for contemporary networks that were designed to be local only, such as Chaosnet or ARCnet.
A half-way house would be to only enumerate the local network and leaving everything else merely explorable. That is conceptually very messy, though.
> From: Peter Jeremy <peter(a)rulingia.com>
> My view may be unpopular but I've always been disappointed that Unix
> implemented blocking I/O only and then had to add various hacks to cover
> up for the lack of asynchonous I/O. It's trivial to build blocking I/O
> operations on top of asynchonous I/O operations. It's impossible to do
> the opposite without additional functionality.
Back when I started working on networks, I looked at other kinds of systems
to see what general lessons I could learn about the evolution of systems, which
might apply to the networks we were building. (I should have written all that up,
never did, sigh.)
One major one was that a system, when small, often collapses multiple needs
onto one machanism. Only as the system grows in size do scaling effects, etc
necessitate breaking them up into separate mechanisms. (There are some good
examples in file systems, for example.)
I/O is a perfect example of this; a small system can get away with only one
kind; it's only when the system grows that one benefits from having both
synchronous and asynchronous. Since the latter is more complicated, _both_ in
the system and in the applications which use it, it's no surprise that
synchronous was the pick.
The reasons why synchronous is simpler in applications have a nice
illustration in operating systems, which inevitably support both blocking
(i.e. implied process switching) and non-blocking 'operation initiation' and
'operation completed notification' mechanisms. (The 'timeout/callout'
mechanism is Unix is an example of the latter, albeit specialized to timers.)
Prior to the Master Control Program in the Burroughs B000 (there may be older
examples, but I don't know of them - I would be more than pleased to be
informed of any such, if there are), the technique of having a per-process
_kernel_ stack, and on a process block (and implied switch), switching stacks,
was not used. This idea was picked up for Jerry Saltzer's PhD thesis, used in
Multics, and then copied by almost every other OS since (including Unix).
The advantage is fairly obvious: if one is deep in some call stack, one can
just wait there until the thing one needs is done, and then resume without
having to work one's way back to that spot - which will inevitably be
complicated (perhaps more in the need to _return_ through all the places that
called down - although the code to handle a 'not yet' return through all those
places, after the initial call down, will not be inconsiderable either).
Exactly the same reasoning applies to blocking I/O; one can sit where one is,
waiting for the I/O to be done, without having to work one's way back there
later. (Examples are legion, e.g. in recursive descent parsers - and can make
the code _much_ simpler.)
It's only when one _can't_ wait for the I/O to complete (e.g. for a packet to
arrive - although others have mentioned other examples in this thread, such as
'having other stuff to do in the meanwhile') than having only blocking I/O
becomes a problem...
In cases where blocking would be better, one can always build a 'blocking' I/O
subsystem on top of asynchronous I/O primitives.
However, in a _tiny_ system (remember my -11/40 which ran Unix on a system
with _48KB_ of main memory _total_- i.e. OS and application together had to be
less than 48KB - no virtual memory on that machine :-), building blocking I/O
on top of asynchonous I/O, for those very few cases which need it, may not be
the best use of very limited space - although I agree that it's the way to go,
overall.
Noel
>> On 2020, Jun 3, at 1:38 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
>>
>> Lawrence Stewart wrote:
>>> I remember working on getting Arpanet access on an 11/34 running V7
>>> around 1978 or 1979. (SU-ISL). We used an 11/23 as a front end to run
>>> NCP, using a variation of Rand’s code. I wrote some sort of bisync
>>> driver for packet communications between the /23 and the /34, and I
>>> think added an IOCTL or some hack to ask if there was a message ready.
>>> So a polling variety of non-blocking I/O :)
>>
>> Has this, or Rand's code, been preserved?
>>
>> I'm only aware of one Arpanet NCP implementation for Unix that is
>> online, the one from University of Illinois.
> Alas I do not know. I may have some old emails from that era. I will check.
I have not so far come across an NCP Unix that was not based on the UoI code base.
At a time there was a “Rand Unix”, that combined the UoI code with a few other
extensions. A 1978 document describes the kernel as:
"UNIX version 6 with modifications some of which are:
- Accounting
- A system call to write end of files on pipes
- A system call which checks whether a process would sleep upon doing a read on either a pipe or tty
- Pseudo teletypes
- The network control program NCP written at the University of Illinois
- A new method of interprocess communication called ports. Ports are similar to pipes but have names and can be accessed by any process.”
The system call to write EOF on pipes is eofp() and the blocking read test is empty(). Both are available in the NCP Unix source code as included on the TUHS Unix Tree page. It could well be that the hack Lawrence refers to above was a modification to empty() to also cover his bisync driver.
I guess empty() is the first step on the path that includes capac()/await() and later select()/poll() as the preferred mechanism to prevent blocking on IPC files (incl. tty’s).
OK. Must be off my game... I forgot to tell people about my BSDcan talk
earlier today. It was streamed live, and will be online in a week or
three...
It's another similar to the last two. I've uploaded a version to youtube
until the conference has theirs ready. It's a private link, but should work
for anybody that has it. Now that I've given my talk it's cool to share
more widely... https://www.youtube.com/watch?v=NRq8xEvFS_g
The link at the end is wrong. https://github.com/bsdimp/bsdcan2020-demos is
the proper link.
Please let me know what you think.
Warner
Hi All.
I've put Clem's file up at http://www.skeeve.com/text-processing.tar.bz2.
It's a little over 16 meg and includes more than just the vi stuff.
Enjoy,
Arnold
Michael Stiller <mstiller(a)icloud.com> wrote:
> Hi Clem,
>
> why offline? Other people are also interested. :-)
>
> Cheers,
>
> Michael
>
>
> > On 3. Jun 2020, at 14:33, Clem Cole <clemc(a)ccc.com> wrote:
> >
> > I think so... I'll send you a URL off line.
> >
> > Clem
> >
> > On Wed, Jun 3, 2020 at 1:14 AM <arnold(a)skeeve.com> wrote:
> > Hi.
> >
> > Does anyone have a mirror of the files that once upon a time were
> > at http://alf.uib.no/pub/vi? They were mirrored at
> > ftp://ftp.uu.net/pub/text-processing/vi also.
> >
> > If so, can you please send me a tarball off list (or tell me where
> > I can download a copy from)?
> >
> > Thanks!
> >
> > Arnold
> From: Paul Winalski
> I'm curious as to what the rationale was for Unix to have been designed
> with basic I/O being blocking rather than asynchronous.
It's a combination of two factors, I reckon. One, which is better depends a
lot on the type of thing you're trying to do. For many typical thing (e.g.
'ls'), blocking is a good fit. And, as As Arnold says, asyhchronous I/O is
more complicated, and Unix was (well, back then at least) all about getting
the most bang for the least bucks.
More complicated things do sometimes benefit from asynchronous I/O, but
complicated things weren't Unix's 'target market'. E.g. even though pipes
post-date the I/O decision, they too are a better match to blocking I/O.
> From: Arnold Skeeve
> the early Unixs were on smaller -11s, not the /45 or /70 with split I&D
> space and the ability to address lost more RAM.
Ahem. Lots more _core_. People keeep forgetting that we're looking at
decicions made at a time when each bit in main memory was stored in a
physically separate storage device, and having tons of memory was a dream of
the future.
E.g. the -11/40 I first ran Unix on had _48 KB_ of core memory - total!
And that had to hold the resident OS, plus the application! It's no
surprise that Unix was so focused on small size - and as a corollary, on
high bang/buck ratio.
But even in his age of lighting one's cigars with gigabytes of main memory
(literally), small is still beautiful, because it's easier to understand, and
complexity is bad. So it's too bad Unix has lost that extreme parsimony.
> From: Dan Cross
> question whether asynchrony itself remains untamed, as Doug put it, or
> if rather it has proved difficult to retrofit asynchrony onto a system
> designed around fundamentally synchronous primitives?
I'm not sure it's 'either or'; I reckon they are both true.
Noel
OK. I've written a script to take the 2.11BSD pl 195 tape and reverse apply
all the patches that we have to get back to 2.11BSD original.
There's some problems. The biggest one is that ld.c was rewritten during
this series and what it replaced is lost. And the 2.10.1 ld.c isn't what's
in 2.11BSD and the patches to get from 2.10.1 to 2.11 don't seem to be out
there. And the other patches in the series make it clear that patches are
missing. 2.11BSD likely will work with 2.10.1's ld, so this isn't fatal.
There's 122 other files that I recovered from 2.10.1. Almost all of those
are a good guess, if not what's actually in 2.11. Many of these can be
verified via other means. Some of these can be snagged from comp.bugs.2bsd
(that's how as was recovered).
There's a number of small cosmetic changes made via copying, some to get
rid of redundant files, etc. I think these don't matter for the function of
the system, but are small differences from the actual tape that shipped.
I still need to try to still create a tape and try to compile. And forward
apply all the patches and create a git repo from it.
All things considered 99% of the files have been recovered at this point.
It's early days, but I've pushed this to github for comments.
http://github.com/bsdimp/mk211bsd
It just assumes you have the Tuhs archive (including the new Usenet
section) and that apout works on your computer. It works on FreeBSD for
sure. No clue about anything else...
Warner
> At around that point in time (I don't have the very _earliest_ code, to get an exact date, but the oldest traces I see [in mapalloc(), below] are from September '78), the CSR group at MIT-LCS (which were the people in LCS doing networking) was doing a lot with asynchronous I/O (when you're working below the reliable stream level, you can't just do a blocking 'read' for a packet; it pretty much has to be asynchronous). I was working in Unix V6 - we were building an experimental 1Mbit/second ring - and there was work in Multics as well.
> I don't think the wider Unix community heard about the Unix work, but our group regularly filed updates on our work for the 'Internet Monthly Reports', which was distributed to the whole TCP/IP experimental community. If you can find an archive of early issues (I'm too lazy to go look for one), we should be in there (although our report will alsocover the Multics TCP/IP work, and maybe some other stuff too).
Sounds very interesting!
Looked around a bit, but I did not find a source for the “Internet Monthly Reports” for the late 70’s (rfc-editor.org/museum/ has them for the 1990’s).
In the 1970’s era, it seems that NCP Unix went in another direction, using newly built message and event facilities to prevent blocking. This is described in "CAC Technical Memorandum No. 84, Illinois Inter-Process Communication Facility for Unix.” - but that document appears lost as well.
Ah, well, topics for another day.
It is too big to attach to email.
On Wed, Jun 3, 2020 at 8:39 AM Michael Stiller <mstiller(a)icloud.com> wrote:
> Hi Clem,
>
> why offline? Other people are also interested. :-)
>
> Cheers,
>
> Michael
>
>
> > On 3. Jun 2020, at 14:33, Clem Cole <clemc(a)ccc.com> wrote:
> >
> > I think so... I'll send you a URL off line.
> >
> > Clem
> >
> > On Wed, Jun 3, 2020 at 1:14 AM <arnold(a)skeeve.com> wrote:
> > Hi.
> >
> > Does anyone have a mirror of the files that once upon a time were
> > at http://alf.uib.no/pub/vi? They were mirrored at
> > ftp://ftp.uu.net/pub/text-processing/vi also.
> >
> > If so, can you please send me a tarball off list (or tell me where
> > I can download a copy from)?
> >
> > Thanks!
> >
> > Arnold
>
>
Hi.
Does anyone have a mirror of the files that once upon a time were
at http://alf.uib.no/pub/vi? They were mirrored at
ftp://ftp.uu.net/pub/text-processing/vi also.
If so, can you please send me a tarball off list (or tell me where
I can download a copy from)?
Thanks!
Arnold
> On 5/31/2020 9:46 AM, Warner Losh wrote:
> > Sorry to top post, but LSX or Miniunix had non blocking I/O as well.
> > It was in one of the documents that Clem scanned in the last year. It
> > specifically was an experiment into how to do it.
> >
> > Warner
> I did add a few new features to LSX to deal with contiguous files
> and to handle asynchronous read/write's for real time applications.
> They are described in the LSX paper in the 1978 BSTJ on the
> UNIX Time-Sharing System.
>
> Heinz
Thanks for highlighting this!
The realm here is async I/O to disk, my original scope was limited to “communication” files (tty’s, pipes, network connections). Still, I find it an interesting topic.
For others, the paper that you refer to can also be found here:
https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/UNI…
If I read correctly, the async functionality was available only in the stand alone program version of LSX. Is that correct? In any case, the source code appears lost.
From another paper in that set, I get the impression that the async functionality for LSX builds on earlier work for a very early version of Unix:
https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…
- - -
When reading through the papers in that TUHS directory, something else caught my attention: early networking at the labs. For a while I have been puzzled by the “serial I/O loop” in use at the labs in the early seventies. Last Fall I found some 1970/1971 BSTJ papers about it, but there it stopped.
I see in the memo on Glance (https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…) that D.R. Weller continued to work on it up to 1973 at least and that it was integrated with Unix in some way. Is that correct? Did the two memo’s referred to (MM 70-1384-1 and TM 73-1356-8) survive?
Then the memo on satellite processors is very interesting (https://www.tuhs.org/Archive/Documentation/TechReports/Heinz_Tech_Memos/TM-…) This appears to show the serial I/O loop in use as late as 1978, with a very intriguing use case involving system call forwarding over the network.
Can you tell me more about the serial I/O loop and its use cases?
> Would you be so kind to explain a bit about the hm version of MH.
Not sure what Clem meant but I used "hm" by Jim Guyton (@Rand) on my
Fortune box until I retired it. It provided a 2D interface. Later I
tried xmh but didn't like it.
The early history of MH is covered in some detail in Willis Ware's "RAND
and the Information Evolution" book from page 128 onward. hm & Guyton
get a paragraph on page 136.
https://www.rand.org/content/dam/rand/pubs/corporate_pubs/2008/RAND_CP537.p…
Team Unix,
Is there a Windows or Linux utility to create a disk image in any of the
above formats, from a local folder tree?
Paul
*Paul Riley*
Mo: +86 186 8227 8332
Email: paul(a)rileyriot.com
> > when you're working below the reliable stream level, you can't just do a > blocking 'read' for a packet; it pretty much has to be asynchronous
> Oh, you should look at the early BBN TCP for V6 Unix - they would have faced the same issue, with their TCP process. They did have the capac() call (which kind of alleviates the need for non-blocking I/O), but that may have only been available for ports/pipes; I'm not sure if the ARPANET device supported it.
I did. There is capac() support also for the IMP interface:
https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/dmr/imp11a.c
(see bottom two functions)
BBN took the same approach as Research: with capac() or select() one can prevent blocking on read() and write().
> From: Ronald Natalie
> The V6 file system was limited to 2^24 blocks
No, 2^16; from filsys.h:
int s_fsize; /* size in blocks of entire volume */
and of course on an -11 an int is 16 bits.
Maybe you're thinking of the file size, which was 2^24 bytes (max).
Noel
