Small improvements to CPU target docs (#1012)

* Small fixes to CPU documentation.

* Small typo fixes.

1 files changed, 14 insertions, 16 deletions

diff --git a/docs/cpu-target.md b/docs/cpu-target.md
index cc1e15b08..dc2319b6f 100644
--- a/docs/cpu-target.md
+++ b/docs/cpu-target.md
@@ -56,7 +56,7 @@ These can also be specified on the slang command line as `-target exe` and `-tar
 
 In order to be able to use the slang code on CPU, there needs to be binding via values passed to a function that the C/C++ code will produce and export. How this works is described in the ABI section. 
 
-That if a binary target is requested, the binary contents will be returned in a ISlangBlob just like for other targets. To use the CPU binary typically it must be saved as file and then potentially marked for execution by the OS before executing. It may be possible to load shared libraries or dlls from memory - but is a non standard feature, that requires unusual work arounds. 
+If a binary target is requested, the binary contents will be returned in a ISlangBlob just like for other targets. To use the CPU binary typically it must be saved as file and then potentially marked for execution by the OS before executing. It may be possible to load shared libraries or dlls from memory - but is a non standard feature, that requires unusual work arounds. 
 
 Under the covers when slang is used to generate a binary via a C/C++ compiler, it must do so through the file system. Currently this means that the source (say generated by slang) and the binary (produced by the C/C++ compiler) must all be files. To make this work slang uses temporary files. That the reasoning for hiding this mechanism - and not return say filenames, is so that in the future when binaries are produced directly (for example with LLVM), nothing will need to change.  
 
@@ -90,17 +90,23 @@ void computeMain(ComputeVaryingInput* varyingInput, UniformState* uniformState);
 The UniformState struct typically varies by shader, and it holds all of the bindings. Where these are located can be determined by reflection. For example 
 
 ```
+struct _S1
+{
+    Thing_0 thing_0;
+    Thing_0 thing2_0;
+};
+
 struct UniformState
 {
-    Thing_0* thing3_0;
-    RWStructuredBuffer<int32_t> outputBuffer_0;
-    Texture2D<float > tex_0;
-    SamplerState sampler_0;
+    Thing* thing3;
+    RWStructuredBuffer<int32_t> outputBuffer;
+    Texture2D<float > tex;
+    SamplerState sampler;
     _S1* _S2;
 };   
 ```
 
-That for C++ targets, the templated types are defined in the slang-cpp-prelude.h that is included. Note that `slang-cpp-prelude.h` *MUST* currently be within the search path passed to the compiler. By default with the CPU path, the path to the slang file is included as a 'system' include path, such that placing the slang-cpp-prelude.h file in the same directory as the slang source file should mean that it is found. 
+For C++ targets, the templated types are defined in the slang-cpp-prelude.h that is included. Note that `slang-cpp-prelude.h` *MUST* currently be within the search path passed to the compiler. By default with CPU code-generation, the file path to the slang file is included as a 'system' include path, such that placing the `slang-cpp-prelude.h` file in the same directory as the slang source file should mean that it is found. 
 
 ConstantBuffers will become pointers to the type they hold (as thing3_0 is in the above structure).
  
@@ -115,14 +121,6 @@ Resource types become pointers to interfaces that implement their features. For
 
 The `_S1` struct in the example above (which may have different names) is actually a struct that holds all of the entry point uniforms if there are any, in this case
 
-```
-struct _S1
-{
-    Thing_0 thing_0;
-    Thing_0 thing2_0;
-};
-```
-
 Note that the this pointer is not directly reflected (although layout of uniform paramters in the struct are). Currently this pointer is just placed after all the other reflected bindings.  
 
 
@@ -178,11 +176,11 @@ struct RWStructuredBuffer
 RWStructuredBuffer<float4> values;
 
 // ...
-Vector<float, 3> defValue = {};         // Zero initialize such that access
+Vector<float, 3> defValue = {};         // Zero initialize such that read access returns default values
 values.at(3).x = 10;
 ```
 
-Note that [] would be turned into the `at` function, which takes the default value as a paramter provided by the caller. If this is then written to then only the defValue is corrupted.  Even this mechanism not be quite right, because if we write and then read again from the out of bounds reference in HLSL we may expect that 0 is returned, whereas here we get the value that was written.
+Note that [] would be turned into the `at` function, which takes the default value as a paramter provided by the caller. If this is then written to then only the defValue is corrupted.  Even this mechanism not be quite right, because if we write and then read again from the out of bounds reference in HLSL we may expect that 0 is returned, whereas here we get the value that was last written.
 
 TODO
 ====