K312240@AEARN.BITNET (Klaus Kusche) (02/28/90)
Dear Mailing List:
First of all, up to now I didn't receive any response to my problems
concerning the EXPRESS graphic configuration tool. I can't believe
that nobody out there is using it! (Or am I the only one having that
Problem?)
Secondly, Ariel J Frank posted/will post a lot of transputer
equipment questions. Here are my *very personal* opinions:
About Parsytec: I just don't like that company. First of all, my
experiences when requesting info's from them were quite bad up to now,
and secondly, why do they refuse to be compatible with the rest of the
transputer world? I have the feeling that they just want to force you
to buy their software: Their hardware is just different enough from the
rest of the world that Inmos-compatible software will not run unchanged,
but can be adapted with a few bytes patch (just Parsytec knows how).
Also, their software releases are usually back a little bit for that
reason...
About memory size:
You're talking about 1 MB per node. I would initially buy 2 or 4, and
make sure that upgrading to 8 is possible (you mentioned Lisp - prepare
for even more). Remember: No paging, everything has to fit into real RAM
(and the compilers or Helios all like to have lots of memory).
At least for the root board, I would say 4 is the absolute minimum, for
the others, it depends on your application and the system software you
use.
About the QBUS: Caplin Cybernetics has such an interface (Inmos
compatible), Parsytec will have one (for Parsytec boards only).
Caplin has Helios drivers for VMS, I don't know about Ultrix.
However, writing drivers for VAX-based boards (or porting existing
PC or Unix drivers) is surely nontrivial.
About PC-based Unix hosts: I know that some people run transputer
software in the DOS window, and I know that some have written
Unix device drivers for PC transputer boards (for iserver and LS C).
All this refers to Interactive Unix, not SCO Xenix.
All languages by Inmos, 3L and LS (and maybe others) come with host
server sources (in C), so it can be done in principle.
However, ready-to-run Unix drivers are usually *not* included.
(I prefer DOS...)
About TDS versus Toolset: Go with the toolset:
* It is much easier to port Toolset's iserver than TDS's serverxx
to a new host.
* It is easier to mix Occam with non-Occam code with the Toolset.
* With the Toolset, you may use your favourite host editor (and other
users may use the transputer board in the meantime if you are on a
multiuser machine), with TDS, you are forced to use the fold editor.
About C:
If you want to have combined C/Occam programs, you have to go with
Inmos C. For Express, I would use LS C (they support both 3L C and
LS C, but I think LS C has the longer tradition with Express).
I've never heard any experiences with Parsec's Par.C (all who have:
please post!!!), but the pre-releases were said to generate awfully
slow code compared with the competition. Moreover, currently most ANSI
extensions are not yet there I think.
About Express:
It can be done with some hackery, but both Parsytec and Parasoft
officially confirm that Express currently will *not* run on Parsytec
hardware.
About MicroWay:
You get what you pay for, and the MicroWay boards are rather cheap...
There are definitely PC board companies which I would trust more with
respect to quality.
However, Helios should run on them.
About Link Switches:
Make sure you really need them before you buy them:
* They are just another thing to program and to worry about.
* There is no agreed standard for systems with link switches.
* Some pieces of software don't like them:
+ Worms (network topology investiators) get sometimes angry if
they hit a link connected to the C004 configuration input.
+ Some software always resets the system when booting an application.
This will also reset the switches, so you boot a no-topology
configuration. The same might happen for debuggers asserting
analyze: Suddenly the link configuration is gone...
About Common Lisp:
No product known. Inform me please if such a thing shows up!
About Trollius:
It comes with sources, and you will have to adapt it by yourself for
your transputer hardware and host.
Currently, it should run with any Unix host, DOS is in preparation
at Cornell.
Again, I believe not having Parsytec hardware will make your life
much easier.
About GNU C:
Has been done as an academic project as far as I know, but is not (yet)
available to the public.
To sum up:
Buy a big 386 PC and some 100% Inmos B004 compatible transputer
boards (B004-compatible refers to the host interface and the way
error/reset/analyze is handled). Check PVR's list of companies!!!
This will give you:
* A minimum-trouble start (with DOS).
* The widest choice of ready-to-run software.
* At least 80 % of the speed/fun/comfort provided by highly-specialized
workstation-based systems.
* A lot of saved money (compared to workstations).
Things to add later (if you know in which direction and with which
software you will go):
* Link switches (better start with cables).
* Unix host drivers.
* Faster (DMA- or FIFO-based) AT bus link interfaces.
PC-based transputer systems are an open market. Anything else will
most likely restrict your future hardware and software choice to a
single company, and will cost more (however, if you like Unix, have
*a lot* of money, want a highly sophisticated programming environment,
and know for sure that you will never need any software except the one
offered for that particular system, you should probably consider Meiko's
Sun solutions or something similar).
I hope that is of help...
************************************************************************
* Klaus Kusche *
* Research Institute for Symbolic Computation *
* Johannes Kepler University Tel: +43 7236 3231 67 *
* A-4040 Linz Telex: (Austria) 22323 uni li a *
* Austria (Europe) Fax: +43 7236 3231 30 *
* *
* Bitnet: K312240@AEARN *
* Arpa/CS/Internet: K312240%AEARN.BITNET@CUNYVM.CUNY.EDU *
* UUCP: mcvax!aearn.bitnet!K312240 *
* Janet: k312240@earn.aearn or k312240%aearn@earn-relay *
************************************************************************ENGLE@A.ISI.EDU (03/01/90)
I thought I might toss in some replies to Klaus Kusche's opinions. > About the QBUS: ...Parsytec will have one (for Parsytec boards only). > ... I don't know about Ultrix. We've been using the Parsytec QBUS board with a MicroVAX running Ultrix for our Helios work. We've done a port of the Helios Server program so that you can access Helios from the VAX and also through sockets so that programs can use the transputers as a resource. This is not an official product as yet, but we expect that it will become available soon. > About Parsytec: ...why do they refuse to be compatible with the rest > of the transputer world? I have the feeling that they just want to force > you to buy their software: Their hardware is just different enough from the > rest of the world that Inmos-compatible software will not run unchanged, > but can be adapted with a few bytes patch (just Parsytec knows how). > Also, their software releases are usually back a little bit for that > reason... We have a few Parsytec boards in house and have not had any software compatibility problems at all. We only run Helios, but its not a special copy of Helios from Parsytec or anything. One possible reason for their lack of compatibility is that I think Parsytec is looking beyond the P.C. add-in market. They are striving to become (and are becoming) a super- computer company. I suspect that in a large system (64 to 256 nodes and beyond) things like differential links become relevant. It also becomes very useful to be able to reset an individual transputer, particularly in multiple user configurations. All of the Parsytec boards that we have, including the QBUS board, have some provision to get at least one link to be Inmos compatible. We currently have a system in-house that uses the Parsytec QBUS board on the MicroVAX which is connected to a series of MicroWay boards in another chassis. The transputers are running Helios and the MicroVAX is running Ultrix. We got this configuration running after considerable work getting the Parsytec board's links to interface to the MicroWay links (which are standard), but in the end it was a documentation failure -- they just hadn't documented all there was to know about getting the links to run Inmos style, and our engineer was curious enough to wonder why a set of resistors were socketed. > About MicroWay: > You get what you pay for, and the MicroWay boards are rather cheap... > There are definitely PC board companies which I would trust more with > respect to quality. We are also running on MicroWay boards and have had no trouble whatsoever. In fact, one of our engineers has said that on an oscilloscope the link signals are much cleaner than some of the other boards he's seen. > However, Helios should run on them [the Microway boards]. It does. > About GNU C: > Has been done as an academic project as far as I know, but is not (yet) > available to the public. Who's doing this? Late last year I inquired about GNU C and didn't find anyone doing it. The main stumbling block is that GNU C's code generation is for register based machines. > PC-based transputer systems are an open market. Anything else will > most likely restrict your future hardware and software choice to a > single company, and will cost more (however, if you like Unix, have > *a lot* of money, want a highly sophisticated programming environment, > and know for sure that you will never need any software except the one > offered for that particular system, you should probably consider Meiko's > Sun solutions or something similar). A cheap(er) trick is to use a Sun 386i, which has a PC bus. This gives you UNIX and the networking environment without the extra price. The risk here is whether Sun will continue to support anything that doesn't have a SPARC chip in it. I agree that you should evaluate how well the various vendors interconnect, perhaps the group on the net could help fill out that matrix. I'll be happy to collect responses on that and to report the results to the net. Our view has been that as long as we can get a single transputer board for the particular bus, we can run links out to a PC chassis with a passive backplane full of 'puters. We have only tested this philosophy out with the above mentioned system...so at N = 1, our theory stands. But it seems that the transputer is so highly integrated that its really a pain in the neck to make the thing incompatible with other systems. Steven W. Engle MIMD Systems, Inc.