bare4_3

examples/rtic_bare4.rs

@@ -35,8 +35,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)]
@@ -119,16 +119,21 @@ const APP: () = {
 //
 //    Why is it important that ordering of volatile operations are ensured by the compiler?
 //
-//    ** your answer here **
+//    Since you are accessing memory outside of the aqusition of rust
+//      the ordering is very important.
 //
 //    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 **
+//    If the write instruction on line 65 before the read instruction on line 64
+//      The word on address GPIOA_MODER would look completely different since r is no longer a copy
+//      with modifications for the word you are writing to.
+//      Or if one of the writes for PA5 happens before any of the initialization writes to RCC_AHB1ENR or BPIOA_MODER.
 //
 //    Without the non-reordering property of `write_volatile/read_volatile` could that happen in theory
 //    (argue from the point of data dependencies).
 //
-//    ** your answer here **
+//    Since the PA5 write does not depend on anything from the initialization in software point of view,
+//      Theoretically it could happen. 
 //
 //    Commit your answers (bare4_3)