TUHS

tuhs@tuhs.org

12 participants
6534 discussions

by Steve Simon

well spec’ed machines where more common in the past. we had all the source for the interdata 3210 at college. we had the edition 7 source, the driver source, the diagnostic tape source, and even all the schematics. two of the lecturers even upgraded it from 1mb to 4mb of RAM, complete with address decoders on their backs with their legs in the air. -Steve > On 6 Aug 2018, at 03:00, tuhs-request(a)minnie.tuhs.org wrote: > > Send TUHS mailing list submissions to > tuhs(a)minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request(a)minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner(a)minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > > > Today's Topics: > > 1. Re: In Memoriam: Per Brinch Hansen (Perry E. Metzger) > 2. Latest Kernighan interview on Youtube (Warren Toomey) > 3. In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel! > (Dave Horsfall) > 4. Re: In Memoriam: Edsger Dijkstra, and happy birthday Jon > Postel! (Noel Chiappa) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 5 Aug 2018 19:18:18 -0400 > From: "Perry E. Metzger" <perry(a)piermont.com> > To: Doug McIlroy <doug(a)cs.dartmouth.edu> > Cc: tuhs(a)tuhs.org > Subject: Re: [TUHS] In Memoriam: Per Brinch Hansen > Message-ID: <20180805191818.0ac05b0f(a)jabberwock.cb.piermont.com> > Content-Type: text/plain; charset=US-ASCII > > On Thu, 02 Aug 2018 08:44:56 -0400 Doug McIlroy > <doug(a)cs.dartmouth.edu> wrote: >> A tangential connection to early Unix experience: >> >> My collection of early computer manuals includes Brinch Hansen's >> manual for the RC 4000, which stands out for its precise >> description of the CPU logic--in Algol 60! It's the only manual I >> have seen that offers a good-to-the-last-bit formal description of >> the hardware. >> >> DEC presented something of the sort for the PDP-11, but punted where >> the woods got thick. When I wanted to know how they computed the >> last bit of floating-point results, I got no satisfaction. Amidst a >> thorough description of addressing came this formulation of the >> actual computation: "form floating point result". > > For those that are familiar with the RISC V architecture, there's a > formal specification of the architecture that was done in a system > built on Coq, and also a fully formally verified translation of the > specification into RTL. (The spec didn't include floating point as of > about a year ago but it may by now.) > > A good overview of the system involved is here: > > http://plv.csail.mit.edu/kami/papers/icfp17.pdf > > Followups might belong on the coff list, not sure. > > Perry > -- > Perry E. Metzger perry(a)piermont.com > > > ------------------------------ > > Message: 2 > Date: Mon, 6 Aug 2018 09:53:19 +1000 > From: Warren Toomey <wkt(a)tuhs.org> > To: tuhs(a)tuhs.org > Subject: [TUHS] Latest Kernighan interview on Youtube > Message-ID: <20180805235319.GA14811(a)minnie.tuhs.org> > Content-Type: text/plain; charset=us-ascii > > in 3 parts: > > https://www.youtube.com/watch?v=zmYhR8cUX90 > https://www.youtube.com/watch?v=VVpRj3Po6K4 > https://www.youtube.com/watch?v=E6vtRm5M8I0 > > Cheers, Warren > > > ------------------------------ > > Message: 3 > Date: Mon, 6 Aug 2018 10:04:17 +1000 (EST) > From: Dave Horsfall <dave(a)horsfall.org> > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > Subject: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday Jon > Postel! > Message-ID: > <alpine.BSF.2.21.9999.1808060955320.79568(a)aneurin.horsfall.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > What a weird day... > > We lost computer pioneer Edsger Dijkstra in 2002; he gave us ALGOL, > structured programming, semaphores, and ranted against the GOTO statement > (much to the distress of the Fortranites and their spaghetti coding). > Oh, and a certain Prof. Goto used to complain that everybody wanted to > eliminate him :-) > > However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he > could pretty much be described as the Father of the Internet. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." > > > ------------------------------ > > Message: 4 > Date: Sun, 5 Aug 2018 21:15:45 -0400 (EDT) > From: jnc(a)mercury.lcs.mit.edu (Noel Chiappa) > To: tuhs(a)tuhs.org > Cc: jnc(a)mercury.lcs.mit.edu > Subject: Re: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday > Jon Postel! > Message-ID: <20180806011545.29C1F18C09A(a)mercury.lcs.mit.edu> > >> From: Dave Horsfall > >> However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he >> could pretty much be described as the Father of the Internet. > > The problem with using the number of documents as a gauge for that is that Jon > often acted as scribe, so that for many things published under his name, he > was acting more as editor. > > As to who (if anyone) does deserve that title, I'm also not sure about the > importance of Cerf and Kahn. NOTE: I am not saying they _didn't_ make the key > contribution - I just haven't looked into it in enough detail to say. > > For example, before the TCP/IP effort got rolling, there was something called > the International Packet Network Working Group (INWG) which had a big role, > but which has been poorly documented. There's a note called "The Internet: On > its International Origins and Collaborative Vision" by Rhonda Hauben, > available here: > > http://www.columbia.edu/~rh120/other/misc/haubenpap.rtf > > which covers it some, and there's a more recent thing by Alex Mackenzie which > is probably better, but I'm too lazy to go find it. > > Louis Pouzin (or whoever it was at CYCLADES who actually had the idea to move > the reliability out of the packet switches, and into the hosts), also would > have a good claim to the title. > > > Anyway, sorry for the offtopic, but my 'fake history' alarm went off... > > Noel > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > TUHS mailing list > TUHS(a)minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > > ------------------------------ > > End of TUHS Digest, Vol 33, Issue 5 > ***********************************

6 years, 11 months

In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel!

by Dave Horsfall

What a weird day... We lost computer pioneer Edsger Dijkstra in 2002; he gave us ALGOL, structured programming, semaphores, and ranted against the GOTO statement (much to the distress of the Fortranites and their spaghetti coding). Oh, and a certain Prof. Goto used to complain that everybody wanted to eliminate him :-) However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he could pretty much be described as the Father of the Internet. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 11 months

