diff --git a/www/atomic_design.html b/www/atomic_design.html index 87a2f624..23148416 100644 --- a/www/atomic_design.html +++ b/www/atomic_design.html @@ -37,7 +37,7 @@

There are currently 3 designs under consideration. They differ in where most -of the implmentation work is done. The functionality exposed to the customer +of the implementation work is done. The functionality exposed to the customer should be identical (and conforming) for all three designs.

diff --git a/www/atomic_design_a.html b/www/atomic_design_a.html index 0fc00436..b329fd1e 100644 --- a/www/atomic_design_a.html +++ b/www/atomic_design_a.html @@ -38,7 +38,7 @@

The compiler supplies all of the intrinsics as described below. This list of intrinsics roughly parallels the requirements of the C and C++ atomics -proposals. The C and C++ library imlpementations simply drop through to these +proposals. The C and C++ library implementations simply drop through to these intrinsics. Anything the platform does not support in hardware, the compiler arranges for a (compiler-rt) library call to be made which will do the job with a mutex, and in this case ignoring the memory ordering parameter (effectively @@ -52,7 +52,7 @@ behavior is acceptable when the inputs do not conform as defined below.

 // In every intrinsic signature below, type* atomic_obj may be a pointer to a
-//    volatile-qualifed type.
+//    volatile-qualified type.
 // Memory ordering values map to the following meanings:
 //   memory_order_relaxed == 0
 //   memory_order_consume == 1
diff --git a/www/atomic_design_c.html b/www/atomic_design_c.html
index ae2f5ffb..f574d4d7 100644
--- a/www/atomic_design_c.html
+++ b/www/atomic_design_c.html
@@ -43,7 +43,7 @@ inserted directly into your application ...  assembly that is not otherwise
 representable by higher level C or C++ expressions.  The design of the libc++
 <atomic> header started with this goal in mind.  A secondary, but
 still very important goal is that the compiler should have to do minimal work to
-faciliate the implementaiton of <atomic>.  Without this second
+facilitate the implementation of <atomic>.  Without this second
 goal, then practically speaking, the libc++ <atomic> header would
 be doomed to be a barely supported, second class citizen on almost every
 platform.