Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!cluster!metro!otc!gregw
From: gregw@otc.otca.oz (Greg Wilkins)
Newsgroups: comp.arch
Subject: Re: Integer Multiply/Divide on Sparc
Message-ID: <1253@otc.otca.oz>
Date: 13 Jan 90 12:17:06 GMT
References: <8840005@hpfcso.HP.COM> <1249@otc.otca.oz> <5837@orca.wv.tek.com>
Reply-To: gregw@hls0.oz.au
Lines: 28

In article <5837@orca.wv.tek.com> andrew@frip.wv.tek.com writes:
>The SPARC ABI describes the virtual machine which is (will be?)
>implemented on all SPARC systems.  It gives the interface which an
>ABI-conformant application can depend on.  If a machine implements both
>the ABI and the new multiply instruction, programs which conform to the
>ABI (and therefore do not use multiply) will still execute correctly.
>This is all that matters.
>
>  -=- Andrew Klossner   (uunet!tektronix!frip.WV.TEK!andrew)    [UUCP]
>                        (andrew%frip.wv.tek.com@relay.cs.net)   [ARPA]

This is not all that matters.  Lets pretend you have just bought a
brand new sparc station X, complete with integer multipy.  You now want to
by some software for it: You have a choice of paying $300 for the ABI
version, which cannot use the multiply instruction (which is not part of
the ABI), but which is ready to run (be it very slowly as it is a multiply
intensive application).  OR you can pay $100,000 and by the source code,
then study law for a while so you can understand the licence agreement,
then hire another system administator (the existing one is too busy finding
disk space to install and compile applications for every tom dick and
harry).

Basicly it has to be in the ABI or it might as well not be in the machine.
That is if this ABI thing gets off the ground, which it will never do if
every so often a new instruction/co-processor is added.


-gregw@otc.oz