Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!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: <1255@otc.otca.oz> Date: 15 Jan 90 00:55:06 GMT References: <8840005@hpfcso.HP.COM> <1249@otc.otca.oz> Reply-To: gregw@otc.UUCP (Greg Wilkins) Organization: OTC Development Unit, Australia Lines: 66 In article you write: >In article <1249@otc.otca.oz> gregw@otc.otca.oz (Greg Wilkins) writes: > in article <8840005@hpfcso.HP.COM>, dgr@hpfcso.HP.COM (Dave Roberts) says: > > Now for some comments: > > (1) SPARCs will get multiply and divide. This is from a guy at > > Sun. Coming soon to a SPARC station near you... > >No, it was a guy at TI. Well I didn't know that!!!!! >complying with the ABI). If you use the current Sun compilers, you get >.mul, .div, .rem etc. .... and if you have a chip which had those as >hw instructions you (as an end user, or software author or whathave >you) could replace those library codes with ones which employed your >nifty instruction(s). No ABI breakage. Well the compiler I use on a sun 4/110 doesn't produce .mul, .div etc but then it is running an ancient version of the operating system (3.2!!!) But assuming that newer compilers will generate them, surely they are expanded when the a.out file is generated, so they cannot be evaluated at load time. I guess they can be expanded to a call to a shared library routine (I don't know how this mechanism works), so libC.a is not linked in until run time, But I don't know if shared libraries are included in the ABI. If it is not, then libC.a will be linked in before an application is distributed, thus local libC.a routines will be ignored. Well lets assume that via some mechanism, multiplies are performed by an undefined function that is linked in at load time. Then the best you can do is cop a function call then a multiply instruction (possibly with moves to and from a co processor). I guess this is not too bad as function calls are pretty fast on a SPARC anyway. But what about multiplies by constants, the compiler will have turned these into wonderful sequences of shifts and adds. If a mul instruction became available, these should be replaced by a load with constant followed by a multiply. But then I guess nothing can solve this one (without greatly slowing the performance of all machines without a multiply instruction). >You jump to some amazing conclusions from a posting from _TI_ about >Sun's plans and business practices. I was not jumping to amazing conclusions, but simply inviting Sun to clarify a point of obvious public concern. Your posting has indicated that maybe it is not such a big deal, but it still would be better to get an official position from sun on the future a sparc and multiply. It is Obvious that 1) SPARC multiply performance can be improved. 2) There is a class of users who would greatly benefit from it. 3) There is a larger class of user who probably wont notice it, but would sure as hell feel nicer about their machines when reading comparative benchmarks. 4) There are many rumours about how/when/if the multiply will be speeded up. 5) Everybody would appreciate a definitive statement from Sun DISCLAIMER: I do not know my employers opinion on these matters. Greg Wilkins ACSnet:gregw@otc.oz.au igc nets: igc:peg:gwilkins "To sin by silence when Phone(w): (02)2874862 Telex: OTCAA120591 they should speak out Phone(h): (02)8104592 Snail:OTC Services R&D, makes cowards of men" Fax: (02)2874990 GPO Box 7000, - Abe Lincoln O/S ph: (prefix) 612 # Sydney 2001, Australia