Mail Archives: djgpp/2001/05/07/15:00:01
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.
- Raw text -