From:	"Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: inefficiency of GCC output code & -O problem
Date:	Sun, 16 Apr 2000 13:28:02 +0400
Organization:	MTU-Intel ISP
Lines:	39
Message-ID:	<38F987A2.B682ACC@mtu-net.ru>
NNTP-Posting-Host:	ppp97-187.dialup.mtu-net.ru
Mime-Version:	1.0
X-Trace:	gavrilo.mtu.ru 955887113 21507 212.188.97.187 (16 Apr 2000 12:11:53 GMT)
X-Complaints-To:	usenet-abuse AT mtu DOT ru
NNTP-Posting-Date:	16 Apr 2000 12:11:53 GMT
X-Mailer:	Mozilla 4.72 [en] (Win95; I)
X-Accept-Language:	en,ru
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Sat, 15 Apr 2000, Alexei A. Frounze wrote:
> 
> > Hmm, how do we really know how many values are left by GCC on the FPU stack?
> 
> I think you can't, in general, not at compile time.
> 
> However, if you get to the point where you need such an intricate
> knowledge about the code generated by GCC, perhaps some reality check
> is in order.  IIRC, the original motivation for your inline assembly
> was to avoid the cost of a call to the `ceil' library function.
> Surely there must be an easier way of doing whatever you needed `ceil'
> for without knowing which part of the FP stack is in use, right?

Not for ceil() only. I mean in general. I.e. can I use FPU with inline ASM and
what are restrictions/limitations? With inline ASM for CPU we have no any
restrictions. But with FPU, we might have them. This depends on GCC and how it
optimizes the code. If it keeps something on the FPU stack when inline ASM
starts or external ASM routine is being launched, program may not work properly. 
Btw, I think GCC optimizes FPU code within separate routines so parhaps we will
never encounter problems with external ASM subroutines. That's OKay, but
question about inline ASM and FPU is still not answered.

> Suppose you describe the original problem(s) which led you to use the
> inline assembly in the first place, in this particular case?  Chances
> are, that problem has a much simpler solution.

Just make either a plane C code (which is slower) or huge external ASM
subroutine (which is too boring for anyone except for those who prefers ASM than
C).

bye.
Alexei A. Frounze
-----------------------------------------
Homepage: http://alexfru.chat.ru
Mirror:   http://members.xoom.com/alexfru

- Raw text -