Newsgroups: comp.sys.transputer From: Richard Beton Subject: Re: Post Mortem Organization: Roke Manor Research Limited Date: Tue, 17 Feb 1998 10:18:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34E963F9.17BB9213@roke.co.uk.no.spam.thankyou> Alec Cawley wrote: > In article , NewsMan > <2021@please.dont.send.email> writes > > > I wonder > >though if anyone has performed a detailed business analysis of > >why the product failed. > > > In embedded processing, the problem was that inmos insisted that you > purchase not only the transputer but also occam and the whole embedded > approach. Occam 1 was simply inadequate for embedded work, and as far as > I know, occam 2 is also. Data structuring - records/structs etc., are > absolutely essential for the classes of embedded work which can use a 32 > bit processor, and occam didn't (doesn't?) have them. It does now, but that's clearly far too late. occam 2.1 should have been released in the late '80s, with occam 3 (or something like it) following in the early '90s. However, support for the embedded market had a sad lack of direction: on the one hand, there was pressure to provide C and Fortran which slowed down the progress with occam tools. On the other, there was a reluctance to provide alternatives to occam. IMO both should have been provided (and well funded) at the outset, but the clear advantages of simplicity, correctness of behaviour and substantially smaller program size should have been pointed out for occam. > Similarly, the > occam PAR construct does not well represent the kind of parallelism > needed in an embedded machine. Presumably the C par() does not either, then. That's transputers for you. ;-) I would add that the strongly static nature of the occam compiler always seemed too inconvenient - late binding of memory allocation might have been a simple enough fix to provide the best of both worlds (effective static analysis by the compiler PLUS portability between target systems of different memory sizes). The difficulty for C-retrained-as-occam programmers was always in the nature of trying to do things in a Von Neumann way, not thinking in CSP. Some of the perceived problems in using occam actually come down to taking the wrong approach at the outset. That's more of a design question than a language question. Another omission from Inmos was a quality optimiser for occam - I understand it was developed but never properly released. Why not? And why is it still not available from the Kent compiler - some IPR contractual reasons I think. Bummer! > > > Then there was no support for "self configuring" - a system has to be > configured for a given "net" of processors at build time. But in my > systems, some of the processors control optional hardware and are not > always fitted. One of the advantage of a disrtibuted processing system > is not having to buy mips you don't need. I did quite a lot of work on self configuring transputer systems (high availability fault tolerance on which I published a paper or two) but the key part of that work was down to writing a different loader from the Inmos one. Which leads me to wonder why Inmos didn't pursue this avenue (not that we made much money from it, it has to be said). But our approach was a departure from the fully-static occam model of a transputer network which is unchanging throughout the lifetime of a given program. > An inmos salesman seriously > proposed to me that I should ship the linker and configurer with the > system and end users should reconfigure their systems - look, some of > our users wear baseball caps backwards. No, they should have taken the 'WinZip Self Extracting Archive' approach - direct support for shipping automatically configurable systems to end-users. Perhaps we expected too much from the Inmos software teams, but, in my book, disappointment in their software offerings preceded disappointment in their hardware offerings by a few years. Aside from 3L, there was never a great cohort of 3rd party tool providers so it all fell on Inmos' shoulders. For background reading, there is a critique of how occam developed and how it could have been better in the paper by Singleton & Cook, in Parallel Processing Developments (Procs WoTUG-19), 1996, IOS. Rick -- Richard Beton BSc CPhys MInstP Roke Manor Research Limited --------- Standard Disclaimer about my own views etc etc -------- --------- My mail client accepts rich text (HTML) mail -------- Welsh Highland Railway: http://www.whr.co.uk/WHR/WHR.html