Xref: utzoo comp.arch:21445 comp.lang.misc:6863
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Unusual instructions and constructions
Summary: This is still not right
Message-ID: <7850@mentor.cc.purdue.edu>
Date: 14 Mar 91 18:24:17 GMT
References: <4748@eastapps.East.Sun.COM> <7571@mentor.cc.purdue.edu> <1991Mar14.013109.16636@kithrup.COM>
Sender: news@mentor.cc.purdue.edu
Followup-To: comp.arch
Lines: 61

In article <1991Mar14.013109.16636@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
> In article <11964@pasteur.Berkeley.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes:
> >Check out this short program:
> 
> [code deleted]
> >It's not optimal: there are two divides.  Still, if you write kindly
> >I'll bet you could talk RMS into seeing if he could recognize the
> >pattern and produce one divide in gcc 2.0 (or for some higher number).
> 
> 
> foop:
| 	pushl %ebp
| 	movl %esp,%ebp
| 	pushl %ebx
| 	movl 8(%ebp),%eax
| 	cltd
| 	idivl 12(%ebp)
| 	movl %eax,%ecx
| 	movl %edx,%ebx
| 	pushl %ebx
| 	pushl %ecx
| 	pushl $.LC0
| 	call printf
| 	leal -4(%ebp),%esp
| 	popl %ebx
| 	leave
| 	ret
> 
> It was already done, for gcc 1.3[89].  Good work, eh?  Yes, the code could
> be optimal:  gcc could look at the entire function, and not bother moving
> from eax to ecx, just pushing them directly.  But those are small amounts
> (two or three cycles, I believe), and are *much* better than the 15+ cycles
> the extra divide would have taken.

This example has far too many loads and stores.  Possibly this MIGHT not be
too important for a division, but how about something like frexp?  The 
operations may be register-register, in which case all these loads and
stores are inappropriate.  Also, something this simple should be inlined;
if a subroutine call, there is the additional save/restore overhead which
has to be done somewhere.

The real need is for the languages and compilers to allow the user to 
introduce idioms, with translation into machine primitives.  In the above
example, idivl is such a primitive, and should be considered no differently
than the various types of subtraction.  The relevant idiom in the above 
example would be 

	q,r = x/y,

where the / is overloaded some more.

If instead r, x, and y were floating point, and q integer, the code would be
quite different, 

Mathematical notation has been developing over centuries, and we still see
many new idioms and overloadings.  It is not necessary to have a committee
to decide what notation will be allowed and what will not.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)