bare4_3

examples/bare4.rs

@@ -112,7 +112,7 @@ fn main() -> ! {
 //
 //    ** your answer here **
 //
-//      read_volatile is inherently unsafe because reading a volatile variable is, indeed volatile
+//      read_volatile is inherently unsafe because reading a volatile variable is indeed volatile.
 //      A volatile variable is volatile because it moves the value out of the address without
 //      preventing further usage of that specific address.
 //
@@ -129,14 +129,23 @@ fn main() -> ! {
 //
 //    ** your answer here **
 //
+//      If you did some weird ordering of some important operations, you will more than likely get
+//      some unexpected behaviour (ex: a LED does not turn on when it should)
+//
 //    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 you swap lets say for example line 63 with line 71, you would most certainly get some unexpected behaviour, since you set the LED to high,
+//      when you have not set the output to be the GP01A
+//
 //    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 **
 //
+//      From a data dependency point of view one could argue that the compiler could see that write and read depends on
+//      eachother and therefore not reorder them.
+//
 //    Commit your answers (bare4_3)