🚀 go-pugleaf

In a recent posting Klaus Kusche typed:
>If someone has experience in getting large Unix C applications to run
>on transputers (or failed to do so), please post!
 
I'm a software engineer at Cogent Research in Beaverton, Oregon.  We build
a transputer-based workstation (yes, transputer-based, no I/O processor,
fully self-hosted machine) that connects to a backplane with transputer cards.
We've built systems with up to 32 transputers.
 
In general we found transputer toolsets to be weak, although much improved
as of late (especially the Logical Systems C compiler).  We internally
modified a compiler we purchased and maintain it.  Our operating system
is as Unix-compatible as is possible on a transputer (however you just
can't implement fork()  on a chip without memory management).
 
We've compiled and run much of the GNU code including gawk, sed, tar, make
(we found some nasty code in make where memory was freed, then used -- we
fixed that in our version), bison, flex, etc...  Since there isn't a code
generator for the transputer for gcc, we've not built it in its entirety,
however a preprocessor for Linda we have is based on gcc and that also
compiles and runs.  Its not uncommon on our system to download a program
from the net, xlisp for example, uudecode it, untar it, type "make", let
the program build, then run it.
 
There are always going to be incompatibilities when you're not running
full-up Unix though and due to the lack of a MMU you're never going to
see it on a transputer.  I've already mentioned the use of fork() or
the bad programming practice of freeing memory, then using it.  Both
of these things are present in codes we've ported.
 
I'd love to see a port of Maple to our box, but I've never seen the code.
It may do awful Unix dependent things.  Is it in the public domain?
On the other hand, our box has a fairly complete Unix run-time library
(for both C and the O/S).
 
There's no reason most large C program can't run on a transputer-based
platform, especially if the program in question was designed to be ported
to several different architectures in the first place, then, usually, the
code is well-constructed.  Toolsets for the transputer have been lacking,
but also have been getting better.
 
John Roberts
Cogent Research, Inc.
robertsj@admin.ogi.edu