README: use markdown format for direct URL link

[cdsspec-compiler.git] / README.md

diff --git a/README.md b/README.md
index 218e960a868351d62e6ceb90f5bc26456f5ca2fe..ea3b2423753bf3698ca3d280187ce63c3bea8261 100644 (file)
--- a/README.md
+++ b/README.md
@@ -22,7 +22,7 @@ eliminate redundant executions to significantly shrink the state space.
 The model checking algorithm is described in more detail in this paper
 (currently under review):
 
-  [http://demsky.eecs.uci.edu/publications/c11modelcheck.pdf](http://demsky.eecs.uci.edu/publications/c11modelcheck.pdf)
+  <http://demsky.eecs.uci.edu/publications/c11modelcheck.pdf>
 
 It is designed to support unit tests on concurrent data structure written using
 C11/C++11 atomics.
@@ -40,7 +40,7 @@ flavors. We have not attempted to port to Windows.
 
 Other references can be found at the main project page:
 
-  [http://demsky.eecs.uci.edu/c11modelchecker.php](http://demsky.eecs.uci.edu/c11modelchecker.php)
+  <http://demsky.eecs.uci.edu/c11modelchecker.php>
 
 Basic build and run
 -------------------
@@ -104,18 +104,18 @@ SC
 
 
 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
-        ./bench.sh                           # run all benchmarks twice, with timing results
+        ./bench.sh                           # run all benchmarks and provide timing results
 
 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.
 
@@ -166,8 +166,8 @@ The following list describes each of the columns in the execution trace output:
 
  * 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
@@ -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
-   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),