From: "Alexei A. Frounze" Newsgroups: comp.os.msdos.djgpp Subject: [Fwd: Re: inefficiency of GCC output code & -O problem] Date: Sun, 16 Apr 2000 13:32:44 +0400 Organization: MTU-Intel ISP Lines: 52 Message-ID: <38F988BC.3D4400E2@mtu-net.ru> NNTP-Posting-Host: ppp97-187.dialup.mtu-net.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: gavrilo.mtu.ru 955887120 21507 212.188.97.187 (16 Apr 2000 12:12:00 GMT) X-Complaints-To: usenet-abuse AT mtu DOT ru NNTP-Posting-Date: 16 Apr 2000 12:12:00 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 -------- Original Message -------- Subject: Re: inefficiency of GCC output code & -O problem Date: Sun, 16 Apr 2000 11:29:28 +0200 (IST) From: Eli Zaretskii To: "Alexei A. Frounze" CC: djgpp AT delorie DOT com On Sun, 16 Apr 2000, Alexei A. Frounze wrote: > > 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. Solving general problems is hard. Breaking them into series of simple ones and then solving each simple one in turn is less hard ;-). So I suggest to solve the problem with ceil, which started this thread in the first place, then move to the next one. Also, please keep posting to the news group as well, since I believe this thread is interesting to many other people who could help you. > I.e. can I use FPU with inline ASM and > what are restrictions/limitations? Yes, you can; yes, there are restrictions. But I cannot describe this in its general form, because the issue is too broad to be addressed in a short message. I'd need to reproduce large parts of the massive Intel manuals to spell out the gory details. > With inline ASM for CPU we have no any restrictions. That's not true: many instructions that use general-purpose registers have restrictions as well. > > 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 I asked for a description of the problem(s), not for comparison of solutions for a problem you didn't explain.