TUHS

tuhs@tuhs.org

16 participants
6536 discussions

by Paul Riley

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*

5 years, 1 month

UNESCO's Software Heritage Foundation

by Clem Cole

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/

5 years, 1 month

Re: [TUHS] History of popularity of C

by Doug McIlroy

> 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

5 years, 1 month

History of popularity of C

by Tyler Adams

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

5 years, 1 month

My BSDcan talk

by Paul Ruizendaal

> 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.

5 years, 1 month

network name space (was: My BSDcon talk)

by Paul Ruizendaal

> 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.

5 years, 1 month

Re: [TUHS] non-blocking IO

by jnc＠mercury.lcs.mit.edu

> 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

5 years, 1 month

Unix on Aprpanet

by Paul Ruizendaal

>> 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).

5 years, 1 month

My BSDcan talk

by Warner Losh

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

5 years, 1 month

Re: [TUHS] Looking for vi files from http://alf.uib.no/pub/vi

by arnold＠skeeve.com

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

5 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS