Info on GE-635
Charles Richmond
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 cric...@digi.lonestar.org
Stavros Macrakis
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.
-s
Alex Colvin
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.
David Harrington
(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: d...@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
99700000
In article <1991Feb1.2...@dartvax.dartmouth.edu> m...@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.
--
hay...@ucscc.ucsc.edu
hay...@ucscc.bitnet
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chronicle
Piercarlo Grandi
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....@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk
Walter Spector
(Piercarlo Grandi) writes:
> 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?
I have a few questions on Jovial:
- When was JOVIAL written?
- What were the salient features of Jovial?
- What did it do/not do well?
- What machines was it developed on? and did it run on?
- Why did(/do) the Feds love it so much?
- What other good stories does anyone have?
In short, what was Jules Schwartz thinking when he wrote
his Own Version of IAL?
> 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.
SYMPL (SYsteMs Programming Language) for the 60-bit CDC systems
had this feature.
Walt Spector
(w...@renaissance.cray.com)
Sunnyvale, California
_._ _._ _.... _. ._.
David B. Thomas
>I have a few questions on Jovial:
> - When was JOVIAL written?
> - What were the salient features of Jovial?
> - What did it do/not do well?
> - What machines was it developed on? and did it run on?
> - Why did(/do) the Feds love it so much?
> - What other good stories does anyone have?
Up until very recently, I was working for a big company --
make that big, slow, stodgy, ungainly bureaucracy --
steeped in computer tradition. All of their business
data, to this day, resides on a univac 1100 (vintage 1957..
not a good year for computers) which was set up poorly
then, and still does not begin to do what it is capable
of. Yes, that's good for a few shudders. They still
use paper tape, EBCDIC, ... escuse me...
<puuuuuuuuaafffhh> okay, I'm back. Now where was I?
Oh! Well, anyway, JOVIAL was one of the very newest and
freshest things I got my hands on while I was there.
We had to distinct compiler/linker/debugger toolsets
(both full of bugs) running on VAXen under VMS.
I'll probably get flamed for saying this, but I really
liked J's handling of types, both builtin and user-defined.
It did pointers and bit fields much more sensibly, but not
as flexibly as C. You rode pretty close to the machine,
and the structure was formal without being ridiculous.
Linking with assembly code was a cinch. Lucky thing,
too, since one of our compilers was messed up, in
such a way that a "return from interrupt" was impossible
to code in jovial. It HAD to be done in assembler.
Oh well... most languages don't do that anyway.
A nifty conecpt in J is that of a COMPOOL, which is sort
of a cross between and .o and a .h file all rolled into
one. You declare shared data in it, then compile the
compool, and include it at the tops of your other sources.
In C, global data must be externally referenced in the .h
file, so all the sources know its type, but it must be
declared in just one place, another .c file. So if it
changes you have to change it in two places. The COMPOOL
serves both purposes and allows you to keep exactly one
description of each object that both specifies its type
and defines/declares/allocates it.
An interesting piece of J folklore: NO console i/o.
None! Zippo! That really messed me up, since the most
natural thing to do in a new language is to write a
"hello, world" program. Aaack! I suppose I could have
stuffed the bits in i/o registers and pretended that the
registers were driving the display unit in an F-16 fighter
(I really did work with some J code that might just be
helping to delete a few iraqis along about now). If you
really HAD to have console i/o there was a way you could
link to a fortran object file. Imagine doing all that
just to say "hello, world"!
One more thing of note ... in C, you always end statements
with a semicolon. In pascal, it's a bit trickier.
Sometimes you'll mess yourself up with extra ones. In J
you REALLY had to watch it. Even in such things as
block definitions or the very last statement of a function,
an extra semicolon could stop your code from compiling.
>In short, what was Jules Schwartz thinking when he wrote
>his Own Version of IAL?
hahahhaa. Ever use that handy unix tool, Juan's Obsequious
Implementation of 'N'?
little david
--
Computer interfaces and user interfaces are as different as night and 1.
Joe McGuckin
I used to work for Proprietary Software Systems - a small (< 35) company that won the contract
to maintain and upgrade the base 1750A JOVIAL compiler for the USAF. Unless they received exemptions,
contractors developing embedded applications for ordinance or on-board flight systems were required to
use the 1750A/JOVIAL combination.
--
Joe McGuckin oilean!j...@sgi.com
Island Software j...@parcplace.com
(415) 969-5453
Douglas W. Jones,201H MLH,3193350740,3193382879
by w...@raphael.cray.com (Walter Spector):
>
> - When was JOVIAL written?
or International Algorithmic Language. By the time of the Algol 60
report, the name IAL was dead.
>
> - What were the salient features of Jovial?
think this was analogous to FORTRAN unnamed common in many ways.
>
> - What did it do/not do well?
the alternatives. By 1975, it was probably still better than many
alternatives for embedded systems.
>
> - What machines was it developed on? and did it run on?
I was at the Rockwell Collins Government Avionics Division in the
summer of 1986, there were lots of Jovial programmers. As I
understand it, the Collins CAPS minicomputer (a nice stack based
architecture) tended to be programmed in JOVIAL for military
applications and PL/I for civilian applications. The first
generation GPS receivers each contain a CAPS processor programmed
in JOVIAL. (I worked with the people who were developing the Ada
compiler for the AAMP -- the monolithic successor to CAPS.)
>
> - Why did(/do) the Feds love it so much?
standard, even if the language could be improved on. JOVIAL was
never widely used or loved outside the Air Force and their
contractors, but within the Air Force, it was the standard language
until Ada came along.
Doug Jones
jo...@cs.uiowa.edu
Tim Roberts
>In article <PCG.91Fe...@odin.cs.aber.ac.uk>, p...@cs.aber.ac.uk
>(Piercarlo Grandi) writes:
>
>> 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.
I have to agree. There is a GREAT deal if Jovial code still running today on
some fascinating and arcane architectures.
> - What did it do/not do well?
It shares many of its strong (and weak!) points with C. It tends to rather
easily allow direct bit-level access to hardware. It was typed, but (like C)
rather weakly. Also, Jovial code tends to make strong use of pointers and
linked lists, simply because the language supports them so well.
> - Why did(/do) the Feds love it so much?
The Feds loved it by definition. It was, for a long time, THE standard
programming language of the US Air Force.
>> 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.
>
>SYMPL (SYsteMs Programming Language) for the 60-bit CDC systems
>had this feature.
Control Data's SYMPL is a very close derivation of Jovial. ITEMs, ARRAYs and
BASED ARRAYs, the odd variable declaration syntax, all of this came from
Jovial. The early SYMPL compilers shared a great deal of common code with
CDC's Jovial compiler. If you know SYMPL, you can read Jovial almost
immediately.
--
ti...@gssc.gss.com Tim N Roberts, CCP Graphic Software Systems
Beaverton, OR
This is a very long palindrome. .emordnilap gnol yrev a si sihT
Lance Billy Fish Smith
>In short, what was Jules Schwartz thinking when he wrote
>his Own Version of IAL?
Hmmmm, I read an unpublished interview with Jules Schwartz where he talked
about JOVIAL. Let me see what I can remember. (<-- In other words, don't
trust anything I say.)
As I recall:
JOVIAL was developed at SDC which was a spin-off of the RAND Corporation. They
were responsible for most of the software of the early military systems like
SAGE and other early warning systems. I think JOVIAL was developed on the Q-32
which was a computer SDC wound up with after the Super-SAGE project was
terminated.
Didn't Schwartz have help on JOVIAL? I seem to remember the name was a bit of
a tweak.
For more concrete information try the either Jean Sammet's or Richard Wexelblat
(ed) history of programming languages. You might also try The System Builders
by Claude Baum. Or maybe the ACM's upcoming History of Programming Languages
Conference will deal with it...
--
Lance "Analog" Smith
Not all those that wander are lost.
Excuse me, but I'm only in this for the entropy.
Send monetary units to: PO Box 13345, Dinkytown Station, Minneapolis, MN 55414
Tom S Wailes
> In article <PCG.91Fe...@odin.cs.aber.ac.uk>, p...@cs.aber.ac.uk
> (Piercarlo Grandi) writes:
>
> - What machines was it developed on? and did it run on?
>
> - Why did(/do) the Feds love it so much?
>
> - What other good stories does anyone have?
>
> (w...@renaissance.cray.com)
Some years ago I had the honor of programming one of the worlds largest
collections of vacuum tubes ever put into large scale use. It was called
the SAGE computer system and boasted of having 54,000 vacuum tubes (all
trying to ruin your day). IBM made these systems ~ 1956-58 for the
Air Force for the Air Defense of the United States and Canada. It was
labeled the "AFSN/Q-7" or the "Q-7" for short. It was put out of service
at the end of 1983. At that time it was replaced by modern main
frames. At one time there were ~30 of these systems up and running in the
US and Canada. Most of the main programs were written in Assembly
Language, and of course there was no operating system. Millions of lines
of Assembly Code were maintained by a group of programmers devoted to
keeping the machine up to date (imagine how it was for us to interface the
AWACS). Anyway, we had a Jovial compiler (any compiler is better than none)
and as I recall we used it for our off-line processing. Things like our
exercise tape creation (for testing our radar scope operators and intercept
directors) was done with programs written in Jovial. I even looked at some
of them. But as things would happen, a very common practice was to make
updates to the assembly code generated by the Jovial compiler. You have to
keep in mind that everyone knew our Assembly code. Only a very few knew
Jovial. I think that at one time alot of the Code written for the NORAD
command center (in C-Springs) was written in Jovial. But perhaps someone
who actually worked there could enlighten us on that.
Tom
Tom Rombouts
>
>For more concrete information try the either Jean Sammet's or Richard Wexelblat
>(ed) history of programming languages. You might also try The System Builders
>by Claude Baum. Or maybe the ACM's upcoming History of Programming Languages
>Conference will deal with it...
The above mentioned Wexelblat book is a polished version of the 1978
ACM History of Programming Languages Conference, held in Los Angeles.
The proceedings can still be ordered from the ACM ($17 members, c.
$24 for non-members.) order department. This is perhaps the most
entertaining collection of language histories ever put together.
For the record, the following languages are covered with about
10 or 15 pages each: ALGOL, APL, APT, BASIC, COBOL, FORTRAN,
GPSS, JOSS, JOVIAL, LISP, PL/I, SIMULA and SNOBOL. Jean Sammet,
also mentioned above, was the chariperson of the committee that
put on this conference. Also, I have heard that audio tapes of these
lectures are also available from the ACM, but have no ordering
info.
P.S. - Watch for "The Language List" - coming to this news group
real soon now!
Tom Rombouts Torrance 'Tater to...@ashtate.A-T.com V:(213)538-7108