IBM 7030 Stretch(en.wikipedia.org)
en.wikipedia.org
IBM 7030 Stretch
https://en.wikipedia.org/wiki/IBM_7030_Stretch
24 コメント
My wife's parents met while working on system software for Stretch. From the stories they've told it sounds like it was quite a beast even by the standards of its day. IIRC, the I/O processor was incapable of running independently, so programmers had to add special instructions in the middle of their own code to give it cycles. Ick.
That's a cooperative synchronous bus, something quite common at the time. It's a bit like a 'yield' instruction in a cooperative multitasking environment.
It's a bit more than that. There's usually quite a bit of flexibility in when to yield, and the consequences might not be that bad. These instructions had to be issued in a very timely way, lest the whole system would come crashing down. Was it unique in that regard? Perhaps not, though "common" is a bit misleading when the computing landscape at the time was so small and fragmented. The difference is that other architectures might have shared one or two misfeatures with Stretch out of unfortunate necessity, but the Stretch designers seemed determined to collect the entire set and then expand on it. I'd guess that, like some projects I've been on, it was a case of one powerful or well connected group of people pushing as much complexity as possible onto another. So it's probably related to the "project management failure" sub-thread.
Requiring periodic yields in user code strikes me as indicating a dedication to simplicity. It was no great burden to add a few instructions to a program, and it apparently saved them from needing to implement a forced, transparent context switch mechanism.
I think you're misunderstanding what we're talking about. This wasn't in user code; it was in the OS ("MCP") itself. It wasn't a few instructions that could be placed at convenient points in the control flow; it was every N instructions when I/O was active. Among other difficulties, that meant accounting for that had to be part of even minor code changes. The people actually doing it certainly didn't think it was simple or "no great burden" as you suggest. Simple would have been an I/O unit that could run independently of the main CPU, as in practically every machine designed since - including the 360 which was designed by the same person. Even he apparently recanted that decision.
So yeah, it's "a bit" like yield, but only in the sense that a Cessna and an F-22 are "a bit" alike. I've done low-level work on multiple RISC processors that had all sorts of exposed-pipeline and delegated-to-software functionality (e.g. TLB handling on MIPS) in the name of simplicity, and I've even enjoyed it somewhat, but I'm still glad I never had to work on anything as "raw" as Stretch.
So yeah, it's "a bit" like yield, but only in the sense that a Cessna and an F-22 are "a bit" alike. I've done low-level work on multiple RISC processors that had all sorts of exposed-pipeline and delegated-to-software functionality (e.g. TLB handling on MIPS) in the name of simplicity, and I've even enjoyed it somewhat, but I'm still glad I never had to work on anything as "raw" as Stretch.
Speaking of bad-ass computers, the 7030 was surpassed in speed in 1964 by the CDC-6600, designed by Seymour Cray.
It had incredibly cool-looking DUAL circular displays and a minimalist console keyboard built into the table...
https://en.wikipedia.org/wiki/CDC_6600#/media/File:CDC_6600....
It had incredibly cool-looking DUAL circular displays and a minimalist console keyboard built into the table...
https://en.wikipedia.org/wiki/CDC_6600#/media/File:CDC_6600....
I programmed one of those in Wirth Pascal, as a freshman at Oregon State University in 1979. Then they retired it, installing a Honeywell running Multics. Then, they replaced that with a Vax 750. It was a step down in awesomeness each time.
The most popular parts of the 6600, as souvenirs, were the smoked-glass cabinet doors.
The most popular parts of the 6600, as souvenirs, were the smoked-glass cabinet doors.
Control Data, or it will control you. Beautiful machine, impressive plumbing in the right hand side cabinet as well.
Friend of mine was sysop on the CDC-6600 at University of Texas in Austin.
He has some good stories. Says he learned how to create operating systems by hours of watching the data flow on those tubes.
He has some good stories. Says he learned how to create operating systems by hours of watching the data flow on those tubes.
I was just reading "A History of Pi" which mentions this computer and its successor:
"π was computed to 250,000 decimal places on an IBM 7030 at the Commissariat à l’Energie Atomique in Paris in February 1966, and a year later, in February 1967, a CDC 6600 was programmed by J. Gilloud and J. Filliatre, at the same institution, to yield 500,000 decimal places. The program was again based on Störmer’s formula (2) and the Shanks-Wrench method for checking the digits; the running time was 28 hours and 10 minutes (of which 1 hour and 35 minutes were used for conversion), and an additional 16 hours and 35 minutes were needed for the check. These quarter- and half-million digit values of π were published in reports of the Commissariat à l’Energie Atomique in Paris."
"π was computed to 250,000 decimal places on an IBM 7030 at the Commissariat à l’Energie Atomique in Paris in February 1966, and a year later, in February 1967, a CDC 6600 was programmed by J. Gilloud and J. Filliatre, at the same institution, to yield 500,000 decimal places. The program was again based on Störmer’s formula (2) and the Shanks-Wrench method for checking the digits; the running time was 28 hours and 10 minutes (of which 1 hour and 35 minutes were used for conversion), and an additional 16 hours and 35 minutes were needed for the check. These quarter- and half-million digit values of π were published in reports of the Commissariat à l’Energie Atomique in Paris."
The creation of this machine is referenced in a book that's often cited here - The Mythical Man-Month - just finished reading it today. It's quite insightful for a book that's draws upon experiences from software projects as far back as the 1950s.
STRETCH also makes an appearance in one of the classic Alfred Bester (the writer, not the telepath) short stories: https://en.wikipedia.org/wiki/Something_Up_There_Likes_Me
Well worth a read if you can find it -- the Wikipedia summary is rather spoiler-y and doesn't capture the charm of the story. Mr. Bester worked in broadcast television at the time he wrote it and there is some amusing commentary about ad trends of the day.
Well worth a read if you can find it -- the Wikipedia summary is rather spoiler-y and doesn't capture the charm of the story. Mr. Bester worked in broadcast television at the time he wrote it and there is some amusing commentary about ad trends of the day.
"PC World magazine named Stretch one of the biggest project management failures in IT history."
It would be interesting to know more about this. The Wikipedia article doesn't really go into any detail and neither does the source article.
For example, there's a comment about having to lower the clock speeds but it doesn't say why this decision had to be made.
For example, there's a comment about having to lower the clock speeds but it doesn't say why this decision had to be made.
The germanium transistors used in Stretch simply weren't fast enough to meet the paper spec. The architecture couldn't do much to work around this.
Cray at CDC used the newer and faster silicon transistors in the 6600. So did IBM's later System/360.
In fact Cray funded the development of the fast silicon transistors at Fairchild with a $500k contract.
https://www.computerhistory.org/siliconengine/silicon-transi...
IBM made the classic corporate mistake - sales over-promised and then told engineering to build something that couldn't be built. So Stretch became an involuntary R&D project instead of a commercial product.
Cray at CDC used the newer and faster silicon transistors in the 6600. So did IBM's later System/360.
In fact Cray funded the development of the fast silicon transistors at Fairchild with a $500k contract.
https://www.computerhistory.org/siliconengine/silicon-transi...
IBM made the classic corporate mistake - sales over-promised and then told engineering to build something that couldn't be built. So Stretch became an involuntary R&D project instead of a commercial product.
Stretch and the 6600 both had popcount instructions that x86 finally got in SSSE3, only ten years ago.
This is sometimes interpreted as indicating NSA interest in the machine.
This is sometimes interpreted as indicating NSA interest in the machine.
Oh neat, it was 64bit!
I wonder if anyone has made an emulator for it yet?
I wonder if anyone has made an emulator for it yet?
It seems wasteful to me since it only had 2MB of RAM. It does say that instructions could be 32 or 64 bits long, but I would guess having 16 or 32 bit instructions would let you pack more instructions into memory.
That's not 'only' that's absolutely mind warping huge for the time when it was made. The physical dimensions of that memory were such that you could see the individual bits as tiny little ferrite cores.
Well 2mbit of ram was (at the time) a huge amount of ram.
But I suspect it was so much “we want to address petabytes of ram” but rather “we are doing numerics that require 64 bits of accuracy”
But I suspect it was so much “we want to address petabytes of ram” but rather “we are doing numerics that require 64 bits of accuracy”
There's some tools and documentation gathered at [0] which would help, but last I heard they hadn't managed to get a hold of the 7030, but the 7090 shares a few hardware characteristics.
Apparently it isn't an easy system to emulate.
[0] http://members.optushome.com.au/intaemul/INDEX.HTM
Apparently it isn't an easy system to emulate.
[0] http://members.optushome.com.au/intaemul/INDEX.HTM
The next chapter from where I am in IBM's Early Computers is on the Strech project meaning that I could be wealth of information if I read faster.
"Of course, Stretch came originally with an oil-cooled core memory system.
Jack Worlton of the Los Alamos Scientific Laboratory (LASL) recalls a problem experienced during the acceptance test phase, when there was a transient memory error in the cores. The engineers worked for days to remedy the error but were unable to figure out what was going wrong. They finally hit upon the problem. As Worlton explains it, there was a piece of solder loose in the oil bath, and because the oil was constantly in circulation the solder would move and attach itself onto a core and cause an error. Then it would move and lodge onto a different core and cause an error there.
It was the only error I know of that was corrected in a machine by giving it an oil change, Worlton quips."
from : http://www.chilton-computing.org.uk/acl/literature/reports/p...