* [ECOS] arm-elf-gcc question
@ 2000-11-10 14:39 Grant Edwards
2000-11-10 14:47 ` Gary Thomas
0 siblings, 1 reply; 4+ messages in thread
From: Grant Edwards @ 2000-11-10 14:39 UTC (permalink / raw)
To: ecos-discuss
This is really a gcc question, but I figure this is the list
with the most people using the same version I am. ;)
Do other people with the arm-elf-gcc 2.95.2 with ecos patches
get this sort of incredibly odd-looking code, or is mine
broken?
[I've only written two compilers in my life, neither of which
was anything to brag about, but... yikes!]
=============================testit.c=================================
struct
{
volatile unsigned char a;
volatile unsigned char b;
volatile unsigned char c;
}foo;
void bar(void)
{
volatile unsigned char d;
unsigned char e;
while ((e=foo.a) != 0x01)
switch (e)
{
case 0x02:
case 0x04:
d = foo.b;
break;
case 0x20:
case 0x00:
d = foo.c;
break;
}
}
======================================================================
$ arm-elf-gcc -g -c -O2 testit.c
$ arm-elf-objdump --source testit.o
testit.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <bar>:
{
volatile unsigned char d;
unsigned char e;
while ((e=foo.a) != 0x01)
0: e1a0c00d mov r12, sp
4: e92dd800 stmdb sp!, {r11, r12, lr, pc}
8: e59f20a4 ldr r2, [pc, #a4] ; b4 <bar+0xb4>
c: e24dd004 sub sp, sp, #4 ; 0x4
10: e5d23000 ldrb r3, [r2]
14: e24cb004 sub r11, r12, #4 ; 0x4
18: ea00002f b dc <bar+0xdc>
switch (e)
1c: e3530020 cmp r3, #32 ; 0x20
20: 979ff103 ldrls pc, [pc, r3, lsl #2]
24: ea00002e b e4 <bar+0xe4>
28: 000000b8 streqh r0, [r0], -r8
2c: 000000c0 andeq r0, r0, r0, asr #1
30: 000000ac andeq r0, r0, r12, lsr #1
34: 000000c0 andeq r0, r0, r0, asr #1
38: 000000ac andeq r0, r0, r12, lsr #1
3c: 000000c0 andeq r0, r0, r0, asr #1
40: 000000c0 andeq r0, r0, r0, asr #1
44: 000000c0 andeq r0, r0, r0, asr #1
48: 000000c0 andeq r0, r0, r0, asr #1
4c: 000000c0 andeq r0, r0, r0, asr #1
50: 000000c0 andeq r0, r0, r0, asr #1
54: 000000c0 andeq r0, r0, r0, asr #1
58: 000000c0 andeq r0, r0, r0, asr #1
5c: 000000c0 andeq r0, r0, r0, asr #1
60: 000000c0 andeq r0, r0, r0, asr #1
64: 000000c0 andeq r0, r0, r0, asr #1
68: 000000c0 andeq r0, r0, r0, asr #1
6c: 000000c0 andeq r0, r0, r0, asr #1
70: 000000c0 andeq r0, r0, r0, asr #1
74: 000000c0 andeq r0, r0, r0, asr #1
78: 000000c0 andeq r0, r0, r0, asr #1
7c: 000000c0 andeq r0, r0, r0, asr #1
80: 000000c0 andeq r0, r0, r0, asr #1
84: 000000c0 andeq r0, r0, r0, asr #1
88: 000000c0 andeq r0, r0, r0, asr #1
8c: 000000c0 andeq r0, r0, r0, asr #1
90: 000000c0 andeq r0, r0, r0, asr #1
94: 000000c0 andeq r0, r0, r0, asr #1
98: 000000c0 andeq r0, r0, r0, asr #1
9c: 000000c0 andeq r0, r0, r0, asr #1
a0: 000000c0 andeq r0, r0, r0, asr #1
a4: 000000c0 andeq r0, r0, r0, asr #1
a8: 000000b8 streqh r0, [r0], -r8
{
case 0x02:
case 0x04:
d = foo.b;
ac: e5d23001 ldrb r3, [r2, #1]
break;
b0: ea00002d b 16c <bar+0x16c>
b4: 00000000 andeq r0, r0, r0
case 0x20:
case 0x00:
d = foo.c;
b8: e5d23002 ldrb r3, [r2, #2]
bc: e54b300d strb r3, [r11, -#13]
break;
}
c0: e5d23000 ldrb r3, [r2]
c4: e20330ff and r3, r3, #255 ; 0xff
c8: e3530001 cmp r3, #1 ; 0x1
cc: 1a000005 bne e8 <bar+0xe8>
}
d0: e91ba800 ldmdb r11, {r11, sp, pc}
--
Grant Edwards
grante@visi.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [ECOS] arm-elf-gcc question
2000-11-10 14:39 [ECOS] arm-elf-gcc question Grant Edwards
@ 2000-11-10 14:47 ` Gary Thomas
2000-11-10 15:26 ` Grant Edwards
0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2000-11-10 14:47 UTC (permalink / raw)
To: Grant Edwards; +Cc: ecos-discuss
On 10-Nov-2000 Grant Edwards wrote:
> This is really a gcc question, but I figure this is the list
> with the most people using the same version I am. ;)
>
> Do other people with the arm-elf-gcc 2.95.2 with ecos patches
> get this sort of incredibly odd-looking code, or is mine
> broken?
>
> [I've only written two compilers in my life, neither of which
> was anything to brag about, but... yikes!]
>
This basically a jump table representing your switch statement.
The compiler makes choices about how to implement such a statement
and in this case, it was decided that a table of addresses indexed
by the "case" selector (i.e. a jump table) was the fastest/cheapest
way to go.
What did you want/expect instead?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] arm-elf-gcc question
2000-11-10 14:47 ` Gary Thomas
@ 2000-11-10 15:26 ` Grant Edwards
2000-11-11 5:08 ` Gary Thomas
0 siblings, 1 reply; 4+ messages in thread
From: Grant Edwards @ 2000-11-10 15:26 UTC (permalink / raw)
To: Gary Thomas; +Cc: ecos-discuss
On Fri, Nov 10, 2000 at 03:47:28PM -0700, Gary Thomas wrote:
> On 10-Nov-2000 Grant Edwards wrote:
> > This is really a gcc question, but I figure this is the list
> > with the most people using the same version I am. ;)
> >
> > Do other people with the arm-elf-gcc 2.95.2 with ecos patches
> > get this sort of incredibly odd-looking code, or is mine
> > broken?
> >
> > [I've only written two compilers in my life, neither of which
> > was anything to brag about, but... yikes!]
>
> This basically a jump table representing your switch statement.
> The compiler makes choices about how to implement such a statement
> and in this case, it was decided that a table of addresses indexed
> by the "case" selector (i.e. a jump table) was the fastest/cheapest
> way to go.
>
> What did you want/expect instead?
I dunno. Something more like what you get if you write it as
an equivalent if/else. I thought it was pretty standard for
compilers to figure out whether a switch() was better
represented by sequential tests or by a jump table. For a
sparsely populated "case space" compilers I've used in the past
have generally swtiched to sequential compares to save space.
Even with size optimization turned on (-Os), it generates the
jumptable version which is 5X larger than sequential compares.
Memory is cheap, but it's never cheap enough. ;)
If the size of the case space is increased slightly (from 0x20
to 0x28) gcc does switch to sequential compares.
The threshold could probably be lower -- especially on the ARM.
The ARM better at comparing for multiple values than many other
CPUs. You can test for any of 8 const values in 8 instructions
(best case):
cmp r3, #1
cmpne r3, #2
[...]
cmpne r3, #8
While on other CPUs it takes roughly twice as many instructions.
--
Grant Edwards
grante@visi.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] arm-elf-gcc question
2000-11-10 15:26 ` Grant Edwards
@ 2000-11-11 5:08 ` Gary Thomas
0 siblings, 0 replies; 4+ messages in thread
From: Gary Thomas @ 2000-11-11 5:08 UTC (permalink / raw)
To: Grant Edwards; +Cc: ecos-discuss
This is definitely a C compiler issue. I'd suggest that you
take it to them (gcc@gcc.gnu.org) if you want to pursue it.
On 10-Nov-2000 Grant Edwards wrote:
> On Fri, Nov 10, 2000 at 03:47:28PM -0700, Gary Thomas wrote:
>
>> On 10-Nov-2000 Grant Edwards wrote:
>> > This is really a gcc question, but I figure this is the list
>> > with the most people using the same version I am. ;)
>> >
>> > Do other people with the arm-elf-gcc 2.95.2 with ecos patches
>> > get this sort of incredibly odd-looking code, or is mine
>> > broken?
>> >
>> > [I've only written two compilers in my life, neither of which
>> > was anything to brag about, but... yikes!]
>>
>> This basically a jump table representing your switch statement.
>> The compiler makes choices about how to implement such a statement
>> and in this case, it was decided that a table of addresses indexed
>> by the "case" selector (i.e. a jump table) was the fastest/cheapest
>> way to go.
>>
>> What did you want/expect instead?
>
> I dunno. Something more like what you get if you write it as
> an equivalent if/else. I thought it was pretty standard for
> compilers to figure out whether a switch() was better
> represented by sequential tests or by a jump table. For a
> sparsely populated "case space" compilers I've used in the past
> have generally swtiched to sequential compares to save space.
> Even with size optimization turned on (-Os), it generates the
> jumptable version which is 5X larger than sequential compares.
>
> Memory is cheap, but it's never cheap enough. ;)
>
> If the size of the case space is increased slightly (from 0x20
> to 0x28) gcc does switch to sequential compares.
>
> The threshold could probably be lower -- especially on the ARM.
> The ARM better at comparing for multiple values than many other
> CPUs. You can test for any of 8 const values in 8 instructions
> (best case):
>
> cmp r3, #1
> cmpne r3, #2
> [...]
> cmpne r3, #8
>
> While on other CPUs it takes roughly twice as many instructions.
>
> --
> Grant Edwards
> grante@visi.com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-11-11 5:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-10 14:39 [ECOS] arm-elf-gcc question Grant Edwards
2000-11-10 14:47 ` Gary Thomas
2000-11-10 15:26 ` Grant Edwards
2000-11-11 5:08 ` Gary Thomas
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).