From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: how to use inline push and pop
Date:	8 May 2001 10:24:00 GMT
Organization:	Aachen University of Technology (RWTH)
Lines:	51
Message-ID:	<9d8hg0$gar$1@nets3.rz.RWTH-Aachen.DE>
References:	<Pine DOT LNX DOT 4 DOT 10 DOT 10105071846560 DOT 8277-100000 AT acp3bf> <3AF6E609 DOT 3CA3B8BC AT sci DOT kun DOT nl>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Trace:	nets3.rz.RWTH-Aachen.DE 989317440 16731 137.226.32.75 (8 May 2001 10:24:00 GMT)
X-Complaints-To:	abuse AT rwth-aachen DOT de
NNTP-Posting-Date:	8 May 2001 10:24:00 GMT
Originator:	broeker@
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Michiel de Bondt <michielb AT sci DOT kun DOT nl> wrote:
> Hans-Bernhard Broeker wrote:

[...]
>> It may simply not be possible. As I said, the stack pointer is extremely
>> central to the code emitted by GCC.  Meddling with it may be outside the

> I think it would be enough for the compiler to know that the stack
> is used.  That indicates that the stack pointer should point to the
> stack top before the inline instruction and should be assumed to
> point to the (possible new) stack top after the inline instruction,
> just as before and after a call. You can put "memory"
> in your clobbered list, but why cannot you put "stack" in your clobbered
> list.

To put this clearly: yes, I do agree that this is an apparent limitation
in GCC.  The point I'm arguing about is whether it's an *important* 
limitation.  

> I only use the stack for my fast recursion and for the relatively
> rare calls to [c]printf to inform the user about the progress. But
> the compiler drags without having a good reason to do so, at least,
> in my opinion. That is the reason for generating slower code.

The compiler has to push all local variables of the function whose
lifetime it doesn't know to be ended with the recursive call.  With
all that inline asm in place, it probably won't be able to detect such
lifetimes correctly.  Which IMHO is another hint that you should
probably be writing the whole function in assembly, in this case.

> But some optimization is necessary: -O0 does not work either, for the same
> reason.

gcc -O0 is, let's be polite, a very simple-minded compiler. It
forcibly assumes you have left it at least one or two registers to
work with, freely. 

>> For code like that, it may be way better to just code it as a separate asm
>> function, or at least as an asm-only function without any remaining C in
>> it.

> But that is hard. Now, I can replace C statements one by one by
> accembly equivalents, testing if the program still works. 

Overly complicated. gcc -S your current source, and work with the generated
assembly source from there on.  If your assembly skills are good enough to
make this whole effort worth trying, this shouldn't be hard for you.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -