I decided that, given that we have a few years until the 50th anniversary,
that I would set up a wiki for Unix in a similar vein to the Multicians one.
So I've made a start at http://wiki.tuhs.org (if/when the A record propagates).
I'd love to get some other people to help out, but I'll keep adding stuff
and we will see how it goes. Any good anecdotes about Unix are most welcome!
If you want to get edit status, register and then e-mail me so I can
manually mark you as having edit status.
Cheers, Warren
> > Louis wrote a disk loaded program called RUNCOM that read command
> > lines from a file,
> Hence, presumably, the .foorc files of Unix and the rc shell.
Yes, rc files were named for runcom, but did not adhere to runcom's
curious limit of 6 commands.
Doug
I got this a couple of days ago and thought I had sent it on, but
apparently not. Here goes.
Greg
On Saturday, 26 December 2015 at 11:12:59 -0500, Tom Van Vleck wrote:
> Short answer to your question is "depends on what you mean by shell."
> Answer for Unix heads is http://multicians.org/shell.html where Louis Pouzin says he made up the name
> for Multics. We never called the CTSS command processor a shell.
>
> When I used CTSS in 1963, command processing was in (wired) code in A-core.
> A simple program tokenized input lines, looked up the token in A-core tables, and either ran an
> A-core routine or loaded a command file, passing the rest of the arguments as a string array.
> To add a command, you had to recompile CTSS. Look at the module COMC in the source.
>
> This command language is documented in the "candy stripe" CTSS manual.
> http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf
>
> About 1964 or 65, COMC was changed to not list the disk loaded commands; if the table
> lookup failed, COMC looked for a disk file in a system directory, and ran it if it was found.
> System maintainers could add a command by copying a file into the directory.
> Command files were in core image format, already loaded and linked. Conventional practice
> was to make them small and to expand the core image for things like I/O buffers at execution start.
>
> Some disk-loaded commands were listed in COMC and flagged as "privileged" so that they could
> call special supervisor entries to get the supervisor to do things forbidden to regular programs.
> the LOGIN command was an example: it could read the password file, forbidden to regular users,
> and could patch the A-core table of logged in users.
>
> Louis wrote a disk loaded program called RUNCOM that read command lines from a file, substituted
> arguments into the command, and requested the supervisor to run them, and then return control
> to RUNCOM. This is a shell-like function.
>
> Noel Morris and I wrote an author-maintained unprivileged B-core CTSS program in 1965 called
> . SAVED that was also shell-like. It read lines from the terminal, tokenized them, expanded
> abbreviations and iterations, and ran sequences of commands, and then resumed itself. It had other
> features such as inter-user text messages. It allowed power CTSS users to extend the
> system-provided command set with their own set of SAVED files, all treated uniformly.
>
> Noel and I also added a facility to CTSS that allowed the system to run batch jobs. The user
> submitted a RUNCOM file to a queue for later processing, much like Unix CRON.
>
> Revised command processing, RUNCOM, and . SAVED are documented in the second edition CTSS manual.
> http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf
>
> Multics had a program known as the shell, which went through a long series of evolutions.
> Users could replace their command shell. A program called the listener read command lines
> and fed them to the shell, which tokenized the command lines and found and called individual commands.
> The argument-substituting run-from-a-file mode of operation of RUNCOM was done by the exec_com command.
> All of these Multics features and design were familiar to Ken and Dennis when they worked on Multics.
>
> You say you have been looking at the CTSS source. You know you can run a simulated
> 7094 running a simulated CTSS, right? http://www.cozx.com/~dpitts/ibm7090.html
>
> regards, tom
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
Jon von Neumann was born in 1903; without him, we probably wouldn't have
had computers at all (but we could've had a Wintel version, I suppose,
wherein everything is controlled by BB).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
All,
I just finished some compact analyses on the boot loaders that are
presented in "Setting up Unix - Sixth Edition" by Thompson and Ritchie.
They are in followup to the more detailed analysis of the Tape Bootstrap
Loader that I mentioned previously and the entry is posted here:
http://decuser.blogspot.com/2015/12/pdp-11-bootstrap-loaders-some-analysis.…
What was most interesting about the analyses and programs was how
related they were. At the end of the day, once I understood how the
first one worked, the other two were pretty simple and required only
minor tweaks in the coding to achieve their results.
I am moving on now that I have a pretty good idea of how these bits of
code work and will be starting to program in Macro-11 for a few weeks to
get a handle on things before I return to the deep dive into the source
code of v6 that I temporarily put on hold so I could actually make sense
of the Assembly bits.
I really appreciate everyone's help, tips, suggestions and even critiques.
Thanks,
Will
I must be the only guy here who browses reddit (or I missed someone
else posting this).
This dude ported 5th edition to a game boy. I'll admit my non coolness
by saying I don't know what a game boy is but I'm guessing it's some
video game thingy.
http://www.kernelthread.com/publications/gbaunix/
Dave Horsfall:
Jon von Neumann was born in 1903; without him, we probably wouldn't have
had computers at all (but we could've had a Wintel version, I suppose,
wherein everything is controlled by BB).
====
On this day in Australia, but not yet in North America or Europe.
Or, as Warren would probably prefer, it was 2015 in England, but still only
1903 in Australia. Such was the great difference in time twixt these two
great nations.
Australia, Australia, we love you from the heart,
the liver, the kidneys, and the giblets,
and every other part!
Norman Wilson
Toronto ON
All,
I'm trying to understand the RK bootloader code that is found in
"Setting up Unix - Sixth Edition". My question is related to RKBA, RK's
bus address buffer. Is the bus address the same as memory address? If
so, the code makes sense, if not, I appreciate y'alls help.
Here's what I have so far:
RK05
01 012700 MOV 177414,R0 ; Move RKDB into R0
02 177414 ; RKDB Address
03 005040 CLR -(R0) ; Decrement R0 and clear the contents of RKDA
04 005040 CLR -(R0) ; Decrement R0 and clear the contents of RKBA
05 010040 MOV R0,-(R0) ; Move the contents of R0(RKBA) into
decremented R0(RKWC)
06 012740 MOV 5,-(R0) ; Decrement R0 and move 5 into RKCS
07 000005 ; Read and go
08 105710 WAIT: TSTB (R0) ; Test the lower byte of RKCS
09 002376 BGE WAIT ; When bit 7 becomes 1, the read is done
10 005007 CLR PC ; Set PC 000000, the start of the bytes read
RKDB - RK data buffer register
This register is a general data register and it only used by the code
above to initialize R0 so that subsequent RK addresses can be found by
simply decrementing R0.
RKDA - RK disk address register
This register determines the starting disk address of the read operation
and is cleared by the code.
RKBA - RK current bus address register
This register contains the bus address to or from which data will be
transferred. Is this the same as memory address?
RKWC - RK word count register
Two's complement of the number of words to be transferred.
RKCS - RK control status register
This is the register that controls the device and provides the device
status to the program
Lines 1-2
The execution of the boot loader code moves the address of RKDB into R0
to initialize the register so that it can be used to obtain the other RK
buffer addresses as they are needed.
Line 3
The RKDA buffer is cleared, setting the disk address to 0.
Line 4
The RKBA buffer is cleared, setting the bus address to 0.
Line 5
The value in R0 is transferred into the RKWC buffer. RKBA or 177410, the
value in R0, is a convenient number to use for the read operation
because it is big enough to cause the program to read in a block of
data. The number is in two's complement and represents -370. This tells
the disk controller that 370 words (540 bytes) will be transferred.
Lines 6-7
The value 5 is placed into RKCS, this value represents a read operation
and go.
Lines 8-9
The lower byte of RKCS is tested and when it is greater than or equal to
zero (not negative), it loops, waiting until the value is negative, that
is until bit 7 becomes 1, which indicates Control Ready (RDY) and done.
Line 10
PC is set to 00000 and execution of the bytes read from the disk
begins at location 00000.
