diff --git a/examples/.bare4.rs.swp b/examples/.bare4.rs.swp
deleted file mode 100644
index 61ee4b1433b1f23c9614525fa4cd5f8b47ea02f2..0000000000000000000000000000000000000000
Binary files a/examples/.bare4.rs.swp and /dev/null differ
diff --git a/examples/bare4.rs b/examples/bare4.rs
index 4262927c0ec43aa9ba7464846d0a321e78768d15..13b684d1f89789a378432e2dacc85b3ddb1dc144 100644
--- a/examples/bare4.rs
+++ b/examples/bare4.rs
@@ -103,14 +103,22 @@ fn main() {
 //
 // why is important that ordering of volatile operations are ensured by the compiler?
 // ** your answer here **
+//  The order of the operations can efekt the out come of the program, race condition.
 //
 // 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 **
+//  in som cases wen seting an walue or aktivating a perifial is nessesary to do befor a read or
+//  simelar.
+//  seting gpioA ass activ befor reading. the compiler do not know if a perifial writ is to set a
+//  setin or blink a led.
 //
 // 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 **
+// If the compiler is left to it self wil it in som case changes the order of the read/write
+// operation. if somthig can gow wrong it will. sow it is lickly that the program is broken if the
+// is no forsd ordering
 //
 // commit your answers (bare4_3)