fix typos and markdown formatting in docs

doc/application_notes/mic_build/app_note_mic_build.md

@@ -36,7 +36,7 @@ provide a powerful code development tool.
 
 ## Configure the package
 
-### For root installation as a priveleged admin
+### For root installation as a privileged admin
 
 If you have root access, the build itself should work with all of the defaults.
 The target install directory will be `/usr/local/browndeer`.
@@ -56,7 +56,7 @@ installed in non-standard locations, the options `--with-libelf`,
 `--with-libconfig`, and `--with-libevent` may be used to make adjustments.  
 See `./configure --help` for a full listing of customizations.
 
-### For user installation as an unpriveleged user
+### For user installation as an unprivileged user
 
 If you do not have root access on the platform it is still possible to do a
 private "user install".  The following paths are assumed to be defined:
@@ -89,7 +89,7 @@ If configured for a user installation type,
 	make install
 
 That's it.  Note that `make clean` will remove files generated by the build
-process and `make distclean` will restored things to their pre-configure
+process and `make distclean` will restore things to their pre-configure
 state.
 
  
@@ -173,7 +173,7 @@ COPRTHR provides robust support for pre-cross-compiled kernels.
 
 Building the COPRTHR SDK for MIC native execution requires cross-compilation on
 the host using --enable-user-install configuration option.  In order to support
-the cross-compilation the path to the location of the required MIC libraries
+the cross-compilation, the path to the location of the required MIC libraries
 must be specified.  This should be the location where the libimf.so library
 built for MIC is installed on the host as part of the Intel SDK.  This
 directory will be designated MIC_LIBS_DIR.
@@ -209,7 +209,7 @@ The absence of JIT compilation support when running with MIC native execution
 can be mitigated using cross-compilation support for kernels provided by
 the COPRTHR SDK.  This cross-compilation support is simply an extension of
 the robust support provided for a standard compilation model and workflow - 
-something OpenCL lack.  There are two approaches - one that works now,
+something OpenCL lacks.  There are two approaches - one that works now,
 and one that will hopefully work in the near future.  We will mention first
 what does not work and why.
 
@@ -286,7 +286,7 @@ section below:
 
 The above modifications will cause the `libocl.so` loader to provide an
 application code using OpenCL a unique OpenCL platform for each server
-represented the exported resources.  Using the STDCL API the resources are
+representing the exported resources.  Using the STDCL API the resources are
 combined to form a single context.  The result is that the application code
 will "see" a context, `stdnpu`, containing four (4) MIC accelerators with
 device numbers 0,1,2, and 3.

doc/application_notes/programming_parallella_using_stdcl/app_note_programming_parallella_using_stdcl.md

@@ -88,7 +88,7 @@ int main()
 ~~~~~~~
 
 The elements of the program are rather simple.  Storage for the matrix and
-vectors are allocated and initialized.  The matrix-vector multiply calculation
+vectors is allocated and initialized.  The matrix-vector multiply calculation
 is performed producing the result vector, which is subsequently printed out.
 
  
@@ -104,7 +104,7 @@ important to understand that architecture matters, and Parallella is actually
 unique.  Understanding the unique features, capabilities, and limitations is
 key to programming the Parallella platform.
 
-Turning back to our matrix-vector multipl example, porting this program to use
+Turning back to our matrix-vector multiply example, porting this program to use
 the Epiphany co-processor on Parallella introduces three basic requirements for
 modifying the code:
 
@@ -194,7 +194,7 @@ device-shareable memory,
 	float* c = (float*)clmalloc(stdacc,n*sizeof(float),0);
 
 where `stdacc` is the STDCL context for the Epiphany accelerator, the second
-argument is just the size of the allocations in bytes, and he flags argument in
+argument is just the size of the allocations in bytes, and the flags argument in
 this case can be left as 0.
 
 Next we must ensure that the memory is synchronized with the Epiphany device
@@ -204,7 +204,7 @@ consistency is a basic requirement for proper operation.  Although it is quite
 possible to create an API premised on automatic memory consistency, such
 approaches have not been successful thus far with accelerators, and all APIs
 have inevitably exposed this control to the programmer.  STDCL introduces this
-programming requirement directly and with clean syntax as compred to the
+programming requirement directly and with clean syntax as compared to the
 implicit syntax found with `#pragma` mark-up APIs.  
 
 Modifying our program to ensure the data is synchronized with the device memory
@@ -236,7 +236,7 @@ execution are launched on the co-processor,
 Notice here that the kernel symbol, `matvecmult_kern`, is the name of our
 kernel function.  Additionally, the arguments passed to the kernel are
 `n,aa,b,c` specified as the last arguments to the `clexec()` call.  The
