Path: utzoo!attcan!uunet!zds-ux!gerry
From: gerry@zds-ux.UUCP (Gerry Gleason)
Newsgroups: comp.arch
Subject: Re: Integer Multiply/Divide on Sparc
Message-ID: <96@zds-ux.UUCP>
Date: 12 Jan 90 15:50:18 GMT
References: <8840005@hpfcso.HP.COM> <1249@otc.otca.oz> <18132@umn-cs.CS.UMN.EDU>
Reply-To: gerry@zds-ux.UUCP (Gerry Gleason)
Organization: Zenith Data Systems
Lines: 81

In article <18132@umn-cs.CS.UMN.EDU> mike@umn-cs.cs.umn.edu (Mike Haertel) writes:
>In article <1249@otc.otca.oz> gregw@otc.otca.oz (Greg Wilkins) writes:
>>Even if it is not a new instruction but an integer co-processor, it
>>still needs to be included in the ABI.

>>Without an official yeh or nay on this one, nobody can have confidence in
>>Suns commitment to open systems and the ABI.

>I don't see how ABI is related to "open systems."

Well, it is and it isn't.

>Source level compatibility ought to be enough for anyone.  With the
>emergence of, e.g., ANSI C, POSIX.1, and (less desirably) the
>X window system, it will be substantially easier to write portable
>programs, and these standards are likely to have a far longer viable
>life than any ABI.

  While I agree that source level standards are what allow for open
systems in the broadest sense, "enough for anyone," no.  ABI's are
important in relationship to "shrink-wrap" selling of software, the
selling of software in pre-packaged executable form for standard
platforms.  There must be enough machines out there compliant
with any particular ABI for the market to be big enough for
distributers to stock products for it.

  A related issue is how many different ABI's does the market have
room for.  I suspect the number is quit small (maybe only 2, certainly
not more than 5), so anyone care to guess which architectures will
win?  For my money, I don't see how Intel 386/486 could not be on
the list, there are simply too many roughly compatible machines out
there already, and then I would be on one or two of SPARC, MIPS,
or 88000.  Greg is right that it is critical to lock down all
aspects of the hardware (and systems software standards) that
effect the ABI.  If Sun or any of the others falter on these points
the marketplace gets devided and will never develop.

>I see source level standards as being far less likely than ABIs
>to kill future innovation.  RISC architectures, and surely the
>SPARC, are far from the last word in computer architecture!

Standards that do not evolve to include future innovation, die
off, but that's not the point.  Source standards do a lot to
preserve/extend software investment, particularly over time,
but all of us know that there is no such thing as just compiling
any source over about 10k (and few smaller) on a different
family of machine (even different '386 PC's you must recite
the proper incantations for things to work).  If there is not
a commodity market in software for a particular architecture,
the only company guarenteen to have an incentive to compile
and package binaries would be to manufacturer.  Admittedly,
the situation is different in the upper ranges of the market;
MIPS R6000 machines as an example, they won't likely be in
environments where the user is the system administrator, and
package installer, so installation and maintainance doesn't
have to be simple.  But for the high-volume low-end of the
market the requirements for strict standards that support
drop-in compatibility will become ever greater.

What I am curious about is whether there have been any reasonable
proposals for the RFP that OSF put out last year.  The one for
an architecture independent distribution standard, or whatever
they called it.  To me it sounded like a great idea that might
be impossible in practice.

>How will your ABI relate to the massively parallel machines
>that are likely to become increasinbly prevalent?  And yet the
>source level standards will still be useful, particularly
>as even some of today's programs might conceivably benefit from
>parallelizing compilers.

For the short term, ABI is not that relevant to parallel machines
because they are mid to high end machines at this point.  Also,
to my knowledge, UNIX has a very narrow range of parallel
architectures that it maps well to (various closely and loosly
coupled MIMD architectures).  So for mainsteam machines (where
ABI's are relevant) I expect that parallelism will be supported
in standards by MACH features or MACH like features, in other
words parallelism isn't really a problem now.

Gerry Gleason