Lpc2000

At 03:47 PM 2/18/05 +1100, Bruce Paterson wrote:
> > 2/ When I display mixed assembly and code, and single step in this mode
> > (code was flashed using serial port seperately) the order seems all
> > screwed. It's like Insight has got which assembly belongs to which bit
> > of C code all out of whack so the effect is you jump all over the C file
>
>Here's an example with just pure assembly. Insight console screen shows
>this for library function _puts_r.  Note how it isn't sequential !
>
>-       0x4224  <_puts_r+8>:            sub     r11, r12, #4    ; 0x4
>-       0x4228  <_puts_r+12>:           sub     sp, sp, #28     ; 0x1c
>-       0x422c  <_puts_r+16>:           mov     r4, r0
>-       0x4234  <_puts_r+24>:           mov     r5, r1
>-       0x4230  <_puts_r+20>:           mov     r0, r1
>-       0x4238  <_puts_r+28>:           bl      0x4880 <strlen>
>-       0x4248  <_puts_r+44>:           mov     r6, r0
>-       0x4264  <_puts_r+72>:           str     r5, [r11, #-52]
>-       0x4274  <_puts_r+88>:           str     r6, [r11, #-48]
>-       0x423c  <_puts_r+32>:           ldr     r3, [pc, #76]   ; 0x4290 <$d>
>-       0x424c  <_puts_r+48>:           str     r3, [r11, #-44]
>-       0x4240  <_puts_r+36>:           mov     r2, #1  ; 0x1
>-       0x4250  <_puts_r+52>:           str     r2, [r11, #-40]
>-       0x4244  <_puts_r+40>:           add     r12, r0, #1     ; 0x1
>-       0x4268  <_puts_r+76>:           str     r12, [r11, #-28]
>-       0x4254  <_puts_r+56>:           sub     r3, r11, #52    ; 0x34
>-       0x426c  <_puts_r+80>:           str     r3, [r11, #-36]
>-       0x4258  <_puts_r+60>:           add     r2, r2, r2
>-       0x4270  <_puts_r+84>:           str     r2, [r11, #-32]
>-       0x425c  <_puts_r+64>:           ldr     r0, [r4, #8]
>-       0x4260  <_puts_r+68>:           sub     r1, r11, #36    ; 0x24
>-       0x4278  <_puts_r+92>:           bl      0xa2bc <__sfvwrite>


That fit's with what I've seen.  GCC is more prone to re-ordering than 
other compilers I've used.  Several things to note on the above sequence
         - The assembly is in strict rising order  (as would be expected)
         - The assembly maintains the proper sequence.  In particular note 
that the order jumps around between function calls  but the function call 
order does not change and statements are not re-ordered from before to 
after the function call.  I don't think the former can be done (I'm not 
sure about the latter, if the statements don't depend on the function calls 
or global variables)

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III