From 1f563c4ee596ae44ebb929ffef65a2bc74e93f7d Mon Sep 17 00:00:00 2001
From: "henthe-5@student.ltu.se" <henthe-5@student.ltu.se>
Date: Fri, 22 Feb 2019 09:19:13 +0100
Subject: [PATCH] bare4_3
---
examples/bare4.rs | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/examples/bare4.rs b/examples/bare4.rs
index 81f7d26..4669705 100644
--- a/examples/bare4.rs
+++ b/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)
--
GitLab