From: Michiel de Bondt Newsgroups: comp.os.msdos.djgpp Subject: Re: how to use inline push and pop Date: Mon, 07 May 2001 20:14:33 +0200 Organization: University of Nijmegen Lines: 94 Message-ID: <3AF6E609.3CA3B8BC@sci.kun.nl> References: NNTP-Posting-Host: hieper.sci.kun.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: wnnews.sci.kun.nl 989259273 18131 131.174.132.100 (7 May 2001 18:14:33 GMT) X-Complaints-To: usenet AT sci DOT kun DOT nl NNTP-Posting-Date: Mon, 7 May 2001 18:14:33 +0000 (UTC) X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hans-Bernhard Broeker wrote: > On Mon, 7 May 2001, Michiel de Bondt wrote: > > Hans-Bernhard Broeker wrote: > > > > > In article <3AF6B070 DOT D006EAC1 AT sci DOT kun DOT nl> you wrote: > > > > > > > So I used __volatile__ and the compile option -fno-defer-pop. > > > > > > Bad idea, I think. Using extended inline asm is the preferrable > > > solution, almost all the time. Your own code shouldn't have to rely > [...] > > > I use extended asm. But I do not know how to tell the fact that the > > stack is used. > > 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 > realm of allowable asm operations. Extended asm is alreay quite > expressive. But there's no way it can inform the compiled code about the > amount you moved %esp around by. > 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. But maybe, I do not know enough about how GCC works. > > > > and no reloads will be necessary. Or if it is, it'll put in the > > > push/pop or mov instructions itself. > > > Not if you reserve registers. First, I did not reserve registers, but > > this resulted in dragging register locals to the stack by the > > generated program. > > So what? In what respect is that different from your own assembly > pushing register contents to the stack, instead? > 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. > > > So I reserved all six registers. As a result, my > > code only compiled with -O1 after then, since otherwise the compiler > > complained about spilled registers. > > Understandable: you effectively removed all the manoeuvering space the > compiler-generated code had --- you choked it to death. You cannot expect > GCC to be able to optimize your C if you put barbed wire and tank-stoppers > all across its path. > But some optimization is necessary: -O0 does not work either, for the same reason. > > 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. That is a very convenient way to make a fast program. Maybe, it is a good idea to inline parts of the .s file. But then, I have to process the .s file, adding " and \n\t" and removing line numbers. The option of removing all C-code is not very appealing either: if I really want to remove all the C-code, I must jump from one asm-block to another and call _[c]printf myself. For now, I will hack on. Thanks for your help. > > -- > Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) > Even if all the snow were burnt, ashes would remain.