From: "Alexei A. Frounze" 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 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit 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