w improved posting to:
http://gcc.gnu.org/ml/gcc-help/2008-09/msg00100.html
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
ith-gmp=$GCCBUILD/gmp --with-mpfr=$GCCBUILD/mpfr
make
make install
cd ..
mkdir $GCCBUILD/gdb
cd $GCCBUILD/gdb
$GCCSRC/gdb/configure $HOST_OPTION --target=$TARGET --prefix=$GCCBUILD/install
make
make install
cd ..
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
PU's. I settled
on exposing stack slots as CPU registers + some other tricks. GCC generates
very decent code(80% of codesize to ARM thumb).
- Cygwin binaries + GCC source code available(of course)
- ++
--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit
r
> you saw.
>
> However, I would not call this an optimization. This is just how the
> toolchain accidentally happens to work.
Without this emergent behaviour, stack slot assignment optimisation
would have been much more important.
--
Øyvind Harboe
http://www.zylin.com
ds.
Spilled registeres are accessed more frequently than other entries in
the stack frame, so getting this right(which I think pretty much all
backends do, after a quick scan) has a significant positive impact on
code-size.
--
Øyvind Harboe
http://www.zylin.com
Answer: FRAME_GROWS_DOWNWARD.
The stack slots for the registers spilled on the
stack are allocated last. When the frame grows downward,
the displacement is smaller than if the frame grows upward.
Thanks.
--
Øyvind Harboe
http://www.zylin.com
mitted to GCC CVS, but the above indicats that there is
some sort of mechanism in GCC already to mitigate this problem...
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00019.html
--
Øyvind Harboe
http://www.zylin.com
int bar(int a);
int test1(int *);
int foo(int a, int b, int c, int d)
{
i
the general
case.
--
Øyvind Harboe
http://www.zylin.com
.
--
Øyvind Harboe
http://www.zylin.com
objects.
The main advantage I see of having nested functions & trampolines in C
is that they will see more testing. I think it would be really tough
for, say Ada, to rely on features in the backend that are not used at
all by C/C++.
--
Øyvind Harboe
http://www.zylin.com
lines exist? I.e. something
that does not generate code runtime.
My personal uninformed opinion is that trampolines cause more trouble
than they are worth.
--
Øyvind Harboe
http://www.zylin.com
Will not this test fail during execution for callee stack cleanup
calling convention?
Fix attached.
--
Øyvind Harboe
http://www.zylin.com
Index: 20001117-1.c
===
RCS file: /cvsroot/gcc/gcc/gcc/testsuite/gcc.dg/20001117-1.c,v
>From within a "define_insn" asm generation C code, is there a way to
figure out the difference between the frame pointer and the stack
pointer?
Based upon your feedback so far, I believe the answer is no.
--
Øyvind Harboe
http://www.zylin.com
7;m wondering about is whether it is possible, in the code that
gets invoked in a "define_insn" to generate the actual assembly, to find
out the difference between the SP and the frame address.
--
Øyvind Harboe
http://www.zylin.com
On Wed, 2005-03-02 at 10:03 -0500, Vladimir Makarov wrote:
> Øyvind Harboe wrote:
>
> >Is there an existing technique to figure out the difference between
> >the frame address and the stack pointer during code generation of
> >arbitary instructions?
> >
> &
I think frame ointer to stack pointer
elimination can fail. If this is the case, is it because the difference
between frame pointer and stack pointer is not a constant or some other
reason?
I'm just curious and would like to read more.
--
Øyvind Harboe
http://www.zylin.com
16 matches
Mail list logo
