TUHS August 2020

tuhs@tuhs.org

61 participants
55 discussions

Re: [TUHS] The most surprising Unix programs

by jnc＠mercury.lcs.mit.edu

> From: Paul Guertin > I teach math in college ... Sometimes, during an exam, a student who > forgot to bring their calculator will ask if they can borrow mine I > always say "sure, but you'll regret it" and hand them the calculator > After wasting one or two minutes, they give it back Maybe I'm being clueless/over-asking, but to me it's appalling that any college student (at least all who have _any_ math requirement at all; not sure how many that is) doesn't know how an RPN calculator works. It's not exactly rocket science, and any reasonably intelligent high-schooler should get it extremely quickly; just tell them it's just a representational thing, number number operator instead of number operator number. I know it's not a key intellectual skill, but it does seem to me to be part of comon intellectual heritage that everyone should know, like musical scales or poetry rhyming. Have you ever considered taking two minutes (literally!) to cover it briefly, just 'someone tried to borrow my RPN calculator, here's the basic idea of how they work'? Noel

4 years

Re: [TUHS] H.J. Lu Bootable Root & Base System disks

by norman＠oclsc.org

In my humble-but-correct opinion*, Linux and its origins fit into the general topic of UNIX history just as well as those of Research UNIX or BSD or SVr4.2.2.2.2.2.2.2 or SunOS or IRIX or Ultrix or Tru64-compaqted-HPSauce or whatever. It all stems from the same roots, despite the protestations of purists from all sides. Warren gets final say, of course, but to encourage him I will say: Ploooogie! Norman Wilson Toronto ON * One of Peter Weinberger's sayings that I still enjoy overusing.

4 years, 1 month

Unix tools to aid in the production of Internet RFCs?

by Dan Cross

Honestly, I'm not quite sure if this is a TUHS, COFF, or IH question. But since my background with respect to such things is largely Unix centric, I thought I'd ask in that context, hence asking on TUHS. I assume some of the regulars on this list have authored RFCs (of the IETF etc variety). The RFC format seems fairly well fixed: table of contents, fixed number of lines per page, page numbers and dates in the footer, and so forth. The format is sufficiently complex that it seems like some tooling could be usefully employed to aid in producing these documents. So I'm curious: what tools did people use to produce those documents? Perhaps `nroff` with custom macros or something? - Dan C.

4 years, 1 month

Quick video: what's the oldest BSD distro

by Warner Losh

https://www.youtube.com/watch?v=ww60o940kEk You may be surprised :) Warner P.S. Hope this is relevant enough to share here. Also, if I botched anything I've not yet mentioned in the comments, please let me know...

4 years, 1 month

Re: [TUHS] bare m4 (was BTL summmer employees)

by Doug McIlroy

A modestly corrected and improved version of my bare-m4 program, which quickly builds from nothing to arithmetic on binary numbers using no builtins other than `define'. is posted at www.cs.dartmouth.edu/~doug/barem4.txt. (.txt because browsers balk at .m4) Doug

4 years, 1 month

early BIND

by Tony Finch

Another question at the intersection of the Internet-History and TUHS lists... I was wondering about the early history of BIND. I started off wondering about the relative ages of JEEVES (the original PDP10 DNS server) and BIND. Judging by the dates on RFCs 881 - 883, the DARPA contract commissioning BIND, and the Berkeley tech reports, it seems there wasn't much time when the DNS was without BIND. But I was struck by the resolver API set out on page 8 of Berkeley tech report UCB/CSD-84-182: it looks nothing like the familiar API that ended up in 4.3BSD. https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/5957.html https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/lib/libc/net/n… So I'm wondering if there's anything out there recording the history between the 1984 tech reports and the 4.3BSD release in 1986. (It's also noteworthy that early BIND supported incremental DNS updates and zone transfers, which didn't reappear in standard form until RFC 2136 (1997) and RFC 1995 (1996)...) Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ public services of the highest quality

4 years, 1 month

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by Paul Ruizendaal

Doug, “In fact Dennis's compiler did not use AID instructions for that purpose.” Whilst local variables are indeed accessed as an offset from the base pointer, I’m not sure that the above statement is correct. In the V6 compiler (-sp) was certainly used to push arguments to the stack, and when the register allocation overflowed, the interim results were pushed to the stack as well with (-sp). See c10.c, the case CALL in rcexpr(), the function comarg() and sptab (which is right at the end of table.s) Links: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c10.c https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/table.s For interim result pushing/popping I refer to the FS and SS macro’s. Dennis discusses these in his “A tour of the C compiler” paper. https://www.jslite.net/cgi-bin/9995/doc/tip/doc/old-ctour.pdf Of course this is all implementational detail, not a core design aspect - as Richard Miller showed in his port to the Interdata architecture (including a port of the Ritchie C compiler). Maybe the sentence should have read: "In fact Dennis's compiler did not rely on having AID instructions for that purpose." Paul @Warren: at moments like these I really like having the line highlight feature that we discussed before Summer.

4 years, 1 month

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by jnc＠mercury.lcs.mit.edu

> From: John Cowan > That's always true on the PDP-11 and Vax ... because the processor > architecture (which has pre-increment and post-decrement instructions, > but not their counterparts) After Doug's message, I carefull re-read this, and I'm not sure it's correct? The PDP-11 has pre-decrement and post-increment, not the other way around (as above) - unless I'm misunderstanding what you meant by those terms? That's why: *p++ = 0; turns (if p is in R2) into CLR (R2)+ R2 is used, and then incremented after it has been used. Noel

4 years, 1 month

Re: [TUHS] Memory management in Dennis Ritchie's C Compiler

by Doug McIlroy

> That's always true on the PDP-11 and Vax, no matter what the OS, > because the processor architecture (which has pre-increment and > post-decrement instructions, but not their counterparts) makes > anything but a downward-growing stack unmanageable. I hadn't heard this urban legend before. A stack is certainly manageable without auto-increment/decrement (AID) instructions. In fact Dennis's compiler did not use AID instructions for that purpose. AID instructions are nice for a LIFO stack, in which a stacked item disappears as soon as it's used--as do intermediate results in expression evaluation. But when the stack contains local variables that are accessed multiple times, the accesses are offset from the stack pointer. If AID instructions set the pointer, then the offset of a particular local varies throughout the code. The compiler can cope with that (I once wrote a compiler that did so), but a debugger will have a devil of a time doing a backtrace when the offset of the return address in each stack frame depends on the location counter. AID instructions are fine for sequentially accessing arrays, and in principle Ken's ++ and -- operators can exploit them. Yet idiomatic C typically wants post-increment and pre-decrement instructions--the opposite of what DEC offered. Examples: char a[N], b[N]; char *ap = a; char *bp = b; int i; for(i=0; i<N; i++) *ap++ = *bp++; int a[N], b[N]; int i = N; while(--i >= 0) a[i] = b[i]; Doug

4 years, 1 month

Memory management in Dennis Ritchie's C Compiler

by Dibyendu Majumdar

Hi, I have a project to revive the C compiler from V7/V10. I wanted to check if anyone here knows about the memory management in the compiler (c0 only for now). I am trying to migrate the memory management to malloc/free but I am struggling to understand exactly how memory is being managed. Thanks and Regards Dibyendu

4 years, 1 month

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 August 2020