Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!elroy.jpl.nasa.gov!peregrine!ccicpg!hobbit!ndjc
From: ndjc@hobbit.UUCP (Nick Crossley)
Newsgroups: comp.bugs.sys5
Subject: Re: Reference ports, etc. (was Re: Nasty bug in release 4 Bourne shell)
Summary: COFF could be useful on SPARC
Message-ID: <11368@hobbit.UUCP>
Date: 15 Jan 91 02:42:19 GMT
References: <5048@auspex.auspex.com> <10518@hobbit.UUCP> <5208@auspex.auspex.com>
Organization: ICL North America, Irvine, CA 92718
Lines: 23

In article <5208@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>So does this mean that one orders the SPARC reference port source from
>AT&T (or USL)?
Yes.

>"Current" SPARC version?  Since no officially-released SPARC systems
>that I know of used COFF, I'm not sure there's a good reason for *any*
>SPARC S5R4 version to bother with COFF.
I believe that's what Sun and AT&T thought, but I can imagine
existing COFF-producing retargetable code generators and other such
tools which could be ported to SPARC much more easily if the supplier
did not have to change object formats at the same time.  In fact,
I have had to work on one such beast.

>Yup, good old "iropt"/"cg", I suspect.
Correct.  One side effect of this is that some of the SGS fringe tools
such as function inlining, line profiling, etc., work very differently
on SPARC and, say, 3B2.
-- 

<<< standard disclaimers >>>
Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282
uunet!ccicpg!ndjc  /  ndjc@ccicpg.UUCP