From 161fbc39858485d884cc88f2c8c5a0e1a4b72a7d Mon Sep 17 00:00:00 2001
From: Hammarkvast <tomham-3@student.ltu.se>
Date: Wed, 8 Apr 2020 13:28:22 +0200
Subject: [PATCH] bare4_3
---
examples/bare4.rs | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/examples/bare4.rs b/examples/bare4.rs
index 6628884..8bf4d12 100644
--- a/examples/bare4.rs
+++ b/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)
--
GitLab