Reference ports, etc. (was Re: Nasty bug in release 4 Bourne shell)

Guy Harris guy at auspex.auspex.com
Sun Jan 13 08:15:30 AEST 1991


>Unfortunately, I don't know the answer to that (yet).  ICL did send
>(nearly) complete V.4 SPARC source code with bug fixes back to
>AT&T,

Good!

>and then AT&T took that over to produce the SPARC reference
>source, making various other changes of their own.

So does this mean that one orders the SPARC reference port source from
AT&T (or USL)?  (Anybody know if, say, Unisoft did the same for the 68K
and 88K ports?)

>This whole area does seem a little weak to me.  There are some
>areas of the source tree which are radically different from one
>port to another, to the extent of offering completely different
>facilities.  (One such area is the compilation system; for example,
>the current SPARC version does not support COFF,

"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.

>and has a radically different C code generator and optimiser from the
>other machines).

Yup, good old "iropt"/"cg", I suspect.  The same will probably be true
of any MIPS "official"/"reference" port; it'll probably use MIPS's
compilers.

The code generator and optimizer, and probably assembler, I can see
having little in common between machines (although many of the machines
may share large common parts of a retargetable code
generator/optimizer/assembler - "iropt" is actually used by Sun on both
68K and SPARC, and was in fact originally done for the Sun FORTRAN
compiler for Sun-2/Sun-3).  I suspect most machines can share the
linker, though, and much of the front end of the compiler (ANSI C is
ANSI C is ANSI C, etc.) - as well as most of the libraries, most of the
kernel, and most of the commands. 

>I believe that most of the porting groups have sent their code back
>to AT&T, but there does appear to be some delay in the merging of
>these - if indeed AT&T have any intent of doing such a merge.

I sure *hope* they do, so that N UNIX vendors don't have to invent the
same wheel N times....



More information about the Comp.bugs.sys5 mailing list