TUHS December 2016

tuhs@tuhs.org

42 participants
43 discussions

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > At some point .. and the ability to assign/pass structures got > supported, though I thought that was the compiler that came with V7. That is my vague recollection too. > I'm still annoyed they didn't fix arrays when they fixed structs. Which aspect? The ability to assign/pass/return arrays, or the funky way that array naming worked (I'm trying to remember the details, I think it was something to do with 'arrays' passed as arguments - it was actually a pointer that was passed, but the declaration didn't have to say 'pointer'). Noel

7 years, 9 months

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

> From: Tony Finch > when did C get its cast operator? Well after that piece of code was written! :-) I don't recall exactly off the top of my head, but I recall 2-3 notes to users about the evolution of C post 'vanilla' V6; I think a lot of it was related to work being done on typetting stuff, hence the moniker 'phototypsetter compiler' which was applied to that 'improved' C. One of the notes is fairly common, but another I have only in hardcopy (although I scanned it at one point). I'll try and turn all of them, along with some notes I made about the differences between 'vanilla' V6 C and 'phototypsetter C' (which a lot of the later V6 users started with - I certainly did), into an article on the Computer History wiki on the early evolution of C. Noel

7 years, 9 months

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

PS: > I recall 2-3 notes to users about the evolution of C post 'vanilla' V6 > ... > One of the notes is fairly common, but another I have only in hardcopy > (although I scanned it at one point). More here: http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html If anyone knows of any other documentation of C evolution, I'd be interested in hearing about it for the Computer History wiki page. Noel

7 years, 9 months

Re: [TUHS] nm on Third Edition .o files?

by jnc＠mercury.lcs.mit.edu

