From: Hans-Bernhard Broeker 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: <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 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.