TUHS

tuhs@tuhs.org

61 participants
6532 discussions

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

4 years, 10 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

4 years, 10 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

4 years, 10 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.

4 years, 10 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

4 years, 10 months

CR delay for VT05

by Richard Tobin

Looking at the 6th edition man page tty(2), I see Carriage-return delay type 1 lasts about .08 seconds and is suitable for the Terminet 300. Delay type 2 lasts about .16 seconds and is suitable for the VT05 and the TI 700. Delay type 3 is unimplemented and is 0. New-line delay type 1 is dependent on the current column and is tuned for Teletype model 37's. Type 2 is useful for the VT05 and is about .10 seconds. Type 3 is unimplemented and is 0. Why would the VT05 (a VDU) need a delay for carriage return? I can just about imagine that it might need one for linefeed if it shifted the characters in memory. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

4 years, 10 months

Re: [TUHS] [simh] 2bsd tarball

by Johnny Billquist

On 2020-07-29 15:17, Paul Koning wrote: > > >> On Jul 29, 2020, at 5:50 AM, Johnny Billquist <bqt(a)softjar.se> wrote: >> >> Just a small comment. Whoever it was that thought DECtape was a tape was making a serious mistake. DECtapes are very different from magtapes. >> >> Johnny > > Depends on what you're focusing on. Most tapes are not random-write. DECtape and EL-X1 tape are exceptional in that respect. But tapes, DECtape include, have access time proportional to delta block number (and that time is large) unlike disks. > > From the point of view of I/O semantics, the first point is significant and the second one not so much. True. But seek times are in the end only relevant as an aspect of the speed of the thing, nothing else. However, seek times on DECtape aren't really comparable to magtape either. Because DECtape deals with absolute block numbers. So you can always, no matter where you are, find out where you are, and how far you will need to move to get to the correct block. With magtapes, this is pretty much impossible. You'll have to rewind, and then start seeking. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

4 years, 10 months

2bsd tarball

by Will Senn

OK, I was able to locate 2bsd.tar.gz and spencer_2bsd.tar.gz in the archive. Neither is an installation tape. It appears that they are just tarballs of their respective systems (there are very minor differences between the two). In the TAPE file in the tarball, it talks about reading the tar program off of the tape using: dd if=/dev/mt0 bs=1b skip=1 of=tar Well, tar is definitely not located at that address, which implies that the tarball isn't a distro tape. This note in the archive used to read: ... The remaining gzipped tar files are other 2BSD distributions supplied by Keith Bostic, except for spencer_2bsd.tar.gz which came from Henry Spencer. They do not contain installation tape images. The 2.9BSD-Patch directory contains patches to 2.9BSD dated August 85, and again supplied by Keith Bostic. ... now it reads: ... 2.11BSD 2.11BSD-pl195.tar is a copy of 2.11BSD at patch level 195, supplied by Tom Ivar Helbekkmo. spencer_2bsd.tar.gz is a version of 2BSD which came from Henry Spencer. ... I recall having to do something with cont.a files, which are not present on these images. So, my questions is, does anyone know of or have an actual 2bsd tape/tape image? Thanks, Will Here's where I found the tarballs: https://www.tuhs.org/Archive/Distributions/UCB/ -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 10 months

in memoriam - Bill English, mouse co-creator

by Will Senn

All, About a week ago, Bill English passed away. He was a Xerox guy, who along with Douglas Engelbart of "Mother of all demos" fame, created our beloved mouse: https://www.bbc.com/news/technology-53638033 I remember, back in the mid-1980's being part of a focus group evaluating Microsoft's mouse. Wow, time flies. -Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

4 years, 10 months

Re: [TUHS] BTL summer employees

by jnc＠mercury.lcs.mit.edu

> From: Lars Brinkhoff > I haven't investigated it thoroughly, but I do see a file .DOVR.;.SPOOL > 8 written in C by Eliot Moss. > ... > When sending to the DOVER, the spooler waits until Spruce is > free before sending another file. Ah, so there was a spooler on the ITS machine as well; I didn't know/remember that. I checked on CSR, and it did use TFTP to send it to the Alto spooler: HOST MIT-SPOOLER, LCS 2/200,SERVER,TFTPSP,ALTO,[SPOOLER] I vaguely recall the Dover being named 'Spruce', but that name wasn't in the host table... I have this vague memory that 'MIT-Spooler' was the Alto which prove the Dover, but now that I think about it, it might have been another one (which ran only TFTP->EFTP spooler software). IIRC the Dover as a pain to run, it required a very high bit rate, and the software to massage it was very tense; so it may have made sense to do the TFTP->EFTP (I'm pretty sure the vanilla Dover spoke EFTP, but maybe I'm wrong, and it used the PUP stream protocol) in another machine. It'd be interesting to look at the Dover spooler on ITS, and see if/how one got to the CHAOS network from C - and if so, how it identified the protocol translating box. Noel

4 years, 10 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