Newsgroups: comp.sys.transputer From: tbjorkho@james.abo.fi (Tom Bj|rkholm AT) Subject: compiler summary Organization: Abo Akademi University, Finland Date: Mon, 4 Oct 1993 22:42:04 GMT Please send mail to: tbjorkho@ra.abo.fi if you find that any of the information below is outdated. I will be happy to update the information. SUMMARY OF TRANSPUTER COMPILER SURVEY The summary is in two parts: 1) A short list of available compilers 2) A description of the compilers (includes only those who have mailed me information). PART 1 - Available transputer Compilers Inmos Ltd, email: conor@inmos.co.uk 1000 Aztec West, Almondsbury, Bristol BS12 4SQ, UK, phone +44 454 616 616: occam 2 (many different versions, toolsets and TDS environment) C C++ Alsys Ltd, email: ats@alsys.co.uk, Alsys, Patridge House, Newton Road, Henley-on-Thames, RG9 1EN, United Kingdom, phone +44 491 579090, fax +44 491 571866: Ada Barry Cook, email: barry@cs.keele.ac.uk: Algol 68 PACT, email: info@pact.nl Foulkeslaan 87, 2625 RB Delft, The Netherlands, phone +31 15 616864, fax +31 15 610032: C Perihelion Software Ltd, email: nickc@perisl.uucp The Maltings, Charlton Rd, Shepton Mallet, Somerset, BA4 5QE, United Kingdom phone +44 749 344 203, fax +44 749 344 977: C Gesellshaft fuer Mathematik und Dataenverarbeitung, German national computer science research institute, Karlsruhe, email: vollmer@karlruhe.gmd.de Vincenz-Priessnitz-Strasse 1, D-7500 Karlsruhe 1, Federal Republic Germany, phone +49 721 66 22 14, fax +49 721 66 22 968: Modula-P Meiko: Fortran Prospero Software: Pascal Rowley Assosiates: Modula-2 The EXPERT Parallel Development System, developed and marketed jointly by PACT (see above) and ACE, provides: PACT Parallel C C++ (Summer 1994) ANSI C K&R C Fortran 77 Modula-2 Pascal 3L Ltd, email: iay@threel.co.uk Peel House, Ladywell, Livingston EH54 6AG, Scotland, UK, phone +44 506 41 59 59, fax +44 506 41 59 44: C C++ Fortran Pascal Strand: Strand 88 PART 2 - Description of the compilers. Includes only compilers that I have received information about. 2.1 INMOS occam 2 toolsets: From: conor@inmos.co.uk "Conor O'Neill" January 1992 From: conor@inmos.co.uk "Conor O'Neill" 6 Sep 1993 >1) General information > - language > - availability > - price for commercial and educational licences occam 2. Available now for cross-compiling to all current transputer variants such as T222, T400, T425, T801, T805, and all planned future variants such as the T9000. Currently supported hosts and product numbers are now 386pc/DOS: IMS D7305;Sun4/SunOS: IMS D4305; VAX/VMS: IMS D6305. > Do you also have native compilers? No, I'm afraid we don't. We don't have enough people to resource this. But there are various little projects going on at various Universities. We supply a source release under various restrictions, so that they can play at porting the compiler. But they can't sell it, or give it away. INMOS can't officially release a price, however the end user price is believed to be around $800/user (on PC & Sun, more on VAX), all sales are through distributors and the end user price is determined by them (including educational discount offers). >2) Handling of parallelism > - language designed especially for parallel computers, > language extensions or library calls? The language is specifically designed for the expression of concurrent algorithms; the parallelism and communication are part of the language, and therefore the compiler can check the usage of communications. The resulting programs can be executed either on a single processor or on a parallel computer. >3) Optimization of code > - Which optimization methods are used? Constant folding; Workspace allocation of frequently used variables at smaller offsets; Dead-code elimination; Peephole optimisation; Instruction scheduling; Constant cacheing; Inlining procedures. > - Will the ALU and the FPU run in parallel? Yes; the compiler overlaps addressing calculations with FPU operations. > - Is in-line code or procedure calls used for functions not > supported in hardware? Yes, a mixture is used; some are inserted in-line, and others are implemented via library calls. >4) Main target for the compiler > - Is the language/compiler especially designed for teaching > parallel programming? To a certain extent, yes. > - Is the language/compiler especially designed for floating point > calculations? Yes Well, to be honest, it's a bit of a silly question unless the language is FORTRAN. All (nearly all?) modern programming languages are designed to be general purpose. One of occam 2's original stated aims was to become the language that people used to describe numerical algorithms. At least it knows what an array is! (Obvious did at 'C'). (:-) >5) Time scheduling support > - The transputer can do time-slicing only on specific intructions > (j, lend, in, out). How does the compiler ensure that there are > enough time-slicing points in the code? The compiler ensures that either a 'j' or 'lend' instruction appears in every loop. > - Does the compiler supply a simple way to insert a time slicing > point, at a specific point in the program? There is a predefined procedure 'RESCHEDULE()' which can be inserted to force a rescheduling point. >6) Process communication > - How do the processes communicate? (channels, shared memory...) Channels. >7) Mixed language programming > - Is the binary/object file created compatible with object files > from other laguages? Yes, the object files can be mixed with those created by the INMOS ANSI C, and C++, toolsets. > - What kind of support for mixed language programming is offered? How to call ANSI C is documented in the user manuals. Also, occam can be called from C. > - Does the compiler support in-line assembly? Yes. All transputer instructions are available, as is symbolic access to occam variables, etc. >8) Debugging tools > - Are there any debugging tools available? INMOS supply a breakpointing and post-mortem debugger as part of the toolset, which works across multi-transputer networks. INMOS also supplies an INQUEST toolset (product numbers are 386pc/Windows: IMS D7300; Sun4/SunOS: IMS D4300). This contains an interactive windowing debugger which is hosted on the PC/Sun. It allows both post-mortem and interactive debugging, break-points, watch-points, single-stepping etc., source/assembly code viewing, variable examination, stack back-tracing, and a programmable command language. The INQUEST toolset also includes some performance analysis tools: an execution profiler gives a post-mortem statistical analysis of the total execution time used by each function; and a network utilisation monitor shows graphically when each processor in a network was busy and when it was idle. >9) Network booting > - How is the code distributed to the transputer network? We supply configuration tools which create a self-loading binary file which can simply be squirted down a transputer link; we also supply EPROM creation tools. In addition, a network of transputers can be booted from a ROM attached to a single transputer. > - Is there a configuration file? > If there is one, what syntax is used? Yes; the syntax is a slight variant of standard occam; extensions are used to describe the hardware network. The compiler/configurer can now automatically multiplex and through- route messages, so there is no longer a limit of 1 channel in each direction on each link. >10) T9000 > - Will there be a T9000 version of the compiler? When? There will be a T9000 version; it will be released at the same time as the T9000. >11) Host systems > - Wich host systems are supported? > - Wich host operating systems are supported? See above (Question 1) > - Is the porting to these operating systems done in house, > or by a third party? All done in house. > - How are the host system dependent parts documented? Documented as required in the user manuals. >12) Misc. > - List of known bugs > - List of satisfied customers Thousands of copies already sold. [ no bugs or satisfied customers mentioned ] 2.2 INMOS ANSI C From: conor@inmos.co.uk "Conor O'Neill" January 1992 From: stevec@inmos.co.uk "tephen Clarke" 3 Sep 1993 > 1) General information > - language > - availability > - price for commercial and educational licences > ANSI C. Available now for cross-compiling to all current transputer variants such as T222, T400, T425, T801, T805, and all planned future variants such as the T9000. Currently supported hosts and product numbers are now 386pc/DOS: IMS D7314; Sun4/SunOS: IMS D4314; VAX/VMS: IMS D6314. >I know that you a few years ago sold 3L C under the name of Inmos C. >I have understood that you have now written a completely own compiler. >Is this correct? Yes, exactly. Prices: INMOS can't officially release a price, however, the end user price is believed to be around $800/user (on PC & Sun, more on VAX), all sales are through distributors and the end user price is determined by them (including educational discount offers). > 2) Handling of parallelism > - language designed especially for parallel computers, > language extensions or library calls? Parallelism is handled by library calls. > > 3) Optimization of code > - Which optimization methods are used? Constant folding, workspace allocation of frequently used variables at smaller offsets, dead-code eliminattion, peephole optimisation, instruction scheduling, constant cacheing, jump to jump elimination and The latest release incorporates a globally optimising compiler (for 32-bit transputers) which performs the following optimisations in addition to those already mentioned: - redundant store elimination, - various flowgraph optimisations, such as branch-to-branch optimisation, and basic block merging, - local and global (ie. function-wide) common subexpression elimination, - loop-invariant code motion, - tail-call and tail-recursion optimisation, - workspace allocation using variable liveness analysis. > - Will the ALU and the FPU run in parallel? Yes. > - Is in-line code or procedure calls used for functions not > supported in hardware? The compiler will generate inline code for calls to library functions which map onto transputer instructions, such as BitCnt, BitRev, BlockMove, CrcByte/Word, channel i/o, Move2D, ProcGetPriority, ProcTime, provided that the targetted transputer has the appropriate instructions; otherwise library calls are used. > 4) Main target for the compiler > - Is the language/compiler especially designed for teaching > parallel programming? No. > - Is the language/compiler especially designed for floating > point calculations? No. > 5) Time scheduling support > - The transputer can do time-slicing only on specific intructions > (j, lend, in, out). How does the compiler ensure that there are > enough time-slicing points in the code? The compiler ensures that a 'j' instruction appears in every loop. > - Does the compiler supply a simple way to insert a time slicing > point, at a specific point in the program? No the compiler does not, though it is straightforward to define a RESCHEDULE macro which uses inline assembly language. > 6) Process communication > - How do the processes communicate? (channels, shared memory...) Library routines are provided for channel communication and semaphores. The compiler can inline calls to the channel communication library routines. Processes may also communicate using shared memory. > 7) Mixed language programming > - Is the binary/object file created compatible with object files > from other laguages? Yes, the object files can be mixed with those created by the INMOS occam and C++ toolsets. > - What kind of support for mixed language programming is offered? Occam can be called from C, C can be called from occam. C++ and C can be intermixed. > - Does the compiler support in-line assembly? Yes. All transputer instructions are available, as is symbolic access to C variables, jump tables may be constructed etc. > 8) Debugging tools > - Are there any debugging tools available? INMOS supply a breakpointing and post-mortem debugger as part of the toolset, which works across multi-transputer networks. INMOS also supplies an INQUEST toolset (product numbers are 386pc/Windows: IMS D7300; Sun4/SunOS: IMS D4300). This contains an interactive windowing debugger which is hosted on the PC/Sun. It allows both post-mortem and interactive debugging, break-points, watch-points, single-stepping etc., source/assembly code viewing, variable examination, stack back-tracing, and a programmable command language. The INQUEST toolset also includes some performance analysis tools: an execution profiler gives a post-mortem statistical analysis of the total execution time used by each function; and a network utilisation monitor shows graphically when each processor in a network was busy and when it was idle. > 9) Network booting > - How is the code distributed to the transputer network? We supply configuration tools which create a self-loading binary file which can simply be squirted down a transputer link; we also supply EPROM creation tools. In addition, a network of transputers can be booted from a ROM attached to a single transputer. > - Is there a configuration file? > If there is one, what syntax is used? Yes, a C-like syntax is used. > 10) T9000 > - Will there be a T9000 version of the compiler? When? There will be a T9000 version; it will be released at the same time as the T9000. > 11) Host systems > - Wich host systems are supported? > - Wich host operating systems are supported? See above (Question 1) > - Is the porting to these operating systems done in house, > or by a third party? In house. > - How are the host system dependent parts documented? Documented as required in the user manuals. The ANSI C language standard requires that a number of implementation-dependant characteristics are documented: these are collected in an appendix of the user manuals. > 12) Misc. > - List of known bugs > - List of satisfied customers The ANSI C compiler passes all of the Plum-Hall ANSI C Validation Suite, and has been officially certified by the British Standards Institute as being fully ANSI/ISO compatible. [ no satisfied customers listed ] 2.3 INMOS C++ From: IN%"nigel@inmos.co.uk" "Nigel Holder" > 1) General information > - language > - availability > - price for commercial and educational licences > C++ based on AT&T cfront for C++ version 2.0. Enhanced and ported by Glockenspiel for INMOS. Translates C++ code into C code for compilation via the INMOS ANSI C compiler. Available now for cross-compiling to all current transputer variants such as T222, T400, T425, T801, T805, and all planned future variants such as the T9000. In addition, a C++ toolset may also target for its own host. Currently supported hosts and product numbers PC/AT-DOS: IMS D7217; VAX-VMS: IMS D6217; Sun3-SunOS: IMS D5217; Sun4-SunOS: IMS D4217. Prices: INMOS can't officially release a price, however, the end user price depends on the host. All sales are through distributors and the end user price is determined by them (including educational discount offers). > 2) Handling of parallelism > - language designed especially for parallel computers, > language extensions or library calls? Parallelism is handled by library calls provided with the ANSI C toolset. You may execute functions in parallel; these may be member functions of a class. > 3) Optimization of code > - Which optimization methods are used? Translated code compiled via ANSI C Compiler so it is the same as the ANSI C compiler (to a certain extent). > - Will the ALU and the FPU run in parallel? Yes. > - Is in-line code or procedure calls used for functions not > supported in hardware? Mostly routine calls; some standard ANSI functions such as memcpy() are handled by inline code. > 4) Main target for the compiler > - Is the language/compiler especially designed for teaching > parallel programming? No. > - Is the language/compiler especially designed for floating > point calculations? No. > 5) Time scheduling support > - The transputer can do time-slicing only on specific intructions > (j, lend, in, out). How does the compiler ensure that there are > enough time-slicing points in the code? The ANSI C compiler ensures that a 'j' instruction appears in every loop. > - Does the compiler supply a simple way to insert a time slicing > point, at a specific point in the program? No the ANSI C compiler does not, though it is straightforward to define a RESCHEDULE macro which uses inline assembly language. > 6) Process communication > - How do the processes communicate? (channels, shared memory...) ANSI C Library routines are provided for channel communication and semaphores. Processes may also communicate using shared memory. > 7) Mixed language programming > - Is the binary/object file created compatible with object files > from other laguages? Yes, the object files can be mixed with those created by the INMOS occam and ANSI C toolsets. > - What kind of support for mixed language programming is offered? C++ and C can be intermixed. Occam can be called from C, C can be called from occam. > - Does the compiler support in-line assembly? The C++ translator does not (yet) but the ANSI C compiler does. > 8) Debugging tools > - Are there any debugging tools available? INMOS supply a breakpointing and post-mortem debugger as part of the toolset, which works across multi-transputer networks. > 9) Network booting > - How is the code distributed to the transputer network? We supply configuration tools which create a self-loading binary file which can simply be squirted down a transputer link; we also supply EPROM creation tools. In addition, a network of transputers can be booted from a ROM attached to a single transputer. > - Is there a configuration file? > If there is one, what syntax is used? Yes, a C-like syntax is used. > 10) T9000 > - Will there be a T9000 version of the compiler? When? There will be a T9000 version; the intention is to release it at the same time as the T9000. Most likely to be for C++ version 3.0 > 11) Host systems > - Wich host systems are supported? > - Wich host operating systems are supported? See above (Question 1) > - Is the porting to these operating systems done in house, > or by a third party? In house. > - How are the host system dependent parts documented? Documented as required in the user manuals. > 12) Misc. > - List of known bugs > - List of satisfied customers Hundreds of copies already sold for the transputer. Cannot comment on how many Glockenspiel have sold for all of their supported hosts. [ none listed ] 2.4 Alsys ADA From: IN%"ats@alsys.co.uk" (Alun Tlusty-Shen) Thank you for the opportunity to take part in your survey. The Alsys Ada Toolset is described in several places in the Inmos iq Systems Databook. More recently we have just released new versions of the product compatible with the revised versions of the Inmos Toolset. This version also includes support for AdaMap. AdaMap automatically generates the necessary occam harness code for multiple programs running on one or more transputers. In addition AdaMap supports debugging of multiple arbitrary transputers in the network. Alsys Ada products are available worldwide and I am sure the relevant offices would be delighted to provide information to specific customer requirements. I enclose a list of the offices and the territories that they cover. From: IN%"rod@minster.york.ac.uk" Rod Chapman Hi there, I saw your note asking for info. on transputer compilers - I know quite a bit about the Ada compiler for the transputer, since I worked on it a bit when I was a student. In response to your 12 questions 1) language - Ada availability - now from Alsys Ltd. of the UK or any other Alsys subsidiary. Two version are available: self-hosted on a T8 board or cross-compile from a VAX. price: don't really know...[ deleted stuff [ don't quote me on that! 2) parallelism Ada is a parallel language. All tasking features are fully implemented. 3) Optimization. The compiler does both lots of optimization including high level stuff like loop invariants and code motion, low level stuff like common subexpressions, and also peephole optimizations. I don't think much effort is given to getting the ALU and FPU to run in parallel. Inlining of subprograms is supported. 4) Target. Mainly for pro. real-time development. Not really a teaching tool. It was developed in order to open up the military market for the transputer. 5) Scheduling. I don't think the compiler makes any special effort to generated scheduling instructions, but enough seem to get generated anyway. Time-slicing of tasks in an Ada program can have controllable time-slicing down to a resultion of 1ms. 6) Communication. Ada tasks talk to each other via rendezvous or shared variables. Ada programs can also use OCCAM channels via a standard library package. 7) Mixed language programming. Object file format is standard INMOS format. The compiler supports interfaces to C, assembler and OCCAM. Ada programs can be called from OCCAM ( they look like a single procedure call ) 8) Debugging. Yes...The Alsys debugger AdaProbe is available at extra cost. It debugs all Ada features at source level including tasking and generics. It handles all transputer models including all T8s, T4s and even T2s. It runs on either VAXes (remotely) or directly on the target processor. 9) Network booting. Code is booted using the standard INMOS toolset. 10) T9000. Last I heard, no decision had been taken about a T9000 version, but the T8 code will run unmodified on a T9000. 11) Host systems: Two are supported i) T800 with 4Meg or more memory hosted on a IBM PC (MS-DOS) or compatible running iserver. ii) VAX running VMS (cross-compiler.) The above information is very "unofficial" and I can't promise it is up to date or fully accurate. 2.5 Barry's ALGOL 68 From: IN%"barry@cs.keele.ac.uk" "B.M. Cook" I have an Algol68 compiler for the transputer, it is still in development but is currently quite usable, missing features are expected soon. [Just in case you remember the reputation of Algol68 as a slow language let me point out that I'm getting about 3 times the speed of a microvax on my PC! (e.g. compilation at around 2000 lines per minute).] > 1) General information > - language Algol68 (RS version, i.e. 1975 revision with separate compilation / libraries /data hiding, etc.) The compiler front-end is the same as used in commercial compilers for e.g. VAX/VMS, ICL2900 - bahaviour is identical to that on a VAX (I've not tested against others). > - availability Test versions only at this time (December 1991). > - price for commercial and educational licences To be determined, most probably copying / handling charges only. > > 2) Handling of parallelism > - language designed especially for parallel computers, > language extensions or library calls? Algol68 has parallelism designed in, not yet implemented. > > 3) Optimization of code > - Which optimization methods are used? Peephole. > - Will the ALU and the FPU run in parallel? Yes. > - Is in-line code or procedure calls used for functions not > supported in hardware? Both, mostly in-line. > > 4) Main target for the compiler > - Is the language/compiler especially designed for teaching > parallel programming? No. > - Is the language/compiler especially designed for floating > point calculations? Yes, currently needs a T800 for floating point. > - Is the compiler written just to supply a language for the > transputer? Yes. > > 5) Time scheduling support > - The transputer can do time-slicing only on specific intructions > (j, lend, in, out). How does the compiler ensure that there are > enough time-slicing points in the code? Luck - the necessary instructions appear fairly often. All my loops use j or lend. Maybe there's some design rather than all luck here! I don't explicity count the number of instructions without a time-slice point and insert extras - although it wouldn't be difficult, all the necessary code is in the optimiser (to prevent me leaving anything in a register through a time-slice point). > - Does the compiler supply a simple way to insert a time slicing > point, at a specific point in the program? Not currently, it could be trivially added. > > 6) Process communication > - How do the processes communicate? (channels, shared memory...) To be determined (parallelism not yet implemented), almost certainly channels. > > 7) Mixed language programming > - Is the binary/object file created compatible with object files > from other laguages? No, the separately compiled modules have more options than normally allowed. > - What kind of support for mixed language programming is offered? None, at present - an interface is possible but is not a high priority in my list of jobs. > - Does the compiler support in-line assembly? It used to, I've turned it off (commented it out) as unsafe - such instances of need for m/c are provided as extensions to the language. > > 8) Debugging tools > - Are there any debugging tools available? Essentially, no - only a stack traceback on error. > > 9) Network booting > - How is the code distributed to the transputer network? Boot via ISERVER. > - Is there a configuration file? No. > If there is one, what syntax is used? > > 10) T9000 > - Will there be a T9000 version of the compiler? When? If the T9000 is as compatible as promised, immediately. I guess this is quite a way into the future, the first job is to get parallelism running properly on the T800 and then I'd like to get my hands on a T9000 (who wouldn't!) > > 11) Host systems > - Wich host systems are supported? Any which will run ISERVER - I'm currently using Sun's and PC's. > - Wich host operating systems are supported? Any which will run ISERVER - I'm currently using Unix and DOS. > - Is the porting to these operating systems done in house, > or by a third party? By whoever provides ISERVER. > - How are the host system dependent parts documented? In the ISERVER documentation. > > 12) Misc. > - List of known bugs Many not-yet-implemented features. > - List of satisfied customers Only myself and R.M.A.Peel at Surrey University (I've not yet released code to anyone else). 2.6 PACT Parallel C From: rob@pact.nl 03-OCT-1993 > 1) General information > - language > - availability > - price for commercial and educational licenses The PACT Parallel C compiler is an ANSI Standard C compiler with standard-conforming language extensions for parallel programming. Single-user list prices of the native version are USD 1200 and USD 1500 for PC and Sun platforms, resp., and of the cross version USD 1500 and USD 2250 for PC and Sun4, resp. Educational discount is 25%. Multi-user licenses are available. > 2) Handling of parallelism > - language designed especially for parallel computers, > language extensions or library calls? We have extended ANSI C with language constructs to support the creation of processes, as well as interprocess communication. We provide par and alt constructs, which can be combined with arbitrary replicators, and a channel data type modifier. This is an example, taken from PACT's sales material: par { int |ch; /* channel of int */ |ch = 10; /* send 10 */ printf("%d\n",|ch); /* report */ } In addition, for those porting code from other transputer compilers or wishing to write code that's portable to other transputer C compilers, we provide a library of parallel processing functions that is compatible with the LSC and ICC libraries ("Jeff Mock" library). > 3) Optimization of code > - Which optimization methods are used? > - Will the ALU and the FPU run in parallel? > - Is in-line code or procedure calls used for functions not > supported in hardware? The compiler builds a Directed Acyclic Graph (DAG) for every basic block in the source file. A basic block may be as small as a single statement, but more often comprises a number of statements. Optimizations performed on these basic blocks include common subexpression elimination, constant folding, dead code elimination, dead assignment elimination, strength reduction, intrinsic function inlining. Transputer code selection for a basic block results in good use of the transputer's core and FP register stacks (much better than codegen using an expression tree). The peephole optimizer includes a code scheduler that overlays core and FPU operations as much as possible. Functions not supported in hardware are mostly done with inline code, unless the amount of code required is so much that it is advantageous to use a function call (smaller programs result in smaller spans and thus run faster). The linker is capable of global span optimization, which often means a 10% speedup as compared to local span optimization done by the assembler only. > 4) Main target for the compiler > - Is the language/compiler especially designed for teaching > parallel programming? > - Is the language/compiler especially designed for floating > point calculations? > - Is the compiler written just to supply a language for the > transputer? The compiler was especially designed to offer a good platform for those wishing to program in C on the transputer: hence the parallel constructs, the high performance and the ISO/ANSI Standard conformance. Because of the language constructs, the compiler is currently used in various parallel programming courses at Universities in The Netherlands and the U.S.A., but also by companies and institutes interested in high quality, high performance of fine grain parallel programs. > 5) Time scheduling support > - The transputer can do time-slicing only on specific intructions > (j, lend, in, out). How does the compiler ensure that there are > enough time-slicing points in the code? > - Does the compiler supply a simple way to insert a time slicing > point, at a specific point in the program? Every loop created with the usual C constructs (do-while, while, for) is guaranteed to contain at least one descheduling point. Additionally, a macro is defined in a header file that simply inserts such a descheduling point ("j 0") wherever the macro is placed. > 6) Process communication > - How do the processes communicate? (channels, shared memory...) Processes may communicate through channels and shared memory. Channels are inline transputer channels, synchronized and all. Threads started by a single process (with the par construct or comparable function calls) all share the same global data space as well as the stack space of their parent processes (normal C scope rules). This means shared memory can also be used to communicate. Of course, semaphores are supported to ensure the correctness of shared memory usage. > 7) Mixed language programming > - Is the binary/object file created compatible with object files > from other laguages? > - What kind of support for mixed language programming is offered? > - Does the compiler support in-line assembly? TCOFF is used for object files and linked units. However, we've had to extend TCOFF slightly for our purposes so mixing of PACT Parallel C object files with other TCOFF object files is restricted. The compiler supports a function-like syntax for in-line assembly, allowing C and assembly expressions to be mixed easily. In addition it is also possible to write assembly files in a format that is mostly compatible with the Inmos assembly language definition, and mix these with C object files. > 8) Debugging tools > - Are there any debugging tools available? A simple single-processor debugger is available, allowing post-mortem memory inspection and disassembly. > 9) Network booting > - How is the code distributed to the transputer network? > - Is there a configuration file? > If there is one, what syntax is used? The executable file is fully self-contained, and need only be sent to the transputer link. Network booters will run on all transputers and will distribute code to the processors as specified. Alternatively, a floodfill configurer can be used to find all available processors and boot them with a slave program (which may or may not be identical to the master program on the root processor). The PACT configurer is compatible with the Inmos C toolset configurer. It allows the hardware and software configuration to be specified, as well as the mapping between the two (which processes to place on which processors). The configurer automatically introduces virtual channels where necessary, allowing any two tasks anywhere in the network to communicate with eachother without restrictions. About the PACT configurer: it uses a syntax like this: T414(memory=512K) transp; connect transp.link[0] to host; process (stacksize=1K, heapsize=0K, priority=LOW, interface (input frommain, output tomain)) calc; process (stacksize=4K, heapsize=300K, priority=LOW, interface (output tocalc, input fromcalc)) main; connect calc.tomain to main.fromcalc; connect calc.frommain to main.tocalc; place calc on transp; place main on transp; use "calc.lku" for calc; use "main.lku" for main; You can have loop- and if-constructs in the configuration file: rep i=0 to 18 { connect .... if (i % 1 == 0) place .... } > 10) T9000 > - Will there be a T9000 version of the compiler? When? Yes, as soon as the T9000 is available we're committed to have a T9000 compiler available. There will be an upgrade plan for existing users. > 11) Host systems > - Wich host systems are supported? > - Wich host operating systems are supported? > - Is the porting to these operating systems done in house, > or by a third party? > - How are the host system dependent parts documented? Native and cross compilers for PC (MS-DOS) and Sun4 (SunOS) are available. The compiler comes with the host server sources, and documentation on how to compile and link these for a particular transputer interface, so any transputer hardware can be used. > 12) Misc. > - List of known bugs > - List of satisfied customers The compiler is validated with the ACE/SCO SuperTest (TM) ANSI C validation suite, as well as a home-grown collection of sequential and parallel programs. All bugs reported by users of the 92.1 release have been fixed in the 93.1 release. In the past year and a half, we have sold compilers to a large number of companies and universities all over the world. All customers appear to be satisfied, since not a single one excersized his/her right to return the compiler within 30 days for a full refund. 2.7 HELIOS C From: IN%"nickc%perisl.uucp@FUNET.FI" This information is for Perihelion's C compiler, usually supplied as part of the Helios Operating System, but available seperately upon request. > 1) General information > - language C > - availability worldwide via D.S.L. or local distributers > - price for commercial and educational licences 600 pounds sterling, (no education discount) > 2) Handling of parallelism > - language designed especially for parallel computers, > language extensions or library calls? Library calls > 3) Optimization of code > - Which optimization methods are used? Peepholing > - Will the ALU and the FPU run in parallel? No > - Is in-line code or procedure calls used for functions not > supported in hardware? Yes, (for a few functions, eg bytblt()), but No for most functions (eg software floating point operations). > 4) Main target for the compiler > - Is the language/compiler especially designed for teaching > parallel programming? No > - Is the language/compiler especially designed for floating point > calculations? No > - Is the compiler written just to supply a language for the > transputer? Yes >5) Time scheduling support > - The transputer can do time-slicing only on specific intructions > (j, lend, in, out). How does the compiler ensure that there are > enough time-slicing points in the code? No > - Does the compiler supply a simple way to insert a time slicing > point, at a specific point in the program? No >6) Process communication > - How do the processes communicate? (channels, shared memory...) Channels, (but you could use shared memory if you really wanted too ...) >7) Mixed language programming > - Is the binary/object file created compatible with object files > from other laguages? Yes D.S.L. also distribute Meiko Fortran, Rowley Modula-2 and Propero Pascal. All of these compile and run under Helios, and the programs produced can be simultaneously with programs from other langugaes. In additional all of the languages can access the run time libraries (written in C), and I suspect, (although I do not know for sure) that cross language procedure calls are possible. > - What kind of support for mixed language programming is offered? Defined interface to the linker to allow multiple foreign object code chunks to be incorperated into a program. Defined calling standards to allow cross-language function calling. Defined interface to the porgram loader to allow simultaneous execution of multiple foreign programs. > - Does the compiler support in-line assembly? No, but is does support in-line op-codes >8) Debugging tools > - Are there any debugging tools available? Yes, a symbolic debugger with a X interface is available >9) Network booting > - How is the code distributed to the transputer network? Code is loaded by the Helios operating system which is already running on the transputer network. > - Is there a configuration file? > If there is one, what syntax is used? Yes, the file is an ASCII file (which can be compiled to a binary format for faster execution), which describes the connectivity of the program (called a task), and the resources it uses. The concept is based on the CSP model. (Communicating Sequential Processes, developed by Professor Hoare at Oxford University). There are two parts to this. The first is a textual description of the hardware netwoork, (or a binary compiled version). This is loaded by Helios during its boot up sequence, and it is used to determine the network topology. (Helios does not automatically configure itself to yhe network - it has to be told what is where). Below is an example of a configuration file for a small network of 8 processors :- subnet /Cluster { Reset { driver; ~00; tram_ra.d } processor 00 { ~IO, , ~01, ~02; } processor 01 { ~00, , , ~03; run -e /helios/lib/fs fs scsi; } processor 02 { , ~00, ~03, ~04; run /helios/lib/lock; } processor 03 { ~02, ~01, , ~05; } processor 04 { , ~02, ~05, ~06; } processor 05 { ~04, ~03, , ~07; } processor 06 { , ~04, ~07, ; } processor 07 { ~06, ~05, , ; } processor IO { ~00; IO } } Amoungst other things, this file desribes how to reset the network, names all of the processors, describes the interconnections between the processors, and specifies which programs should be run on which processors, during the startup sequence. The second part of the configuration system is another file which describes how a group of programs should be mapped onto the hardware. The program group (known as a task force), can be made up of programs in any language. The programs are assumed to communicate via the C library functions fread() and fwrite(), (although it is possible to use POSIX functions, or low level system calls if desired). The configuration file is written in a language called CDL (Component Description Language). This is the language that is based upon the CSP model. It does not have conditional statements, but it does have a kind of looping construct in the form of replicators. This is a syntax that allows a part of the configuration file to repeated a given number of times. This allows the construction of pipelines, farms, grids, hypercubes and so on. The language is quite complex, so I would recommened obtaining a copy of "The Helios Parallel Operating System", published by Prentice Hall, (author Perihelion Software Ltd), ISBN 0-13-381237-5, for a proper description. Here is a very simple example of the CDL language: component master { memory 500000; } master ( <> slave, <> slave, <> slave, <> slave) This says that the task force consists of two programs, one called master which requires a processor with a minimum of 500000 bytes of memory free, and one called slave. The master program wants to be able to have bidirectional communications with four seperate copies of the slave program, (ie a process farm). The Helios system will take this CDL description together with the hardware description and its knowledge of the current state of the transputer network and attempt to fulfill the requirements to the best of its ability. Helios will automatically set up the communication channels between the process, and it will handle any routining necessary. Any and all processes can perform screen I/O, although if multiple processes are going to be performing simultaneous I/O they should be aware that their output could be interleaved on a line by line basis. >10) T9000 > - Will there be a T9000 version of the compiler? When? Yes, Who knows ! (Well, when the T9000 appears, the compiler will be about 3 months behind). >11) Host systems > - Which host systems are supported? PC, SUN, SM90 (Telmat's UNIX box), Meiko Computing Surface, > - Which host operating systems are supported? UNIX, MS-DOS, MS-WINDOWS > - Is the porting to these operating systems done in house, > or by a third party? Both Perihelion Software has ported Helios C to the Helios Operating system, and this is the only one that is officially supported. The same compiler technology is used by a company called Norcroft who have produced versions of the compiler for the 68000 series, the SPARC chip, the Acorn ARM chip, the CLIPPER chip, and the MIPS chip. The Acorn ARM compiler is the compiler provided by Acorn for their Archimedes series of workstations. In addition Perihelion Software have ported the compiler to the Intel i860 and the Texas TMS320C40 chips, but neither of these are officially supported (yet). Finally the transputer compiler has itself been ported to run under UNIX on SUNs (series 3 and 4), HP (series 800 and 700), and DEC (series 5000). > - How are the host system dependent parts documented? Technical notes >12) Misc. > - List of known bugs None (honest!) > - List of satisfied customers Far too many to list here :-) [ none listed ] I hope this information is of use to you. If want more commercial orientated information, may I recommend that you contact D.S.L. directly (telephone 010 749 344345, fax 010 749 344 977). 2.8 GMD Modula-P From: vollmer@karlsruhe.gmd.de At the GMD (Gesellshaft fuer Mathematik und Datenverarbeitung, german national computer science research intitute), research group in Karlsruhe, a parallel language (called Modula-P) and a compiler for the T800 Transputer has been developed. Modula-P is a superset of Modula-2, enriched with parallel features of CSP/occam. The compiler produces native T800 code, and the programs run on a T800 network. The compiler is a cross compiler, written itself in Modula-2. The MOCKA-P system is based on GMD's Modula 2 system MOCKA (MOdula 2 Compiler KArlsruhe). Language: Modula-P Extension of Modula-2 with CSP/occam constructs: CHANNEL OF .., PAR .. END, ALT .. END, TIMER, replication, local and global processes. At each point in a process running, an other process may be started in a PAR statement. These processes can be placed in the network automatically or by user specified directives. Information about the topology may be derived at runtime through library calls. Messages are passed transparently between all processes in the network, i.e. no routing information must be specified by the programmer. Price: 250 US$ (educational) / 2000 US$ (industrial) No special optimization is performed, but the ALU and FPU will run in parallel. The main target with the compiler is to supply a language for the transputer. The compiler does not insert additional time slice point, but this can be done by compiler pragmas. Currently the simplest way to include a time slice point, is to do a timer input with a very small delay. The processes communicate with: - Sychronous typed channels - local processes can use shared variables. - semaphores. The system uses its own assembler and linker. Assembler language routines may be called from Modula-P. There is no in line assembler. The system comprises a graphical, interactive runtime debugger. The network is booted from the the host computer according to a configuration file. There is no operating system on the tranputers, a small and fast kernel (MOPS) support the communication between processes running on different transputers. Calls to MOPS are inserted by the compiler. Modula-P programs may access the operating system of the host (i.g. file I/O ...) by procedure calls to the Modula-P system library. Host dependencies are contained in one Modula-P module, and documented there. There are no outdoor customers. Thank you all who have sent me information. -- Tom Bjorkholm Process Design Laboratory Phone: +358 21 654 863 Department of Chemical Engineering Fax: +358 21 654 479 Abo Akademi University Internet: tbjorkho@ra.abo.fi Biskopsgatan 8 or: tbjorkholm@finabo.abo.fi SF-20500 Abo Bitnet: TBJORKHOLM@FINABO FINLAND Nordunet: ABOVAX::TBJORKHOLM