bare4_3

examples/bare4.rs

@@ -39,8 +39,8 @@ use address::*;
 
 #[inline(always)]
 fn read_u32(addr: u32) -> u32 {
-    //unsafe { core::ptr::read_volatile(addr as *const _) }
-    core::ptr::read_volatile(addr as *const _)
+    unsafe { core::ptr::read_volatile(addr as *const _) }
+    //core::ptr::read_volatile(addr as *const _)
 }
 
 #[inline(always)]
@@ -128,16 +128,20 @@ fn main() -> ! {
 //
 //    Why is it important that ordering of volatile operations are ensured by the compiler?
 //
-//    ** your answer here **
+//    ** Variable used by volatile operations may change between accesses,
+//      reordering might introduce undefined or unexpected behaviour,
+//      if a read is ordered before a write the value would alter and not return the expected,
+//      or if reading from a register is performed before that register is set as read.  **
 //
 //    Give an example in the above code, where reordering might make things go horribly wrong
 //    (hint, accessing a peripheral not being powered...)
 //
-//    ** your answer here **
+//    ** Read or write to GPIOA_BSRR before GPIOA_MODER is set to output,
+//      doing anything before setting RCC_AHB1ENR would be bad **
 //
 //    Without the non-reording proprety of `write_volatile/read_volatile` could that happen in theory
 //    (argue from the point of data dependencies).
 //
-//    ** your answer here **
+//    ** Writing/Reading in wrong order would result in unexpexed results. **
 //
 //    Commit your answers (bare4_3)