raghu@osc.edu (Raghu Machiraju) (10/08/90)
Has there been any attempt to port the AT&T translator to the transputer. If anybody has done so or is aware of such an effort would he/she be kind enough to share his/her experiences . More specifically I am interested in using the Logical Sytems C compiler for the port . Raghu
saustin@bbn.com (Steve Austin) (10/08/90)
raghu@osc.edu (Raghu Machiraju) writes: >Has there been any attempt to port the AT&T translator to the transputer. >If anybody has done so or is aware of such an effort would he/she be kind >enough to share his/her experiences . More specifically I am interested in >using the Logical Sytems C compiler for the port . I haven't ported AT&T's translator to RUN on a transputer, but it is trivially easy to get C++ code compiled FOR a transputer - or anything else really - if you have a C compiler for the target machine. The program 'CC' is just a shell script which takes the C++ program, runs it through the pre-processor, runs the output of this through cfront and then compiles the resulting C code with the standard compiler. It is easy to divert the last step (compiling with the default cc) and then compile with the cross-compiler. If you don't want to mess around with the shell script environment variables, you can yse the -Fc switch to get C code produced from the standard output of CC, redirect this to a temporary file and compile this. I have also got this to work when the C++ and C compilers run on different machines by using some "rsh" hacks. There are some minor difficulies to be overcome. 1. "munch" may not work, since the nm command for the non-native code may not be compatible. I have avoided this by not using globals variables which have constructors. The action of munch is to construct a special function called _main(), which calls these constructors at the star of main(). 2. You have to write a dummy *C* _main() i.e. void _main() {} so that you don't get a complaint that the symbol _main is undefined when you link. 3. You have to write code for "operator new" and "operator delete" (in C++). I just wrote new as a wrapper for "malloc" and delete as a wrapper for "free". 4. Watch out for problems with include files. The only problem I had was that SUN's ctype.h seems to be different from anybody else's. This is a difference between the character table being defined as _ctype_ in on and __ctype in another (or something like that). However, your mileage may vary. Running CC on a SUN, I have done this successfully for the following processors. Transputer IBM RS6000 I860 Steve Austin P.S. No guarantees of accuracy here. I speak for myself, not my employer. P.P.S Yes, I know this is a hack - no flames please.
philip@pescadero.Stanford.EDU (Philip Machanick) (10/08/90)
In article <59874@bbn.BBN.COM>, saustin@bbn.com (Steve Austin) writes: [...] |> I haven't ported AT&T's translator to RUN on a transputer, but it is |> trivially easy to get C++ code compiled FOR a transputer - or anything |> else really - if you have a C compiler for the target machine. |> |> The program 'CC' is just a shell script which takes the C++ program, |> runs it through the pre-processor, runs the output of this through |> cfront and then compiles the resulting C code with the standard compiler. |> |> It is easy to divert the last step (compiling with the default cc) and |> then compile with the cross-compiler. If you don't want to mess around with |> the shell script environment variables, you can yse the -Fc switch to get |> C code produced from the standard output of CC, redirect this to a temporary |> file and compile this. [...] |> There are some minor difficulies to be overcome. [...} |> 4. Watch out for problems with include files. The only problem I had |> was that SUN's ctype.h seems to be different from anybody else's. |> This is a difference between the character table being defined |> as _ctype_ in on and __ctype in another (or something like that). |> However, your mileage may vary. When I ported cfront to a new machine, I found the easiest way to handle header file problems was to use the C header files from the target machine. The same would probably be true when cross-compiling. Since cfront runs after the pre-processor, all the includes are expanded by the time your mangled c code is produced. (The C++ headers use the standard C headers extensively.) I would imagine you would also want to build the C++ library for the target machine. A problem I have had here is the function memcpy is used in the iostream classes. This is a Unix, rather than C, function as far as I can work out, and is not even supported on all versions of Unix. Fortunately, it's very simple to write your own. -- Philip Machanick philip@pescadero.stanford.edu
sylvie@litp.ibp.fr (Sylvie LEMARIE) (10/15/90)
1 About C++ porting on transputer
Our research group is involved in development of environment for
transputer-based machine. We run Helios as our basic system support.
We are porting C++ (2.0) to be run with the helios C.
This C compiler is almost C-ansi but the C++ compiler optimizes some
declarations which are not accepted by the Helios C, for example
struct A { ... }
struct B { A* a; }
B b;
The ATT C++ (2.0) compiler does not generate the A structure since just
a pointer is used. This botches the Helios C compiler.
So we have modified the ATT compiler to cope with Helios C.
Some other minor problems occur, requiring minor extensions.
Other problems include :
- the C Helios does not have an independent preprocessor stage, we have
ported the Gnu-CPP to run in front of the ATT-cfront.
- _main is an Helios function
- ...
I can't distribute these sources since ATT copyrighted but if some
vendors are interested, business could be business.
2 About cross-compiler
We have a cross-compiler Sun -> Helios. Our header files are just
mounted by NFS and we use the -I directive.
Sylvie Lemarie
Philippe Gautron, UUCP: gautron@rxf.ibp.fr
Rank Xerox France / LITP
Universite de Paris VI
4 place Jussieu, 75252 PARIS CEDEX 05
FRANCE