Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!orca.wv.tek.com!frip!andrew
From: andrew@frip.WV.TEK.COM (Andrew Klossner)
Newsgroups: comp.arch
Subject: Re: Integer Multiply/Divide on Sparc
Message-ID: <5837@orca.wv.tek.com>
Date: 11 Jan 90 20:19:20 GMT
References: <8840005@hpfcso.HP.COM> <1249@otc.otca.oz>
Sender: andrew@orca.wv.tek.com
Reply-To: andrew@frip.wv.tek.com
Organization: Tektronix, Wilsonville, Oregon
Lines: 21

[]

	"What about the ABI (application binary interface) standard you
	guys are pushing ... Even if it is not a new instruction but an
	integer co-processor, it still needs to be included in the
	ABI."

This is backward.  There is no need to include a new, commonly
implemented instruction in the ABI, and there are good reasons not to
do it.  The ABI details a common subset, the intersection of conformant
systems, not the union.

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]