* Re: code generation for arm targets
@ 2000-03-22 10:11 Nick Clifton
0 siblings, 0 replies; 3+ messages in thread
From: Nick Clifton @ 2000-03-22 10:11 UTC (permalink / raw)
To: vlebedev; +Cc: gcc
Hi Vadim,
: I see some strange things in code generation for arm-elf target:
:
: 28 str lr, [sp, #-4]!
:
: Take a look at line 28.
:
: The lr register is saved in the "unallocated" stack area. The stack
: pointer is updated to include local variables frame only at line
: 33.
No its not.
: Wouldn't it be safer (with respect to interrupt and signal handling)
: to update the stack pointer immiedately upon entering the function?
You missed the ! at the end of the instruction. This indicates a
pre-indexed addressing mode. In this case the instruction will
compute:
sp = sp - 4
*sp = lr
so that stack pointer is updated before (or at the same time as) the
stack slot is written to.
Cheers
Nick
^ permalink raw reply [flat|nested] 3+ messages in thread
* code generation for arm targets
@ 2000-03-22 7:49 Vadim Lebedev
2000-03-22 10:11 ` Richard Earnshaw
0 siblings, 1 reply; 3+ messages in thread
From: Vadim Lebedev @ 2000-03-22 7:49 UTC (permalink / raw)
To: Gcc@Gcc.Gnu.Org
Hi,
I see some strange things in code generation for arm-elf target:
example:
// demo2.cpp
struct toto{
int a;
char (*qwerty)(int opt);
};
struct toto test;
char test_qwerty(int opt)
#if 0
{
return (opt+0x40);
}
#else
;
#endif
void init(void){
test.qwerty = test_qwerty;
}
struct xx{
char b[528];
int x[32];
};
void doit(xx*);
int main(void)
{
char fab;
struct xx s;
s.b[0] = 1;
s.b[527] = 2;
s.x[0] = 3;
s.x[31] = 4;
doit(&s);
init();
/* la ligne qui tue */
fab=test.qwerty(10);
}
The generated code is:
1 @ Generated by gcc 2.96 20000307 (experimental) for ARM/elf
2 .file "demo2.cpp"
3 gcc2_compiled.:
4 .text
5 .align 2
6 .global init__Fv
7 .type init__Fv,function
8 init__Fv:
9 @ args = 0, pretend = 0, frame = 0
10 @ frame_needed = 0, current_function_anonymous_args = 0
11 ldr r2, .L4
12 ldr r3, .L4+4
13 str r3, [r2, #4]
14 mov pc, lr
15 .L5:
16 .align 2
17 .L4:
18 .word test
19 .word test_qwerty__Fi
20 .Lfe1:
21 .size init__Fv,.Lfe1-init__Fv
22 .align 2
23 .global main
24 .type main,function
25 main:
26 @ args = 0, pretend = 0, frame = 656
27 @ frame_needed = 0, current_function_anonymous_args = 0
28 str lr, [sp, #-4]!
29 mov r2, #2
30 mov r1, #3
31 mov ip, #4
32 mov r3, #1
33 sub sp, sp, #656
34 mov r0, sp
35 strb r3, [sp, #0]
36 strb r2, [sp, #527]
37 str r1, [sp, #528]
38 str ip, [sp, #652]
39 bl doit__FP2xx
40 bl init__Fv
41 ldr r3, .L8
42 mov r0, #10
43 mov lr, pc
44 ldr pc, [r3, #4]
45 mov r0, #0
46 add sp, sp, #656
47 ldmfd sp!, {pc}
48 .L9:
49 .align 2
50 .L8:
51 .word test
52 .Lfe2:
53 .size main,.Lfe2-main
54 .global test
55 .bss
56 .align 2
57 .type test,object
58 .size test,8
59 test:
60 .space 8
61 .ident "GCC: (GNU) 2.96 20000307 (experimental)"
Take a look at line 28.
The lr register is saved in the "unallocated" stack area. The stack pointer
is updated
to include local variables frame only at line 33.
Wouln't it be safer (with respect to interrupt and signal handling) to
update the stack
pointer immiedately upon entering the function?
Another question:
It seems that in last week snapshots exception handling is completely broken
for arm
targets... Could somebody confirm it?
Thanks
Vadim
Vadim
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: code generation for arm targets
2000-03-22 7:49 Vadim Lebedev
@ 2000-03-22 10:11 ` Richard Earnshaw
0 siblings, 0 replies; 3+ messages in thread
From: Richard Earnshaw @ 2000-03-22 10:11 UTC (permalink / raw)
To: Vadim Lebedev; +Cc: rearnsha
vlebedev@aplio.fr said:
> 28 str lr, [sp, #-4]!
> Take a look at line 28.
> The lr register is saved in the "unallocated" stack area. The stack
> pointer is updated to include local variables frame only at line 33.
> Wouln't it be safer (with respect to interrupt and signal handling) to
> update the stack pointer immiedately upon entering the function?
Take another look. The store is a pre-decrement write -- that's what the
'!' is for. The instruction allocates a word of stack as it writes the
location, so there is no problem.
R.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-03-22 10:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-22 10:11 code generation for arm targets Nick Clifton
-- strict thread matches above, loose matches on Subject: below --
2000-03-22 7:49 Vadim Lebedev
2000-03-22 10:11 ` Richard Earnshaw
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).