cas: fix typo

1 files changed, 10 insertions, 11 deletions

diff --git a/content/2023-09-01-cas-llsc-aba/index.md b/content/2023-09-01-cas-llsc-aba/index.md
index 177404f..ab7387b 100644
--- a/content/2023-09-01-cas-llsc-aba/index.md
+++ b/content/2023-09-01-cas-llsc-aba/index.md
@@ -13,18 +13,17 @@ different semantics of `atomic` instructions (compare and swap `CAS` vs
 load-linked store-conditional `LL/SC`), `lock-free` programming and the `ABA`
 problem.
 
-In the realm of `lock-free` programming and the `ABA` problem, I shared a war
-story from some years ago when I was debugging a random memory corruption in
-our multi-threaded simulator. Sharing that story actually gave the idea to
-write this post as reference for potential new co-workers or all the internet
-people <3.
+In the realm of `lock-free` programming and the `ABA` problem, I shared a story
+from some years ago when I was debugging a random memory corruption in our
+multi-threaded simulator. Sharing that story actually gave the idea to write
+this post as reference for potential new co-workers or all the internet people
+<3.
 
 After many hours of debugging the random memory corruption, which *obviously*
-did not occur very often, it turned out to be a bug in a custom memory
-allocator. To be more precise, in a primitive used by the allocator to manage a
-list of free memory blocks. The allocator was used from multiple threads
-concurrently and hence `pushing` and `popping` free memory blocks had to be
-thread-safe.
+did not occur very often, turned out to be a bug in a custom memory allocator.
+To be more precise, in a primitive used by the allocator to manage a list of
+free memory blocks. The allocator was used from multiple threads concurrently
+and hence `pushing` and `popping` free memory blocks had to be thread-safe.
 
 The operations to manage the free block list were implemented with an
 `lock-free` algorithm, which we will visit later when analyzing the bug.
@@ -595,7 +594,7 @@ _exclusive_addr_ and the data to be written with the saved _exclusive_val_.
 Iff both compare true, the _store exclusive_ is carried out successfully.
 
 The following pseudo code taken from a comment in
-[QEMU:ranslate-a64.c][qemu-a64-ex] shows how QEMU emits _store exclusive_
+[QEMU:translate-a64.c][qemu-a64-ex] shows how QEMU emits _store exclusive_
 instructions where `env` refers to the cpu state.
 ```c
 ///  gen_store_exclusive(..)