vu2oak@PINE.CIRCA.UFL.EDU ("GORUR") (02/15/90)
Has anyone heard of a company making C compilers for transputers,other than 3L and logical systems?If any one has used C-compilers made by either 3L or logical systems,can you give me some more info on that..any bugs..any drawbacks incompatibility with OCCAM code etc.. thanks arun Database research center University of Florida,Gainesville,FL
robertsj@ADMIN.OGI.EDU (John Roberts) (02/16/90)
Hi! I work at a place called Cogent Research and we build a self-hosted transputer- based workstation (plus compute server). We use the C and Fortran compiler formerly supplied by Penguin/Pentasoft that's now distributed by Unidot in Golden, Colorado. It grew out of work done at Cornell University on the old Floating Point System T-series machine and its the best implementation we've found (we have tweaked it here and there and rewritten portions for our own use). As with all other transputer compilers I've seen the real performance bottleneck is in the linker, the linker needs to compute all the prefix information for relocations and this is usually *slow*. At Cogent we finally gave up and wrote our own linker since all the other ones we came across were so slow. I'd bet ours is the fastest in the business now. So I'd suggest you time linking speeds of "hello, world" and a few larger programs when comparing toolsets. We used to use the Logical Systems toolset and it was pretty good, with one exception, it could not generate relocatable code (I'm not sure if this limitation has been overcome yet). You had to fix all programs to a specific address in memory. Needless to say, for our purposes, that of putting a real operating system on the chip, with multiple tasks going, that was an impossible limitation. That's why we jumped to Unidot's. Don't expect any service/support from Unidot though, the guy who vends it doesn't seem to believe in support. He'll tell you anything on the phone (a la "I'll fix it today and send it to you tomorrow), but he *never* comes through. At least Logical Systems support was extremely friendly and competant (and they *would* come through on promises). I don't have any info on 3L, haven't seen/used their stuff. If you have any more queries, just email them to me, or even phone me up and ask for "John in software". John Roberts robertsj@admin.ogi.edu ps In case you're interested, I'll enclose my standard speil on Cogent's system... If not, abort/terminate this message here. Oh, my phone number is (503)690-1450 (Cogent Research, Inc.) Here is a description of the Cogent Machine overall hardware. The Cogent Workstation consists of two Inmos T800 transputers, each with 4 Mbytes of RAM, a 90 MByte internal hard drive and an 800K floppy drive. The monitor is 1024 by 808 by 256 (8 bits per pixel). A workstation can be connected to one or more computer servers, we call them "Resource Servers." Resource Servers consist of a backplane with 16 slots. One slot is dedicated to a communication board to connect to other Resource Servers or workstations. The other 15 slots can hold processor boards. Each processor board contains 2 T800's again each with 4 MBytes of RAM. In addition to bus communication, there is a crossbar switch to connect links on any two transputers in the Resource Server. The idea is that short messages will go rapidly over the bus, and longer messages will go over the serial links. A Resource Server can have up to 30 processors with 120 Mbyte of RAM. This is in addition to a workstation's 2 processors and 8 Mbytes of RAM. It is also possible for multiple workstations to be connected to a single resource server, so users can share processors. Processors are allocated in a fashion similar to using "malloc" and "free" memory allocation in C. When a user aquires a processor, he or she owns it until it is explicitly relinquished (or until the user turns off their workstation). No other user has access to another's processors (this decision was made since the transputer does not have memory protection, this way no other user can corrupt your memory -- only you can corrupt your memory). Our operating system is called Qix, "pronounced Quicks", (our Workstation is called an "XTM Workstation"). It is highly compatible with the POSIX standard A host of utilities that are normally provided with *IX systems are provided with our system (such as grep, awk, sed, vi, emacs, diff, more, tar, compress, etc...). The underlying communication system implemented is a simplified and extended version of Yale Linda called "Kernel Linda". This is implemented at a very low level of our OS (for speed). A full Yale Linda implementation is in the works, however Kernel Linda also has some extensions not present in Yale Linda (such as multiple tuple spaces, necessary for our multitasking environment). It is possible to write parallel programs using Kernel Linda that use all the processors available to any one user (for instance a user with a workstation and a resource server could have up to 32 processors available for his program). We also have a very nice windowing package based on Sun's NeWS called "PIX". PIX is our implementation of NeWS (if you're not familiar with NeWS, its sort of an extension of Display Postscript). Languages currently available are C, C++ and Fortran. John Roberts robertsj@ogcadmin.ogi.edu "hanging out at Cogent Research, Inc. and the Oregon Graduate Center" For further info: Cogent Research, Inc. 1100 NW Compton Drive Beaverton, Oregon 97006 (503)690-1450
gdburns@TBAG.OSC.EDU (Greg Burns) (02/16/90)
The 89.1 Logical Systems Transputer Toolset does support relocatable code using almost exactly the same method as the Unidot compiler. Trollius has the same requirement here as Qix and I couldn't agree more with Robert's comments about Unidot versus Logical Systems service. LSTT is also cheaper, available in source, and has a development future that inspires confidence in OEMs and end-users alike. Since you mentioned putting a real operating system on a chip, what is the Qix policy on the old bad pointer crashes system transputer problem and what is the Qix policy on multiple users sharing a chip? --Greg
ccplumb@lion.waterloo.edu (Colin Plumb) (02/16/90)
In article <9002151831.AA11345@tbag.osc.edu> gdburns@TBAG.OSC.EDU (Greg Burns) writes: > Since you mentioned putting a real operating system on a chip, what > is the Qix policy on the old bad pointer crashes system transputer > problem and what is the Qix policy on multiple users sharing a chip? As John said, Qix allocates processors to users so you can isolate the effects of a crash. You can share processors if you really want to, although the calls have all changed since I was at Cogent and I can't tell you the details. The allocation is dynamic so you can grab all the chips for a few seconds of heavy grinding. If a chip crashes in a resource server, the bus controller (a dedicated T414 which manages the link switches) notices that it's not being sent heartbeat messages any more and reboots the offending chip. In a workstation, if the main processor crashes, there's not a lot anyone can do, but that's why the workstations have two processors: so you can run risky stuff on the slave, which the master can kick if it's down :-). -- -Colin
dsl@meiko.co.uk (02/19/90)
Transputer C compilers: The Helios C compiler is the recommended compiler for transputers running the Helios operating system. Helios C is a well established compiler which conforms to the ANSI proposals. Main features are: ANSI conformance; POSIX runtime libraries; extended preprocessor including #pragma, #ifdefined, etc; and extensive distributed programming capabilities through close integration with Helios. There is a multi-processor source level debugger to support Helios C. More than 500 copies of the Helios C compiler are in use worldwide on transputer systems. It is available in the USA from MIMD Systems (415) 595 7303, CSA (801) 374 2300, and Microway (508) 746 7341. For distributors in other countries please contact David Sykes at Distributed Software Ltd, 670 Aztec West, Bristol BS12 4SD, UK tel +44 (0)454 612777 fax +44 (0)454 618188.