🚀 go-pugleaf

In article <KHB.90Jan11212327@chiba.kbierman@sun.com> 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