uucp@BBN.COM (03/18/88)
This letter talks kindly towards the GNU C compiler, rather harshly
about the SUN link editor, and more harshly about Ph.D projects in
multi-processing systems.
We are currently using the GNU C compiler (V1.15) on a SUN 3 (on which it
works fine by the way) and are trying to develop it as a "universal"
system of putting stand-alone code into 68000/68020 stand-alone systems.
During this process we have/are running into some problems with the GNU
C compiler and particularly with the SUN link editor. Perhaps someone
somewhere can offer some suggestions.
First, the compiler problem. For low level operations such as unsigned long
multiplies, GCC cheats a bit in that it simply calls a routine which has
previously been compiled by the SUN normal compiler. This routine does, you
guessed it, an unsigned long multiply. The opcode generated for this routine
is therefore SUN 3 (i.e. 68020) dependent and in fact for the unsigned long
multiply, it uses the 68020 microcode command for that operation. This rather
naturely does not run on a 68000. I suppose we could get around this by
hand coding 68000 assembly code into the relatively few appropriate places
in the GCC source and using #ifdef mc68000. Has anyone got any other
suggestions before we do this?
We also noticed that GCC generated MIT format opcode (as does the SUN CC
command). We have commonly used Motorola format however and wondered if
someone has built up the translation tables to interrept MOT opcode
mnemonics rather or in addition to MIT format. Obviously this is for
hand written MOT format assembler we have previously written and do not
particularly want to trash. Please either post or mail to me since I
do not hav FTP capabilities (or at least don't know how to use them).
It would also be nice if someone at FSF or a willing donor, contrinbuted
the standard IO routines, in GCC source for PRINTF, SCANF, etc. Providing
the GETCHAR and PUTCHAR is very system dependent, but a GOOD set of IO
routines rather the the hacked versions we have would be very nice.
Back on the track.....
The major problem we have encountered is trying to debug the downloaded code.
PRINTF is not my ideal and this is particularly true when, as we are currently
doing, you only get a register dump and a program counter. We have
been unable to make the SUN link editor LD provide a useful link map for
non-relocatable code. Does anyone know how to do this? The SUN manuals
do not show many switches for LD and the link map produced is very primitive
without much detail. As a question and suggestion for FSF, is (will) the
GNU linker provide link maps (ala VMS, Whitesmith's) which can be used
for very low level debugging. If it does (will) when is (will) the linker
be available?
One other comment about the SUN linker, we tried cross-compiling C into 68020
code on our VAX using Whitesmith's compiler, downloading that code to the SUN
and then linking. LD complained about a "missing magic number". Does anyone
have any knowledge of this or will chanting in the light of a full moon while
standing is swamp water and chanting things I won't mention in reverse reveal
the true magic number to me.
A few suggestions for the future......
The reason we are interested in stand-alone system is to provide a modular
multi-processing environment made up of commercial processor boards.
While not the greatest in terms of compactness, it will probably work a lot
faster (take this either way) than special purpose architectures which
are dedicated to a particular task that was good for a Ph.D and take that long
to program.
What we need however is a way to {\it DEBUG} the system. Based on my naive
nature, it would seem very plausible that something like GDB could be made to
control other processors either directly or by passing commands to the
ROM monitor generally available on stand-alone systems.
In operation, you would compile, download and start execution at the (known)
starting address of your code on one of the multi-processors. GDB-M, to
coin a name, would then control the operation of that processor just as
it works on the SUN central CPU except that the SUN CPU would push and pull
the control data. Symbolic debugging should still be possible, even easier,
since the code on the multi-processors would typically be loaded at absolute
addresses. Comments.
As always the opinions expressed herein are expressly my own and are not
the opinions of my company.
{ihnp4, tundra, umn-cs}!mmm!schultz
John C. Schultz @ 3M Co.
3M Center, Bldg. 518-1-1
St. Paul, MN 55144
(612) 733-4047
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestmichael@hao.UCAR.EDU (Michael Schmidt) (03/19/88)
In article <910@ima.ISC.COM>, harvard!rutgers!umn-cs!uucp@BBN writes: >I suppose we could get around this by >hand coding 68000 assembly code into the relatively few appropriate places >in the GCC source and using #ifdef mc68000. Has anyone got any other >suggestions before we do this? You may want to get GCC 1.18. As quoted from the man page: -m68000 Generate output for a 68000 (rather than a 68020). >We have commonly used Motorola format however and wondered if >someone has built up the translation tables to interrept MOT opcode >mnemonics rather or in addition to MIT format. Same as above. The GCC 1.18 has a compile time switch to generate Motorola format. -- Michael Schmidt, Universitaet-GH Paderborn, FB 17, Warburger Str.100, D-4790 Paderborn, West Germany z.Zt.: University of Colorado, Boulder Mail: michael@boulder.UUCP or michael@boulder.Colorado.EDU -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request