Update README.md
diff --git a/README.md b/README.md
index 09fda56..5426458 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,27 @@
-# cpu features [![Build Status](https://travis-ci.org/google/cpu_features.svg?branch=master)](https://travis-ci.org/google/cpu_features)
+# cpu_features [![Build Status](https://travis-ci.org/google/cpu_features.svg?branch=master)](https://travis-ci.org/google/cpu_features)
-A cross platform C89 library to get cpu features at runtime.
+A cross-platform C library to retrieve CPU features (such as available
+instructions) at runtime.
-### Checking features at runtime.
+## Design Rationale
+
+- **Simple to use.** See the snippets below for examples.
+- **Extensible.** Easy to add missing features or architectures.
+- **Compatible with old compilers** and available on many architectures so it
+ can be used widely. To ensure that cpu_features works on as many platforms
+ as possible, we implemented it in a highly portable version of C: gnu89.
+- **Sandbox-compatible.** The library uses a variety of strategies to cope
+ with sandboxed environments or when `cpuid` is unavailable. This is useful
+ when running integration tests in hermetic environments.
+- **Thread safe, no memory allocation, and raises no exceptions.**
+ cpu_features is suitable for implementing fundamental libc functions like
+ `malloc`, `memcpy`, and `memcmp`.
+- **Unit tested.**
+
+### Checking features at runtime
+
+Here's a simple example that executes a codepath if the CPU supports both the
+AES and the SSE4.2 instruction sets:
```c
#include "cpuinfo_x86.h"
@@ -18,11 +37,11 @@
}
```
-### Caching for faster evaluation of complex checks.
+### Caching for faster evaluation of complex checks
-Features are bit packed and some compilers generate poor code when combining
-them. A simple solution is to read them once and store the result in a global
-variable.
+If you wish, you can read all the features at once into a global variable, and
+then query for the specific features you care about. Below, we store all the ARM
+features and then check whether AES and NEON are supported.
```c
#include "cpuinfo_arm.h"
@@ -33,7 +52,14 @@
// use has_aes_and_neon.
```
-### Checking compile time flags as well.
+This is a good approach to take if you're checking for combinations of features
+when using a compiler that is slow to extract individual bits from bit-packed
+structures.
+
+### Checking compile time flags
+
+The following code determines whether the compiler was told to use the AVX
+instruction set (e.g., `g++ -mavx`) and sets `has_avx` accordingly.
```c
#include "cpuinfo_x86.h"
@@ -44,10 +70,17 @@
// use has_avx.
```
-`CPU_FEATURES_COMPILED_X86_AVX` is set to 1 if the compiler is instructed to use
-AVX, 0 otherwise. This allows combining compile time and runtime knowledge.
+`CPU_FEATURES_COMPILED_X86_AVX` is set to 1 if the compiler was instructed to
+use AVX and 0 otherwise, combining compile time and runtime knowledge.
-### Use x86 microarchitecture to reject poor hardware implementations.
+### Rejecting poor hardware implementations based on microarchitecture
+
+On x86, the first incarnation of a feature in a microarchitecture might not be
+the most efficient (e.g., AVX on Sandy Bridge). We provide a function to
+retrieve the underlying microarchitecture so you can decide whether to use it.
+
+Below, `has_fast_avx` is set to 1 if the CPU supports the AVX instruction
+set—but only if it's not Sandy Bridge.
```c
#include "cpuinfo_x86.h"
@@ -59,42 +92,27 @@
// use has_fast_avx.
```
-On x86, the first incarnation of a feature in a microarchitecture may not be
-very efficient (e.g. AVX on Sandybridge). We provide a function to retrieve the
-underlying microarchitecture so clients can decide whether they want to use it
-or not.
+This feature is currently available only for x86 microarchitectures.
-## What does it currently support
+## What's supported
-| | x86 | ARM | aarch64 | mips | POWER |
-|---------------------------- | :-: | :-: | :-----: | :----: | :-----: |
-|Features From cpu | yes | no* | no* | no yet | not yet |
-|Features From Linux | no | yes | yes | yes | not yet |
-|Micro Architecture Detection | yes | no | no | no | not yet |
-|Windows support | yes | no | no | no | not yet |
+| | x86 | ARM | AArch64 | MIPS | POWER |
+|---------------------------- | :-: | :-: | :-----: | :----: | :-----: |
+|Features revealed from CPU | yes | no* | no* | not yet | not yet |
+|Features revealed from Linux | no | yes | yes | yes | not yet |
+|Microarchitecture detection | yes | no | no | no | not yet |
+|Windows support | yes | no | no | no | not yet |
-- **Features From Cpuid**: features are retrieved by using the cpuid
- instruction. (*) Unfortunately this instruction is privileged for some
- architectures; in this case we fall back to Linux.
-- **Features From Linux**: we gather data from several sources depending on
- what's available:
+- **Features revealed from CPU.** features are retrieved by using the `cpuid`
+ instruction. *Unfortunately this instruction is privileged for some
+ architectures, in which case we fall back to Linux.
+- **Features revealed from Linux.** We gather data from several sources
+ depending on availability:
+ from glibc's
[getauxval](https://www.gnu.org/software/libc/manual/html_node/Auxiliary-Vector.html)
+ by parsing `/proc/self/auxv`
+ by parsing `/proc/cpuinfo`
-- **Micro Architecture Detection**: On x86 some features are not always
+- **Microarchitecture detection.** On x86 some features are not always
implemented efficiently in hardware (e.g. AVX on Sandybridge). Exposing the
- microarchitecture allows the client to reject some microarchitectures.
+ microarchitecture allows the client to reject particular microarchitectures.
-## Design Rationale
-
-- Simple to use, API should be straightforward from the snippets above.
-- Unit tested.
-- Extensible. It should be easy to add missing features or architectures.
-- Compatible with old compilers and available on many architectures so it can
- be used widely. We target gnu89.
-- Works in sandboxed environment: some architectures rely on parsing files
- that may not be available in a sandboxed environment. It is useful when
- running integration tests in hermetic environments.
-- Thread safe, no allocation, no exception: suitable for implementation of
- fundamental libc functions like malloc, memcpy, memcmp...