Am 14.09.2002 07:09:48, schrieb "Harry Lemmens" <[email protected]>:
>I have found what I think may be a bug with switch() But cannot reproduce
>with a simple example. (Not exactly a Bug, but 256 Bytes of wasted space are
>inserted in the machine code after a switch() statement, independent of the
>optimise parameter .
>Extract from the Listing showing the flaw
>
> 10:test.c **** switch(c)
> 74 .stabn 68,0,10,.LM3-diag
> 75 .LM3:
> 76 0004 3F50 CFFF add #llo(-49), r15
> 77 0008 3F90 4A00 cmp #llo(74), r15
> 78 000c 4E2C jhs .L2
> 79 000e 0F5F rla r15
> 80 0010 104F 0000 br .L12(r15) ; .L12
> 81 .p2align 1,0
> 82 .L12:
> 83 0014 0000 .word .L2
> 84 0016 0000 .word .L2
> 85 0018 0000 .word .L2
>
> ... (for 256 bytes of FlashRom space)
well here you cut out e.g.
132 0076 0000 .word .L2
133 0078 0000 .word .L6 ;<<<<<<<<
134 007a 0000 .word .L2
they are not all the same these entries!
(but as most of your "case"es are just "break;" most are the same...)
>
> 155 00a4 0000 .word .L2
> 156 00a6 0000 .word .L2
> 157 .L6:
> 11:test.c **** {
> 12:test.c ****
> 13:test.c **** case 't' : //
> 14:test.c **** break;
>
>The following is the minimum I have been able to create, and still reproduce
>the flaw.
>If I alter each case to become sequential (IE: 1,2,..7) The bug disappears.
>
>If the last case statement is removed, the flaw disappears. Seems very
>sensitive to something in the code
what you are seeing is a "jump table".
add #llo(-49), r15 ;subtract 'cause no values <49 are in
the case stmts
cmp #llo(74), r15 ;check for upper limit: c < (49+74)
jhs .L2
rla r15 ; multiply by two -> use c*2 as offset
in the jumptable
br .L12(r15) ; .L12 ; -> add PC, (c-49)*2
it's the same technique, TI sugest to demux the TIMER_A1 interrupt
vector.
if you only switch for a few values, a jump table may be bigger than
testing individual values, but in this case, the jump table seems to be
the smaller solution.
its not a bug, its a feature ;-)
chris
