Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!mailrus!cornell!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.lang.c
Subject: Re: No return() and returns a value !?  (Was: Quick C)
Message-ID: <5571@june.cs.washington.edu>
Date: 26 Aug 88 20:56:16 GMT
References: <8808261424.AA11504@ucbvax.Berkeley.EDU>
Reply-To: pardo@uw-june.UUCP (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Lines: 37

TURGUT@TREARN.BITNET (Turgut Kalfaoglu) writes:
> f(i){ int tmp; i = i*i; tmp = 222; }
> returns a value!

This kicked my funny bone.  look at the assembly output (or
dissassembled output) of the compiler.  You will see that:

* function return values are always in the same register (e.g, r0)
* temporary calculations are made using the same register

thus

* the "correct" value winds up in the return value accidentally.

The reason this kicked my funny bone is that at times there has been
code that *relied* on this behavior and I have seen at least one style
guide that says "don't depend on this behavior".

Gcc (GNU C compiler) is smart enough (on a VAX, anyway) to perform
temporary computations in the return register, avoiding extra copies,
while pcc (which, in all fairness, is many years older) will
occasionally produce code as shown below, even with the optmizer
turned on (not for the above code, though, it does other entertaining
things):

	cvtbl	-4(fp),r0
	movl	r0,r0		# Could be optimized to "nop" :->
	ret

This is all because of a "phase ordering problem", that you can't
select register use until you know what instructions you're trying to
use and you can't select optimal instructions until you know what
registers you have to play with.

	;-D on  ( More fun than a barrel of cats )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo