Path: utzoo!attcan!uunet!mailrus!ames!vsi1!zorch!ardent!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Integer Multiply/Divide on Sparc
Message-ID: <34461@mips.mips.COM>
Date: 13 Jan 90 22:22:39 GMT
References: <8840005@hpfcso.HP.COM> <1249@otc.otca.oz> <5837@orca.wv.tek.com> <1253@otc.otca.oz>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 49

In article <1253@otc.otca.oz> gregw@hls0.oz.au writes:

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

Well, let us observe that:
	a) Most architecture families have added user-visible instructions
	over time, haven't they:
	S/360 -> S/370 -> etc
	68000->68010->68020
	8086->80286->80386->80486
	for example.
	b) For microprocessors, there are PLENTY of oppurtunities to use
	new things while still retatining backwards binary compatibility,
	like:
		use them in the kernel [50% of your cycles, often....]
		(as khb mentions) shared libraries
		kernel emulation of instructions
		translation [remember that people often translate RISC
		instructions on the fly, becasue it's epseiclaly easy]
	and finally:
	c) Many microprocessors are also used in embedded control, where
	ABI's are mostly irrelevant.
	d) Finally, some programs are ONLY compiled and run on local
	machines, and if somebody wants to compile with appropriate
	flags, so be it.  [After all, consider the history of floating
	point accelerators and Sun & elsewhere, and with Weitek chips that
	go in place of 80387s, etc, etc].

Clearly, one wants to avoid gratuitous changes, and too many different
versions of things, but it is certainly a fact of life that:
	a) at any give time, you may not have enough silicon to do everything
	you'd like to.
	b) Successive generations will almost always have some differences
	relative to the kernel.
	c) And finally, as families evolve, the optimal code generation
	may well change from machine to machine anyway, even if they're
	binary compatible in both directions.  This effect has been seen for
	a long time on S/360.... and VAXen, and 386vs486, etc ,etc.

Anyway, let's observe that what's IMPORTANT is getting enough volume
on anything to make it interesting.... the fact that some 386s run MSDOS,
and some run UNIX, and some run OS/2 doesn't stop people from buying them.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086