TUHS August 2020

tuhs@tuhs.org

61 participants
55 discussions

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

by Steve Simon

I am fairly sure the interdata port from Wollongong used the v6 c compiler, and this lived on in the “official” v7 port from perkin elmer, it still used the v6 compiler. i remember the pain of the global namespace for structure members. -Steve

3 years, 8 months

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

by Doug McIlroy

> >> Even high-school employees could make lasting contributions. I am > >> indebted to Steve for a technique he conceived during his first summer > >> assignment: using macro definitions as if they were units of associative > >> memory. This view of macros stimulated previously undreamed-of uses. > > > Can you give some examples of what this looked like? > See attached for an answer to Arnold's question Doug

3 years, 8 months

BTL pranks [was AT&T Research]

by Doug McIlroy

> Did the non-Unix people also pull pranks like the watertower? One of my favorites was by John Kelly, a Texas original, who refused the department-head perk of a rug so he could stamp his cigarettes out on the vinyl floor. John came from Visual and Acoustics Research, where digital signal processing pressed the frontiers of computing. Among his publications was the completely synthetic recording of "Daisy, Daisy" released circa 1963. Kelly electrified the computer center with a blockbuster prank a year or two before that. As was typical of many machine rooms, a loudspeaker hooked to the low-order bit of the accumulator played gentle white noise in the background. The noise would turn into a shriek when the computer got into a tight loop, calling the operators to put the program out of its misery. Out of the blue one day, the loudspeaker called for help more articulately: "Help, I'm caught in a loop. Help, I'm caught in a loop. ..." it intoned in a slow Texas drawl. News of the talking computer spread instantly and folks croweded into the machine room to marvel before the operators freed the poor prisoner. Doug

3 years, 8 months

Style command source available?

by Richard Salz

Is the style command (and perhaps other DWB programs) legally available anywhere? Replies to me will be summarized for the list. :) tnx.

3 years, 8 months

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

by norman＠oclsc.org

Dan Cross: I'll confess I haven't looked _that_ closely, but I rather imagine that the V10 compiler is a descendant of PCC rather than Dennis's V6/V7 PDP-11 compiler. ==== Correct. From 8/e to the end of official Research UNIX, cc was pcc2 with a few research-specific hacks. As Dan says, lcc was there too, but not used a lot. I'm not sure which version of lcc it was; probably it was already out-of-date. In my private half-backed 10/e descendant system, which runs only on MicroVAXes in my basement, cc is an lcc descendant instead. I took the lcc on which the book was based and re-ported it to the VAX to get an ISO- compliant C compiler, and made small changes to libc and /usr/include to afford ISO-C compliance there too. The hardest but most-interesting part was optimizing. lcc does a lot of optimization work by itself, and initially I'd hoped to dispense with a separate c2 pass entirely, but that turns out not to be feasible on machines like the VAX or the PDP-11: internally lcc separates something like c = *p++; into two operations c = *p; p++; and makes two distinct calls to the code generator. To sew them back together from cvtbl (p),c incl p to cvtbl (p)+,c requires external help; lcc just can't see that what it thinks of as two distinct expressions can be combined. It's more than 15 years since I last looked at any of this stuff, but I vaguely remember that lcc has its own interesting (but ISO/POSIX-compatible) memory-allocation setup. It allows several nested contexts' worth of allocation, freeing an inner context when there's no longer any need for it. For example, once the compiler has finished with a function and has no further need for its local symbols, it frees the associated memory. See the lcc book for details. Read the book anyway; it's the one case I know of in which the authors followed strict Literate Programming rules and made a big success of it. Not only is the compiler well- documented, but the result is a wonderful tour through the construction and design decisions of a large program that does real work. Norman Wilson Toronto ON

3 years, 8 months

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

by jnc＠mercury.lcs.mit.edu

> From: Dibyendu Majumdar > 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. Well, I don't know much about the V7 compiler; the V6 one, which I have looked at, doesn't (except for the optimizer, C2) use allocated memory at all. The V7 compiler seems to use sbrk() (the system call to manage the location of the end of a process' data space), and manage the additional data space 'manually'; it does not seem to use a true generic heap. See gblock() in c01.c: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V7/usr/src/cmd/c/c01.c which seems to use two static variables (curbase and coremax) to manage that additional memory: p = curbase; if ((curbase =+ n) >= coremax) { if (sbrk(1024) == -1) { error("Out of space"); exit(1); } coremax =+ 1024; } return(p); My guess is that there's no 'free' at all; each C source file is processed by a new invocation of C0, and the old 'heap' is thrown away when the process exits when it gets to the EOF. Noel

3 years, 8 months

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

by jnc＠mercury.lcs.mit.edu

> From: Larry > It's possible the concept existed in some other OS but I'm not aware of > it. It's pretty old. Both TENEX and ITS had the ability to map file pages into a process' address space. Not sure if anything else of that vintage had it (not sure what other systems back then _had_ paging, other than Atlas; those two both had custom KA10 homebrew hardware mods to support paging). Of course, there's always Multics... (sorry, Ken :-). Noel

3 years, 8 months

bsdcan talk

by Andrew Hume

fyi warner, in your talk, you referred to Alex Fraser at bell labs. he was my first director, and always went by “sandy”. i asked my wife (who was a secretary at the time) and she said he was occasionally referred to as Alex. certainly, every time i saw anything written by him or references to a talk by him always used “sandy”. andrew

3 years, 8 months

Re: [TUHS] TUHS Digest, Vol 55, Issue 9

by Will Senn

> > Message: 6 > Date: Fri, 5 Jun 2020 16:51:27 -0600 > From: Warner Losh <imp(a)bsdimp.com> > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > Subject: [TUHS] My BSDcan talk > Message-ID: > <CANCZdfpq8tiDYe2iVeFh1h0VMDK+4B=kXuGSJ3iNmtjbzHQT6Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > Just saw your BSDcan talk. Great stuff, so much progress in the last five years. Just wanna say thanks. When I started looking into ancient systems, it was hard finding anything coherent on the historical side beyond manuals and this list (thankful to Warren & co for the list). Your talk is packed with interesting information and really pulls together the recent pieces. Great job, Warner.

3 years, 8 months

BSTJ archives

by Kirk McKusick

I needed to look up something in the Bell System Technical Journal (Wikipedia didn't have it) and discovered that the old Alcatel-Lucent site that used to host a free archive of BSTJ no longer seems extant. (No surprise, the Web is nothing if not ephemeral.) After a bit of Googling, I did find that the archives are now residing at <https://archive.org/details/bstj-archives> and found what I was looking for there. Hope others find this link useful. At least until it too "sublimaates". Kirk McKusick

3 years, 8 months

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