Refactor LPC17xx to use ioregs!

[bgamari]

This is the beginning of the port of LPC17xx to the new ioregs! infrastructure.

[bharrisau]

Maybe this is where bors died?

[bgamari]

@bharrisau despite the fact that we never asked bors to do anything with this branch?

[bharrisau]

Don't know - the last commit had a pile of bors messages.

[bharrisau]

This is still in-progress, correct?

[bgamari]

@bharrisau yeah, I was planning on focusing my energies on the K20 port which I can more easily test. This can serve as a starting point for someone with LPC17xx hardware though.

[farcaller]

Looking at the size stats the binaries are getting bigger, ioregs!() is not getting optimised enough?

[bgamari]

@farcaller hmm, that's concerning. Let me have a look.

[bgamari]

Consider the following example,

#![feature(phase, asm)]
#![crate_type="staticlib"]
#![no_std]

extern crate core;
extern crate zinc;

use core::option::Some;
use zinc::hal::lpc17xx::pin;
use zinc::hal::pin::GPIO;

#[no_split_stack]
#[no_mangle]
pub fn main() {
  let led = pin::Pin::new(pin::Port0, 16, pin::GPIO, Some(zinc::hal::pin::Out));
  led.set_high();
  led.set_low();
  unsafe { asm!("nop") }
}

Before ioregs! the binary was 280 bytes and main looked pretty good,

000000cc <main>:
  cc:   f24c 0004   movw    r0, #49156  ; 0xc004
  d0:   bf00        nop
  d2:   f2c4 0002   movt    r0, #16386  ; 0x4002
  d6:   6801        ldr r1, [r0, #0]
  d8:   f021 0103   bic.w   r1, r1, #3
  dc:   6001        str r1, [r0, #0]
  de:   f24c 0000   movw    r0, #49152  ; 0xc000
  e2:   f2c2 0009   movt    r0, #8201   ; 0x2009
  e6:   6801        ldr r1, [r0, #0]
  e8:   f441 3180   orr.w   r1, r1, #65536  ; 0x10000
  ec:   6001        str r1, [r0, #0]
  ee:   f44f 3180   mov.w   r1, #65536  ; 0x10000
  f2:   6181        str r1, [r0, #24]
  f4:   61c1        str r1, [r0, #28]
  f6:   4770        bx  lr

After ioregs! things grew by 8 bytes,

000000cc <main>:
  cc:   f24c 0000   movw    r0, #49152  ; 0xc000
  d0:   bf00        nop
  d2:   f2c4 0002   movt    r0, #16386  ; 0x4002
  d6:   6841        ldr r1, [r0, #4]
  d8:   f021 0103   bic.w   r1, r1, #3
  dc:   6041        str r1, [r0, #4]
  de:   f24c 0000   movw    r0, #49152  ; 0xc000
  e2:   f2c2 0009   movt    r0, #8201   ; 0x2009
  e6:   6801        ldr r1, [r0, #0]
  e8:   f441 3180   orr.w   r1, r1, #65536  ; 0x10000
  ec:   6001        str r1, [r0, #0]
  ee:   6981        ldr r1, [r0, #24]
  f0:   f441 3180   orr.w   r1, r1, #65536  ; 0x10000
  f4:   6181        str r1, [r0, #24]
  f6:   69c1        ldr r1, [r0, #28]
  f8:   f441 3180   orr.w   r1, r1, #65536  ; 0x10000
  fc:   61c1        str r1, [r0, #28]
  fe:   4770        bx  lr

Note the repeated ldr and orr instructions. I have no idea how the compiler got away without these previously given it's a volatile access.

[farcaller]

wanted to dump line numbers, figured out that debug info is broken once again in rust-lang/rust#15156

[farcaller]

Ok, the split is what I've expected:

/Users/farcaller/src/zinc/apps/app_test.rs:15
let led = pin::Pin::new(pin::Port0, 16, pin::GPIO, Some(zinc::hal::pin::Out));
  cc: f24c 0004   movw  r0, #49156  ; 0xc004
  d0: f2c4 0002   movt  r0, #16386  ; 0x4002
  d4: 6801        ldr r1, [r0, #0]
  d6: f021 0103   bic.w r1, r1, #3
  da: 6001        str r1, [r0, #0]
  dc: f24c 0000   movw  r0, #49152  ; 0xc000
  e0: f2c2 0009   movt  r0, #8201 ; 0x2009
  e4: 6801        ldr r1, [r0, #0]
  e6: f441 3180   orr.w r1, r1, #65536  ; 0x10000
  ea: 6001        str r1, [r0, #0]
  ec: f44f 3180   mov.w r1, #65536  ; 0x10000
/Users/farcaller/src/zinc/apps/app_test.rs:16
led.set_high();
  f0: 6181        str r1, [r0, #24]
/Users/farcaller/src/zinc/apps/app_test.rs:17
led.set_low();
  f2: 61c1        str r1, [r0, #28]
/Users/farcaller/src/zinc/apps/app_test.rs:18
unsafe { asm!("nop") }
  f4: bf00        nop
  f6: 4770        bx  lr

vs.

/Users/farcaller/src/zinc/apps/app_test.rs:15
let led = pin::Pin::new(pin::Port0, 16, pin::GPIO, Some(zinc::hal::pin::Out));
  d2: f2c4 0002   movt  r0, #16386  ; 0x4002
  d6: 6841        ldr r1, [r0, #4]
  d8: f021 0103   bic.w r1, r1, #3
  dc: 6041        str r1, [r0, #4]
  de: f24c 0000   movw  r0, #49152  ; 0xc000
  e2: f2c2 0009   movt  r0, #8201 ; 0x2009
  e6: 6801        ldr r1, [r0, #0]
  e8: f441 3180   orr.w r1, r1, #65536  ; 0x10000
  ec: 6001        str r1, [r0, #0]
/Users/farcaller/src/zinc/apps/app_test.rs:16
led.set_high();
  ee: 6981        ldr r1, [r0, #24]
  f0: f441 3180   orr.w r1, r1, #65536  ; 0x10000
  f4: 6181        str r1, [r0, #24]
/Users/farcaller/src/zinc/apps/app_test.rs:17
led.set_low();
  f6: 69c1        ldr r1, [r0, #28]
  f8: f441 3180   orr.w r1, r1, #65536  ; 0x10000
  fc: 61c1        str r1, [r0, #28]
/Users/farcaller/src/zinc/apps/app_test.rs:18
unsafe { asm!("nop") }
  fe: 4770        bx  lr

You do read-modify-write where you don't need it, the reg is write-only.

[bgamari]

@farcaller ahhh, of course. Silly me. Indeed marking them wo fixes the issue. Good catch.

[farcaller]

I'll close this one as lpc17xx ioregs will be based on svd