t...@harminc.net (Tony Harminc) writes: > There *was* a single-chip 370 produced by someone in the late 70s - a > "168i". I think it was a university or research institute, but not > IBM. I'm not finding anything on Google with a casual search, but > things like this are easily overwhelmed.
SLAC did 168E ... basically could run problem state fortran at 168 speed ... for data collection/reduction along the accelerator line ... long ways from single chip. 168 had been four circuits per chip, 3033 initially was 168 logic initially layed out on something like 40circuits per chip ... but just using 4 circuits in each chip ... getting 20% chip improvement. during development there was some rework of part of the 168 logic to make better use of higher chip density ... get 3033 up to 50% faster than 168. http://www.jfsowa.com/computer/memo125.htm i've frequently claimed that John Cocke's 801/risc was reaction to horrible complexity of (failed) FS effort ... initially simplified (aka reduced instruction set) for single chip implementation ... and then later simplified instructions that were all single machine cycle. 360s, 370s, etc ... have been microcode implemented on variety of other kinds of engines. circa 1980 there was an effort to replace the wide variety of internet microprocessors used for controllers, low&mid range 370s, the planned as/400 replacement for s/38, etc ... all with 801/risc Iliad chips. For various reasons the efforts floundered and they went back to doing custom processor implementations. It took another couple decades ... but lots of stuff is now risc in one way or another (as previously mentioned the past couple generations of i86 are risc processors with hardware layer translating i86 to risc micro-ops). In the mid-80s, there was a 3-chip 370 that ran at 168 speed from Boeblingen called ROMAN. I had a project/proposal to pack arbitrary mix of large numbers of ROMAN and Iliad chips in the same rack ... with large number of racks (sort of precursor to latest rack announcement). a couple old email refs: http://www.garlic.com/~lynn/2011b.html#email850314 http://www.garlic.com/~lynn/2007d.html#email850315 I had also been working with NSF on what was to become NSFNET backbone (i.e. tcp/ip is the technology basis for the modern internet, NSFNET backbone was the operational basis for the modern internet, and CIX was business basis for the modern internet). Above refs. that I had to find standin for me doing presentation to head of NSF ... because of rack cluster effort meeting. Lots of low & mid-range clone 370 vendors were starting to spring up all over the place. Somebody in Siemens germany had somehow acquired a proprietary ROMAN document ... and was trying to get it returned to IBM with all fingerprints removed. He sent it to somebody at Amdahl in silicon valley ... who arranged to hand it over to me. Other trivia ... SLAC had hosted the monthly IBM user group meetings (BAYBUNCH) and was also the first webserver outside of europe. http://www.slac.stanford.edu/history/earlyweb/history.shtml and from long ago and far away ... mentions slac/cern 168E ... having become 3081E (3mips to 14mips). Date: Fri, 7 Jul 89 10:52:39 CDT From: wheeler Subject: requirements task force Note that both DEC and Apollo (along with hp) are heavily into distributed environment, heterogeneous network/system/enterprise management, and networks. Note that heterogenous means more than OSI, TCP/IP, UNIX, etc ... it means interoperability between all of them along with DECNET, VMS, XNS, etc. Apollo's FDDI group is heavily involved in XTP and the former manager of the Apollo FDDI group (they've been active for some time and spending lot of time optimizing performance of high thruput adapters) left Apollo and formed synernetics (he was involved with XTP at Apollo and synernetics is a XTP/TAB member). They are working on initial cut of FDDI station management (SMT ... and have been out talking to a number of groups, including IBM ... I also believe he has even had contacts with Andy). Distributed 370s have a hard time keeping up. Way back in history (someplace), I spent a lot of time up at SLAC (there is tight coupling between SLAC and CERN). At that time SLAC was doing the 168E, a bit-slice processor that would run standard 370 Fortran programs. They technology has been improved and now CERN & SLAC are calling it a 3081E (i.e. the processing power of 3081). The design was to have one of these processors at each of the (large number of) data collection points. Something that will be competing with this will be the 370 simulator that <xxxxxx> has done for the SUN4. He currently has VM/370 running at about 168 thruput on the old SUN4 (big register memory are super for large integrated applications but state switch overhead can be heavy/horrible ... something that we are currently grappling with ... some possibilities exist for pipelining/overlapping state switch like <yyyyyy> is doing with Vector Buffer architecture). I've known <xxxxxx> for a long time and he is experienced at what he does (he was lead development programming at Amdahl, then chief architect at 2pi, did DOS port for Olivetti, did 370 software ports/stuff for Nixdorf and most recently was contract to Boca West doing the OSI implementation for CPD). 168 thruput means he is effectively getting about 4:1 ratio of Sparc instructions to 370 instructions (implying that he could get 12.5 370 mips on the recently announced 50mip Sparc chip). ... snip ... -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
