further improvements

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/arm-cpp-memory-model/1.md

@@ -36,9 +36,11 @@ MULT R3, #R1, #5 // B
 
 4. **Hardware Perceived Order** - this is the perspective observed by other devices in the system, which can differ if the hardware buffers writes or merges memory operations. Crucially, the hardware-perceived order can vary between CPU architectures, for example between x86 and Arm, and this should be considered when porting applications. 
 
-An abstract diagram from the academic paper is shown below [Maranget et. al, 2012]. A write operation in one of the 5 threads in the pentagon below might propagate to the other threads in any order. 
+An abstract diagram from the academic paper is shown below ["A Tutorial Introduction to the ARM and POWER Relaxed Memory Models" Maranget et. al, 2012]. 
 
-![abstract_model](./multi-copy-atomic.png)
+A write operation in one of the five threads in the pentagon below might propagate to the other threads in any order. 
+
+!["Multi-copy Atomic Model" abstract_model](./multi-copy-atomic.png)
 
 ## High-level differences between the Arm Memory Model and the x86 Memory Model
 

content/learning-paths/servers-and-cloud-computing/arm-cpp-memory-model/2.md

@@ -8,9 +8,9 @@ layout: learningpathall
 
 ## The C++ memory model for single threads
 
-For a long time, writing C++ programs on single-core systems was relatively straightforward. The compiler could reorder instructions however it wished, so long as the program’s observable behavior remained unchanged. This optimization freedom is commonly referred to as the “as-if” rule. Essentially, compilers can optimize away or move instructions around as if the code had not changed, provided they do not affect inputs, outputs, or volatile accesses.
+For a long time, writing C++ programs on single-core systems was straightforward. Compilers could reorder instructions freely, as long as the program’s observable behavior remained unchanged. This flexibility is commonly referred to as the “as-if” rule. Essentially, compilers could optimize away or move instructions around as if the code had not changed, provided the changes did not affect inputs, outputs, or volatile memory accesses.
 
-The single-threaded world was simpler: you wrote code, the compiler made it faster (by safely reordering or eliminating instructions), and performance benefited. Over time, multi-core processors and multi-threaded applications became the norm. Suddenly, reordering instructions was not only about performance because it could change the meaning of programs with threads reading and writing shared data simultaneously.
+The single-threaded world was simpler: you wrote code, the compiler safely reordered or eliminated instructions to make it faster, and your program performed better. But as multi-core processors and multi-threaded applications became common, instruction reordering was not only about improving performance - it could actually change the meaning of programs, especially when multiple threads accessed shared data simultaneously.
 
 ### Expanding the memory model for multiple threads