summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRichard Braun <rbraun@sceen.net>2019-08-20 00:45:12 +0200
committerRichard Braun <rbraun@sceen.net>2019-08-20 00:45:12 +0200
commit0eb44e36d9a699ee00ab8e33a5f913f81955df2d (patch)
tree1adedc2958782197e298c2b387b5d9147458d21c
parenta4b531d146c95e688db9618506315e8e61e2484d (diff)
Edit the memory model man page
-rw-r--r--doc/memory.9.txt36
1 files changed, 19 insertions, 17 deletions
diff --git a/doc/memory.9.txt b/doc/memory.9.txt
index 67441bcd..f88025ba 100644
--- a/doc/memory.9.txt
+++ b/doc/memory.9.txt
@@ -28,12 +28,15 @@ INTRA-THREAD MEMORY ORDERING
Memory ordering in a single thread of execution behaves as defined by
the C specification the kernel is conforming to. This means that the
generated code must not change the _observable behavior_ of the program,
-which is informally called the "as-if rule". During its execution,
-the kernel may change the environment. For example, it may configure
-an MMU and change the entire memory map. Environmental changes may
-conflict with compiler optimizations. Since the compiler cannot
-recognize these changes and adjust the generated code accordingly,
-this is a responsibility of the developer.
+which is informally called the _as-if rule_. During its execution,
+the kernel may change the environment, and environmental changes may
+conflict with compiler optimizations. For example, it may configure
+an MMU and change the entire memory map. Compiler optimizations, and
+in particular instruction reordering, may cause instructions intended
+to run with the new memory map to run with the previous one, and
+potentially trigger a fault. Since the compiler cannot recognize such
+situations and adjust the generated code accordingly, this is a
+responsibility of the developer.
This memory model defines several ways to control code generation.
@@ -41,16 +44,15 @@ Local atomic operations
~~~~~~~~~~~~~~~~~~~~~~~
_Local atomic operations_, as defined in module:kern/latomic, are similar
-to the standard atomic operations, but are only valid on a single processor.
-They are atomic with respect to one another and interrupts. They may
-be used for communication between a thread and an interrupt handler
-interrupting that thread. Because local atomic operations may not be
-used for inter-processor communication, they allow a cheaper implementation
-than atomic operations. Because they only need to be atomic with respect
-to one another and interrupts, they may be built using a generic and
-portable implementation using interrupt-based critical sections, which
-is useful when starting a new port, or if the target architecture supports
-a single processor at most and doesn't provide atomic instructions.
+to global atomic operations, but are only valid on a single processor.
+They are atomic with respect to one another and interrupts. Because they
+may not be used for inter-processor communication, they allow a cheaper
+implementation than atomic operations. Because they only need to be
+atomic with respect to one another and interrupts, they may be provided by
+a generic and portable implementation built with interrupt-based critical
+sections, which is useful when starting a new port, or if the target
+architecture supports a single processor at most and doesn't provide
+atomic instructions.
Strong sequencing
~~~~~~~~~~~~~~~~~
@@ -64,7 +66,7 @@ they affect the implementation in addition to the abstract machine.
Here is the list of strong sequence points :
* SC local atomic operation or fence
-* SC atomic operation or fence
+* SC global atomic operation or fence
* volatile inline assembly with the memory clobber
SEE