> From: "Steve Johnson" > The number on the left is a PDP-11 address, probably for some kind of > control register. It's the Processor Status Word, which contained the CPU's hardware priority level, condition codes, etc. > That's a construction that's left over from B. I wonder why it was written as "0177776->integ", rather than "*017776"? Probably the former allowed the C compiler to work out what size the operand was. (BTW, 'integ' was declared in a structure declaration as follows: struct { int integ; }; (Did the code looked at actually say "0177776->int"? The compiler might have barfed on a reserved keyword being used like that.) Noel

7 years, 9 months

nm on Third Edition .o files?

by Diomidis Spinellis

Has anyone got a setup where they can run something like nm(1) on the compiled Third Edition Unix C files and send me the output? (Alternatively, just send me the .o files, and I'll whip up something to read their symbols.) I tried to compile the source code on a modern system by hacking old C to something closer to what GCC will accept, with commands such as the following. cc -E dp.c | sed 's/=\([&|+-]\)/\1=/g;s/struct[ \t]*(/struct {/' | gcc -w -x c - However, I stumbled on the use of structure fields on things that aren't structures, e.g. "0177776->int =| 300"

7 years, 9 months

Re Dennis' Draft of the Unix Timesharing System: not so draft?

by arnold＠skeeve.com

I forwarded your note to BWK who seems to still have a few tenuous connections to the Labs. Good luck with it. Arnold

7 years, 9 months

How Unix made it to the top

by Doug McIlroy

It has often been told how the Bell Labs law department became the first non-research department to use Unix, displacing a newly acquired stand-alone word-processing system that fell short of the department's hopes because it couldn't number the lines on patent applications, as USPTO required. When Joe Ossanna heard of this, he told them about roff and promised to give it line-numbering capability the next day. They tried it and were hooked. Patent secretaries became remote members of the fellowship of the Unix lab. In due time the law department got its own machine. Less well known is how Unix made it into the head office of AT&T. It seems that the CEO, Charlie Brown, did not like to be seen wearing glasses when he read speeches. Somehow his PR assistant learned of the CAT phototypesetter in the Unix lab and asked whether it might be possible to use it to produce scripts in large type. Of course it was. As connections to the top never hurt, the CEO's office was welcomed as another ouside user. The cost--occasionally having to develop film for the final copy of a speech--was not onerous. Having teethed on speeches, the head office realized that Unix could also be useful for things that didn't need phototypesetting. Other documents began to accumulate in their directory. By the time we became aware of it, the hoard came to include minutes of AT&T board meetings. It didn't seem like a very good idea for us to be keeping records from the inner sanctum of the corporation on a computer where most everybody had super-user privileges. A call to the PR guy convinced him of the wisdom of keeping such things on their own premises. And so the CEO's office bought a Unix system. Just as one hears of cars chosen for their cupholders, so were these users converted to Unix for trivial reasons: line numbers and vanity. Doug

7 years, 9 months

Dennis' Draft of the Unix Timesharing System: not so draft?

by Warren Toomey

All, I'm writing a paper based on my June 2016 talk on PDP-7 Unix. As part of that I was looking at the BCPL -> B -> NB -> C history. And as part of that, I was reading Ken's B manual, written in 1972: https://www.bell-labs.com/usr/dmr/www/kbman.pdf Then I noticed at the end Ken refers to: Ritchie, D.M. The UNIX Time Sharing System. MM 71-1273-4. which makes me think that the draft version Doug McIlroy found (now at http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/UnixEd…) must have made it into a full memorandum. Given that we have the memorandum number, does anybody know if it would be possible to find it in the archives from what was Bell Labs? Cheers, Warren

7 years, 9 months

Happy birthday, J.F.Ossanna!

by Dave Horsfall

J.F.Ossanna was given unto us in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. PS: Ada Lovelace, arguably the world's first computer programmer, was given unto us in 1815; she saw the potential in Charles Babbage's new-fangled thing. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 10 months

Re: [TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

by Clem Cole

On Thu, Dec 8, 2016 at 5:39 AM, Joerg Schilling <schily(a)schily.net> wrote: > Back to the Bourne Shell: > > The original Bourne Shell did not use malloc, but rather had a SIGSEGV > handler > that used to extend the "string stack" called "stak" via sbrk() whenever > the > code tried to access data beyond the end ot the heap. > Right although the 68K was not the first or the only system to have that problem - again IIRC Series/1 and maybe one of the PE systems. You are correct then SunOS and >>some<< of the 68000 based system did have the problem you suggested. And in fact, Masscomp (and Apollo) which used 68000's (but used two of them so could run full VM) could survive that style of fault (because it never occurred). BTW: the "conceptual problem" , you mentioned while true, is being a little harsh. As the one of the 68K designers (Les Crudele) said to me once, when they wrote the microcode, there were not thinking about instruction restart - so the issue was that Nick did not save enough state to do it. The model for the 68000 that they were using was the base/limit PDP-11 and the original PDP-10. Also at the time, the competition was the 6800, the 8080, Z80, 6502. They were trying to put a PDP-11/70 on chip (without getting into trouble like CalData did - which Les, Nick and team were very aware having been DEC and CalData customers before they were at Moto]. While we think of the 68000 family has being 32 bit, the fact is inside it is a 16 bit system (the barrel shifter and execution functions are 16). And it was a skunk works project -- the 6809 was Moto's real processor. It was an experiment done by a couple of rogue engineers that said - hey we can do better, The fact was they made a chip that was good enough to actually compete with the Vax in the end, because it was fast enough AND they had the wisdom to define 32 bits of address space and 32 bit operations (again having been PDP-11 users), but as Les used to say - part of the thinking was that while DEC was moving to the Vax, they had hoped to break into the area that they 16 bits minis claimed - which they in-fact did. And if you think in terms of a Clay Christensen's disruption theory, the fact that VM did not work easily (i.e. was a "worse" technology than the Vax) was ok - a new breed of customer did not care. 68000 was huge success, despite Moto marketing ;-) To me the larger issue with the 68010 was that when Nick did add the restart microcode, the new '10 microcode actually dumped version dependant state on the external stack (in Intel terminology -different "step" '10 put different state on the external stack or worse, could not restart an instruction that had been saved from a different step processor). This screw up was a huge issue when we did replaced the "executor" with a 68010, because it meant that all cpu boards had to be the same processor microcode revision. Masscomp was of course the first to make an MP, so was the the first firm to run into the issue (I remember debugging it - we could not reproduce the issue because of course tjt and my own machine's by chance had "MPU" boards as we called them with the same step -- it was one of the field service guys that realized that the customer system had a mixed step board -- i.e. when they replaced a single MPU in the field, the system stopped working). IIRC: Moto never fixed the '10, as that processor was reasonably short lived in the open market. They did fix the microcode in the '20 so the state on the external stack was independent of stepping. Clem

7 years, 10 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 December 2016