Re: [TUHS] In Memoriam: Per Brinch Hansen

by Doug McIlroy

A tangential connection to early Unix experience: My collection of early computer manuals includes Brinch Hansen's manual for the RC 4000, which stands out for its precise description of the CPU logic--in Algol 60! It's the only manual I have seen that offers a good-to-the-last-bit formal description of the hardware. DEC presented something of the sort for the PDP-11, but punted where the woods got thick. When I wanted to know how they computed the last bit of floating-point results, I got no satisfaction. Amidst a thorough description of addressing came this formulation of the actual computation: "form floating point result". Doug

6 years, 11 months

Australian Computer Museum Society collection faces bulldozers

by asbesto

IDK if you know this, but https://www.itnews.com.au/news/australian-computer-museum-society-collectio… :( -- [ ::::::::: 73 de IW9HGS : http://freaknet.org/asbesto ::::::::::: ] [ Freaknet Medialab :: Poetry Hacklab : Dyne.Org :: Radio Cybernet ] [ NON SCRIVERMI USANDO LETTERE ACCENTATE - NON MANDARMI ALLEGATI ] [ *I DELETE* EMAIL > 100K, ATTACHMENTS, HTML, M$-WORD DOC and SPAM ]

6 years, 11 months

Re: [TUHS] Doug McIlroy's C++ regular expression library (mostly) revived

by Doug McIlroy

Why would anyone be interested in an old regex package that never was a part of any Unix distro? The driving force was Posix, whose regex spec was quite inscrutable. Could there be a reference implementation? It was easy to fool every implementation I could get my hands on, including Gnu's over-the-top 9000-line implementation. But as I got into it, I got fascinated by regexes per se. In making a recognizer, there's a tradeoff between contruction time and execution time. Linear execution can be achieved, but at a potentially exponential cost in construction time (and space). Backreferencing takes the regex languages out of the class of regular languages. Recalling that regular languages are closed under intersection and negation, I wondered about how to implement new regex operators, & and -. I came up with a scheme for this optional non-Posix feature that involved layering continuation-passing over more traditional methods. And while I was at it, I broke out smaller sublanguages for special treatment (as does Gnu), all the way down to Knuth-Morris-Pratt for expressions in which the only operation is catenation. And finally, having followed the development of C++ from its infancy, I wanted to try out its new template facility, so there's a bit of that in the package, too. Arnold has discovered that not only has C++ evolved, but also that without the discipline of -Wall to force clean code, I was rather cavalier about casting, both explicitly and implicitly. The only real customer the code ever had was the AST project, which translated it to C. After the C++ had sat idle for a half-dozen years, I thought to revive it in Linux, but found it riddled with incompatibilities with that new environment and gave up. Arnold deserves a citation for bravery in pushing that through 15 years further on. Doug

