From scj at yaccman.com Fri Jul 2 11:36:04 2021 From: scj at yaccman.com (scj at yaccman.com) Date: Thu, 01 Jul 2021 18:36:04 -0700 Subject: [TUHS] Disassemblers In-Reply-To: References: Message-ID: <0f8af9213f5e8a3c536047e580a9e5c8@yaccman.com> I saw this post and it reminded me of a meeting that Dennis and I had with Bill Wulf. At one point, Dennis decided to write an optimizer but gave up after a week or two because when he had coded the data structures he needed he had filled up the PDP-11 memory! It was a very strong part of the Unix meme that Unix and C would run on small computers since most of the universities couldn't afford bigger ones at the time. When PCC came along and started running on 32-bit machines, I started thinking about algorithms for optimization. A problem that I had no good solution for could be illustrated by a simple piece of code: x = *p; y = *q; q gets changed *q = z; The question is, do I need to reload x now because q might have been changed to point to the same place as p? At around this time, Al Aho was invited to go to CMU and give a talk, and he invited me to come with him. We spent about an hour and a half one-on-one with Bill Wulf -- I seem to remember a lot of mutual respect going on. But when I asked him about my problem, he really didn't have much to say about it. I finally got him to agree that his compiler had a bug. But he said there was a flag they could set on the compiler that would turn of optimization and if your program had mysterious bugs, you should use the flag. I recall that Al, always in search of better algorithms, was a bit disappointed -- I was a bit more pragmatic about it. On the whole, it was a good meeting, and the "Engineering ... Compiler" book was one of my favorites when it came out. Steve --- On 2021-06-19 09:59, Clem Cole wrote: > On Sat, Jun 19, 2021 at 12:33 PM Henry Bent wrote: > >> Wait, so it was easier to write an emulator for a PDP-10 binary than it would have been to port BLISS to the PDP-11? Given the different word sizes I would not have expected that. > > BLISS-11 was (way) too big to run in the 64K address of the PDP-11 (even separated I/D). Originally, it was a PDP-10 cross compiler and later moved to the Vax. It generated much better code than the original Ritchie or later Johnson compilers. The code generator/optimizer was famous (literally the book on code optimization was written about it, called of course: "The Design of an Optimizing Compiler" [1] by Wulf and some of his students [ISBN 0444001581] - _a.k.a._ 'The Green Book' worth reading BTW. > > Later on, DEC's TLG tried at least twice that I know of to make it self-hosting but gave up. Long story (and definitely a different thread) if DEC has not screwed up the marketing of BLISS, I suspect it might have given C a run for the money. But BLISS _vs_. C is a great example of Cole's law that _Simple Economics always beats Sophisticated Architecture_ [and using Christensen's 'disruptive theory -- it gets better and supplants the incombent]. > > Anyway, the compiler/code generator/linker for DEC Fortran-IV for RT-11, RSX, and DOS-11 was written in BLISS-11. So for CU to retarget it for V6 they needed a PDP-10, which they did not have. So they wrote a simulator. I remember when they gave a talk about it at Usenix, somebody asked them how well Tenex ran on it. > >> Did they have a cover sheet or something equivalent that they came with? I'm having trouble imagining dealing with that much unindexed data on an early system. > > Not to my knowledge. Two things that I believe we need to do for the TUHS archives to be even more meaningful is 1.) decode them from tp/ar -- even if you read the tape, they are packed together in v5/v6 ar files which are PDP-11 binary. 2.) Create an index of what is there. > > I've thought about both things but have way too much on my plate to do it myself. > >> Fascinating. Thank you as always for the insight. > > Most welcome. > Clem > ᐧ Links: ------ [1] https://www.amazon.com/Design-Optimizing-Compiler-William-Allan/dp/0444001581 -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Jul 2 12:05:42 2021 From: crossd at gmail.com (Dan Cross) Date: Thu, 1 Jul 2021 22:05:42 -0400 Subject: [TUHS] First machine to run rogue? Message-ID: What was the first machine to run rogue? I understand that it was written by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the `curses` library (Ken Arnold's original, not Mary Ann's rewrite). I've seen at least one place that indicates it first ran on 6th Edition, but that doesn't sound right to me. The first reference I can find in BSD is in 2.79 ("rogue.doc"), which also appears to be the first release to ship curses. Anyone have any info? Thanks! - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Fri Jul 2 12:13:05 2021 From: scj at yaccman.com (scj at yaccman.com) Date: Thu, 01 Jul 2021 19:13:05 -0700 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: References: <20210526030341.GD27558@mcvoy.com> <2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org> Message-ID: I found Dennis's compiler to be a thing of beauty when compiling statements, but hell on wheels when doing expressions. One of the motivations for writing Yacc was that I wanted to add the exclusive or into the expression syntax and we had agreed on the character (^) and the precedence. Practically the whole expression grammar needed to be rewritten, and small typos created un-debuggable chaos. The state of the art at the time was to write multi-layered grammars for each precedence level. A paper was published on how to shrink the resulting parsing tables by eliminating redundant states. I realized that the same results could be obtained by writing an ambiguous expression grammar and using a precedence table to resolve the ambiguities. The initial response in the academic community to programming with ambiguous grammars was somewhere between skeptical and horrified -- as if I had shown porn to a Victorian. So Al and I worked out a proof that we would get the same optimized parser in a much more intuitive way. I do agree with Rob that some of the languages that Yacc gave birth to should never have been born. Remember, though, that the dominant language at the time was FORTRAN, and it had all sorts of strange implementation issues in their hand-written compilers. Things like subscript indices had to be single variables in some places, and in others could have a constant added to the index. One of Yacc's best features was that it made consistency of usage the path of least resistance when designing the language, and the grammar was often easier to understand than the programming manual. At Bell Labs, Barbara Ryder wrote a program that would read FORTRAN and detect things that would not work on one or more of the six major FORTRAN's at the time. It was an inspiration for me, later, do the same thing with Lint. I do suggest that having languages like C++ that have bloated up to over 1000 pages in the programmer reference doesn't feel like a real advance, especially since the real language problems of today are how to program very large numbers of processor-like objects on a single chip. We need new ways to think, and I doubt that we'll get there by making C++ require a 2000-page manual. --- On 2021-05-25 23:52, Rob Pike wrote: > I enjoy writing recursive descent parsers, and I enjoy the grammars that result from such parsers when cleanly done. > > I do agree though that if you grammar is being invented as you go, yacc can be a boon. But in a sense, that's also it's biggest failing: it makes it too easy to write bad grammars. > > -rob > > On Wed, May 26, 2021 at 4:22 PM Bakul Shah wrote: > >> Many existing programming languages do have a simple enough >> syntax to make it easy to write a recursive descent parser for them >> but not alll. >> >> Handwritten recursive descent parsers are often LL(1) with may be >> a separate operator-precedence parsing for expressions. >> >> If you are defining a new language syntax you can make sure parsing >> is easy but not all languages are LL(1) (which is a subset of LALR(1), >> which is a subset of LR(1), which is a subset of GLR). Handwritten >> parsers for these more general grammars are bound to get more >> complicated. >> >> Even *we* understand parsing, writing a parser for some existing >> languages which grew "organically" can become tedious, or >> complicated or adhoc. Often such languages have no well specified >> grammar (the code is the specification!). A yacc grammar would help. >> >> Often one writes a yacc grammar while a new language & its syntax >> is evolving. Changing a yacc file is more localized & easier than fixing >> up a handwritten parser. Even Go has such a grammar initially. >> >> -- Bakul >> >>> On May 25, 2021, at 8:03 PM, Larry McVoy wrote: >>> >>> You do, I don't. I'm not alone in my lack of understanding. >>> >>> I think that all the things that yacc solved, Steve gets some kudos. >>> I've used it a bunch and I did not need to be as smart as you or >>> Steve to get the job done. >>> >>> You getting past that is cool but it doesn't make his work less. >>> >>> On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote: >>>> And today, we understand parsing so well we don't need yacc. >>>> >>>> -rob >>>> >>>> >>>> On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe >>>> wrote: >>>> >>>>> The last article of the latest issue of the Communications of the ACM >>>>> that appeared electronically earlier today is a brief interview with >>>>> this year's ACM Turing Award winners, Al Aho and Jeff Ullman. >>>>> >>>>> The article is >>>>> >>>>> Last byte: Shaping the foundations of programming languages >>>>> https://doi.org/10.1145/3460442 >>>>> Comm. ACM 64(6), 120, 119, June 2021. >>>>> >>>>> and it includes a picture of the two winners sitting on Dennis >>>>> Ritchie's couch. >>>>> >>>>> I liked this snippet from Jeff Ullman, praising fellow list member >>>>> Steve Johnson's landmark program, yacc: >>>>> >>>>>>> ... >>>>>>> At the time of the first Fortran compiler, it took several >>>>>>> person-years to write a parser. By the time yacc came around, >>>>>>> you could do it in an afternoon. >>>>>>> ... >>>>> >>>>> >>>>> ------------------------------------------------------------------------------- >>>>> - 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 at math.utah.edu - >>>>> - 155 S 1400 E RM 233 beebe at acm.org >>>>> beebe at computer.org - >>>>> - Salt Lake City, UT 84112-0090, USA URL: >>>>> http://www.math.utah.edu/~beebe/ - >>>>> >>>>> ------------------------------------------------------------------------------- >>>>> >>> >>> -- >>> --- >>> Larry McVoy lm at mcvoy.com [1] http://www.mcvoy.com/lm Links: ------ [1] http://mcvoy.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jul 2 12:51:22 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 1 Jul 2021 22:51:22 -0400 Subject: [TUHS] First machine to run rogue? In-Reply-To: References: Message-ID: I first got it on V7, as I said on our 11/70 for sure but I don’t remember if we had it on the 11/60 before that. On Thu, Jul 1, 2021 at 10:07 PM Dan Cross wrote: > What was the first machine to run rogue? I understand that it was written > by Glenn Wichman and Michael Toy at UC Santa Cruz ca. 1980, using the > `curses` library (Ken Arnold's original, not Mary Ann's rewrite). I've seen > at least one place that indicates it first ran on 6th Edition, but that > doesn't sound right to me. The first reference I can find in BSD is in 2.79 > ("rogue.doc"), which also appears to be the first release to ship curses. > > Anyone have any info? Thanks! > > - Dan C. > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Jul 2 14:40:09 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 2 Jul 2021 14:40:09 +1000 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: References: <20210526030341.GD27558@mcvoy.com> <2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org> Message-ID: