Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!PT.CS.CMU.EDU!FAS.RI.CMU.EDU!schmitz
From: schmitz@FAS.RI.CMU.EDU (Donald Schmitz)
Newsgroups: comp.sys.m68k
Subject: Re: GCC, SUN LD, suggestions about debugging multiprocessors
Message-ID: <1174@PT.CS.CMU.EDU>
Date: 19 Mar 88 18:47:49 GMT
References: <910@ima.ISC.COM>
Sender: netnews@PT.CS.CMU.EDU
Distribution: na
Organization: Carnegie-Mellon University, CS/RI
Lines: 20
Keywords: GCC SUN LD multi-processors

/* sorry if this shows up more than once */

>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 are doing a similar thing, and we simply use the SUN C compiler.
Although our additional CPUs are all 68020s, the cc documentation seems to
indicate switches can be used to make cc compile 68010 code for backwards
compatability with SUN-2s.   Of course if gcc is much better than cc, this is
a lose (I'd be interested in hearing of any gcc advantages, it wouldn't be
real hard to do better than SUN cc).  We still don't have a good way to
debug, we simply look at the symbol table, PC and SP, and try to find which
routine bombed and what its arguments were, then debug it on the SUN.