Lpc2000

At 03:20 PM 2/21/05 +1100, Bruce Paterson wrote:
>Robert Adsett wrote:
>
> > 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
>
>I'm afraid I don't understand the above statements. Neither the first or
>the 2nd columns are in order. That is, even if we jumped around in the C
>code (middle column with puts_r), I would have expected the 1st column
>to have rising addresses (location of actual assembler code).....but it
>doesn't; It's all over the place as well !


You're right I missed that.  I do remember when I was single stepping that 
the assembly code did make sense.  It also matched the assembly output from 
the compiler if I remember correctly.

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