-`clexec() call is non-blocking and therefore it is required that the host
+`clexec()` call is non-blocking and therefore it is required that the host
 code eventually block until all device operations are completed.  
 
 Next we must ensure that the device memory where the results are stored is
@@ -382,7 +382,7 @@ parallelism.
 
 The basic problem with our initial port is exemplified by two related
 observations.  First, when we defined the index range used to launch threads,
-we asked for n threads executed in local workgroups of 16to match the number of
+we asked for n threads executed in local workgroups of 16 to match the number of
 cores on the Epiphany processor.  Second, when we examime our kernel code, we
 find that we have a very "light" kernel that perofrms a single summation over n
 products.
@@ -394,7 +394,7 @@ for thousands of threads.  Epiphany is not a GPU and this alters the fundamental
 
 Based on our architecture, we know how we would like the program to behave.
 Specifically, we would like to perform our parallel calculation using 16 
-threads corresponding to the 16 phisial RISC array cores.  Any over-threading
+threads corresponding to the 16 physical RISC array cores.  Any over-threading
 beyond this cannot bring any benefit and can only incur penalties for increased overhead.  So we take this into account as a basic design strategy when porting
 our program to Parallella.
 
@@ -442,7 +442,7 @@ void matvecmult_kern2( unsigned int n, float* aa, float* b, float* c )
 
 ## Modifying the Host Code
 
-The modifications to the host code are much simpler, and in fact our trivial.
+The modifications to the host code are much simpler, and in fact are trivial.
 The only required change is to modify the index range over which the kernel is
 executed, changing this from n to 16,
 
@@ -572,7 +572,7 @@ here consisting of only a single line of code, must be pulled out and
 used to create a kernel for parallel execution on the Epiphany device.
 
 The approach discussed in Section 3 in which the parallelism is matched
-the phyical cores of the RISC array will be employed here from the
+to the phyical cores of the RISC array will be employed here from the
 start.  The idea is quite simple.  The work of adding the elements of
 the data vector will be distributed as evenly as possible over the 16 phyisical
 cores to calculate partial sums.  Subsequently the 16 partial sums will be
@@ -898,7 +898,7 @@ this as an exercise.
 
 The kernel below will apply the stencil operation to a tile (approximately)
 1/16th the size of the data array.  The bookkeeping implements the constraint
-that elements on the outer edge of the array is not calculated since the
+that elements on the outer edge of the array are not calculated since the
 stencil leaves the update of these points ill-defined.
 
 ~~~~~~~

doc/coprthr_primer/coprthr_primer_clrpc.md

@@ -8,7 +8,7 @@ OpenCL host calls to be executed on remote platforms.  By design this may
 require no changes at all to the host application when using the OpenCL loader
 provided with the COPRTHR SDK.  For more complex and specialized applications,
 client host code can be linked directly with libclrpc and a few extensions are
-provided for specifying the remote CLRPC server or servers tht the application
+provided for specifying the remote CLRPC server or servers that the application
 should be connected to.
 
 At the present time many of the complex OpenCL semantics have been tested,
@@ -23,8 +23,8 @@ by bandwidth issues.  There is no magic to be found and, much like the early
 issues with the PCIe bus transfers dominating any theoretical performance gains
 from a GPU, the network latency and bandwidth must be addressed in order to
 successfully utilize CLRPC.  Fortunately many examples of use cases can be
-identified where the use of remote compute devices can be made ot perform with
-an overal advantage in terms of reduced time-to-solution for the compute task
+identified where the use of remote compute devices can be made to perform with
+an overall advantage in terms of reduced time-to-solution for the compute task
 at hand.
 
 
@@ -46,9 +46,9 @@ Options:
 	: Specify the port the server should listen on.
 
 By default the server will bind to `127.0.0.1` port `2112`.
-These defaults may be overiden with the command line options as shown.  
+These defaults may be overridden with the command line options as shown.  
 The following example shows how to run the server such that it will listen on a
-platforms external IP address to export the OpenCL platforms over a network,
+host's external IP address to export the OpenCL platforms over a network,
 
 	clrpcd -a 192.168.1.5
 
@@ -93,28 +93,28 @@ CLRPC and exposes a problem with the OpenCL approach to the concept of a
 "platform" that may be decribed as the vendor platform barrier.  A more
 complete discussion of this issue is provided below along with a solution
 through the use of the STDCL context `stdnpu` that includes all networked
-devices.  The simple answer to question stated above is that one must still
+devices.  The simple answer to the question stated above is that one must still
 select a single platform, whether local or remote, based on the name of the
 platform, and construct an OpenCL context and get device IDs as one is normally
 required to do in OpenCL.  If one wants to use multiple CLRPC servers this
 would then mean managing multiple platforms at the application level.  As an
 alternative, the introduction of a more precise mechanism for specifying OpenCL
-platforms (`ocl.conf`) to be presented to an allication using the `libocl`
-loader can be used for controlling individual CLRPC server that an application
+platforms (`ocl.conf`) to be presented to an application using the `libocl`
+loader can be used for controlling individual CLRPC servers that an application
 uses.  Fortunately STDCL provides a better way provided (`stdnpu`).
 
 
 ## OpenCL Extensions for More Control
 
 For some specialized applications it may be desireable to link to the
 `libclrpc` OpenCL implementation directly and set the remote CLRPC server
-connections from within a client application, by passing entirely the use of an
+connections from within a client application, bypassing entirely the use of an
 OpenCL platform loader.  For this purpose, extensions are provided for defining
 CLRPC server connections prior to the OpenCL call `clGetPlatformIDs()`.  
 
 The following example shows the current API extension.  However **please note**
 that these extensions are not fully developed and should be expected to be
-changed in subsequented releases.  The are described here only because they may
+changed in subsequent releases.  They are described here only because they may
 be of interest for early experimentation by developers.  Programmers are
 strongly encouraged to use the method described above involving the use of
 `ocf.conf` files for defining connections to CLRPC servers.

doc/coprthr_primer/coprthr_primer_hello_stdcl.md

@@ -1,6 +1,6 @@
 # Hello STDCL
 
-As with most programming, its best to begin with a hello world example that
+As with most programming, it's best to begin with a hello world example that
 captures the most important aspects of the API. This section will
 describe a hello STDCL program that provides everything a programmer needs to
 know to get started with the interface. A basic understanding of OpenCL is
@@ -32,7 +32,7 @@ __kernel void matvecmult_kern(
 ~~~
 
 Next, we need host-code to run on the CPU and manage the execution on the GPU.
-The host code below contains everything needed to executute the above kernel.
+The host code below contains everything needed to execute the above kernel.
 By using STDCL this program is many times smaller than what would be required
 to use OpenCL directly, and its also a lot simpler based on the use of better
 syntax and semantics.
@@ -45,7 +45,7 @@ syntax and semantics.
 
 int main()
 {
-   stdcl_init(); /* requred for Windows only, Linux and FreeBSD will ignore this call */
+   stdcl_init(); /* required for Windows only, Linux and FreeBSD will ignore this call */
 
    cl_uint n = 64;
 
@@ -125,7 +125,7 @@ New to this release is support for Fortran bindings to STDCL. Quite simply,
 this allows nearly all of the functionality provided by STDCL to be available
 to Fortran programmers, providing a simple powerful interface to OpenCL
 programming from Fortran applications. The example below is nearly identical to
-the hello STDCL example above, except it is written in Fortran. On detail to
+the hello STDCL example above, except it is written in Fortran. One detail to
 note is that the opaque OpenCL and STDCL types, which are merely pointers in
 practice, must be referenced directly and generically as C pointers since
 Fortran does not support type alising. 

doc/coprthr_primer/coprthr_primer_libocl.md

@@ -25,7 +25,7 @@ with the OpenCL 1.1 specification.
 
 The 'libocl' loader replaces the random enumeration of '.icd' files placed in 
 the '/etc/OpenCL/vendors/' directory with a precise configuration file that 
-may be set by the system admin and then overriden by any user following 
+may be set by the system admin and then overridden by any user following 
 a well-defined ordering of search paths.
 
 The following order for search paths provides for an increasingly specialized 

doc/coprthr_primer/coprthr_primer_overview.md

@@ -59,7 +59,7 @@ workflow employed by serious programmers developing serious applications.
 ## libclelf
 
 The ELF extensions for OpenCL (CL-ELF) are formally implemented withing the
-library libclelf which is use by the offline compiler and linker to create
+library libclelf which is used by the offline compiler and linker to create
 cross-compiled linkable object files. The dynamic loader that is provided as
 part of the STDCL implementation uses this same library to load the correct
 source or binary kernel for use within an application. 
@@ -70,7 +70,7 @@ The SDK includes an OpenCL loader that is
 backward compatible with the conventional libOpenCL ICD loader. The purpose of 
 libocl.so, which may be aliased to libOpenCL.so, is to provide a much greater 
 set of capabilities than what is provided with the standard loader. Among these 
-capabilities are more sensible system configuraton and resource management 
+capabilities are more sensible system configuration and resource management 
 options, as well as the creation of custom contexts based on the hardware that 
 is actually installed on a given system. OpenCL platform configuration issues 
 are more reliably addressed by the user or system administrator, and not the