diff --git a/examples/bare4.rs b/examples/bare4.rs index 5186bc9b000e64b04000b4b25b57b9c644687ba8..cf488f2bb4ef3c24f8efa2fdcc2723e480c9c5ca 100644 --- a/examples/bare4.rs +++ b/examples/bare4.rs @@ -116,13 +116,15 @@ fn main() -> ! { // // error: aborting due to previous error // -// Reading adresses is not safe so it panics +// read_voliatile is a unsafe so it panics // // Digging a bit deeper, why do you think `read_volatile` is declared `unsafe`. // (https://doc.rust-lang.org/core/ptr/fn.read_volatile.html, for some food for thought ) // // ** your answer here ** -// +// +// because rust cant guarantee to know whats on the memmory address +// // Commit your answers (bare4_2) // // 3. Volatile read/writes are explicit *volatile operations* in Rust, while in C they @@ -135,15 +137,31 @@ fn main() -> ! { // Why is it important that ordering of volatile operations are ensured by the compiler? // // ** your answer here ** +// +// because volatile just reads the momory address so if it is done in the wrong order it +// might read values that are wrong and the use them. // // 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 ** -// +// +// // power on GPIOA +// let r = read_u32(RCC_AHB1ENR); // read +// write_u32(RCC_AHB1ENR, r | 1); // set enable +// +// //configure PA5 as output +// let r = read_u32(GPIOA_MODER) & !(0b11 << (5 * 2)); // read and mask +// write_u32(GPIOA_MODER, r | 0b01 << (5 * 2)); // set output mode +// +// if poweron giopa would happen after the config it could cause problems +// // 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 ** +// +// its important that they are non-reordering because otherwise if a write_volitile is dependent on data from a read_volitile +// and its reorderd it would not have all the relevent data it needs. // // Commit your answers (bare4_3)