From:	"Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
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
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 <eliz AT is DOT elta DOT co DOT il>
To: "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
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.

- Raw text -