CDC 6600 Emulation?
George R. Gonzalez
emulator going.
Here's my thoughts, input welcome.
Emulating the CPU is no big deal (as a first guess). It's got relatively
few opcodes,
all straightforward, almost RISC-ey.
The 60-bit word length is not a big problem, just use 64 bits and mask when
needed.
Emulating the floating-point is also not a big problem, the FP format is
quite
straightforward, with IIRC an actual msb normalized bit.
With a CPU emulator, and a little bit of system API emulation for I/O, you
might be able to run precompiled binaries. IIRC when I use to work on the
FORTRAN and Pascal compilers and their run-time libraries,
they did darn few system calls, mainly
simple I/O and one or two memory requests.
If you wanted to actually boot an operating system, then you have a big
kettle of worms.
You then have to emulate the PPU's and the I/O channels. The PPU's are not
particularly hard to do (they're somewhat like the CDC 160). But there are
10 to
20 of them to emulate in parallel. And the console scope has to be
constantly
refreshed by one of them. And the I/O channels are probably not too well
documented. And an old system programmer told me the I/O code was
very disk timing-dependent. And oh-yes, you have to emulate the
dual-scope-display
console, with its vector-graphics and vector-drawn characters.
And of course there's the question of where you get a bootable
deadstart tape image, preferably legally.
Given all the -hard- gotchas above, I'd settle for just having a CPU
emulator,
with a few useful compiler binaries to play with. Say FORTRAN, Pascal,
and Snobol4. Anybody have any of these lying around? Oh cripes,
we need the linker and the libraries too.
Rupert Pigott
news:a48s9n$2bh$1...@laurel.tc.umn.edu...
> I've been trying to estimate what it would take to get a reasonable 6600
> emulator going.
> Here's my thoughts, input welcome.
>
> Emulating the CPU is no big deal (as a first guess). It's got relatively
> few opcodes,
> all straightforward, almost RISC-ey.
>
> The 60-bit word length is not a big problem, just use 64 bits and mask
when
> needed.
> Emulating the floating-point is also not a big problem, the FP format is
> quite
> straightforward, with IIRC an actual msb normalized bit.
[SNIP]
Anyone know where you can find a detailed architectural
reference for the thing... I keep tripping over Seymour
Cray tributes and no actual useful architectural info
on the CDC6600.
Cheers,
Rupert
Al Kossow
<gr...@flash.net> wrote:
> Given all the -hard- gotchas above, I'd settle for just having a CPU
> emulator,
> with a few useful compiler binaries to play with. Say FORTRAN, Pascal,
> and Snobol4. Anybody have any of these lying around? Oh cripes,
> we need the linker and the libraries too.
CDC was in your neck of the woods, George. I'd suggest trying to find
what software might still be around in the Twin Cities. There are at
least two efforts that I know of to create a 6600 series simulator and
both are hung up trying to find software (and some device-level docs)
Tim McCaffrey
>
>With a CPU emulator, and a little bit of system API emulation for I/O, you
>might be able to run precompiled binaries. IIRC when I use to work on the
>FORTRAN and Pascal compilers and their run-time libraries,
> they did darn few system calls, mainly
>simple I/O and one or two memory requests.
>
You would think this, wouldn't you? However, when I worked at Michigan State
University I had the privledge to port a Lisp Interpreter from the University of
Texas at Austin. Now, we both started from the same OS (Scope 3.4), but both
places had made lots of local modifications to the OS (which, as far as I could
see, was pretty common), and over time they had drifted considerably from the
"standard" OS. Apparently, at about the same time, management decided that it was
too much work customizing all the applications that came, and decided to get the
system closer to a current CDC OS. MSU chose NOS/BE, being the descendant of
Scope 3.4, UT@A chose NOS (descendant of KRONOS) for the application level API
(note, that both systems were still pretty customized internally, they just were
trying the standardize the API). The effort to port that LISP interpreter from the
NOS API to NOS/BE was an incredible pain (did I mention the whole thing was
written in assembly?). Even the SPITBOL interpreter, which already ran on NOS/BE,
still needed to be tweaked before it would run correctly (IIRC, it was mostly in
the area of terminal I/O, which was entirely MSU (re)written).
>Given all the -hard- gotchas above, I'd settle for just having a CPU
>emulator,
>with a few useful compiler binaries to play with. Say FORTRAN, Pascal,
>and Snobol4. Anybody have any of these lying around? Oh cripes,
>we need the linker and the libraries too.
First and foremost, get Compass. After that you get everything else working
(almost everything else is written in assembly) (at least Fortran and Snobol4
were, Pascal was written in Pascal).
Compass, Fortran (4,5), and Cobol came from CDC. University of Minnesota also had
a Fortran compiler (Minnesota Fortran, which was sort of a Fortran 4.5 (4=66,
5=77)). Snobol4 was from an Arizona University, and Pascal came from Wirth (the
First Pascal!).
MSU may have some tapes lying about (they were a big CDC shop at one time), but
that is sort of ancient history.
- Tim
Eugene Miya
<gr...@flash.net> wrote:
>> Given all the -hard- gotchas above, I'd settle for just having a CPU
>> emulator,
>> with a few useful compiler binaries to play with. Say FORTRAN, Pascal,
>> and Snobol4. Anybody have any of these lying around? Oh cripes,
>> we need the linker and the libraries too.
In article <aek-110202...@il0502a-dhcp188.apple.com>,
Al Kossow <a...@spies.com> wrote:
>CDC was in your neck of the woods, George. I'd suggest trying to find
>what software might still be around in the Twin Cities. There are at
>least two efforts that I know of to create a 6600 series simulator and
>both are hung up trying to find software (and some device-level docs)
Software?
You want software?
You bought one of Seymour's machines: you make all your own software.
It wasn't a machine for the faint of heart.
The Museum has a 6600, S/N 1 apparently. LLNL is contemplating
borrowing it back for 3 months (not runnable). We may be getting the
ex-CDC guys (would post in comp.sys.cdc) for a Cray retrospective with LLNL.
Yeah, this architecture above all others an emulator would be most
amusing to read.
We'll see.
Eugene Miya
Tim McCaffrey <t...@spamfilter.asns.tr.unisys.com> wrote:
>Pascal came from Wirth (the First Pascal!).
I finally met Niklaus for the first time last fall even though we
co-authored the first Univac validation report (on the U. Wisc compiler
by Charlie Fischer). Actually it was Kathy Jensen who did most of the work.
He can't find his original source code. He's certainly looking, and I
will stop by his office the next time I visit the ETH (possibly
sometime during the next couple of years).
Henry Churchyard
Tim McCaffrey <t...@spamfilter.asns.tr.unisys.com> wrote:
]> With a CPU emulator, and a little bit of system API emulation for
]> I/O, you might be able to run precompiled binaries. IIRC when I
]> use to work on the FORTRAN and Pascal compilers and their run-time
]> libraries, they did darn few system calls, mainly simple I/O and
]> one or two memory requests.
] You would think this, wouldn't you? However, when I worked at
] Michigan State University I had the privledge to port a Lisp
] Interpreter from the University of Texas at Austin. Now, we both
] started from the same OS (Scope 3.4), but both places had made lots
] of local modifications to the OS (which, as far as I could see, was
] pretty common), and over time they had drifted considerably from the
] "standard" OS. Apparently, at about the same time, management
] decided that it was too much work customizing all the applications
] that came, and decided to get the system closer to a current CDC OS.
] MSU chose NOS/BE, being the descendant of Scope 3.4, UT@A chose NOS
] (descendant of KRONOS) for the application level API (note, that
] both systems were still pretty customized internally, they just were
] trying the standardize the API). The effort to port that LISP
] interpreter from the NOS API to NOS/BE was an incredible pain (did I
] mention the whole thing was written in assembly?). Even the SPITBOL
] interpreter, which already ran on NOS/BE, still needed to be tweaked
] before it would run correctly (IIRC, it was mostly in the area of
] terminal I/O, which was entirely MSU (re)written).
In the 1980's, UT had the core of their computer-account management
and accounting systems on dual Cybers running the custom "UT2D"
operating system. They seemed to have difficulty getting those
functions off of the Cybers; in any case, the Cybers were still
running well into the 1990's...
--
Henry Churchyard chu...@crossmyt.com http://www.crossmyt.com/hc/
Joe Pfeiffer
>
> Anyone know where you can find a detailed architectural
> reference for the thing... I keep tripping over Seymour
> Cray tributes and no actual useful architectural info
> on the CDC6600.
J. E. Thornton's book, ``Design of a Computer: the Control Data
6600'' is an extraordinarily detailed description of the machine.
Sadly, it's out of print. His paper, ``Parallel Operation in the
Control Data 6600,'' is a very very good description. It was in the
Proceedings of the Fall Joint Computer Conference, 1964, and should be
easily findable.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair
Joe Pfeiffer
>
> Software?
> You want software?
> You bought one of Seymour's machines: you make all your own software.
> It wasn't a machine for the faint of heart.
There is a legend (at least, my computer architecture professor told
this story, but I've never seen a reference to it) that the only
reason there was a FORTRAN compiler was that a salesman who was
authorized to sign contracts on behalf of the company didn't know what
he was doing and a customer demanded it.
Karl Kleine
I have a listing. about 6500 lines of Pascal code.
Main author is Urs Amman. The listing originates
from the Technical University of Berlin and reflects
the state of about 1976 of the compiler.
Right now it's part of an exhibition of old software
artefacts, next to the ETH yellow reports and similar
stuff of that time...
The title line says: COMPILER FOR PASCAL 6000 - 3.4
(I guess that's the SCOPE 3.4 we were using then)
and below: RELEASE 1 JUNE 1974
UPDATE 1-9 1/7/74-15/4/75
TUB1-2 3/1/76-12/1/76
I'm a bit behind with the web pages for the exhibition,
but there will be a picture of the first page as well
as the code for the IF-statement, sowing the recursive
descent parsing. I guess it will be online in a week or
two (these pictures, not the source text as such)
________________________________________________________
Prof. Karl Kleine http://www.fh-jena.de/~kleine
Fachhochschule Jena kle...@fh-jena.de
Carl-Zeiss-Promenade 2 +49-3641-205-502 [fax -503]
D-07745 Jena, Germany
Tim Shoppa
>
>eug...@cse.ucsc.edu (Eugene Miya) writes:
>>
>> Software?
>> You want software?
>> You bought one of Seymour's machines: you make all your own software.
>> It wasn't a machine for the faint of heart.
>
>There is a legend (at least, my computer architecture professor told
>this story, but I've never seen a reference to it) that the only
>reason there was a FORTRAN compiler was that a salesman who was
>authorized to sign contracts on behalf of the company didn't know what
>he was doing and a customer demanded it.
All the 6600 hacking I ever did (from the "high-performance scientific
computing" side of the fence) was from FORTRAN - I couldn't imagine
the computer without it. Nor could anyone that I worked with, nor
any of the other 6600 users (mostly aerospace companies) that I knew of.
TRW was running a 6600 in Southern California (cannot remember the
facility name; it's the one with the monthly LA hamfest in the parking lot)
at least up into the early 90's, IIRC.
Tim.
CBFalconer
How about the early Pascal validation suite, which pre-dated the
first ANSI/ISO standard release, and was the co-operative work of
many.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Charles Richmond
has some documentation for the CDC-6600...
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Charles Richmond
is available on the internet in a couple of places. If it is *not*
the first, it could be made to work on the CDC-6600 without too
much trouble IMHO.
Charles Richmond
>
> Eugene Miya <eug...@cse.ucsc.edu> wrote:
> > In article <a491ve$o94$1...@trsvr.tr.unisys.com>,
> > Tim McCaffrey <t...@spamfilter.asns.tr.unisys.com> wrote:
> >>Pascal came from Wirth (the First Pascal!).
>
> > I finally met Niklaus for the first time last fall even though we
> > co-authored the first Univac validation report (on the U. Wisc compiler
> > by Charlie Fischer). Actually it was Kathy Jensen who did most of the work.
> > He can't find his original source code. He's certainly looking, and I
> > will stop by his office the next time I visit the ETH (possibly
> > sometime during the next couple of years).
>
> I have a listing. about 6500 lines of Pascal code.
> Main author is Urs Amman. The listing originates
> from the Technical University of Berlin and reflects
> the state of about 1976 of the compiler.
>
at the bottom of the following WEB page:
<http://www.cwi.nl/~steven/pascal/>
Here is the comment from the compiler:
(***********************************************
* *
* Portable Pascal compiler *
* ************************ *
* *
* Pascal P4 *
* *
* Authors: *
* Urs Ammann *
* Kesav Nori *
* Christian Jacobi *
* Address: *
* Institut Fuer Informatik *
* Eidg. Technische Hochschule *
* CH-8096 Zuerich *
* *
* This code is fully documented in the book *
* "Pascal Implementation" *
* by Steven Pemberton and Martin Daniels *
* published by Ellis Horwood, Chichester, UK *
* ISBN: 0-13-653-0311 *
* (also available in Japanese) *
* *
* Steven Pemberton, CWI/AA, *
* Kruislaan 413, 1098 SJ Amsterdam, NL *
* Steven.P...@cwi.nl *
* *
***********************************************)
Al Kossow
> >
> The Charles Babbage Institute at the University of Minnesota surely
> has some documentation for the CDC-6600...
Does anyone here have any experience obtaining copies of any of the
documents that they list in their archives?
CBFalconer
P4 is a subset, not the full CDC compiler. P4 is the ancestor of
many other compilers.
artie
>I've been trying to estimate what it would take to get a reasonable 6600
>emulator going.
>Here's my thoughts, input welcome.
>
>Emulating the CPU is no big deal (as a first guess). It's got relatively
>few opcodes,
>all straightforward, almost RISC-ey.
>
>The 60-bit word length is not a big problem, just use 64 bits and mask when
>needed.
>Emulating the floating-point is also not a big problem, the FP format is
>quite
>straightforward, with IIRC an actual msb normalized bit.
<snip>
You've bitten off an interesting challenge! From having worked on
other emulators, you're right that the I/O is going to be a real
problem.
But when I read your post and saw your remark about FP being easy,
memories of moving a numerical integration package to the 6600 came
back to me -- no, they were nightmares. Remember, this is *long*
before IEEE math -- from what I recall, 6600 floating point had its own
peculiarities (not as bad as the 1108, iirc, but that's another bad
dream).
namaste-
Prof Karl Kleine
This is definitely NOT the CDC Pascal compiler we spoke about.
The P4 compiler translates to an intermediate code which is then
interpreted. Of course it is derived from the CDC compiler, but
its main objective is portability and making the language
available for other computer systems. It needs an existing
Pascal system for bootstrapping, thus a classical push bootstrap.
Also, as far as I remember, it only covers a subset of Pascal.
Michael Thompson
France.
In article <3c681b76$1...@news.ucsc.edu>, eug...@cse.ucsc.edu says...
CBFalconer
>
> In article <3c681b76$1...@news.ucsc.edu>, eug...@cse.ucsc.edu says...
> >
> >In article <a491ve$o94$1...@trsvr.tr.unisys.com>,
> >Tim McCaffrey <t...@spamfilter.asns.tr.unisys.com> wrote:
> >>Pascal came from Wirth (the First Pascal!).
> >
> >I finally met Niklaus for the first time last fall even though we
> >co-authored the first Univac validation report (on the U. Wisc
> >compiler by Charlie Fischer). Actually it was Kathy Jensen who
> >did most of the work. He can't find his original source code.
> >He's certainly looking, and I will stop by his office the next
> >time I visit the ETH (possibly sometime during the next couple
> >of years).
>
> I have a CDC6600 Pascal compiler on 1/2" tape that was written by
> CDC in France.
That sounds 'wirthwhile', especially if it includes the full
source, run-time, etc. We could run the source through GPC and
see if it is bootstrappable. GPC tries to do all things,
unfortunately.
Tim McCaffrey
>
>TRW was running a 6600 in Southern California (cannot remember the
>facility name; it's the one with the monthly LA hamfest in the parking lot)
>at least up into the early 90's, IIRC.
>
>
And that reminds me....
There was a job posting at Patrick AFB in Florida a year or two ago
for a Operator/Programmer for a CDC Cyber 170/750 (which, at one time, I knew
only too well). So the Air Force may actually have one (or more) still
running.
- Tim
Douglas H. Quebbeman
news:a48s9n$2bh$1...@laurel.tc.umn.edu...
>
> With a CPU emulator, and a little bit of system API emulation for I/O, you
> might be able to run precompiled binaries. IIRC when I use to work on the
> FORTRAN and Pascal compilers and their run-time libraries, they did darn
few
> system calls, mainly simple I/O and one or two memory requests.
OK,
The "simulate the CPU and the underlying OS (RA+1) calls but not the PPs"
approach has been done quite successfully. There was once a product called
AlphaCyber (ran on Alphas) from a firm called infoWare that did precisely
this.
CDC sued them for violating the copyrights of the OS and the manuals.
> If you wanted to actually boot an operating system, then you have a big
kettle of worms.
> You then have to emulate the PPU's and the I/O channels. The PPU's are
not
> particularly hard to do (they're somewhat like the CDC 160). But there
are 10 to
> 20 of them to emulate in parallel. And the console scope has to be
constantly
> refreshed by one of them. And the I/O channels are probably not too well
> documented. And an old system programmer told me the I/O code was
> very disk timing-dependent. And oh-yes, you have to emulate the
dual-scope-display
> console, with its vector-graphics and vector-drawn characters.
The PPs did not operate "in parallel" but in sequentially in a round-robin
fashion. Yes, they turned out to be easy to do. The channels OTOH did
turn out to be problematic, but not impossible to implement.
The console hasn't been too terribly hard to do. First, except for the
eye candy like LIFE, WRM, EYE, etc, the OS *never* used the console's
graphics mode. The console itself had a hardware character generator.
The operating system itself took care of the refresh. So a first-pass
emulator merely needs to implement the text mode and provide the user
with a control-key to clear the screen when it becomes unmanageable.
In the next instant, PP9 (under Chippewa, or PP1 under SCOPE/KRONOS)
writes everything to the console again.
The timing is a red-herring. This was a synchronous system, no race
conditions exist. At least none that I've encountered...
> And of course there's the question of where you get a bootable
> deadstart tape image, preferably legally.
If one goes back in time far enough, one might find that CDC was
not as careful as it should have been in ensuring that its OS code
contained copyrights. One might find pre-Berne convention works that
lack copyrights, and which are therefore in the public domain.
> Given all the -hard- gotchas above, I'd settle for just having a CPU
emulator,
> with a few useful compiler binaries to play with. Say FORTRAN, Pascal,
> and Snobol4. Anybody have any of these lying around? Oh cripes,
> we need the linker and the libraries too.
Again, duplicating the operating system may well get you
into more trouble than you expect...
Regards,
-dq
Douglas H. Quebbeman
news:a4bot8$k2c$1...@trsvr.tr.unisys.com...
It appears that, at least as recently as August 2000, a Cyber
170 driving the Early Warning Radar System at Cape Cod Air
Force Station, known as "Pave Paws", was still in operation.
Dunno if Patrick AFB would be providing support for the
Cape Cod AFS site or not...
-dq
Douglas H. Quebbeman
news:3c696b98$1...@news.iglou.com...
Complete site inventory of the Cape Cod station may be
found at:
http://www.fas.org/spp/military/program/track/clear/cru_jim1.htm
Amazing what our government puts online...
Regards,
-dq
Kent Olsen
"Tim McCaffrey" <t...@spamfilter.asns.tr.unisys.com> wrote in message
news:a4bot8$k2c$1...@trsvr.tr.unisys.com...
My first thought is that it just wasn't possible to know a Cyber 170 system
"too well". On the other hand, once you got past the initial hurdle of the
strange instruction set it was pretty easy to follow.
My ex-wife was a manager at PAFB/CCAFS for many years. She would know but I
haven't spoken with her in many years. (I have no idea why I'm writing
this...) If I had known of an operational 170 anywhere in Florida I would
have certainly looked for employment and/or consulting opportunities.
I really loved those old machines.....
Kent
John A. Stovall
I was with CDC for 20 years and there is still a 170 operating on
Cobra Judy (USS Observation Island) running NOS. I know one of the
CE's on it.
Eric Smith
> I have a CDC6600 Pascal compiler on 1/2" tape that was written by CDC in
> France.
If you need it read, contact Al Kossow <a...@spies.com>.
Best regards,
Eric
Eugene Miya
CBFalconer <cbfal...@worldnet.att.net> wrote:
>How about the early Pascal validation suite, which pre-dated the
>first ANSI/ISO standard release, and was the co-operative work of many.
Arthur's suite? Sure.
I was one of the many. From the first prototype test set (14 programs?
I still have the report somewhere) to the 800 program or so version on
tape somewhere.
The amazing thing is that I have kept in some touch with many from the
original Committee.
I still retain copies of the Pascal News.
The Museum has several Teraks, and I have RT-11 and UCSD floppies which I gave
them. It booted fine.
Eugene Miya
eug...@cse.ucsc.edu (Eugene Miya) writes:
>>> Software?
>>> You want software?
>>> You bought one of Seymour's machines: you make all your own software.
>>> It wasn't a machine for the faint of heart.
I was just showing our 6600 to a potential new hire.
In article <1badufs...@cs.nmsu.edu>, Joe says...
>>There is a legend (at least, my computer architecture professor told
>>this story, but I've never seen a reference to it) that the only
>>reason there was a FORTRAN compiler was that a salesman who was
>>authorized to sign contracts on behalf of the company didn't know what
>>he was doing and a customer demanded it.
Possibly.
Talking with Backus (nice guy, he's a Museum Fellow but wants nothing to
do with computers), von Neumann was particularly down on Backus as a
bright fellow "wasting his time." That was the 50s. Imagine getting
dumped on by von Neumann of all people.
In article <a49bh...@drn.newsguy.com>,
Tim Shoppa <sho...@trailing-edge.com> wrote:
>All the 6600 hacking I ever did (from the "high-performance scientific
>computing" side of the fence) was from FORTRAN - I couldn't imagine
>the computer without it. Nor could anyone that I worked with, nor
>any of the other 6600 users (mostly aerospace companies) that I knew of.
I only briefly worked on a 6400.
I was talking to the LLNL guys and apparently most of their nuclear codes
are now written in C (for MPI). That's a shocker to me. I have to guess
that they brute forced it, re-ported what they did (bit the bullet)
and tossed the rest. I'll find out more specifics as the year proceeds.
Makes me wonder what LANL and Sandia are doing.
>TRW was running a 6600 in Southern California (cannot remember the
>facility name; it's the one with the monthly LA hamfest in the parking lot)
>at least up into the early 90's, IIRC.
Redondo Beach? (The site of the Snowman and the Falcon).
Next to that extremely high security facility called Mattel Toys.
I grew up in the neck of the woods.
Eugene Miya
Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
>"Rupert Pigott" <Dark...@btinternet.com> writes:
>> Anyone know where you can find a detailed architectural
>> reference for the thing... I keep tripping over Seymour
>> Cray tributes and no actual useful architectural info
>> on the CDC6600.
>
>J. E. Thornton's book, ``Design of a Computer: the Control Data
>6600'' is an extraordinarily detailed description of the machine.
>Sadly, it's out of print.
I second this:
%A J. E. Thornton
%T Design of a Computer: The CDC 6600
%I Scott, Foresman & Co.
%C Glenview, IL
%D 1970
%K recommended, RISC inspiration,
%K btartar, book, text,
%X The 6600 has influenced a lot of the supercomputers from
Cray and CDC. Also no commercial manufacturer of such
an outstanding machine has ever revealed so much detail.
Amos Omondi
%X Population count: pages 101 and 105, Figure 67 (cascading adds).
>His paper, ``Parallel Operation in the
>Control Data 6600,'' is a very very good description. It was in the
>Proceedings of the Fall Joint Computer Conference, 1964, and should be
>easily findable.
Also a pre Cray ERA book which is undergrad understandable is:
%Q Engineering Research Associates (ERA)
%T High-Speed Computing Devices
%S The Charles Babbage Institute, Reprint Series for the History of Computing
%V IV
%I Tomash Publishers
%C Los Angeles
%D 1950, reprinted 1983
%K book, test, computers,
%X Important historic ideas about reliability, performance,
architecture, and simplicity.
Eugene Miya
Karl Kleine <kle...@fh-jena.de> wrote:
>I have a listing. about 6500 lines of Pascal code.
>Main author is Urs Amman. The listing originates
>from the Technical University of Berlin and reflects
>the state of about 1976 of the compiler.
>
>Right now it's part of an exhibition of old software
>artefacts, next to the ETH yellow reports and similar
>stuff of that time...
>
>The title line says: COMPILER FOR PASCAL 6000 - 3.4
I think that its great that you guys found this. I'll let you guys
deal with the pedigree.
Holy Cow! I own some of those Yellow covered reports.
I need to concentrate on other more pressing things.
Keep it up.
CBFalconer
>
> CBFalconer <cbfal...@worldnet.att.net> wrote:
>
> >How about the early Pascal validation suite, which pre-dated the
> >first ANSI/ISO standard release, and was the co-operative work of many.
>
> Arthur's suite? Sure.
> I was one of the many. From the first prototype test set (14 programs?
> I still have the report somewhere) to the 800 program or so version on
> tape somewhere.
Any way I could get a copy of that tape contents? I had it once,
but it disappeared in a disk crash. No idea what happened to the
tape proper.
>
> The amazing thing is that I have kept in some touch with many from the
> original Committee.
>
> I still retain copies of the Pascal News.
I do too somewhere. Whatever happened to Andy Mickel after he
burned out?
> The Museum has several Teraks, and I have RT-11 and UCSD floppies which I gave
> them. It booted fine.
I have a box of 8" scud floppies here. They have been sitting for
20+ years. I abandoned it completely when they pulled the
licences and sold it off. A lot of original source releases,
which were a mess.
jmfb...@aol.com
"George R. Gonzalez" <gr...@flash.net> wrote:
>I've been trying to estimate what it would take to get a reasonable 6600
>emulator going.
>Here's my thoughts, input welcome.
>Given all the -hard- gotchas above, I'd settle for just having a CPU
>emulator,
>with a few useful compiler binaries to play with. Say FORTRAN, Pascal,
>and Snobol4. Anybody have any of these lying around? Oh cripes,
>we need the linker and the libraries too.
Good! Now you're beginning to think about dependencies.
This is exactly what I'm trying to explain. And you did
it with 10 words in one sentence. :-)
/BAH
Subtract a hundred and four for e-mail.
Dave Bloodgood
text on programming in compass - It gives all the instructions ( and likely
the opcodes ) for the 6400, 6500 and 6600. As I recall, the 6400 and 6500
used the same cpu, and the 6600 had parallel ALUs of some sort - Im not sure
that that would impact the emulation.
When I was at Purdue, they had a 6400 + 6500 ( or maybe 2 6500's ) running -
they worked well.
Interestingly enough, I left Purdue in 1978 to go to work for TRW, in
Redondo Beach ( Lots of us did that also ) - I was thrilled to find another
CDC there to work on. Unfortunately, the TRW TSS system was probably
overtaxed - I recall jockeying for position, to get on a silent 700
terminal, to make runs. I was lucky, my runs were fairly quick, others had
"interactive" programs that ran for hours, once the data were entered -
those people would hunch over the silent 700 all day - Im glad it wasnt me !
My last usage of the TRW TSS was in spring of 1980, when the activities I
was involved with started using a HP 2100 based system - it was local,
dedicated and was fast enough to handle our needs.
I remember seeing a sign a coworkers office wall - "TRW TWS" --- for "Time
Wasting System"
Dave
"John A. Stovall" <sto...@our-town.com> wrote in message
news:ua6j6ug6a6phl80l1...@4ax.com...
Douglas H. Quebbeman
news:3c69bb6d$1...@news.ucsc.edu...
> In article <3C6835E5...@yahoo.com>,
> CBFalconer <cbfal...@worldnet.att.net> wrote:
> >How about the early Pascal validation suite, which pre-dated the
> >first ANSI/ISO standard release, and was the co-operative work of many.
>
> Arthur's suite? Sure.
> I was one of the many. From the first prototype test set (14 programs?
> I still have the report somewhere) to the 800 program or so version on
> tape somewhere.
>
> The amazing thing is that I have kept in some touch with many from the
> original Committee.
>
> I still retain copies of the Pascal News.
I still have a complete set, minues the issues that came
out after I dropped out...
-dq
George R. Gonzalez
> into more trouble than you expect...
>
> Regards,
> -dq
Thanks, Douglas, for all the interesting info.
It's a tad puzzling that CDC was chasing Cyber software $ well into 1994.
Must have had some very optimistic lawyers!
I'm contacting their successor, ACS, to see if they even know they
own NOS. Maybe they'd love to get a tax write-off by "donating"
it to the common good?
Regards,
George
George R. Gonzalez
"Al Kossow" <a...@spies.com> wrote in message
news:aek-110202...@il0502a-dhcp188.apple.com...
> CDC was in your neck of the woods, George. I'd suggest trying to find
> what software might still be around in the Twin Cities. There are at
> least two efforts that I know of to create a 6600 series simulator and
> both are hung up trying to find software (and some device-level docs)
I have feelers out to several of the guys that supported the op sys thru the
70's
and 80's, more news as it develops. One of them threw away a bunch of
NOS tapes last year. Maybe something can be pieced together, lawyers
willing...
Bill McDermith
not as trivial as it would seem to emulate the ones-complement
arithmetic that the CDC machines used...
A straight forward implementation of subtract will cause
1 - 1 to generate zero, BUT negative zero, and this
can cause plenty of problems...
(octal, 18-bit)
000001 - 000001 = 000001 + 777776 = 777777 (-0)
(note that there is no carry out, so there is no end-around carry...)
If this is done as part of the 18-bit increment unit,
you end up with B7 = 1, B1 = 1:
SB7 B7-B1
EQ B7,B0,target -or- ZR B7,target
fails to branch as the eq operation will check +0 (B0) against
-0 and fail...
There are plenty of these little details to keep track of...
BTW: A description of the CDC 6600 is also in "Computer Structures:
Principles and Examples" by Siewiorek, Bell, and Newell, McGraw-Hill,
1982... Starting on page 730 is a paper by Thornton called "Parallel
Operation in the Control Data 6600". The paper also includes an ISP
description of the 6600 (minus the floating point units :-(
This book may be easier to locate then some of the others...
Or, this paper is part of Gordon Bell's web pages:
http://research.microsoft.com/~gbell/Computer_Structures__Readings_and_Examp
les/00000509.htm
abebooks.com has copies of "Assembly Language Programming" by
Ralph Grishman available from various sources...
If anyone has a copy of "Design of a Computer: The Control Data 6600" by
James E. Thornton, I'd love to have it (along with all the other
CDCphiles... :-)
I can't find it anywhere...
Good luck...
Bill McDermith
"George R. Gonzalez" <gr...@flash.net> wrote in message
news:a48s9n$2bh$1...@laurel.tc.umn.edu...
> I've been trying to estimate what it would take to get a reasonable 6600
> emulator going.
> Here's my thoughts, input welcome.
>
> Emulating the CPU is no big deal (as a first guess). It's got relatively
> few opcodes,
> all straightforward, almost RISC-ey.
>
> The 60-bit word length is not a big problem, just use 64 bits and mask
when
> needed.
> Emulating the floating-point is also not a big problem, the FP format is
> quite
> straightforward, with IIRC an actual msb normalized bit.
>
> With a CPU emulator, and a little bit of system API emulation for I/O, you
> might be able to run precompiled binaries. IIRC when I use to work on the
> FORTRAN and Pascal compilers and their run-time libraries,
> they did darn few system calls, mainly
> simple I/O and one or two memory requests.
>
> If you wanted to actually boot an operating system, then you have a big
> kettle of worms.
> You then have to emulate the PPU's and the I/O channels. The PPU's are
not
> particularly hard to do (they're somewhat like the CDC 160). But there
are
> 10 to
> 20 of them to emulate in parallel. And the console scope has to be
> constantly
> refreshed by one of them. And the I/O channels are probably not too well
> documented. And an old system programmer told me the I/O code was
> very disk timing-dependent. And oh-yes, you have to emulate the
> dual-scope-display
> console, with its vector-graphics and vector-drawn characters.
>
> And of course there's the question of where you get a bootable
> deadstart tape image, preferably legally.
>
CBFalconer
>
> One thing you might want to keep in mind is that it's
> not as trivial as it would seem to emulate the ones-complement
> arithmetic that the CDC machines used...
>
> A straight forward implementation of subtract will cause
> 1 - 1 to generate zero, BUT negative zero, and this
> can cause plenty of problems...
>
> (octal, 18-bit)
> 000001 - 000001 = 000001 + 777776 = 777777 (-0)
>
> (note that there is no carry out, so there is no end-around carry...)
>
> If this is done as part of the 18-bit increment unit,
> you end up with B7 = 1, B1 = 1:
> SB7 B7-B1
> EQ B7,B0,target -or- ZR B7,target
> fails to branch as the eq operation will check +0 (B0) against
> -0 and fail...
> There are plenty of these little details to keep track of...
I have no idea if it applies to the 6600, but if the fundamental
arithmetic unit is a subtractor then -ve zero will never arise.
That makes the add operation "complement and subtract". Or is it
+ve zero will never arise - can't remember and I see no purpose in
figuring it out. I discovered this too late to make hardware
economies in one machine.
This leaves a nice handsome pattern to detect uninitialized
variables.
J Ahlstrom
> If anyone has a copy of "Design of a Computer: The Control Data 6600" by
> James E. Thornton, I'd love to have it (along with all the other
> CDCphiles... :-)
> I can't find it anywhere...
>
> Good luck...
> Bill McDermith
>
> "
> >
Any chance that we could get the publisher (Wiley?) to allow
someone to scan it onto the web?
How would we even begin to find out?
JKA
--
The first ten amendments to the constitution
are what make this a country worth fighting
for. Ignorance and apathy are what make it
so difficult to defend.
Jack Barone
You do not preserve freedom by destroying freedom.
Eric Green
Eugene Miya
Douglas H. Quebbeman <do...@ixnayamspayiglou.com> wrote:
>"Eugene Miya" <eug...@cse.ucsc.edu> wrote in message
>news:3c69bb6d$1...@news.ucsc.edu...
>
>I still have a complete set, minues the issues that came
>out after I dropped out...
I lucked out.
I got back issues from Andy copies of #1.
I used the Usenix trick of a blank tape economy. I guess Andy needed
1/2 tapes. (long story about my experiences trading tapes.)
Hat off to Lou Katz and Dennis for this.
Eugene Miya
CBFalconer <cbfal...@worldnet.att.net> wrote:
>Eugene Miya wrote:
>>
>> CBFalconer <cbfal...@worldnet.att.net> wrote:
>>
>> >How about the early Pascal validation suite, which pre-dated the
>> >first ANSI/ISO standard release, and was the co-operative work of many.
>>
>> Arthur's suite? Sure.
>> I was one of the many. From the first prototype test set (14 programs?
>> I still have the report somewhere) to the 800 program or so version on
>> tape somewhere.
>
>Any way I could get a copy of that tape contents? I had it once,
>but it disappeared in a disk crash. No idea what happened to the
>tape proper.
I'd give it to you if I could locate the tape.
Check back with me later. Then I need to find a 9-trk.
I did a preliminary look, but did not find them.
>> The amazing thing is that I have kept in some touch with many from the
>> original Committee.
>>
>> I still retain copies of the Pascal News.
>
>I do too somewhere. Whatever happened to Andy Mickel after he
>burned out?
I've not tried to track him down. I liked him.
Cool guy;
end.
>> The Museum has several Teraks, and I have RT-11 and UCSD floppies which I gave
>> them. It booted fine.
>
>I have a box of 8" scud floppies here. They have been sitting for
>20+ years. I abandoned it completely when they pulled the
>licences and sold it off. A lot of original source releases,
>which were a mess.
Ken Bowles is another person in history.
Dennis Ritchie
>
> Bill McDermith wrote:
>
> > If anyone has a copy of "Design of a Computer: The Control Data 6600" by
> > James E. Thornton, I'd love to have it (along with all the other
> > CDCphiles... :-)
> > I can't find it anywhere...
> Any chance that we could get the publisher (Wiley?) to allow
> someone to scan it onto the web?
>
> How would we even begin to find out?
The original publisher (at least my 1970 edition) was
Scott, Foresman and company, now a part of the Pearson
publishing empire. It's pre-ISBN; Library of Congress
catalog number is 74-96462.
As a book, it's really not very good: it jumps too much
between very detailed things and scants the higher-level
design. It's an engineer's memory dump, and I was
irritated by it, as an account, from the moment I bought it
(about the time of publication).
Nevertheless, it is still a fascinating document, ill-organized
as it is. The problem in obtaining permission in advance
is finding someone who is willing to spend a moment thinking
about the question. (Something to be said for a fait accompli).
Dennis
Felger Carbon
by
> > > James E. Thornton, I'd love to have it (along with all the other
> > > CDCphiles... :-)
> > > I can't find it anywhere...
A simple Google search on the title above gives 99 hits, 66 non-duplicative
(according to Google). Between the various hits, there may be a significant
portion of the book on the net.
Kent Olsen
Negative 0 was not a problem on the 6000s as the value could not be
generated by any of the math operations. Mask, Boolean, and Shift
could generate -0. Even the SXx instructions actually computed the
"set" value so -0 was not an issue there.
The hardware was famous for some of the shortcuts that were taken to
reduce the amount of electronics. Subtract was native, Addition was
Complement and Subtract. IIRC, Floating Divide in the early machines
was actually Generate Reciprocal and Floating Multiply.
The CXx instruction was always the most curious to me. First, someone
decided to actually implement the instruction. Then, on the early
machines it was the most expensive instruction in terms of cycles
required to complete -- the hardware actually looped on each bit and
"counted" the number of "1"s. Finally, the instruction was improved
so that it was no more costly than any boolean instruction. And
became a mainstay of COMPASS programming techniques. Other
architectures would have done well to copy it!
Kent
Eugene Miya
>> > James E. Thornton, I'd love to have it (along with all the other
>> > CDCphiles... :-)
J Ahlstrom wrote:
>> How would we even begin to find out?
Start with rare book dealers.
That's how I found a copy of Bongard's Pattern Recognition book (cited in GEB).
I used Usenet to find a copy of Wulf's DoaOC.
In article <3C6B7468...@bell-labs.com>,
Dennis Ritchie <d...@bell-labs.com> wrote:
>As a book, it's really not very good: it jumps too much
>between very detailed things and scants the higher-level
>design. It's an engineer's memory dump, and I was
>irritated by it, as an account, from the moment I bought it
>(about the time of publication).
>
>Nevertheless, it is still a fascinating document, ill-organized
>as it is. The problem in obtaining permission in advance
>is finding someone who is willing to spend a moment thinking
>about the question. (Something to be said for a fait accompli).
I'm going to add that comment to my biblio Dennis. ;^)
Douglas H. Quebbeman
> It's a tad puzzling that CDC was chasing Cyber software $ well into 1994.
> Must have had some very optimistic lawyers!
>
> I'm contacting their successor, ACS, to see if they even know they
> own NOS. Maybe they'd love to get a tax write-off by "donating"
> it to the common good?
ACS???
Control Data Systems became Syntegra, which is a subsidiary of
British Telecomm...
http://www.cdc.com/support/sis/products/cdsprodsindex.html
-dq
--
-Douglas Hurst Quebbeman (do...@ixsnayamspayiglou.com) [Call me "Doug"]
Surgically excise the pig-latin from my e-mail address in order to reply
"The large print giveth, and the small print taketh away." -Tom Waits
Douglas H. Quebbeman
news:Njxa8.4897$qt6.4...@newsread2.prod.itd.earthlink.net...
>
> BTW: A description of the CDC 6600 is also in "Computer Structures:
> Principles and Examples" by Siewiorek, Bell, and Newell, McGraw-Hill,
> 1982... Starting on page 730 is a paper by Thornton called "Parallel
> Operation in the Control Data 6600". The paper also includes an ISP
> description of the 6600 (minus the floating point units :-(
> This book may be easier to locate then some of the others...
>
> Or, this paper is part of Gordon Bell's web pages:
>
http://research.microsoft.com/~gbell/Computer_Structures__Readings_and_Examp
les/00000509.htm
I have the ISP for the PPs typed-in and verified against
a good photocopy; I also have TIFs of the ISP for the CPU,
but have not rendered them into text. I'll make them available
to any interested parties...
Regards,
Jason Lee Eckhardt
>
>
>Start with rare book dealers.
Yes. A good place to start for rare books is http://used.addall.com.
It currently does not come up with a hit for Thornton.
>I used Usenet to find a copy of Wulf's DoaOC.
>
Fortunately, this is available on-demand from UMI.
J Ahlstrom
Jason Lee Eckhardt wrote:
Can you supply more details on how to get this
book on demand from UMI?
George R. Gonzalez
> CDC was in your neck of the woods, George. I'd suggest trying to find
> what software might still be around in the Twin Cities. There are at
> least two efforts that I know of to create a 6600 series simulator and
> both are hung up trying to find software (and some device-level docs)
Bingo!
By the purest coincidence, I just found out one of my old college buddies
is the Last Programmer On Earth supporting NOS at CDC's descendant
organization. He's indicated he's going to add some info to this thread
Real Soon Now.
George William Herbert
>Jason Lee Eckhardt wrote:
>> Eugene Miya <eug...@cse.ucsc.edu> wrote:
>> >I used Usenet to find a copy of Wulf's DoaOC.
>>
>> Fortunately, this is available on-demand from UMI.
>
>Can you supply more details on how to get this
>book on demand from UMI?
Most specifically:
http://wwwlib.umi.com/bod/fullcite?id=123873
-george
Bill McDermith
"Kent Olsen" <ke...@nettally.com> wrote in message
news:a46c04a2.02021...@posting.google.com...
> <<deletia>>
>
> Negative 0 was not a problem on the 6000s as the value could not be
> generated by any of the math operations. Mask, Boolean, and Shift
> could generate -0. Even the SXx instructions actually computed the
> "set" value so -0 was not an issue there.
I was just saying that the "quick" approach -- just doing an adder
and doing subtract by complementing the second operand and
adding, does generate -0... You have to be a little subtle here to get
it right...
>
> The hardware was famous for some of the shortcuts that were taken to
> reduce the amount of electronics. Subtract was native, Addition was
> Complement and Subtract. IIRC, Floating Divide in the early machines
> was actually Generate Reciprocal and Floating Multiply.
My understanding was that all the 6000 series machines used a variation
of newton's method to generate the reciprocal and then multiply... Of
course,
I suppose you could call the 6000 series the "early machines" :-)
>
> The CXx instruction was always the most curious to me. First, someone
> decided to actually implement the instruction. Then, on the early
> machines it was the most expensive instruction in terms of cycles
> required to complete -- the hardware actually looped on each bit and
> "counted" the number of "1"s. Finally, the instruction was improved
> so that it was no more costly than any boolean instruction. And
> became a mainstay of COMPASS programming techniques. Other
> architectures would have done well to copy it!
Well, it became a mainstay COMPASS technique if you were on a 6600...
In the 6600 processor (and the 6600 processor in the 6700) this instruction
was handled in the divide unit and completed in 8 minor cycles; in the other
"unified" cpus it took 68 to 72 minor cycles... So in the "unified"
machines,
you avoided the instruction unless you needed that peculiar result...
>
> Kent
>
Bill
Nick Spalding
> In article <3c6c06c6$1...@news.ucsc.edu>, Eugene Miya <eug...@cse.ucsc.edu> wrote:
> >
> >
> >Start with rare book dealers.
>
> Yes. A good place to start for rare books is http://used.addall.com.
> It currently does not come up with a hit for Thornton.
Another is http://www.abebooks.com but whether it is any good for
technical stuff I know not.
--
Nick Spalding
Eugene Miya
Jason Lee Eckhardt wrote:
>> Yes. A good place to start for rare books is http://used.addall.com.
>> It currently does not come up with a hit for Thornton.
BTW, I realize that I increase the competition for rare books against me
by suggesting what I did.
In article <3c6c06c6$1...@news.ucsc.edu>, Eugene Miya <eug...@cse.ucsc.edu> wrote:
>> >I used Usenet to find a copy of Wulf's DoaOC.
>>
>> Fortunately, this is available on-demand from UMI.
Ah, but not the way I got it! Bill used to read net.arch.
But those days are not more.
In article <3C6C10B6...@cisco.com>,
J Ahlstrom <jahl...@cisco.com> wrote:
>Can you supply more details on how to get this
>book on demand from UMI?
Contact UMI.
You need to understand who UMI is. University Microfilms Inc, is a spin
off of the University of Michigan who keeps copies of all PhD
thesis/dissertations and many "rare" texts. That is their business.
If for instance you want Kay's FLEX thesis or Sutherland's SKETCPAD
thesis, they have it (that period before text formatters except typwriters).
It used to be possible to walk into Computer Literacy Bookshop and just
buy many of them. I just ran into one of the CMU Cm* PhDs and I had
happened to read his nicely formatted (because of Brian Reid's Scribe)
nice bound UMI copy. He had no idea what UMI did that.
Alas no more. CLB is gone. Just an online presence in FatBrain now.
Joe Pfeiffer
> "Kent Olsen" <ke...@nettally.com> wrote in message
> news:a46c04a2.02021...@posting.google.com...
> > <<deletia>>
> >
> > Negative 0 was not a problem on the 6000s as the value could not be
> > generated by any of the math operations. Mask, Boolean, and Shift
> > could generate -0. Even the SXx instructions actually computed the
> > "set" value so -0 was not an issue there.
>
> I was just saying that the "quick" approach -- just doing an adder
> and doing subtract by complementing the second operand and
> adding, does generate -0... You have to be a little subtle here to get
> it right...
Not any more subtle, actually -- CDC built a subtracter, and added by
complementing the second operand (as the previous poster said).
> >
> > The hardware was famous for some of the shortcuts that were taken to
> > reduce the amount of electronics. Subtract was native, Addition was
> > Complement and Subtract. IIRC, Floating Divide in the early machines
> > was actually Generate Reciprocal and Floating Multiply.
>
> My understanding was that all the 6000 series machines used a variation
> of newton's method to generate the reciprocal and then multiply... Of
> course,
> I suppose you could call the 6000 series the "early machines" :-)
No, the CDC did divide. It was the Cray-1 that used
reciprocal-and-multiply.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair
Sam Yorko
>
>
> The CXx instruction was always the most curious to me. First, someone
> decided to actually implement the instruction. Then, on the early
> machines it was the most expensive instruction in terms of cycles
> required to complete -- the hardware actually looped on each bit and
> "counted" the number of "1"s. Finally, the instruction was improved
> so that it was no more costly than any boolean instruction. And
> became a mainstay of COMPASS programming techniques. Other
> architectures would have done well to copy it!
>
> Kent
Sounds like the NSA was a major customer....
Bit count is a very useful instruction in cryptography.
Sam
Dennis Ritchie
...
> "Kent Olsen" <ke...@nettally.com> wrote ...
> > The hardware was famous for some of the shortcuts that were taken to
> > reduce the amount of electronics. Subtract was native, Addition was
> > Complement and Subtract. IIRC, Floating Divide in the early machines
> > was actually Generate Reciprocal and Floating Multiply.
>
> My understanding was that all the 6000 series machines used a variation
> of newton's method to generate the reciprocal and then multiply... Of
> course,
> I suppose you could call the 6000 series the "early machines" :-)
At least according to Thornton's book, on the 6600 there was a
real divide (requiring 2900 ns). On the Cray 1 and subsequent
machines, the reciprocal technique was used, however. The
same unit did Population count (800 ns). It was also, if
we are to believe Thornton, parallelized in an addition tree.
As an aside, Thornton has an italicized note pointing out
a "minor embarrassment [that] was corrected": the opcodes
for Floating Divide, Round Floating Divide, Count 1s were
44, 45, 47 (octal). Pass, or no-op, was 46. He says,
"as the reader has perhaps already suspected, the Pass
instruction ended up triggering a complete divide sequence."
Olsen is further quoted,
> >
> > The CXx instruction was always the most curious to me. First, someone
> > decided to actually implement the instruction. Then, on the early
> > machines it was the most expensive instruction in terms of cycles
> > required to complete -- the hardware actually looped on each bit and
> > "counted" the number of "1"s. Finally, the instruction was improved
> > so that it was no more costly than any boolean instruction. And
> > became a mainstay of COMPASS programming techniques. Other
> > architectures would have done well to copy it!
>
> Well, it became a mainstay COMPASS technique if you were on a 6600...
> In the 6600 processor (and the 6600 processor in the 6700) this instruction
> was handled in the divide unit and completed in 8 minor cycles; in the other
> "unified" cpus it took 68 to 72 minor cycles... So in the "unified"
> machines,
> you avoided the instruction unless you needed that peculiar result...
It's quite possibly the case that various versions of the 6600 then 7600
machines treated these things differently and that Thornton, McDermith,
and Olsen are all correct for a particular model. Cray was willing
to change algorithms in midstream. (Earliest C-1 had no parity: it
was added, and later SECDEC; Early C-1 had non-commutative multiplication;
this got fixed.
Dennis
Rob Thorpe
> Bill McDermith wrote:
>
> > If anyone has a copy of "Design of a Computer: The Control Data 6600" by
> > James E. Thornton, I'd love to have it (along with all the other
> > CDCphiles... :-)
> > I can't find it anywhere...
> >
> > Good luck...
> > Bill McDermith
> >
> > "
> > >
>
> Any chance that we could get the publisher (Wiley?) to allow
> someone to scan it onto the web?
>
> How would we even begin to find out?
>
> JKA
If you are just looking for information on the CDC 6600, there is a
lot on Gordon C Bells personal site:
http://research.microsoft.com/~gbell
http://research.microsoft.com/~gbell/Computer_Structures_Reading_and_Examples/
http://research.microsoft.com/~gbell/craytalk/
Bob Willard
>
> If you are just looking for information on the CDC 6600, there is a
> lot on Gordon C Bells personal site:
Uh, his name is C. Gordon Bell.
--
Cheers, Bob
Kent Olsen
Hi Sam,
There are a lot of algorithms that make good use of the bitcount
instruction. Back in my 6000 days I wrote a lot of code that required
bit counts, number of consecutive 1's, etc. Having instructions that
actually did these things (or could compute the values) without
looping was a boon and a real tribute to the original designers.
I was amazed that 40+ years ago, a group of hardware engineers would
actually have the foresight to build the instruction into the machine.
I suspect that the instruction was an afterthought -- they had an
extra opcode and decided to find a use for it. (I would think that if
they had actually thought the instruction worthwhile that it would
have been better designed from the beginning.)
jchausler
Sam Yorko wrote:
> Sounds like the NSA was a major customer....
> Bit count is a very useful instruction in cryptography.
Its also useful in process control. I worked with a
GE-PAC 4010 in 74 which had IIRC several bit
count instructions (I've unfortunately lost all reference
to the machine, although the switch and light front
panel from one of them, de-installed in 93, is hanging
on the wall in a picture frame overlooking me as I
write this :-) My memory says things like CTO "count
total ones" and maybe CTZ "count total zeros" and
maybe even a third one which would actually reset
one of the bits after finding it. IIRC these were used
both to scan input registers for changes and to keep
flag words. The 4010 (one of the 4000 series) was
a purpose build process control computer. Its word
length was 24 bits. The OS was RTMOS (we referred
to it as "rat mouse"). If anyone knows where I can get
a processor manual for this I would like to hear about it.
Chris
AN GETTO$;DUMP;RUN,ALGOL,TAPE
$$
Eric Smith
> Bit count is a very useful instruction in cryptography.
Where is it used in cryptography?
Sam Yorko
Actually, I think I was confused. I think a useful instruction for
crypto is finding the first one in a register....
Sam
Jitze Couperus
<eric-no-s...@brouhaha.com> wrote:
Cryptanalysis specifically.
Think of how you would simulate production and (especially) use of
"Zygalski sheets" in a computer.
In the 6600 class machines, the pop count was physically implemented
as part of another functional unit.
In the 7600 it had its own functional unit. At great expense.
No - it was not an afterthought. Certain earlier British machines
where Turing had a hand in the design (Pilot ACE) had similar
thinking in them - although manifested differently.
By the time the Cyber 180 series came out, it was not as important
as the type of encryption that is prone to attack based on
Zygalski-type approaches was known to be vulnerable
to most every government - especially after the Pueblo
with its equipment became available for analysis by
the other guys.
Jitze Couperus
Couperus) wrote:
I wrote:
>
>... Certain earlier British machines
>where Turing had a hand in the design (Pilot ACE) had similar
>thinking in them - although manifested differently.
>
Sorry - correction - I think it was DEUCE.
Paul Repacholi
> I just ran into one of the CMU Cm* PhDs and I had happened to read
> his nicely formatted (because of Brian Reid's Scribe) nice bound UMI
> copy. He had no idea what UMI did that.
Don't suppose he would have a spare copy of Hydra/StarOS(?) or know
where there may still be a copy?
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Kent Olsen
in a word. A series of shifts and logical ORs were used in some of
the system libraries.
Another (though less popular) technique was to use the floating point
pack, normalize, and unpack instructions to do the job. In many cases
this was actually faster that the traditional method and with only a
couple of instructions extended to "number of consecutive bits", etc.
Kent
Sam Yorko <JOATno...@computer.org> wrote in message news:<3C6DAA37...@computer.org>...
Edward Rice
"Douglas H. Quebbeman" <do...@ixnayamspayiglou.com> wrote:
> The "simulate the CPU and the underlying OS (RA+1) calls but not the
PPs"
> approach has been done quite successfully. There was once a product
called
> AlphaCyber (ran on Alphas) from a firm called infoWare that did
precisely
> this.
>
> CDC sued them for violating the copyrights of the OS and the manuals.
Immortality? We don't need no steenkin' immortality!
> The PPs did not operate "in parallel" but in sequentially in a
round-robin
f > fashion. Yes, they turned out to be easy to do. The channels OTOH did
> turn out to be problematic, but not impossible to implement.
IIRC, they were /clocked/ round-robin, but the behavior was as though they
were parallel processing. Since they shared core, this controlled the
demand they could place on memory, while allowing full access. So, if you
finished a load instruction, one or another PP could change that memory
location before you got around to storing back to the same location.
Technically not parallel -- but real close in effect.
> If one goes back in time far enough, one might find that CDC was
> not as careful as it should have been in ensuring that its OS code
> contained copyrights. One might find pre-Berne convention works that
> lack copyrights, and which are therefore in the public domain.
Or, possibly, obtain educational distribution rights, or a copy for
development purposes with further distribution withheld until they see what
you come up with.
ehr
George R. Gonzalez
"Edward Rice" <ehr...@his.com> wrote in message
news:B89C3DEE9...@0.0.0.0...
> IIRC, they were /clocked/ round-robin, but the behavior was as though they
> were parallel processing. Since they shared core, this controlled the
> demand they could place on memory, while allowing full access. So, if you
> finished a load instruction, one or another PP could change that memory
> location before you got around to storing back to the same location.
> Technically not parallel -- but real close in effect.
Thanks, Edward, for getting us back to my main question, how did they
do semaphores, or in plainer lingo, how did they interlock access to
common system tables?
(And to make things worse, the later 6600's could have (ECS) Extended Core
Storage,
which was a big pile of somewhat slower core. Two mainframes could share
ECS.
So you could have 20+ PPU's, 2-4 CPU's all accessing shared memory.
But again, no sign of any (obvious) interlocks!
Douglas H. Quebbeman
> "Douglas H. Quebbeman" <do...@ixnayamspayiglou.com> wrote:
>
> > The "simulate the CPU and the underlying OS (RA+1) calls but not the
PPs"
> > approach has been done quite successfully. There was once a product
called
> > AlphaCyber (ran on Alphas) from a firm called infoWare that did
precisely
> > this.
> >
> > CDC sued them for violating the copyrights of the OS and the manuals.
>
> Immortality? We don't need no steenkin' immortality!
I guess lawyers figure they'll get it some other way...
> > The PPs did not operate "in parallel" but in sequentially in a
round-robin
> > fashion. Yes, they turned out to be easy to do. The channels OTOH did
> > turn out to be problematic, but not impossible to implement.
>
> IIRC, they were /clocked/ round-robin, but the behavior was as though they
> were parallel processing. Since they shared core, this controlled the
> demand they could place on memory, while allowing full access. So, if you
> finished a load instruction, one or another PP could change that memory
> location before you got around to storing back to the same location.
> Technically not parallel -- but real close in effect.
True, when you're considering their operation relative to the CP, but
in my current cycle of activity, I'm focused on their operation relative
to each other. I'll be relying on platform native task scheduling to
control the balance between the CP emulator, running as one process,
and the PP barrel emulator, running as a second process, communicating
through a shared memory segment (oops, segment might be a bad word...).
> > If one goes back in time far enough, one might find that CDC was
> > not as careful as it should have been in ensuring that its OS code
> > contained copyrights. One might find pre-Berne convention works that
> > lack copyrights, and which are therefore in the public domain.
>
> Or, possibly, obtain educational distribution rights, or a copy for
> development purposes with further distribution withheld until they see
what
> you come up with.
We're working the system...
;)
-dq
Kent Olsen
they
> do semaphores, or in plainer lingo, how did they interlock access to
> common system tables?
>
Hi George,
There's a pretty good explanation of how a system managed to do
interlocking without semaphores over in this thread:
ECS was interlocked with something called a "flag register".
Kent
Tim McCaffrey
>
>(And to make things worse, the later 6600's could have (ECS) Extended Core
>Storage,
>which was a big pile of somewhat slower core. Two mainframes could share
>ECS.
>So you could have 20+ PPU's, 2-4 CPU's all accessing shared memory.
> But again, no sign of any (obvious) interlocks!
>
time (I think MSU had a 6400, a 6500 and 170/750 hooked up to 512k words of
ECS). However, the PPs of the 6600 could not access ECS, although the 7600's
could, I think. Also, I believe ECS was limited to 2 or 4 Meg words
(actually, I think it was 2, you could get 4 if you used some unused bits for
address bytes). Access was in 10 word chunks, again, IIRC, latency was 1
microsecond, but you got all 600 bits at once (pretty good bandwidth, that).
- Tim