6 years, 11 months

In Memoriam: Per Brinch Hansen

by Dave Horsfall

[ I've always posted these to TUHS with no objections, so I have no idea whether COFF would be a better forum; feel free to spank me (I might even enjoy it!) ] We lost Per Brinch Hansen, a computer scientist, on this day in 2007. He specialised in operating systems and concurrent programming, and wrote the classic book "Operating System Principles" which was published in six languages for decades. He also wrote another book "The Architecture of Concurrent Programs" which demonstrated an entire operating system written in Concurrent Pascal (much like the Lions' books on Unix). -- Dave

6 years, 11 months

That tour through the C compiler...

by Dave Horsfall

My DuckDuckGo-fu appears to be on the blink (and I refuse to use Google out of privacy concerns); is there a PDF/PS/groff somewhere? I don't use fancy-wanky markup languages. Thanks. -- Dave

6 years, 11 months

Re: [TUHS] Looking for final C compiler by Dennis Ritchie

by Paul Ruizendaal

> Thank you for the info - I will certainly look at the USENIX tapes. > > I will try to port the C compiler to amd64 - while preserving as much of > the original code as I can. But not sure if this is even feasible. > > Thanks and Regards > Dibyendu If that is your goal, you might want to start with the version included with 2.11BSD. It is essentially the same as the version from V7, but with 15 more years of bug fixes. I used that source to port V6 Unix to the TI990 architecture back in 2014/2015 and the good thing about it is that it still compiles with a modern gcc. For your project, I think you would be able to use the first pass ‘c0’ almost unchanged. The second pass ‘c1’ would need major restructuring. It mainly builds a tree for each expression and then performs various transformations, many of which are PDP11 specific (but also portable ones, like handling of constant expressions). It then covers the tree with code fragments selected from a library. This library (‘optable') would need a full rewrite as well. The last pass ‘c2’ is the optimiser and is also highly PDP11 specific. It reads the assembler output of ‘c1’ function by function, building an instruction list. It then performs some portable optimisations (eliminating unnecessary jumps, etc.) and also more PDP11 specific optimisations (the most complex being removing redundant register loads - the concept of which would be reusable). There are about 12,000 lines of code and as a rough guess I would say that some 40% needs rewriting. A new code fragment library would probably be some 2 to 3 thousand lines. I recall reading about a project to revive the Ritchie C compiler one or two years ago, but a quick web search came up dry. Anybody else remember reading that?

6 years, 11 months

Frank Heart, Who Helped to Design the ArpaNet IMPs at BBN Dies at 89

by Clem Cole

Note the NY Times head lines this as 'pre-Internet' which is a little sad, but what can you do: https://www.nytimes.com/2018/06/25/technology/frank-heart- who-linked-computers-before-the-internet-dies-at-89.html

6 years, 11 months

Doug McIlroy's C++ regular expression library (mostly) revived

by Arnold Robbins

Hi All. I have (mostly) revived Doug McIlroy's C++ regular expression parsing library. I gratefully acknowledge and thank him for allowing me to publish the code and for his help in finding all the bits and pieces. It's available at https://github.com/arnoldrobbins/mcilroy-regex . The main things I've done are to gather all the bits and pieces, rename files to have a .cpp extension, and get everything to compile using current g++ and standard make. I'm at the point where I could use some help. The various tests do not all run successfully. 1. make retest - a number of tests fail 2. ./tesgrep.sh - a number of tests fail 3. ./testsed.sh - tests fail with core dumps Looking briefly, some of the code in sed plays C games, casting various things arouond to pointers of different types and dereferencing them; these things tend to cause trouble in C++. I'm hopeful that more eyes on this code will help it come back to life more quickly. Any and all help will be appreciated. Thanks, Arnold P.S. Let's not start a flame war about C vs. C++ etc. etc. If you can help, please just dive in. Otherwise, just go, "wow, neat work" and move on to something else. :-) Thanks.

6 years, 11 months

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