From owner-freebsd-hackers Thu Jul 19 1:26: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 347AE37B401 for ; Thu, 19 Jul 2001 01:26:06 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.141.193.Dial1.SanJose1.Level3.net [209.247.141.193]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA09402; Thu, 19 Jul 2001 01:26:00 -0700 (PDT) Message-ID: <3B5699BD.10BE44F8@mindspring.com> Date: Thu, 19 Jul 2001 01:26:37 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Farooq Mela Cc: hackers@FreeBSD.ORG Subject: Re: Quick question about x86 asm References: <3B554445.193CE946@sm.socccd.cc.ca.us> <3B55BD97.A6E40F1E@mindspring.com> <3B567452.36965E56@sm.socccd.cc.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Farooq Mela wrote: > > cc -S is your friend. > > Right, well that can certainly help, but what gcc generates can be > dependant on calling convention, optimization setting, &c &c, and > though the code generated in one particular scenario may not be an > absolute indicator of it's behavior. In other words, I was looking for > more of a "yes" or "no" type response ;-). Anyway, redirecting this > question to a gcc list. The correct assembly code to use is "dependent on the calling convention, &c, &c" of the C code you are going to link it into, so that's not a strong argument. Given a function argument list and return type, it's going to remain pretty constant, so long as you compile your -S function in an isolated environment, such that it has to be capable of linking against other code, once assembled ...in other words, you don't have to worry about the peephole optimizer being able to span multiple object files, so it's not really a problem that involves changes to calling convetion or tail call or other optimization. The answer you were probably looking for is that the eax register is _not_ loaded with a return value in the "void" case, but it may contain a value different than when it went in, anyway, if the register ended up being used for scratch. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message