On 2016-03-26 20:43, Clem Cole<clemc(a)ccc.com> wrote:
>
> On Fri, Mar 25, 2016 at 11:09 PM, Charles Anthony <
> charles.unix.pro(a)gmail.com> wrote:
>
>> >And Dec's RADIX-50, packing 3 characters into 16 bits. (IIRC the origin of
>> >the 6.3 filenames. bit I can't document that.)
>
> Sort of.... before ASCII, DEC used a few other 5 bit codes that were
> around such as baudot (look at the PDP-1/4 etc and KSR 28). RAD50 was a
> natural scheme for storing file name and using bits efficiently.
>
> Which, of course, lead to the abomination of case folding - it's not a bug,
> it's a feature 😂
>
> RAD50 gave us the x.y file name form with the implied dot et al. 6.3 and
> later 8.3 were natural directions from that coding. Using the .3 ext as a
> type tag of course followed that naturally given that's all that was stored
> in the disk "catalog." [And CP/M and PC/MS-DOS inherit that scheme -
> including the case folding silliness even though by that time all keyboard
> were upper and lower case and they stored the files in 8 bits].
Some other people already mentioned this, but... - SIXBIT. DEC might
have used baudot in the very early machines, but I would say that SIXBIT
dominated here for a long time. We see it both in the PDP-8, but also
the PDP-6 and its follow ons. RAD50 was the natural extension of SIXBIT
on a machine that did not have a word size that was a multiple of 6.
The x.y filename, as well as the 6+3 pattern predate the PDP-11. I would
say that in this area, the PDP-11 didn't come with anything new, but
just made life more complicated.
OS/8 for sure only have 6+2 filenames, but still in the x.y form.
TOPS-10 have, I think, 6+3. And the Monitor (I think that was the name
for the PDP-6 OS) was, I think, also 6+3.
And it was all SIXBIT.
And SIXBIT also give you the case folding.
I say the PDP-11 complicated life just because DEC was already so much
into having filenames stored more compact than normal text, and having a
6+3 pattern, so they came up with R50, which fits the bill, but it's
more headache than it was worth, if you ask me.
Since the PDP-11 have 8 bit bytes, it would have made much more sense to
just store filenames as 8 bit bytes. It would have cost some more
storage, but not that much. But it took time for DEC to realize that the
space savings here were not really a good tradeoff. Old habits die hard,
I guess.
By the way, RSX (and early VMS) actually use 9+3 filenames.
> UNIX of course, would put the "type" in the file itself (magic #) and force
> the storing of the dot, but removed the strict mapping of name and type.
> Having grown up in both systems, I see the value of each; but agree I think
> I find UNIX's scheme better and lot more flexible.
I think I agree on the point of having filenames in a free format. Not
sure I really like storing the type in the file itself. So I'm sortof
torn. Or rather, I would like to keep type separate from both.
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
Hey All,
I just saw in another thread the statement their are no odd requests here.
So I thought I would test that.
The day NeXT took over Apple I read a page somewhere on the internet that started with line.
Bow down to UNIX children of Macintosh... It then when on its Old Testament conquering tone about the new way of computing that was coming.
Does anybody have any idea who wrote this or where to find it?
Thanks,
Ben
Hello everyone,
I am Rocky and this is my first message. Before starting, I would like to thank you for all the valuable informations and stories you post here.
About the History of Unix, I was wondering with another guy why the rc script has that name. As many of you already know, and according to NetBSD, FreeBSD, OpenBSD (current) manual,
"The rc utility is the command script which controls" the startup of various services, "and is invoked by init(8)" (from DESCRIPTION).
"The rc command appeared in 4.0BSD" (from HISTORY).
Words may slightly change between the three distributions, but the meaning and the informations provided are the same. So, the etymology of rc does not appear in the man pages. Do you know how to recover it? Do (or did) the letters rc have some meaning in this context?
Cheers,
Rocky
On 2016-03-25 00:27, Milo Velimirovic wrote:
>
>> On Mar 24, 2016, at 6:06 PM, Johnny Billquist <bqt(a)update.uu.se> wrote:
>>
>> On 2016-03-24 23:50, Peter Jeremy wrote:
>>> On 2016-Mar-24 11:17:18 +0100, Johnny Billquist <bqt(a)update.uu.se> wrote:
>>>> It is the normal behavior of any instruction that interrupts are not
>>>> recognized until the next instruction fetch. This is how the microcode
>>>> works, and it is also pretty much the same in any processor today.
>>> ...
>>>> individual instructions. You still get a fetch between each instruction,
>>>> at which point, interrupts will be recognized.
>>>
>>> Some instructions inhibit the "check for interrupts at the end of this
>>> instruction" check. I'm most familiar with the 8080 EI instruction,
>>> which enabled interrupts after the following instruction (so things like
>>> EI;HLT didn't have a window). It seems the PDP-11 SPL behaves the same.
>>
>> I don't think it should on the PDP-11, and the documentation do not mention any such thing.
>> There is a good reason the 8080 (and Z80, and others) have this property. The RETI instruction on these machines do not enable itnerrupts themselves, so just as you note, you need to both enable interrupts and return from interrupt atomically, or else you get into a mess.
>>
>> The PDP-11 RETI instruction changes the processor priority as a part of the instruction. You do not use SPL (whatever) before a RETI.
>> Thus, it do not make sense that SPL on a PDP-11 would have this property. If if indeed do disable recognizing interrupts after an SPL, it sounds more like a bug. I guess I'll go and read the microcode so see if that mentions any of this, since I'm sortof into reading it anyway as I was trying to debug a problem on an 11/70 only a couple of months ago…
>
> The PDP-11 has no RETI instruction; it has a RTT (ReTurn from Trap) and a RTI (ReTurn from Interrupt) instructions, but you already knew that, right? In some cases it’s problem that it’s not possible to determine which is appropriate or correct to use. According to the PDP11 Architecture Handbook the difference between them is in what happens when the RTx instruction loads a PSW that has the T bit set and when it forces a Trace trap. RTI - immediate trap, RTT traps after the instruction following the RTT.
Oops. Yes, it's RTI and RTT. But the names are beside the point, and so
is the difference between these two. The point is that the
instruction(s) do set the processor priority level, and you do not use
SPL in combination with them, so it makes no sense to have SPL inhibit
interrupts for any length at all. (And yes, I did know that.)
Oh, and as far as RTT vs. RTI goes, not it's not hard to know which one
you want. You want RTT for your debugger and RTI for everything else.
The difference is about what happens after the return. With RTT, the
T-bit trap will not trap until another instruction has executed. With
RTI, you would never manage to step to the next instruction with the
T-bit, since every time you returned, you'd get another trap.
But I bet you knew that as well... ;-)
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
Seems like we are all contributing old card stories.. here is one of my
favorites from my past.
At CMU, all systems programmers working for the computer center had to put
shifts in as the operator behind the "glass door" doing the grunt stuff
(but we got all the computer time we wanted, an office and terminal - so it
was a good deal in those days). The student courses, in particular the
engineering intro to FORTRAN (WATFIV), used the TSS based 360/67 which we
programmed and ran; but they used the batch system on cards not timesharing
with the ASR 33's which was quite expensive. There was a traditional glass
room with the computer, its tapes and other gear, and a counter with a
"call human for help" button where "paying users'" could come ask questions
of the operator on duty. On the older side of the counter was the flock
of keypunch machines and a high speed card read. The printers were in
secure areas, so we would bring out student prints from their batch jobs as
needed and put them on the binds near the counter ( as was the pretty much
the standard of those days).
By rule, the system's programmers were also not supposed to help the
students with their assignments. They were supposed to get help from their
TA's and Profs, *etc*. who had regular hours. But often folks were up
very late working on assignments and no one from the course was around to
ask questions. And as the operator, if you had a minute, it was not
uncommon to have a little empathy for your brothers and sisters in arms on
the other side of the counter. As long as this was not abused, the TA's,
Profs as well as our bosses in the computer center tolerated the process.
But if we were obviously busy, we really did not have the time to do much
to help them.
One night I was working the over night operator shift with another coworker
who will be left nameless (but I will say that he's now a SVP at a large
computer firm these days). It was a very busy night for us for some
reason, probably something like printing bills, or checks for the school or
some such; along with a full backup, so we had our hands full between
mounting tapes, changing types of paper and print heads *etc.*, security
procedures with the results and the like. That night, there was also a big
assignment due shortly for one of the classes.
Sure enough the buzzer started ringing and it was a frustrated (and as I
remember somewhat clueless) student that needed help with his assignment.
He was claiming that the his deck was being rejected/was not working.
Note "turn around" from deposit card deck to receipt of print out was
probably in the order of 10-15 minutes, and sometimes longer. One of us
came out, showed him something like a missing "BATCH WATFIV" command card
or some such and reminded them of the official policy and probably pointed
to the sign, as we were very busy with our job. We would politely tell
them to try to find a TA or someone in the class that could help him.
The student went away, and we went back to work. A few minutes later the
buzzer went off again, same student, and the cycle repeated with some other
trivial issue. After the 4th or 5th time it was becoming a real issue
because we were really quite busy. At that point, my coworker came out and
said, here bring me your deck. He looked at them and quickly said -- "The
problem is you used the wrong color cards."😈
The student was completely dejected and walked away. I looked up and
said, man that was cruel. But it did buy us time to finish our work.
Never found out if he re-keypunched his cards.
Clem
Steve Johnson:
This reminds me that someone at BTL threw together a "TSO Shell". It was
a wrapper around /bin/sh that slept for 10 seconds before executing each
line...
=====
And after each command exited. Discarding anything typed ahead
during the sleep, of course.
And printed all-upper-case IEFCRAPNONSENSE messages even when a
command exited successfully.
I think I still have a copy somewhere. It dates from the 6/e era,
so it would need a lot of work to compile and run on a modern system.
Occasionally I think of converting it to ISO and POSIX even though
that seems contradictory somehow.
Norman Wilson
Toronto ON
Not quite a self reproducing program and I did take down one of the UCSD servers one day.
I was writing a shell script to do some complex and long running task. This was in the early days of the shell supporting functions. The script had a large number of functions and I named one of them to be the same name as the shell script.
I set it in motion and logged out, as I knew it would take several hours to finish the work.
The next day I logged in to find that the machine had the load spike as the shell script recursively started itself when it got to the function call that had the same name as the shell script. The admin kindly sent me a ‘top' output showing the load at several hundred and all the jobs having my name and being my shell script.
Under this he wrote: “Never do this again.”
I haven’t.
David
> Btw. It does not emulate the smell of small machine oil
or the mess of ppt punch chaff on the floor
Yes. I saw Clem's mail just as I was about to recommend
placing a small dish of machine oil beside the simulator.
Alas, it seems I missed out on the chad experience. Data was
regularly imported to the PDP-7 by ppt, but rarely exported.
Night-owl Ken must have taken some ppt backups, evidence of
which the midnight janitors whisked away.
Doug
It's a bit off-topic, but what were non-Unix filesystems like around 1969-1970?
The PDP-7 filesystem has i-nodes (file metadata) and filenames separate
from the i-nodes. This allows hard links and thus a non-tree structured
filesystem.
This has always struck me to be one of the most important features of
the Unix filesystem: names separated from the rest of the file metadata,
and arbitrary hard links so that there is no preferred filename.
Were these features in other contemporaneous filesystems?
As a side note, the PDP-7 kernel knows about the top-level directory ("dd")
but it is agnostic to the concept of "." and "..". What that means is
that you can build a filesystem with "." and ".." links and the kernel
will deal with them as per all other links. But you can also build a
filesystem without "." or ".." and the kernel doesn't care.
There's not enough evidence (source code, papers, anecdotes) to confirm
or deny the presence of "." in the PDP-7 code that Norman scanned for us.
".." does seem to exist as it is mentioned in one source file, ds.s.
It's an intruiging mystery.
Cheers, Warren
This came up today at work; what's the origin of the open file table? The
suggestion was made that, instead, a ref-counted data structure could be
allocated at open() time to serve the same purpose, and that a table of
open files was superfluous. My guess was that this made it (relatively)
easy to look up what files referred to a particular device?
> Those file structures are collected into a single, global table. The
> question is why this latter table? One could rather imagine an
> implementation where open() allocates (e.g., via malloc())
Depending on how malloc() is implemented, fragmentation can be
serious in a program that runs forever with as many frees as
allocs. Separate allocations for each item can also be costly in time.
One malloc() strategy is to divide the arena into regions,
each of which caters for blocks of a single size, so
fragmentation doesn't occur. In essence that's how the
system tables work, except that these tables have
hard limits. Now, if the tables could be reallocated
as needed ...
Another problem with per-item allocations is performance
monitoring and debugging. It's hard to see what's
going on in a well mixed dynamic storage heap.
Doug
https://newsroom.intel.com/news-releases/andrew-s-grove-1936-2016/
I know some of the processor people at intel and I was looking around,
found this, interesting read if you are into the history:
http://people.cs.clemson.edu/~mark/330/chronques.html
For those that don't know, Colwell did the P6 pipeline, I think under
Groove or right after Groove got cancer. There was P5, then P6, then
they did a different pipeline that they called Pentium 4 (made no sense
to me but their names never do). The Pentium 4 was the one where
they speculated on what the answer would be for some instructions.
As in you could do a load and they'd guess that it was zero or not.
They were going for great clock rate, and they got it, but they also
got instructions that would take 2000 cycles to get through.
That pipeline got booted and so far as I know, the Colwell P6 pipeline
lives on in every Intel processor after the Pentium 4.
Getting back to Andy, I loved his time as CEO, I think he did a lot of
good for that company. Here's to him!
Sorry to continue the detour from disk file systems to card trays, but this
> Walking down the corridors of Comp Sci, a student in front of me
> dropped his entire deck of approx 2000 cards, all over the floor...
> I have no idea whether he got them sorted, but I sure as hell used
> rubber bands after that!
reminded me that Vic Vyssotsky liked to say of his BLODI (block diagram)
language for simulating sample-data systems that it was the only card-safe
language. You could toss a program deck down the stairs, pick it up at the
bottom, submit it to the compiler, and it would work. That was 10 years
before the filing of the famous "natural order" patent on spreadsheets,
which ordered execution the same way.
Doug
On 2016-03-18 03:00, Warren Toomey <wkt(a)tuhs.org> wrote:
> It's a bit off-topic, but what were non-Unix filesystems like around 1969-1970?
> The PDP-7 filesystem has i-nodes (file metadata) and filenames separate
> from the i-nodes. This allows hard links and thus a non-tree structured
> filesystem.
>
> This has always struck me to be one of the most important features of
> the Unix filesystem: names separated from the rest of the file metadata,
> and arbitrary hard links so that there is no preferred filename.
>
> Were these features in other contemporaneous filesystems?
I don't know exactly how contemporary ODS-1 is. It's the file system
used on RSX-11, and I think it should atleast trace back to around 1972,
but I can't say more for sure.
Anyway, ODS-1, just like the Unix file system, have the directory hold
just the filename and a file identifier (pretty much the same as inode
number). There are of course some differences in details, but I would
say it is very similar to how Unix works. ODS-1 do not have reference
counting, but instead allows dangling directory entries that do not
point to valid files. Instead ODS-1 have a generation counter for each
file identifier, so that when it is reused, links to the old file will
not accidentally refer to the new file.
I would think that something like Multics had something similar, but I
have no idea about that one...
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
> Were these features [arbitrary hard links] in other contemporaneous filesystems?
Multics had arbitary "links", which were distinguished from "branches"--the
actual file. Links and branches coexisted in directories. Unix was consciously
derived from this model, but simplified so that only links have names
and branches live elsewhere (the inode list). The architecture is
described in http://www.multicians.org/fjcc4.html. This paper is
dates from 1964 or 1965; it was certainly authoritative in 1969.
I don't know whether it evolved further.
Christopher Strachey and Joe Stoy independently conceived a model
isomorphic to Unix for OS 6 at Oxford. The two systems were
essentially contemporaneous.
I am not aware of other systems that allowed multiple names for
one file, though clearly the scent was in the air at the time.
doug
> From: Johnny Billquist
> I would think that something like Multics had something similar
No, as far as I know, Multics was always 'old-style' - the directory contained
not just the name of the file, but also all the file's meta-data. Multics had
only symbolic links, I'm pretty sure.
To answer the original question, I can't think offhand of another system that
separated naming and file meta-data before Unix did it. I've always assumed
that that was one of Unix' novel ideas.
Noel
$ pdp7 unixv0.simh # Run the PDP-7 Unix kernel on SimH
PDP-7 simulator V4.0-0 Beta
sim> c # Start execution
login: ken
password: ken
@ date
Thu Jan 01 1970 00:00:05
@ ls -l
00004 drw-- 01 777 00050 dd
00035 drwr- 01 012 00060 .
00003 drw-- 01 777 00270 system
00036 lrwr- 01 777 00305 date
00037 lrwr- 01 777 00441 ls
@
inum perms lnks uid size file
Root was user-id -1, but the octal print routine sees as an unsigned
int and prints it truncated to three octal digits, 777.
So, the kernel boots and runs.
Cheers, Warren
(Posted to both The Unix Heritage Society and the TZ mailing list)
I've been off-and-on reading the "live minus thirty years" old usenet
feed at olduse.net, and noticed something that may be of interest to
both of these groups: The original mod.sources posting of the (as far as
I can tell) earliest available version of Arthur David Olson's timezone
handling code, in 1986.
https://groups.google.com/d/msg/mod.sources/gcolqTxTt9w/04ZtaYCxLvcJ
For the files present in both, it matches revision 7441f6b6 from the git
repository, except for SCCS IDs vs %W%.
https://github.com/eggert/tz/tree/7441f6b6705782743f40b9fc40cdcc80a498fda5
The git repository contains a file ialloc.c that is not present in the
release.
Probable renamed files - These appear in the git repository under their
new
names, but had the older names in the release.
New: localtime.c newctime.3 zdump.c zic.8 zic.c
Old: tzcomp.8 tzcomp.c tzdump.c settz.c settz.3
Files in the release but not this version of the git repository:
mkdir.c strchr.c: These never appear, though they're referenced in
Makefile edits.
pacificnew: doesn't appear until SCCS version 8.1 in revision aaf2a927
dated July 2006.
years.sh: Appears as SCCS 7.1 yearistype.sh, dated March 1992.
According to Ken, the inspiration for ++ and -- came
from the PDP-7 hardware, not from previous languages.
The PDP-7 supported only ++i, where i had to be one
of only a few memory addresses. "For symmetry", Ken
says, he put all four operations in B. (And he did
not use the hardware autoincrement.)
Doug
All,
Is there a good source of information about the Unix v6 filesystem
outside of the source code itself? Also, is there a source for the
history of the early Unix filesystems from v6 onward?
Thanks,
Will
> From: Brantley Coile
> But B's ++ and -- operators seem to be unique.
B seems to be like UNIX itself in this regard: a carefully selected set of
old ideas, along with a few new ones of equal value.
Noel
>> https://www.bell-labs.com/usr/dmr/www/kbman.html
>> https://www.bell-labs.com/usr/dmr/www/bintro.html
> Yup, there certainly were different versions of B.
Yes, kbman covers only one of the two implementations that
cohabited the PDP-11. The other was the same language, with
software paging, so it could have a larger data space.
Various aspects of the language were borrowed from PL/I,
BCPL and Algol 68. ++ and -- were novel operators. The
reversal of Algol's assignment operators (e.g. -=
became =-) was eventually repealed in C.
doug
e
