Mail Archives: djgpp-workers/1999/08/09/07:25:57
On Sun, Aug 08, 1999 at 02:06:09PM +0300, Eli Zaretskii wrote:
> > On 5 Aug 99, at 16:20, Laszlo Molnar wrote:
> > > Another
> > > idea: maybe you could change the default 8 byte aligment of the stack
> > > to 4 when building gcc (if you build it with 2.95). It would make the
> > > executable somewhat smaller (and maybe faster? - not sure, just an
> > > idea).
> Laszlo, I don't understand why are you suggesting a 4-byte alignment
> for the stack. I think it has only disadvantages, since local
> variables of types double and long long will be misaligned, so if
> anything, it will run slower. There's no effect on the binary size
> (since the stack is sbrk'ed at run time), and not on the size of the
> executable in memory (since the alignment works by moving the stack
> bottom to 8-byte aligned address without changing the size of the
> allocated stack). Am I missing something?
gcc 2.95 tries to align the stack much harder than the previous
gcc/egcs versions. It puts lots of add esp,xxx or sub esp,xxx
instructions into the code (before the call instructions). However it
not always does it right, and sometimes it uses two add esp, instead of
one. This makes the code larger. The size of the alignment can be
changed with the flag -mpreferred-stack-alignment (or something like
this). My suggestion was that we could use 4 byte alignment for
building gcc itself, to make the executable smaller. I don't think
aligning the stack to 8 byte boundary would make a big difference in
compile time of gcc.
For user programs 8 byte alignment should be the default.
> > Perhaps it's best to stay with defaults for i86 for release of
> > DJGPP port. All similar changes should be carefully tested and
> > most discussions in latest time were about using even 16 bytes
> > alignment. But all such optimizations are common for all
> > i86 targets and doing them especially for DJGPP would
> > duplicate the same efforts (and I'm not sure we'll do it better)
> I couldn't agree more with Andris.
I suggested using -fvtable-thunks, because egcs 1.x used it on linux
by default. This flag would make c++ programs both smaller and faster.
Of course I agree with you that testing is needed, so waiting for gcc
3.0 seems to be a good idea.
- Raw text -