jlol@REMUS.EE.BYU.EDU (Jay Lawlor) (11/28/90)
Hi, I was reading a paper which reported performance of an algorithm in the form of execution times on an IBM 7094 II. Does anyone know how fast this machine was and how much memory it might have had? As a reference point, the paper was published in 1965. Thanks for any help. Jay
tk@rice-chex.ai.mit.edu (Tom Knight) (11/28/90)
This machine had approximately a 5 microsecond instruction time for simple (clear accumulator) instructions. For floating ops, I think the time was more like 12-17 microseconds. It used sign/magnitude arithmetic and had a peculiar notion of a "logical" accumulator (unsigned) and an "arithmetic" accumulator which included a sign bit. These registers shared 35 of the 36 bits, only the MSB differed. CLA cleared the arithmetic accumulator, CAL cleared the logical accumulator. The machine had some very specialized instructions, highly non-Risc like, such as TRQ (translate by replacement from MQ) which could be used (it was said) to make COBOL more efficient. It was a predecessor of the 360 Edit and Translate instructions. Almost all machines had a full address space consisting of 32K words. The machines at MIT running CTSS had a second core bank of 32K words which held the operating system and I/O buffers, but user programs couldn't access it. The major programming languages were MAD (Michigan Algorithmic Decoder), Fortran II, and FAP (Fortran Assembly Program). For all you FAP programmers out there: TSX $EXIT,4
is@athena.cs.uga.edu ( Bob Stearns) (11/28/90)
The IBM 7094-II was a 32K word (36 bits/word) processor follow on to the family 709-7090-7094. At its best (my memory may be failing here) it was capable of something like .2MFLOP. This is an oldy-goldy scientific processor built before the "universal" 360/370/390 architecture. It was programmed entirely from banks of tapes attached on primitive channels; very few 7094's ever had the RAMAC disk drives. All input (cards) and output (printing) was done offline using IBM 1401's.
herrickd@iccgcc.decnet.ab.com (11/29/90)
In article <9011272349.AA25956@ucbvax.Berkeley.EDU>, jlol@REMUS.EE.BYU.EDU (Jay Lawlor) writes: > Hi, > > I was reading a paper which reported performance of an algorithm in > the form of execution times on an IBM 7094 II. Does anyone know how > fast this machine was and how much memory it might have had? As a > reference point, the paper was published in 1965. > > Thanks for any help. > > Jay I'm sure others will give you the kinds of answers you want that will let you know how inferior the 7094 model II is to the 386 on your desk. But the 7094 model II was the fastest (production) computer in the world. It was so fast that it couldn't afford to wait for ordinary input and output devices. In fact, the acolytes of a 7094 II always included a 1401 (or 1410) roomful of computer to transfer card decks to mag tape (800 bpi, and then, mirabile dictu, 1600 bpi) for the attention of the 7094 II and then transfer the words of the oracle back to new cards and printed paper. I had a Summer job in Flint, Michigan with my deck of 2500 cards (we were doing a relaxation on a 50 by 50 grid) and could actually see and push buttons on the 1401. (Oh the joys of turning the room lights down and watching the Christmas display on the front panel of a Real (TM) computer.) The 7094 II was in its temple in Warren, Michigan and could only be approached by special messengers carrying my data on mag tapes. Its light display was too special for a mere user to observe. dan herrick herrickd@astro.pc.ab.com
news@ism780c.isc.com (News system) (11/30/90)
In article <12073@life.ai.mit.edu> tk@rice-chex.ai.mit.edu (Tom Knight) writes: >This machine had approximately a 5 microsecond instruction time for >simple (clear accumulator) instructions. For floating ops, I think >the time was more like 12-17 microseconds. It used sign/magnitude The 7094 manual in front of me indicates that on average integer operations (add, sub, and, etc) requires about 3.2 microseconds. 4.0 microseconds is the worst case time. Floating add was from 4 to 24 microseconds, floating multiply was from 4 to 10 microseconds. The speed of the 7094/II was a little greater but not by much. >arithmetic and had a peculiar notion of a "logical" accumulator >(unsigned) and an "arithmetic" accumulator which included a sign bit. >These registers shared 35 of the 36 bits, only the MSB differed. CLA >cleared the arithmetic accumulator, CAL cleared the logical >accumulator There was only one accumulator. There were two types of operations on the accumulator. It was analogus to signed and unsigned of C. > The machine had some very specialized instructions, >highly non-Risc like, such as TRQ (translate by replacement from MQ) >which could be used (it was said) to make COBOL more efficient. It >was a predecessor of the 360 Edit and Translate instructions. Actually the opcode name is CRQ (Convert by Replacement in MQ). This was not for the benifit of COBOL. The instruction existed before COBOL. The machine was originally programmed largely in assembly language. CRQ and and other similar instructions were provided for converting BCD to binary and back as well as for other tasks like leading zero supression (replace leading zeros with blanks) in a BCD representation. >The major programming languages were MAD (Michigan Algorithmic >Decoder), Fortran II, and FAP (Fortran Assembly Program). > >For all you FAP programmers out there: TSX $EXIT,4 Late in its life IBM supplied an operating system called IBSYS. IBSYS provided FORTRAN/IV, COBOL, and MAP (Macro Assembly Program). Marv Rubinstein -- 7094 mavin
jkenton@pinocchio.encore.com (Jeff Kenton) (11/30/90)
From article <50926@ism780c.isc.com>, by news@ism780c.isc.com (News system): > > Marv Rubinstein -- 7094 mavin ^^^^^ Maven: a programming language for people with more enthusiasm than skill. ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ----- ----- jeff kenton: consulting at jkenton@pinocchio.encore.com ----- ----- until 11/30/90 -- always at (617) 894-4508 ----- ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -----
martyi@nubbins.wpd.sgi.com (Marty Itzkowitz) (12/01/90)
The 7094II, and its predecessor machines the 704, 709, 7090, and 7094I,
also have the distinction of being responsible for those strange terms
in LISP, cdr and car. Machine words were divided into 4 fields,
the opcode, the tag, the decrement and the address, and there were instructions
to load and store out of these fields.
The first LISP implementation kept two pointers in a word, referred to as
"contents of decrement register" and "contents of address register", hence
the acronyms, "cdr" and "car".
The 709x series were fun to work with. If you wired an audio amplifier
to the bits of the MQ register, you could play music by loading bit patterns
into the word. There was a set of sense registers that could be loaded from
switches on the console.
Most of these machines used an auxiliary 1401/1410/1460 to read user jobs
from cards and write them onto tape for the 709x. The 1401 was also an
interesting machine--it had the least-RISCY instruction I know of:
WRP xxx write-read-punch-and-branch.
It would read a card from the card reader into a hard-wired buffer,
punch a card from a second hard-wired buffer, print a line on the line
printer from a third buffer, and then branch unconditionally to xxx. I couldn't
resist writing a program to read a card deck, label and serialize the cards,
and produce a listing, just to use this instruction!
Marty Itzkowitzchuckh@apex.UUCP (Chuck Huffington) (12/01/90)
In article <9011272349.AA25956@ucbvax.Berkeley.EDU> jlol@ee.byu.edu writes: |I was reading a paper which reported performance of an algorithm in |the form of execution times on an IBM 7094 II. Does anyone know how |fast this machine was and how much memory it might have had? As a |reference point, the paper was published in 1965. Ah, one of my favorite old machines. 32K words of 36 bit memory, in two banks of 16K. Odd words in one bank and even words in the other. This allowed both words of a double to be fetched at once without worrying about alignment. There was a CE mode that changed the banking to high and low half of memory. This was used for memory diagnostics. I can't remember the clock speed, but it seems to me the major cycle time was 1 microsecond. Most instructions took a couple of cycles with a fair bit of overlap (2 instruction "pipeline"). The overlap could also be disabled to aid troubleshooting. I'm pretty sure I still have a set of prints and CE manuals at home. I'll try and check the cycle times and report further. Chuck Huffington uunet!apex!chuckh
barry@tiger1.Prime.COM (Barry Wolman) (12/04/90)
In article <1990Nov28.143631.725@athena.cs.uga.edu>, is@athena.cs.uga.edu ( Bob Stearns) writes: |> The IBM 7094-II was a 32K word (36 bits/word) processor follow on to the |> family 709-7090-7094. At its best (my memory may be failing here) it was |> capable of something like .2MFLOP. This is an oldy-goldy scientific |> processor built before the "universal" 360/370/390 architecture. It was |> programmed entirely from banks of tapes attached on primitive channels; very |> few 7094's ever had the RAMAC disk drives. All input (cards) and output |> (printing) was done offline using IBM 1401's. FMS (Fortran Monitor System) was a simple OS oriented towards running Fortran and assembly programs in a scientific enviornment. I believe FMS was written by members of SHARE, the IBM User Group. The University of Michigan, where I got my undergraduate degree, had its own executive (called MESS, as I recall) optimized for running student MAD programs as quickly as possible. An interesting problem with which MESS had to deal was protecting the OS in the absence of hardware protection. If you requested the Fortran compiler (Fortran II in those days), what you actually got was a MADTRAN, which translated Fortran II to MAD, followed by a normal MAD compilation. This process was MUCH faster than using the normal IBM Fortran compiler. As I recall, the first "pass" of the IBM compiler did nothing but copy the input program from the source tape to a scratch tape! The "premiere" OS for the 7094 series was the CTSS operating system developed at MIT, where I did my graduate work. CTSS was available as a production system in 1963 and underwent additional development until about 1967 when most work at MIT was aimed at Multics. CTSS required a modified 7094 with two banks of 32K words of memory. The OS resided in bank A and user programs in bank B. Quite a lot of useful work got done in spite of the limited memory. Garden variety FMS jobs could run as background while interactive users ran in foreground. CTSS was quite popular at MIT and was around until sometime in the early-mid 70s. CTSS had an interesting feature that I haven't seen in any recent OS. A user could interrupt a program at any point and issue the command "save file" to create FILE.SAVED. This preserved the entire state of the computation, including file buffers and positions. Most commands were just files that had been saved immediately after loading. The user could return at an arbitrary time in the future and resume the computation where it had been interrupted. In fact, the computation could be resumed multiple times. A useful debugging technique was to save just before a problem occurred and then explore various paths by rerunning the saved image. If files implicitly associated with the saved file weren't deleted, the user could come back MONTHS later and resume exactly where s/he left off, even if there had been an OS upgrade installed. I'd sure like to be able to do that today! Barry -- ------------------------------------------------------------------------ - Barry Wolman | barry@s66.prime.com Principal Technical Consultant | 500 Old Connecticut Path Prime Computer | Framingham, MA 01701 | 508/620-2800, ext. 1100 ------------------------------------------------------------------------ -
borasky@ogicse.ogi.edu (M. Edward Borasky) (12/27/90)
I thought this question got answered WEEKS ago. The IBM 7094 II was about 0.25 MIPS on integer operations. This would make it about a quarter of a VAX-11/780. I don't recall seeing any estimates of floating point speed, although it MAY be in Frank McMahon's Livermore data base. You could always call Frank at Lawrence Livermore National Lab; I'm pretty sure he ran an early version of the Livrmore Loops on a 7094 II.