MIT provides MULTICS source and documentation (DPS-8 simulation)

jim s jwstephens at msm.umr.edu
Tue Nov 13 00:58:42 CST 2007


Roy J. Tellason wrote:
> On Monday 12 November 2007 17:24, Al Kossow wrote:
>   
>>  > The I/O on a full blown system is where a modern system might have
>>  > emulation problems
>>
>> This is exactly where simulation has been hung up for years. The mass
>> storage and terminal system is complex, with microcoded controllers for
>> tape and disk and dedicated front end processors for terminal/network I/O.
>>     
>
> This sort of thing is exactly the area where I'm fuzziest when it comes to any 
> sort of a real understanding of big iron.  Aside from seeing references to 
> such stuff from time to time,  I really don't have a clue as to why you'd 
> _want_ something like a separate dedicated processor to handle I/O,  for one 
> example. 
The Multics system was designed to be scaled to very large numbers of 
processors and thousands of users.
It was recognized that all of the tasks to handle the disk i/o which was 
very important to performance
need not all go thru the processors in all cases.

Multics was a virtual memory system.  The nature of this sort of system 
was researched by students
at MIT and ideas to enhance performance showed that a lot of the 
activities could be carried out by
subsystems which were dedicated to just the specific task of moving data 
to and from the memory.

Early systems also had three level storage systems which incorporated a 
swapping drum to allow
the same performance of a large amount of core memory w/o having the 
actual core available by
swapping user spaces to the drum.  Disk was sufficiently fast to allow 
the virtual memory approach
to start to be used in a timesharing system, but not fast enough to 
match the drum storage performance.

When the system I worked on was configured the threshold was crossed and 
the USL Multics
system was configured with no drum and a large (1 or 2mb I think) or 
memory rather than a drum.
>  Or mass storage.  Or whatever. 
The communications front end handled a lot of the mundane tasks of 
interfacing with terminals
and transmitted in streams of character data to and from the terminal 
rather than dealing with
character transfers.
>  And I really don't have that much 
> of a handle on how the architecture of those sorts of machines differs from 
> the micros I'm familiar with.  Even that bit of time I got to spend with the 
> Heath H11 was very alien to the rest of what I'm familiar with.
>
> I realize that I'll never get as familiar with some of this stuff as some of 
> you guys that have actually worked with it,  but can any of you point me 
> toward some resources that might let me understand some of it better than I 
> do now?
>   
C. Gordon Bell's books are a good place to start.  One oriented towards 
DEC systems is at

http://research.microsoft.com/~GBell/CGB%20Files/Computer%20Engineering%207809%20c.pdf

This book which is online covers all computers for the time it was 
published and is very useful
to read.

http://research.microsoft.com/~GBell/CGB%20Files/Computer%20Structures%20Principles%20and%20Examples%201982%20ng%20c.pdf

Also on that site is a listing of computer companies he compiled which 
is very useful if you can't
quite think of the name of the computer company you have a part for.  
(off the subject but useful)

http://research.microsoft.com/~GBell/CGB%20Files/91_US_minicomputer_companies_1960-1982+44_minisupers_superminis_scalables_1983-1995.htm

I find his web site is useful in general to pour over for reading.  The 
links above are from books he has had put online
since going to work for Microsoft.

http://research.microsoft.com/~GBell/



More information about the cctech mailing list