crichmon@digi.lonestar.org (Charles Richmond) (01/30/91)
I have read several posts about the old General Electric 635 mainframe.
Can anyone give more information about this computer? Specifically:
1) What was the word size?
2) What character code did it use?
3) How many registers did it have?
4) How fast could it execute instructions?
5) Did it support any form of floating point?
6) What languages were available for it?
7) Does anyone still have one of these beasts?
Maybe someone can post information from the technical manuals for this
machine. Is there somewhere that I can get ( or get a look at ) the
hardware reference manual (principles of operation, for IBM types)?
I understand that Honeywell took over maintenance on this machine after
GE quit the mainframe computer business. Any Honeywell people out there
know if I can get manuals from Honeywell.
Thanks for the info . . .
-----------------------------------------------------------------------
Charles Richmond crichmon@digi.lonestar.orgmark@hubcap.clemson.edu (Mark Smotherman) (01/30/91)
From crichmon@digi.lonestar.org (Charles Richmond): > I have read several posts about the old General Electric 635 mainframe. > Can anyone give more information about this computer? Specifically: From GE-625/635 Programming Reference Manual, July 1964 (Rev. April 1968, Rev. July 1969), No. CPB-1004F. > 1) What was the word size? 36 bits > 2) What character code did it use? "Alphanumeric data are represented by six-bit or nine-bit characters." "The character set used is the Computer Equipment Department Standard Character Set, which is readily convertible to and from the ASCII character set." > 3) How many registers did it have? Registers accessible to the program: Accumulator Register AQ 72 bits Eight Index Registers (X0..X7) Xn 18 bits each Exponent Register E 8 bits Base Address Register BAR 18 bits Indicator Register IR 18 bits Timer Register TR 24 bits Instruction Counter IC 18 bits > 4) How fast could it execute instructions? Appendix A gives basic timings that vary; e.g.: 1.9 microseconds for Load A and Add to A 2.1 usec for Store A 7.6 usec for Multiply Integer 15.1 usec for Divide Integer 2.8 usec for Floating Add 6.5 usec for Floating Multiply 31 usec for Floating Divide 1.7 usec for conditional transfers Additionally a section on "Calculation of Instruction Execution Times" gives eight categories of timing adjustments including data dependencies between instructions spanning different instruction pairs, transfers of control at and to odd storage locations, and certain address modifications. > 5) Did it support any form of floating point? Single precision and double. "The upper 8 bits represent the integral exponent E in the two's complement form, and the lower 28 or 64 bits represent the fractional mantissa M in 2's complement form." > 6) What languages were available for it? The reference manual lists programming manuals for Fortran-IV and COBOL-61 (plus it contains information on the assembly language, GMAP). > 7) Does anyone still have one of these beasts? ??? -- Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634 INTERNET: mark@hubcap.clemson.edu UUCP: gatech!hubcap!mark
johnl@iecc.cambridge.ma.us (John R. Levine) (01/30/91)
In article <12828@hubcap.clemson.edu> mark@hubcap.clemson.edu (Mark Smotherman) writes: >> 6) What languages were available for it? >The reference manual lists programming manuals for Fortran-IV and COBOL-61 >(plus it contains information on the assembly language, GMAP). There were two main operating systems, GECOS or GCOS, and DTSS. It is my impression that the first C compiler ran on a 635 under GCOS. Its predecessor B certainly did. DTSS was written at Dartmouth, where they implemented zillions of languages -- everyone knows about Basic (which was a real compiler, and generated quite respectable code so quickly that nobody bothered to save object code) but they also had Fortran, Snobol, PL/I, Trac, Dynamo, etc. -- John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl " #(ps,#(rs))' " - L. P. Deutsch and C. N. Mooers
macrakis@gr.osf.org (Stavros Macrakis) (01/30/91)
In article <1665@digi.lonestar.org> crichmon@digi.lonestar.org (Charles Richmond) writes:
I have read several posts about the old General Electric 635 mainframe.
Can anyone give more information about this computer? Specifically:
1) What was the word size?
36 bits
2) What character code did it use?
It supported 6 and 9 bit bytes. On DTSS (Dartmouth time-sharing
system), it used ASCII, but it's possible that GECOS (General Electric
Common Operating System) used EBCDIC.
3) How many registers did it have? Well, it didn't have general
registers. It had a 36-bit accumulator, a 36-bit extension (Q), and 8
18-bit index registers, and a special (9? bits) exponent register (E)
for floating-point.
4) How fast could it execute instructions?
Couldn't tell you. On the order of 500 kips, I think.
5) Did it support any form of floating point?
Yes. The EAQ registers together made up the floating point
accumulator, giving you 72 bits of mantissa in the accumulator. I
forget how it handled floating-point sign. Note that you got a few
more bits of accuracy in the EAQ than you could get in the
double-precision storage format. Handy in assembler, but not clear
how you tell a higher-level language how to take advantage of it.
6) What languages were available for it? Well, on DTSS, there
was Basic (of course), Lisp, Trac, assembler, Fortran, and something
like sed. GECOS must have had RPG and Cobol.
7) Does anyone still have one of these beasts?
Don't know, but see below re. DPS-8.
...
I understand that Honeywell took over maintenance on this machine after
GE quit the mainframe computer business.
Actually, the 635 was the ancestor of a whole series of machines: the
645 was a variant with special instructions for segmentation and
protection, built especially for the Multics project.
When Honeywell bought out GE's computer business (in 197x), the GE 600
line was renamed the Honeywell 6000 line, and later the Honeywell
DPS-8 series. Honeywell's computer business was bought out by Bull
(most of which was for many years a subsidiary of Honeywell). The
machines are still sold by Bull. NEC sells DPS-8's, but also a
high-end machine which is based on but incompatible with the DPS-8....
The DPS-8 runs GCOS-8; Multics was discontinued a couple of years ago
(although there are perhaps a couple of machines still running it?);
DTSS has also presumably long been abandoned by Dartmouth, but I don't
know its ulterior history.
A few more technical details on its instruction set architecture:
- 18-bit word addressing
- One-word instructions
- Lots of very fancy addressing modes (e.g. decrement count (setting a
flag if zero), increment address, and indirect through address),
which would be very hard for a compiler to generate except in
stereotyped situations.
- A hairy series of `repeat' instructions, which would take one or two
following instructions and repeatedly execute them until some
condition was met. This was meant for list and string processing,
but they were very hard to use. Also very hard for a compiler to
use except in stereotyped situations.
-sdavidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (01/30/91)
In article <1991Jan30.014342.12733@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: | zillions of languages -- everyone knows about Basic (which was a real | compiler, and generated quite respectable code so quickly that nobody bothered | to save object code) but they also had Fortran, Snobol, PL/I, Trac, Dynamo, | etc. B, C, and BCPL were available, as was ILANG (implementation language), later renames ALFA (advanced language for automation). There were two versions of Algol-60, a TP program I can't remember, etc. In addition to GECOS (GCOS after 1971), and DTSS, there were several hardware variants running other systems. The 605 (came after the 635) had four BARs, pure shared code, and run the CRD operating system (never had a nifty name) which supported GECOS, DTSS, and GCOS timesharing under it. There was also the 645 with virtual memory, which was the first MULTICS machine. The latest Honeywell/NEC processors will still run old GECOS software, and at least one part of GE was still pushing deck through the card reader (yes really) compiled in 1962. There is also an extended instruction set (EIS, run in the EIS-box) which adds string and block instructions for COBOL, PL/I, and clever GMAP programmers. This must be the ultimate CISC, since the basic 635 has 512 instructions, an interupt inhibit bit, and 64 address indirection modes. These allow immediate addressing, several kinds of indirect addressing which can be many levels deep, and implementation of multiple stacks using stack control words (tally words) in sizes of six bits, nine bits, or any number of words up to 511. It also has execute and execute double instructions, and supports position independent code with its IC (instruction counter relative) addressing. Code can actually be moved in memory on the fly, and at least ILANG took advantage of this for overlay management. Sorry if I told you more than you wanted to know, I spent nearly a decade programming these machines, wrote 100k lines of assembler and probably as much B/C/ILANG/Algol to go with it, and I get carried away. This has to be one of the most fun machines to program in assembler, or to write a code generator for, because it has such a vast number of instructions and modes that you can always make something a little bit tighter. Modern instruction sets are easier to program and probably more efficient, but they are a lot less *fun*. Probably why I have only written about two pages of assembler in the last eight years or so. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
russell@apple.com (Russell Williams) (01/31/91)
In article <12828@hubcap.clemson.edu> mark@hubcap.clemson.edu (Mark Smotherman) writes: > From crichmon@digi.lonestar.org (Charles Richmond): > > 3) How many registers did it have? > Registers accessible to the program: > Accumulator Register AQ 72 bits > Exponent Register E 8 bits The EAQ registers were linked in that the A and Q could be accessed separately as word registers or together as a double-word register. A floating load loaded the exponent into the E and the manitissa into the Q (thus allowing extra mantissa precision to be carried during accumulator operations), and a double floating load loaded the exponent into the E and the mantissa into the AQ. > > 4) How fast could it execute instructions? Depends on the speed of the core. Both 2 microsecond and 1 microsecond core memories were sold for it (and possibly other speeds as well). I cannot be sure, but from watching the speedometer (there was an analog MIPS meter by the console), I would guess that the times cited by Charles Richmond are for slower core. > 2) What character code did it use? The six bit code was basically BCD; the 9 bit code was basically ASCII with an extra zero bit. The 635 architecture was based on the IBM 7094. Several modifications were made over the years: virtual memory and some other items were added to make the 645 Multics machine. Thereafter the 635 and 645 evolved into the 6000 and 6100 series from Honeywell. The 635 and 645 were hardwired machines based on discrete transistors, while the 6000 series used ICs and was microcoded. The 6000 series added microcode/hardware for decimal arithmetic. The descendents of the 6000 are still around with Honewyell and NEC nameplates.
guy@auspex.auspex.com (Guy Harris) (01/31/91)
>"Alphanumeric data are represented by six-bit or nine-bit characters." >"The character set used is the Computer Equipment Department Standard >Character Set, which is readily convertible to and from the ASCII >character set." The 645, of course, used 9-bit ASCII - or, more accurately, its OS, i.e. Multics, used 9-bit ASCII rather than the character set or sets used by G(E)COS on the 635. >> 3) How many registers did it have? >Registers accessible to the program: >Accumulator Register AQ 72 bits Actually, the AQ was, as I remember, referred to elsewhere as the 36-bit AC (accumulator) and 36-bit MQ (multiplier-quotient) register; however, as I remember, most instructions - most non-floating-point instructions, anyway - that worked with the AC only had equivalents that worked on the MQ, and the AQ in its entirety was used for multiplies and divides, so you could probably call AC "general register 0" and MQ "general register 1" (they were both usable as index registers, in addition to the 8 index registers).
barry@world.std.com (Barry L Wolman) (01/31/91)
I didn't think anyone was left who knew about or cared about the old 635. I spent 7 (happy!) years at GE (later Honeywell) working on the Multics project. I can attest to the fact that the 645 (without EIS) and 6180 (with EIS) posed challenging problems for a code generator. I wrote the code generators used by the first and second versions of the Multics PL/I compiler and the complete Multics BASIC compiler. The number of instructions in the base architecture was 512, but this is misleading, because there were 8 instances of each instruction that affected an index register, e.g. EAX0, EAX1, ..., EAX7. Most people would count these as one instruction, rather than 8. Nevertheless, the 645 with EIS probably was the ultimate CISC machine. The EIS overlayed a byte oriented string + decimal instruction set on top of a machine that was word oriented inside. Most PL/I or COBOL string|decimal operations could be done via a single EIS instruction, e.g., substr(alpha,i,j) = substr(b,m,n); could be done with a single string move instruction once the values of i, j, m, and n were loaded into arithmetic registers. The string move instruction automatically handled truncation and padding. Unfortunately, GE had a hard time getting the EIS to work right on the 6180. They had lots of problems with interaction between the EIS and the segmentation and paging hardware that had been added to the 6180. The 6180 hardware showed all the symptoms of bad software - fix a problem in one area and something else breaks, fix the second problem and a third thing breaks, fix the third problem and the first problem comes back, ... Some examples of the type of problems: block of 8 zeros instead of the right value in middle of string where it crossed a page boundary, all characters in string shifted 8 bytes in wrong direction, random faults in middle of instruction. You can imagine the complexity of the logic needed to preserve and then restore the state of a machine where a single instruction can move 1MB of data, take multiple segment faults, and multiple page faults. They finally got the hardware to work right, but it took a lot of effort. I took a lot of flak from the user community because I was trying to generate the best possible code sequences. Code the worked perfectly when exhaustively tested in the lab would fail randomly in user environments because of the interactions mentioned above. The last time I checked (a few years ago) I found that code I wrote for the first Multics PL/I code generator in 1967 was still being used. Anybody know how many Multics systems are still running? Barry Wolman 159 Oxbow Road Needham, MA 02192 617/449-3874 barry@world.std.com
mac@eleazar.dartmouth.edu (Alex Colvin) (02/02/91)
I couldn't resist adding to the bits of GE635 trivia... not only did it run GE's GCOS operating system, and Dartmouth's DTSS, but the later editions ran CP-6, descended from some of the Xerox XDS. Among the languages not mentioned so far (I didn't know anyone else knew TRAC) were DYNAMO (continuous systems simulation), and one of the world's first Algol68 compilers (unrevised, and never completed). Though the opcode field was 9 bits wide, it was sparsely populated. I think fewer than 200 were valid. The register model (E, A, and Q) was taken from the classic IBM 7090 36-bit machines, whose scientific customers fled rather than use 32 bit 360s.
dgh@Unify.com (David Harrington) (02/02/91)
In article <MACRAKIS.91Jan30031445@diderot.gr.osf.org>, macrakis@gr.osf.org (Stavros Macrakis) writes: > 2) What character code did it use? > It supported 6 and 9 bit bytes. On DTSS (Dartmouth time-sharing > system), it used ASCII, but it's possible that GECOS (General Electric > Common Operating System) used EBCDIC. I seem to recall GECOS standing for GE Comprehensive OS, but who's arguing? :-) The original GECOS (and GCOS, after Honeypot bought it) used 6-bit BCD characters; somewhere around 1972 they released the EIS (Extended Instruction Set) hardware add-on, which allowed character addressing on 9-bit boundries for ASCII (+1), so you got 4 ASCII characters per word. > 3) How many registers did it have? Well, it didn't have general > registers. It had a 36-bit accumulator, a 36-bit extension (Q), and 8 > 18-bit index registers, and a special (9? bits) exponent register (E) > for floating-point. I don't remember the E register. I thought floating point was done in the AQ register with the leftmost 9 (or was it 18?) bits used for the exponent. Remember the TSX1 subroutine call convention? > 4) How fast could it execute instructions? > Couldn't tell you. On the order of 500 kips, I think. On the console of the system was a "speedometer" as I liked to call it. It was an analogur guage with a needle that registered your KIPS. Pegged at 1 MIPS. > 5) Did it support any form of floating point? > Yes. The EAQ registers together made up the floating point > accumulator, giving you 72 bits of mantissa in the accumulator. I > forget how it handled floating-point sign. Note that you got a few > more bits of accuracy in the EAQ than you could get in the > double-precision storage format. Handy in assembler, but not clear > how you tell a higher-level language how to take advantage of it. > 6) What languages were available for it? Well, on DTSS, there > was Basic (of course), Lisp, Trac, assembler, Fortran, and something > like sed. GECOS must have had RPG and Cobol. COBOL, Algol-68, Snobol, too, at least at the Univ. of Kansas. > - 18-bit word addressing > - One-word instructions > - Lots of very fancy addressing modes (e.g. decrement count (setting a > flag if zero), increment address, and indirect through address), > which would be very hard for a compiler to generate except in > stereotyped situations. > - A hairy series of `repeat' instructions, which would take one or two > following instructions and repeatedly execute them until some > condition was met. This was meant for list and string processing, > but they were very hard to use. Also very hard for a compiler to > use except in stereotyped situations. > > -s Ahhh, yes... the good old RPD (repeat double) instruction! -- David Harrington internet: dgh@eire.unify.COM Unify Corporation ...!{csusac,pyramid}!unify!eire!dgh 3870 Rosin Court voice: +1 916 920-9092 Sacramento, CA 95834 fax: +1 916 921-5340
haynes@ucscc.UCSC.EDU (99700000) (02/02/91)
In article <1991Feb1.222231.14103@dartvax.dartmouth.edu> mac@eleazar.dartmouth.edu (Alex Colvin) writes: >The register model (E, A, and Q) was taken from the classic IBM 7090 36-bit >machines, whose scientific customers fled rather than use 32 bit 360s. I'll add a little to this. G.E. hoped to capture a lot of 7090/7094/7040/44 customers. Toward this end they built a simulator aid box (called 9SA) with a port that connected to the 635 memory and another that connected to a 635 processor. The 9SA performed part of the 7090 family instruction set. When it came to an instruction it could not perform it would trap the 635 CPU, which would read the 9SAs registers, emulate the instruction in software, store the results back into the 9SA, and set it going again. The 9SA had no I/O facilities and the 635 I/O architecture was quite different from IBMs; so emulating I/O in 709x/704x programs was more complicated. The intention was to lend the 9SA to a customer until he had converted his IBM programs to run in native mode on the 635; then GE would take it back. In fact the conversion process took a lot longer than expected, so the 9SAs didn't turn over as fast as expected. Some ex-GE people had a different idea, and started a company to manufacture machines that, through microprogramming, would emulate the 7094 exactly. Rats! I can't remember the name of the company now; it started in Phoenix and later moved to Los Angeles. -- haynes@ucscc.ucsc.edu haynes@ucscc.bitnet "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/03/91)
On 1 Feb 91 22:22:31 GMT, mac@eleazar.dartmouth.edu (Alex Colvin) said: mac> I couldn't resist adding to the bits of GE635 trivia... Me too. mac> not only did it run GE's GCOS operating system, and Dartmouth's DTSS, mac> but the later editions ran CP-6, descended from some of the Xerox XDS. And Multics, as many have remarked. mac> Among the languages not mentioned so far (I didn't know anyone else mac> knew TRAC) were DYNAMO (continuous systems simulation), and one of the mac> world's first Algol68 compilers (unrevised, and never completed). A very important language for the 635 was Jovial. I think that Jovial is one of the more widely used languages, in terms of lines of code lying around. Wasn't the USA military WWCCS implemented in a few million lines of (among others) Jovial on GE 600 (in their various later incarnations as Honeywell 6000, etc.) machines? Notable point about Jovial: it is the only language I have seen that makes explicit the important difference between serial and parallel representations of arrays of records. Finally, Algol 68 was eventually implemented quite extensively and well under Multics on the Level 68. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
rwa@cs.athabascau.ca (Ross Alexander) (02/06/91)
mark@hubcap.clemson.edu (Mark Smotherman) writes: >From crichmon@digi.lonestar.org (Charles Richmond): >> 3) How many registers did it have? >Registers accessible to the program: >Accumulator Register AQ 72 bits Accumulator/Quotient Register :-) A very minor nit (pardon my pedantry, and thanks for the fine posting): AQ was accessable as AQ (72 bits) as in LDAQ, STAQ and so on, but it was also available as two separate registers; LDA, LDQ, STA, STQ, and so on treated it as two entirely distinct 36 bit registers. You could also treat it as four 18 bit index registers via the address modes {a,q}-{upper,lower} and their variants; but this symmetry was broken WRT the load-effective-address command EA{A,Q,X[0-7]}, which worked only to index registers 0-7 and A or Q upper. This is all from my time spent on an H6050, which was object compatible. -- -- Ross Alexander rwa@cs.athabascau.ca (403) 675 6311 ve6pdq "Sometimes, you want everything to look like a nail." -- Larry Wall