This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Changing the frame layout of H8 port to reduce code size
- From: Kazu Hirata <kazu at cs dot umass dot edu>
- To: gnuh8 at gnuh8 dot org dot uk, gcc at gcc dot gnu dot org
- Cc: toshiyasu dot morita at renesas dot com, law at redhat dot com
- Date: Tue, 27 Jan 2004 03:02:40 -0500 (EST)
- Subject: Changing the frame layout of H8 port to reduce code size
Hi,
I am thinking about changing the frame layout of H8 port to reduce
code size and would like to ask for comments. Currently, the frame
layout used in h8300-{elf,hms}-gcc looks like
argument
:
argument
program counter
frame pointer (can be omitted)
local
:
local
saved register
:
saved register <- sp
with the stack pointer pointing to the stack location containing the
last saved register. I am proposing to flip the order of the locals
and the saved registers like so
argument
:
argument
program counter
frame pointer (can be omitted)
saved register
:
saved register
local
:
local <- sp
Assuming that we use -fomit-frame-pointer and save three registers,
the first long word of the local in the original layout is accessed
like
mov.l @(12,er7),er0
whereas in my proposed layout, the first long word is pointed to by
the stack pointer (with no offset), so the following would suffice,
saving two bytes.
mov.l @er7,er0
Also if you want to pass a stack location to a function, you might see
sub.l er0,er0
add.b #12,er0
add.l er7,er0
jsr @_foo
But this would become
mov.l er7,er0
jsr @_foo
As another example,
sub.l er0,er0
add.b #16,er0
add.l er7,er0
jsr @_foo
would become
mov.l er7,er0
adds #4,er0
jsr @_foo
A quick test with uClinux for H8 shows that all the object files
shrink or retain the same size.
Any comments? You won't be affected unless your application digs up
the stack upward. Otherwise, you're in trouble. If that's the case,
I'll refrain from checking in the above change or add a switch to go
back to the old layout (or a switch to enable the new layout). Note
that I am not changing the calling conventions, so linking code
compiled with different versions of GCC would be OK.
p.s.
i386 port of GCC uses this kind of frame layout. That is, it saves
registers and then allocates locals.
Kazu Hirata