README: more formatting, correct statement about bench.sh
[model-checker.git] / README.md
index 218e960a868351d62e6ceb90f5bc26456f5ca2fe..c7a4848e34776706c78f4e5abd3fe738f1ee3c76 100644 (file)
--- a/README.md
+++ b/README.md
@@ -104,18 +104,18 @@ SC
 
 
 Note that we also provide a series of benchmarks (distributed separately),
 
 
 Note that we also provide a series of benchmarks (distributed separately),
-which can be placed under the benchmarks/ directory. After building CDSChecker,
+which can be placed under the `benchmarks/` directory. After building CDSChecker,
 you can build and run the benchmarks as follows:
 
         cd benchmarks
         make
         ./run.sh barrier/barrier -y -m 2     # runs barrier test with fairness/memory liveness
 you can build and run the benchmarks as follows:
 
         cd benchmarks
         make
         ./run.sh barrier/barrier -y -m 2     # runs barrier test with fairness/memory liveness
-        ./bench.sh                           # run all benchmarks twice, with timing results
+        ./bench.sh                           # run all benchmarks and provide timing results
 
 Running your own code
 ---------------------
 
 
 Running your own code
 ---------------------
 
-We provide several test and sample programs under the test/ directory, which
+We provide several test and sample programs under the `test/` directory, which
 should compile and run with no trouble. Of course, you likely want to test your
 own code. To do so, you need to perform a few steps.
 
 should compile and run with no trouble. Of course, you likely want to test your
 own code. To do so, you need to perform a few steps.
 
@@ -166,8 +166,8 @@ The following list describes each of the columns in the execution trace output:
 
  * Action type: The type of operation performed
 
 
  * Action type: The type of operation performed
 
- * MO: The memory-order for this operation (i.e., `memory_order_XXX`, where XXX is
-   relaxed, release, acquire, rel_acq, or seq_cst)
+ * MO: The memory-order for this operation (i.e., `memory_order_XXX`, where `XXX` is
+   `relaxed`, `release`, `acquire`, `rel_acq`, or `seq_cst`)
 
  * Location: The memory location on which this operation is operating. This is
    well-defined for atomic write/read/RMW, but other operations are subject to
 
  * Location: The memory location on which this operation is operating. This is
    well-defined for atomic write/read/RMW, but other operations are subject to
@@ -176,7 +176,7 @@ The following list describes each of the columns in the execution trace output:
  * Value: For reads/writes/RMW, the value returned by the operation. Note that
    for RMW, this is the value that is *read*, not the value that was *written*.
    For other operations, 'value' may have some CDSChecker-internal meaning, or
  * Value: For reads/writes/RMW, the value returned by the operation. Note that
    for RMW, this is the value that is *read*, not the value that was *written*.
    For other operations, 'value' may have some CDSChecker-internal meaning, or
-   it may simply be a don't-care (such as 0xdeadbeef).
+   it may simply be a don't-care (such as `0xdeadbeef`).
 
  * Rf: For reads, the sequence number of the operation from which it reads.
    [Note: If the execution is a partial, infeasible trace (labeled INFEASIBLE),
 
  * Rf: For reads, the sequence number of the operation from which it reads.
    [Note: If the execution is a partial, infeasible trace (labeled INFEASIBLE),