Greybeards

[Robert Bonomi]

>Date: Fri, 22 Oct 2010 10:33:20 -0700
>From: Gary Kline <kline at thought.org>
>Subject: Re: Greybeards (Re: Netbooks & BSD)
>
>On Thu, Oct 21, 2010 at 06:22:59AM -0500, Robert Bonomi wrote:
>> > From owner-freebsd-questions at freebsd.org  Wed Oct 20 15:04:17 2010
>> > From: Mike Jeays <mike.jeays at rogers.com>
>> > To: Bob Hall <rjhjr0 at gmail.com>,
>> >         FreeBSD Mailing List <freebsd-questions at freebsd.org>
>> > Date: Wed, 20 Oct 2010 16:05:34 -0400
>> > Cc: 
>> > Subject: Re: Greybeards (Re: Netbooks & BSD)
>> >
>> >
>> > OK, I guess you win! End-of-thread time?
>> 
>> Well, if one is going to get into that kind of bragging, the first *mainframe*
>> I worked on didn't have any disks at all. purely mag-tape based.   An early-
>> generation IBM system/360 with a whopping 64k words of _core_ memory.  The 
>> operating system was "TOS" (the <T>ape <O>perating <S>ystem), predecessor of
>> DOS, which the machine was upgraded to when they got a couple of hard-disks
>> for it.  Single user, bare-bones batch processing,  punch-card input.  
>> late 1960s.
>
>
>	I learned FORTRAN back in summer quarter '78 on a CDC-6400 that
>	used punch cards.  Had to use my _nose_ to finish one card.  The 
>	6400 took up a chunk of the basement of Evans HAll and had a
>	HUGE 64k of core!  That's the limit of my bragging--er,
>	commenting:-)
>
>	"TOS"?  <snicker>, LOL, ROFL ...

Yawp.  Really.  TOS and DOS.  Those _were_ the names the two OS varients
were known by.  

Not too long thereafter, IBM decided the minimum configuration would include
disk packs,  And 0S/360 became the universal choice.


As for the 6400, it had 64k words of 60-bit  (each word could hold 10 
characters in the internal CDC character set) memory.  roughly 2x to 2.5x
the capacity of the 64k 32-bit words on the IBM.

I programmed on the 6400, and it's big brother, the 6600, for a number of 
years.  An absolutely _lovely_ architecture  at a high level it was a 
beatutifully simple architecture,  with a machine-language that you could
learn in an afternoon, if you'd had any exposure to _any_ other assemler
language.  The instruction set was _so_ rational, you didn't need a "cheat
sheet" (aka, "green card", "yellow card", whatever) to keep track of what
was what.

Now, admittedly, the closer you got to the hardware, the more "strange" the 
machine got.  It's the only machine I know of, where "CPU HALT" is an
_unpriviliged_ user-mode instruction. and one where user programs are 
*expected* to use it to end every program.

And, of course, the 6600 architecture (the 6600 was the original model, 6400s
were introduced later as a 'economy' version) as one other endearing 
characteristic.  It *can't*add*.  At the hardware level, addition is done
by 'complement and subtract'.  And  the CPU clock is more than 10x faster 
than memory read cycle.  Memory is 32-way(!!) interleaved, to keep up.

Oh yeah, the machine -really- annoyed computer-science purists.  Up to
the limit of data that you oult fit in main memory, an optimized _bubble-
sort_ was faster than =any= other sorting algorithm.  This came as a *RUDE*
surprise to more than one first-year C.S dept faculty member.  There was
always some smart-*ss in the class who got the bubble-sort implementation
"right", and it ran in far less time than even quicksort.   If you did
_careful_ benchmarking, you could see that when the data-sets got large
enough that the 'expected' (bubble-sort "loses") behavior _was_ there.
but the cross-over/break-even point was at a point that was _larger_ 
than the maximum main memory that you could hang on a machine with only
an 18-hit address-space.  Uuser apps were limited to only 17 bits of
addressing.

It also freaked some people that you could copy a dataset that was 
many times the size of main memory, using only _one_ buffer, and isusing
only *one* 'read" and *one* "write" instruction.  The operating system
was 'management by committee' at the _hardware_ level, and could literally
be doing _20_ different things simultaneously.   Start one member of the
'committee' transferring data from the 'source' into the buffer, and hav
a -second- member transfering _out_ of the butter to the destination, 
and just sit ack and watch them go at it.

The 6600 also gets credit for being the first CPU where speed-of-light
limitqation had to be taken into consideration.  roughly 40% of the data
"in" the CPU didn't have a fixed location,  but was 'in transit' to where
it "would be" needed..  internal wiring of a particular insulation color 
was _not_ 'field repairable'.  you had to remove the wire entirely, and
replace it with a nother pice with the -specific- part number that came 
from the factory.