aoki@postgres (Paul M. Aoki) (07/08/88)
I would like to use our Sequent Symmetry (a 386-based multiprocessor)
as a compile-server for a bunch of Sun3 workstations. Specifically, I
am trying to get a 68020 C compiler, assembler, and linker/loader to
work on the Symmetry.
GNU cc seems to work fine on the Symmetry, so I can produce 68020
assembly code. All I need is a working 68K /bin/{as,ld} and I'm set.
Problem: programs that produce .o files are just a *little* more
sensitive to byte-ordering than compilers, and the 68K and 386 have
reverse byte-ordering. I really don't want to go through every line
of Sun's as and ld (or the GNU as and ld) and stick byte-swapping
macros in -- someone somewhere must have done something like this before!
QUESTION: Does anyone have a 68020 as/ld that works on little-endian machines?
Code that runs on a VAX running UN*X would be great, and something
that runs on a 386 UN*X box would be ideal.
We run SunOS 3.5 on the Suns and DYNIX 3.0 on the Sequent, both SysV/BSD
hybrids.
Please pass on any hints or pointers you have ...
----------------
Paul M. Aoki
CS Division, Dept. of EECS // UCB // Berkeley, CA 94720 (415) 642-1863
aoki@postgres.Berkeley.EDU ...!ucbvax!aokifnf@fishpond.UUCP (Fred Fish) (07/10/88)
In article <4352@pasteur.Berkeley.Edu> aoki@postgres (Paul M. Aoki) writes: >GNU cc seems to work fine on the Symmetry, so I can produce 68020 >assembly code. All I need is a working 68K /bin/{as,ld} and I'm set. >Problem: programs that produce .o files are just a *little* more >sensitive to byte-ordering than compilers, and the 68K and 386 have >reverse byte-ordering. I really don't want to go through every line >of Sun's as and ld (or the GNU as and ld) and stick byte-swapping >macros in -- someone somewhere must have done something like this before! As someone who has supported m68k cross compilation environments for several years on a number of different systems, including some with different byte ordering than the m68k, I would advise making only minimal changes in the source code of the tools themselves. Use the natural byte ordering of the host machine, and convert the object files with a conversion program when you need to actually transfer and execute them on an m68k based machine. Writing the conversion program will almost certainly be less work than weeding out all the byte dependencies in the tools. Conversion tools for COFF objects and "a.out" objects are available from many vendors that support m88k cross environments, though this might not be useful to you if you are trying to work totally with freely redistributable software. -Fred -- # Fred Fish, 1346 West 10th Place, Tempe, AZ 85281, USA # noao!nud!fishpond!fnf (602) 921-1113