[ECOS] arm-elf-gcc question

[ECOS] arm-elf-gcc question

[Grant Edwards]

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

RE: [ECOS] arm-elf-gcc question

[Gary Thomas]

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?

Re: [ECOS] arm-elf-gcc question

[Grant Edwards]

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

Re: [ECOS] arm-elf-gcc question

[Gary Thomas]

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