guy@auspex.auspex.com (Guy Harris) (01/13/91)
>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....
ndjc@hobbit.UUCP (Nick Crossley) (01/15/91)
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
guy@auspex.auspex.com (Guy Harris) (01/17/91)
>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. That's one nice thing about having your compilers generate assembler code rather than object code - they don't have to know quite so much about object-file formats, because they leave that knowledge up to the assembler....