Newsgroups: comp.sys.transputer From: Alec Cawley Subject: Re: Short memories Organization: Home Date: Sun, 16 Nov 1997 10:53:47 +0000 Mime-Version: 1.0 Message-ID: In article <879642701snz@nlcc.demon.co.uk>, Mark Ian Barlow writes >In article <346DBE48.36CA@sj.co.uk> steve@sj.co.uk "steve" writes: > >>Paul Walker wrote: >> >>> Buyers please! --for an ARM based transputer replacement Paul knows my position on this. >The need to run occam is paramount for me, too. I like to *reason* about >what I'm writing, instead of just guessing. KROC is a possibility, (I'm >afraid to admit I don't know if the endiannesses match) SPOC might do it >too, but maybe we should all start being *very* nice to Micheal Poole. >If he can port 2.1 to x86 (as he has), perhaps he's our man. Could >someone rich could buy him an Acorn PC and bung him a few grand? > >There remains the problem of reproducing Error/Analyse in all it's post- >mortem glory (Interactive debugging of real-time systems is a non-starter, >IMHO; I can't type fast enough to keep up with a speeding lump of metal, >despite years of experience) Any thoughts? My transputer systems don't user Error/Analyse. But I don't have much problem with leaving enough of the system alive after a failure to report postmortem data to the host system. I just layer the systems. Post mortem reporting is the responsability of the lowest layer - debugged once in two weeks hard work with a logic analyser four years ago, untouched since. About the only thing which really hangs the system is attempt to communicate on an uninitialised channel (sorry - I use C++, not occam) - and once you know that this is the only "deadly hush" failure mode, it's easy to find which channels you have fiddled with. Besides which, an ARM implementation ought to be able to error-detect this. This sort of thing is different - and easier - with a self-router than with dedicated links. Often, the route to the host processor can be kept open because the host itself hasn't crashed. On my architecture, you can devide the links into "upstream" - to the host processor - and "downstream" - away. If a CPU crashes - and hence stops accepting messages, it tends to jam the downstream direction before it jams the upstream. Furthermore, if the implementation is such that the "crashed" processor continues to accept incoming messages while it dumps it's last will and testament to the network, it won't even jam the network. The most luxurious case involves a second link. You have two complete networks - one to do the "real job", with one or more links per processor, and a separate link to a post-mortem network. This is no more pins than Error/Analyse and invoves duplicated rather than distinct logic (a design saving). Probably the number of gates involved is slightly larger - but not (IMO) critically so. The ARM has a conventional supervisor/user mode switch. I think that it would not be difficult to build a microkernel in supervisor mode (a couple of K of hand-crafted assembler) which would deliver a user mode model exactly like a transputer (or as exactly as we wanted, with 10+ years of experience). Depending upon ARM model, you can have an MMU which will trap illegitimate accesses. BTW, the ARM, like all goood processors, is little-endian . -- Alec Cawley Newbury Berks, UK