Newsgroups: comp.sys.transputer From: Rupert Pigott Subject: Re: Post Mortem Organization: AeroPig (Flying Pigs a Speciality) Date: Mon, 23 Feb 1998 21:16:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34F1E71C.F3860C51@globalnet.co.uk> NewsMan wrote: > Stephen Maudsley wrote > > > >Is there any public domain profit and loss information - a business > >analysis will be lacking without one. > > This is true. What we can do here will be limited but may be of use > nonetheless. What follows is a summary of responses so far. Sorry if I > have missed anything you included. It wasn't deliberate! Please post all > suggestions for change to the newsgroup. > > HARDWARE > > * Promised (and needed) developments didn't appear > * T9000 was late. New processors were needed over time. T9000 too > ambitious as a single step. > * Chips were produced that malfunctioned. T9K's maybe... The industry darlings INTEL have shipped considerablymore flawed stuff in the past... T2/T425/T80x parts all seemed remarkably bug free to me. > * Lack of investment to beat any competition Probably. > * Price. Chips were costly compared with competition and still have high > costs. While Inmos designed the transputer to reduce time-to-market this > helped initial design costs but not ongoing unit-production costs. Other > chips were cheaper so systems expected to ship in quantity used other > CPUs and the slightly higher costs of the initial design were more than > offset by the costs of producing many many units. This has encouraged > use of the transputer for bespoke systems and not for the mass market > that the device needed to survive. When I looked at them Transputers were *much* cheaper than thecompetition. They were falling behind on raw speed, but then again they gained on cost due to the extremely low external component count. > * Virtual memory desirable. Impossible with the T[248] series chips due to the PMI and the instructionprefetch to name two problems... Shame they never produced a part which could talk to external MMUs. > * Virtual links desirable. Not very likely in the early 1980s when they designed it ! > * Alternative supplier desirable. Again not likely... It was too much of a freak ! > * A range of devices is needed. Cheaper parts for smaller applications > couple with more powerful parts for more demanding apps. To an extent > the T2 series did this. To put some figures on this can someone post > sample parts prices, please? Didn't they do a T400 part which just two links - or did that never escapethe development dungeon ? > > > SOFTWARE - OCCAM > * Inmos encouraged occam only and strongly discouraged other > languages. C was late. Inmos wanted to drive the market rather than > reacting to it. True. > * CSP was inadequate as the only process model. Again, Inmos reacted > late to needs for other models. Perhaps - although I actually liked it. Doing multi-threaded NT and UNIXapps is a nightmare after the strictly controlled environment of OCCAM. > * Data structures late being implemented in occam. > * Poor occam support for file-system handling. Not really appropriate for the language, 'C' doesn't exactly shine here eitherif you exclude the possibility of libraries. > * Initially poor debugging support for software and hardware bugs. Can't comment on that. > * TDS too restrictive. Again: "work our way or not at all." Probably - it looked neat to me as a rank amateur though :) > * Inquest debugger too expensive. > * Occam compiler too static in nature. Maybe... The static nature of the compiler made the code that more stable :) > * No quality occam optimising compiler. I rarely managed to tweak things to run much faster than the compiler managed,but I was *very* wet behind the ears at the time. > > > SOFTWARE - GENERAL > * No clear identification of target market. Two markets emerged: Ultra high > performance computers and embedded systems. > * Software support was lacking. > * Turnkey system required. > * Operating system required. Helios, when it came, was too pricey. OSes really like to have MMUs, that seemed to be a major stumbling block to me.I believe that there was a port of Chorus to the T4/8 - possibly even to the T9K. > * No self-configuring loader. Some have written their own loaders to > overcome this deficiency. At least one per-CPU manager was written. > Again, this should have been part of the operating system. > * Unix or another operating system could have been written or ported to > deal with multiple CPUs transparently as part of a turnkey system. Minix ran on the transputer, real Unixen require MMU's though. Interestinglyenough there is a Linux project which aims to provide a Linux kernel which runs on machines without MMUs. I believe that they made their first (68K) release recently. > > > MARKETING > * Inmos tried to ignore C. > * Inmos required purchase of occam and TDS with transputer. > * Inmos didn't respond to users' requests for changes. > * Inmos tried to do too many different things at the same time. They tried > to be a semiconductor company, a compiler company and a systems > company. > * SGS Thomson has never shown much interest in the product. > * Inmos was overly insular and self-confident. They missed opportunities to > work with others feeling that they knew best how to do everything. > * The whole enterprise should be behind the product. Focus is required. > > Please bear in mind that the above has been quickly thrown together as a > first draft only. > NewsMan Not a bad assessment overall :) Cheers Rupert.