So there are a few ports I know of that I wonder if they ever made it back
into that great github repo.I don't think they did.
harris
gould
That weird BBN 20-bit machine
(20 bits? true story: 5 4-bit modules fit in a 19" rack. So 20 bits)
Alpha port (Tru64)
Precision Architecture
Unix port to Cray vector machines
others? What's the list of "lost machines" look like? Would companies
consider a donation, do you think?
If that Cray port is of any interest I have a thread I can push on maybe.
but another true story: I visited DEC in 2000 or so, as LANL was about to
spend about $120M on an Alpha system. The question came up about the SRM
firmware for Alpha. As it was described to me, it was written in BLISS and
the only machine left that could build it was an 11/750, "somewhere in the
basement, man, we haven't turned that thing on in years". I suspect there's
a lot of these containing oxide oersteds of interest.
ron
(Yes, a repeat, but this momentous event only happens every few years.)
The International Earth Rotation Service has announced that there will be
a Leap Second inserted at 23:59:59 UTC on the 31st December, due to the
earth slowly slowing down. It's fun to listen to see how the time beeps
handle it; will your GPS clock display 23:59:60, or will it go nuts
(because the programmer was an idiot)?
I actually have a recording of the last one, over at
www.horsfall.org/leapsecond.webm (yes, I am a tragic geek),
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
>Date: Wed, 4 Jan 2017 16:41:07 -0500
>From: "Ron Natalie" <ron(a)ronnatalie.com>
>To: "'ron minnich'" <rminnich(a)gmail.com>, <tuhs(a)minnie.tuhs.org>
>Subject: Re: [TUHS] lost ports
>Message-ID: <01c001d266d3$42294820$c67bd860$(a)ronnatalie.com>
>Content-Type: text/plain; charset="utf-8"
...
>I did kernel work on the PA for HP also worked on their X server (did a few other X server >over the years).
>The hard part would be finding anybody from these companies who could even remember
>they made computers let alone had UNIX software.
I worked for the computer division in Philips Electronics, DEC,
Compaq, HP, HPE and still remember some of it :-)
I wasn't involved in OS development, but in testing, turnover to
National Sales Organisations, etc. Even now at some customer side I
still have a few aDEC400xP servers from 1992 running SCO UNIX 3.2V4.2
(last update 1999). Also a few AlphaServers with Digital UNIX, Tru64;
finally some Itanium servers with HP-UX 11.23/11.31.
Especially the big/small endian issue gave our customer (and therefore
myself) a few headaches. Imagine getting a chunk of shared memory and
casting pointers assuming the 'system' takes care of alignment. Big
surprise for the customer moving from Tru64 to HP-UX.
I just went looking at the v6 source to confirm a memory, namely that cpp
was only invoked if a # was the first character in the file. Hence, this:
https://github.com/dspinellis/unix-history-repo/blob/Research-V6-Snapshot-D…
People occasionally forgot this, and hilarity ensued.
Now I'm curious. Anyone know when that convention ended?
ron
Goodness, I go to sleep, wake up 8 hours later and there's 50 messages in
the TUHS mailing list. Some of these do relate to the history of Unix, but
some are getting quite off-topic.
So, can I get you all to just pause before you send in a reply and ask:
is this really relevant to the history of Unix, and does it contribute
in a meaningful way to the conversation.
Looks like we lost Armando, that's a real shame.
Cheers, Warren
Peter Salus writes "The other innovation present in the Third Edition
was the pipe" ("A Quarter Century of Unix", p. 50). Yet, in the
corresponding sys/ken/sysent.c, the pipe system call seems to be a stump.
1, &fpe, /* 40 = fpe */
0, &dup, /* 41 = dup */
0, &nosys, /* 42 = pipe */
1, ×, /* 43 = times */
On the other hand, the Fourth Edition manual documents the pipe system
call, the construction of pipelines through the shell, and the use of wc
as a filter (without an input file, as was required in the Second Edition).
Would it therefore be correct to say that pipes were introduced in the
Fourth rather than the Third Edition?
>
> What made Linux happen was the BSDi/UCB vs AT&T case. At the time, a
> lot of hackers (myself included) thought the case was about *copyright*.
> It was not, it was about *trade secret* and the ideas around UNIX. * i.e.*
> folks like, we "mentally contaminated" with the AT&T Intellectual Property.
>
Wasn’t there a Usenix button with the phrase “Mentally Contaminated” on it?
I’m sure I’ve got it around here somewhere. Or is my memory suffering from
parity errors?
David
> keeping the code I work on portable between Linux and the Mac requires
> more than a bit of ‘ifdef’ hell.
Curmudgeonly comment: I bristle at the coupling of "ifdef" and "portable".
Ifdefs that adjust code for different systems are prima facie
evidence of NON-portability. I'll buy "configurable" as a descriptor
for such ifdef'ed code, but not "portable".
And, while I am venting about ifdef:
As a matter of sytle, ifdefs are global constructs. Yet they often
have local effects like an if statement. Why do we almost always write
#ifdef LINUX
linux code
#else
default unix code
#endif
instead of the much cleaner
if(LINUX)
linux code
else
default unix code
In early days the latter would have cluttered precious memory
with unfreachable code, but now we have optimizing compilers
that will excise the useless branch just as effectively as cpp.
Much as the trait of overeating has been ascribed to our
hunter ancestors' need to eat fully when nature provided,
so overuse of ifdef echos coding practices tuned to
the capabilities of bygone computing systems.
"Ifdef hell" is a fitting image for what has to be one of
Unix's least felicitous contributions to computing. Down
with ifdef!
Doug
From: "Doug McIlroy" <doug(a)cs.dartmouth.edu>
Subject:Re: [TUHS] Mac OS X is Unix
> keeping the code I work on portable between Linux and the Mac requires
> more than a bit of ‘ifdef’ hell.
| Curmudgeonly comment: I bristle at the coupling of "ifdef” and "portable".
| Ifdefs that adjust code for different systems are prima facie
| evidence of NON-portability. I'll buy "configurable" as a descriptor
| for such ifdef'ed code, but not "portable".
| <snip>
| "Ifdef hell" is a fitting image for what has to be one of
| Unix's least felicitous contributions to computing. Down
| with ifdef!
| Doug
Doug makes a very good point about ifdef hell. Though I’d claim that it isn’t even “configurable” at some level.
Several years ago I was working at Megatek, a graphics h/w vendor. We were porting the X11 suite to various new boards at the rate of about 1 a week it seemed. Needless to say the code became such a mishmash of ifdef’s that you couldn’t figure out what some functions did any longer. You just hoped and prayed that your patch worked properly on the various hardware you were targeting and didn’t break it for anyone else. You ran the unit tests, if they passed you pushed your change and ran an hid under a rock for a while until you were sure it was safe to come out again.
David
hi all,
For those who have been following my 2.11BSD conversion, I was working
on this in about 2005 and I might have posted about it then, and then
nothing much happened while I did a university degree and so on, but
recently I picked it up again. When I left it, I was partway through
an ambitious conversion of the BSD build system to my own design (a
file called "defs.mk" was included in all Makefiles apparently), and I
threw this out because it was too much work upfront. The important
build tools like "cc" were working, but I have since reviewed all
changes and done things differently. The result is I can now build the
C and kernel libraries and a kernel, and they work OK.
This seems like a pretty good milestone so I'm releasing the code on bitbucket.
See https://bitbucket.org/nick_d2/ for the list of my repositories,
there is another one there called "uzi" which is a related project,
but not document so I will write about it later, in the meantime
anyone is welcome to view the source and changelogs of it.
The 2.11BSD repository is at the following link:
https://bitbucket.org/nick_d2/211bsd
There is a detailed readme.txt in the root of repository which
explains exactly how I approached the conversion and gives build
instructions, caveats and so forth. To avoid duplication I won't post
this in the list, but I suggest people read it as a post, since it's
extremely interesting to see all the porting issues laid out together.
See
https://bitbucket.org/nick_d2/211bsd/src/27343e0e0b273c2df1de958db2ef5528cc…
Happy browsing :)
cheers, Nick
> From: Clem Cole
> You might say something like: Pipe's were developed in a 3rd edition
> kernel, where there was is evidence of nascent idea (its has a name and
> there are subs for it), but the code to fully support it is lacking in
> the 3rd release. Pipes became a completed feature in the 4th edition.
To add to what others have pointed out (about the assembler and C kernels),
let me add one more data-bit. In the Unix oral histories done by Michael S.
Mahoney, there's this:
McIlroy: .. And on-e day I came up with a syntax for the shell that went
along with the piping, and Ken said, "I'm going to do it!" He was tired of
hearing all this stuff, and that was - you've read about it several times,
I'm sure - that was absolutely a fabulous day the next day. He said, "I'm
going to do it." He didn't do exactly what I had proposed for the pipe
system call; he invented a slightly better one that finally got changed
once more to what we have today. He did use my clumsy syntax.
He put pipes into Unix, he put this notation [Here McIlroy pointed to the
board, where he had written f > g > c] into shell, all in one night. The next
morning, we had this - people came in, and we had - oh, and he also changed
a lot of - most of the programs up to that time couldn't take standard
input, because there wasn't the real need. So they all had file arguments;
grep had a file argument, and cat had a file argument, and Thompson saw
that that wasn't going to fit with this scheme of things and he went in and
changed all those programs in the same night. I don't know how ... And the
next morning we had this orgy of one-liners.
So I don't think that suggested text, that it was added slowly, is
appropriate. If this account is correct, it was pretty atomic.
It sounds more the correct answer to the stuff in the source is the one
proposed, that it got added to the assembler version of the system before it
was done in the C version.
Noel
Warren:
Can anybody help explain the "not in assembler" comment?
====
I think it means `as(1) has predefined symbols with the
numbers of many system calls, but not this one.'
Norman Wilson
Toronto ON
I recall reading a long time ago a sentence in a paper Dennis wrote which
went something like "Unix is profligate with processes". The word
profligate sticks in my mind. This is a 30+-year-old memory of a probably
35+-year-old paper, from back in the day when running a shell as a user
level process was very controversial. I've scanned the papers (and BSTJ) I
can find but can't find that quote. Geez, is my memory that bad? Don't
answer that!
Rob Pike did a talk in the early 90s about right and wrong ways to expose
the network stack in a synthetic file system. I'd like to find those
slides, because people keep implementing synthetics for network stacks and
they always look like the "wrong" version from Rob's slides. I've asked him
but he can't find it. I've long since lost the email with the slides,
several jobs back ...
thanks
ron
> In one of his books, Wirth laments about programmers proudly
> showing him terrible code written in Pascal
For your amusement, here's Wirth himself committing that sin:
http://www.cs.dartmouth.edu/~doug/wirth.pdf
> From: Nick Downing
> way overcomplicated and using a very awkward structure of millions of
> interdependent C++ templates and what-have-you.
> ...
> the normal standard use cases that his group have tested and made to
> work by extensive layers of band-aid fixes, leaving the code in an
> incomprehensible state.
Which just goes to provide support for my long-term contention, that language
features can't help a bad programmer, or prevent them from writing garbage.
Sure, you can take away 'goto' and other dangerous things, and add a lot of
things that _can_ be used to write good code (e.g. complete typing and type
checking), but that doesn't mean that a user _will_ write good code.
I once did a lot of work with an OS written in a macro assembler, done by
someone really good. (He'd even created macros to do structure declarations!)
It was a joy to work with (very clean and simple), totally bug-free; and very
easy to change/modify, while retaining those characteristics. (I modified the
I/O system to use upcalls to signal asynchronous I/O completion, instead of
IPC messages, and it was like falling off a log.)
Thinking we can provide programming tools/languages which will make good
programmers is like thinking we can provide sculpting equipment which will
make good sculptors.
I don't, alas, have any suggestions for what we _can_ do to make good
programmers. It may be impossible (like making good sculptors - they are born,
not made).
I do recall talking to Jerry Saltzer about system architects, and he said
something to the effect of 'we can run this stuff past students, and some of
them get it, and some don't, and that's about all we can do'.
Noel
I have a ImageMagic CD that I got back in 1994 that I found in my
garage. It has a bunch of versions of linux that aren't on kernel.org.
The 0.99 series, the 0.98 series and what looks like 1.0 alpha pl14
and pl15.
Is anybody here interested in them?
I have fallen out of contact with the Linux folks, so don't know if
anybody on kernel.org would be interested in these. Does anybody care?
Warner
On 2016-12-29 03:00, Nick Downing <downing.nick(a)gmail.com> wrote:
> I will let you know when I get
> it working :) It's not a current focus, but I will return to it someday.
> In the meantime, I'm putting it on bitbucket, so others will be able to
> pick it up if they wish. However, this also isn't my current focus, it's
> there, but it's not documented.
>
> The IAR compiler on the Z180 supports a
> memory model similar to the old "medium" memory model that we used to
> use with Microsoft or Turbo C on DOS machines, that is, multiple code
> segments with a single data segment. Yes, the Z180 compiled C code is
> larger than the PDP-11 compiled C code, but luckily you can have
> multiple code segments, which you cannot (easily) have on the PDP-11.
>
> Unfortunately code and data segments share the same 64 kbyte logical
> address space, so what I did was to partition the address space into 4
> kbytes (always mapped, used for interrupt handlers, bank switching
> routines, IAR compiler helper routines, etc), 56 kbytes (kernel or
> current process data and stack) and 4 kbytes (currently executing
> function). The currently executing function couldn't be more than 4
> kbytes and couldn't cross a physical 4 kbyte boundary due to the
> hardware mapping granularity, but this was acceptable in practice.
>
> I got
> the Unix V7 clone working OK under this model and then added the
> networking, so although it was a bit of a dogs breakfast, it proves the
> concept works. My memory management left a fair bit to be desired (too
> much work to fix) however I think porting 2.11BSD would solve this
> problem since it works in the PDP-11 under split I/D, which has similar
> constraints except the 4 kbyte code constraint. My understanding is
> 2.11BSD is actually a cut down 4.3BSD running on the HAL from 2.xxBSD, I
> would like to audit each change from 4.3BSD to make sure I agree with
> it, so essentially my project would be porting 4.3BSD rather than
> 2.11BSD. But I'd take the networking stack and possibly a lot more code
> from 2.11BSD, since it is simplified, for instance the networking stack
> does not use SYN cookies. cheers, Nick
Having written quite some code on the Z180, as well as god knows how
much code on the PDP-11, I'm going to agree with Peter Jeremy in that I
do not believe 2.11BSD can be made to run on a Z180. (Well, of course,
anything is possible, you could just write a 68000-emulator, for
example, but natively... no.)
Unix V7 is miles from 2.11BSD. Unix V7 can run on very modest PDP-11
models. 2.11BSD cannot be made to run on a PDP-11 without split I/D
space, which effectively gives you 128K of address space to play with,
in addition to the overlaying done with the MMU remappings.
The MMU remappings might be possible to emulate enough with the segment
registers of the Z180 for the Unix needs, but the split I/D space just
won't happen.
2.9BSD was the last version (I believe) which ran on non split-I/D machines.
Johnny
>
> On Wed, Dec 28, 2016 at 6:14 PM, Peter Jeremy <peter(a)rulingia.com> wrote:
>> On 2016-Dec-25 17:21:31 -0500, Steve Nickolas <usotsuki(a)buric.co> wrote:
>>> On Mon, 26 Dec 2016, Nick Downing wrote:
>>>> I became frustrated with the limitations of both UZI and NOS and decided to
>>>> port 2.11BSD to the cash register as the next step, my goal was (a) make it
>>>> cross compile from Linux to PDP-11, (b) check it can build an identical
>>>> release tape through cross compilation, (c) port it to Z80 using my
>>>> existing cross compiler.
>>> A Z180 is powerful enough to run 2.11BSD? o.o;
>> I suspect shoe-horning 2.11BSD onto a Z180 would be difficult - 2.11BSD
>> on a PDP-11 requires split I+D and has kernel and userland in separate
>> address spaces. Even with that, keeping the non-overlay part of the
>> kernel in 64KB is difficult. Equivalent Z180 code is going to be much
>> larger than PDP-11 code.
>>
>> I'd be happy to be proved wrong.
>>
>> --
>> Peter Jeremy
--
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
Since Larry started the wish-listing of people we'd like to see on the
list, I'll add mine:
* Doug Gwynn
* Chris Torek
* Guy Harris
Anyone know how to track down any of these folks?
My two cents. :-)
Happy New Year everyone,
Arnold
As Neil Young said when he played with the band, it's been of one of
the great joys of my life to be here with you (yeah, I paraphrased).
As a kid who wanted to be at Bell Labs, a student who got the troff
manual and used it for the next 30 years, a student who got an account
on the vax 11/750 that had the BSD source on it and learned so much,
I just want to thank all of the Bell Labs people for being here and
Warren for putting this list together and for Unix teaching me so much.
If I could have one thing for Christmas it would be bwk joining the list.
I did some extensions to awk and asked him about it and he tarred up
~bwk/awk and sent it to me. I've got the awk source and the book source
in english and french (I think). Brian is awesome, it would be cool to
have him on this list.
All that said, I super grateful to be here amongst the people who were
there when you got an image from Ken. You guys are lucky.
--lm
[ This whole article is just a flight of fancy; feel free to ignore it or
at least treat it as the whimsy that it is. ]
The PDP-7 Unix system is the first step on the evolution of Unix as we know it.
We have a snapshot of the system around the end of 1970/beginning of 1971 at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/
and a reconstructed and working partial system at
https://github.com/DoctorWkt/pdp7-unix
PDP-7 Unix was a playground for Ken, Dennis and others to try out ideas and
implementations, and it was quickly superseded by 1st Edition PDP-11 Unix.
Details of how it evolved are at https://www.bell-labs.com/usr/dmr/www/hist.html
and https://www.bell-labs.com/usr/dmr/www/chist.html
All fine and good. However, I keep wondering, how far could they have taken
Unix on the PDP-7 platform?
The Kernel
----------
The reconstructed kernel only occupies 3070 words of 4096 words available,
so there is room left for more code. There is already an alternative
reconstruction where the "dd" concept has been replaced with the ".."
concept (see https://github.com/DoctorWkt/pdp7-unix/tree/master/src/alt)
PDP-7 Unix doesn't have the concept of absolute or relative filenames
(e.g. /usr/bin/ls or a/b/c or ../../file), Could the nami kernel function
be modified to do this? It would probably mean changing from two characters
packed into a word to a single character per word (to make searching for
'/' easier), and this would turn it into something more recognisable as Unix.
What about pipes? They should not be too hard to implement. Even sixteen
pipes with a 16-word buffer each would only be 256+ extra data words in
the kernel. And a hundred words of code?
There are only a few special devices in the kernel: ttyin, ttyout, keyboard,
display, pptin, pptout. What about a disk block device? Was there a PDP-7
tape device, and if so, why not a tape driver and block device?
Filesystem
----------
The implementation of the filesystem is, in some places, quite inefficient.
The free block list is implemented as follows. In each block, there are
10 free block numbers then a pointer to the next part of the free list.
However, each block can hold 64 block numbers, so why are only 10 free
block numbers stored in each block? By using the whole of a block to store
free block numbers, there would actually be more free blocks to use!
Each i-node (size 12 words, 7 of which are direct or indirect pointers)
has one word which holds a unique value. This doesn't seem to be used at
all. If it was reused as a block pointer, this would allow files to be
up to 8*64=512 (small) or 8*64*64=32768 (large) words in length, instead of
7*64=448 words (small) or 7*64*64=28672 (large) words.
The system is set up to only use one side of the two-sided disk device.
It looks like the other side was used to backup (snapshot) a working
system in case of catastrophic filesystem corruption: they could simply
copy the blocks from the "snapshot" side back to the working side. We
could double the size of the filesystem quite easily.
Macro Assembler
---------------
The kernel is written using fairly tight assembly code, and there probably
isn't a way to translate it into a high-level language. The PDP-7 has an
arcane instruction set, and the existing assembler syntax is nothing special.
What about a macro assembler that makes it easier to write code, especially
readable code? Here are some ideas based on the existing kernel:
u.rq := 8 ==> lac 8; dac u.rq
function swap ==> swap: 0
{
return; jmp swap i
}
subroutine .fork ==> fork: line 1 // i.e. not a function
{
line 1
}
loop ==> 1:
{
} jmp 1b
if (sad dm1) ==> sad dm1
{ jmp 1f
code1 code1
} else { 1: code2
code2
}
betwen(o101,o132) ==> jms betwen; o101; o132
There are probably a bunch more that could be added. The aim is to
make the control structures easier to read and write. The programmer
still has to grok the PDP-7 instruction set.
B (or other) Language
---------------------
PDP-7 Unix has a B compiler while compiles source down to a virtual
instruction set which is interpreted by the B interpreter. We have the
B interpreter code, and Robert Swierczek managed to rewrite the B compiler,
see https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/b.b
At first glance, the PDP-7 architecture is not that amenable to high level
languages, but it turns out that it is indeed possible to write a compiler for
a C subset that targets the PDP-7, see https://github.com/DoctorWkt/a-compiler.
So, could the B compiler be modified to actually output PDP-7 assembly code?
If so, we could rewrite the utilities (cp, mv, ls etc.) in a high-level
language and make the system easier to maintain. I would recommend treating
int and char as the same and only storing one char per word.
And then, even though the PDP-7 architecture doesn't support it, how hard
would it be to add int/char types and bring the language one step closer to C?
Conclusion
----------
All of this is pie in the sky. It can certainly be done, but a) who has
the time and b) it would be a "tour de force", nothing really useful. But
imagine if, at the beginning of 1970, Unix had a proper B or C compiler,
utilities written in this high-level language, a kernel written in a semi-high
level language, and a system with pipes and proper pathnames.
Cheers, Warren
Let me be the first to say that the International Earth Rotation Service
has announced that there will be a Leap Second inserted at 23:59:59 UTC on
the 31st December, due to the earth slowly slowing down. It's fun to
listen to see how the time beeps handle it; will your GPS clock display
23:59:60, or will it go nuts like my last one did (I had to power cycle
the thing)?
My recording of the last one: horsfall.org/leapsecond.webm .
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> So was "/usr/bin" initially only for user-contributed binaries, or was
it from its inception a place for binaries that were not essential for
system boot and could not fit in the root partition?
The latter is my understanding, but early on the two
interpretations would have been nearly coextensive.
Remember, though, that even Ken wrote some "user-contributed"
code.
Doug
