Line wrap docs

README.md

@@ -15,8 +15,7 @@ code with API calls tailored for a particular simulator.
 
 Currently, the compiler supports building models for the Intel®
 [Simics®](https://www.intel.com/content/www/us/en/developer/articles/tool/simics-simulator.html)
-simulator, but other back-ends may be added in the
-future.
+simulator, but other back-ends may be added in the future.
 
 
 ## Building and testing DMLC 
@@ -50,21 +49,21 @@ regularly with a locally built DMLC, then consider setting the variables
 `.bashrc`. Remaining variables are better to only enable when needed.
 
 ### DMLC_DIR
-After building DMLC, you need to set `DMLC_DIR` to `<your-project>/<hosttype>/bin`
-in subsequent invocations of `make` in order to build devices with the locally
-build compiler. `<hosttype>` is either `linux64` or `win64` depending on your 
-host type. 
+After building DMLC, you need to set `DMLC_DIR` to
+`<your-project>/<hosttype>/bin` in subsequent invocations of `make` in order to
+build devices with the locally build compiler. `<hosttype>` is either `linux64`
+or `win64` depending on your host type.
 
 ### T126_JOBS
 When set, the given number of tests are run in parallel.
 
 ### DMLC_PATHSUBST
 The DMLC build copies a few DML library files, e.g. `dml-builtins.dml`, into
-`<hosttype>/bin`. When a compile error happens, error messages will normally point
-to this copy rather than the source. By setting `DMLC_PATHSUBST` to
+`<hosttype>/bin`. When a compile error happens, error messages will normally
+point to this copy rather than the source. By setting `DMLC_PATHSUBST` to
 `<hosttype>/bin/dml=modules/dmlc/lib`, error messages will be rewritten to point
-to the source file instead.  `<hosttype>` is either `linux64` or `win64` 
-depending on your host type. 
+to the source file instead.  `<hosttype>` is either `linux64` or `win64`
+depending on your host type.
 
 ### PY_SYMLINKS
 When set to `1`, `make dmlc` will symlink Python files instead of copying

SECURITY.md

@@ -4,7 +4,11 @@
 -->
 
 # Security Policy
-We (the Device Modeling Language development team) are committed to rapidly addressing security vulnerabilities affecting our customers and providing clear guidance on the solution, impact, severity and mitigation. 
+We (the Device Modeling Language development team) are committed to rapidly
+addressing security vulnerabilities affecting our customers and providing clear
+guidance on the solution, impact, severity and mitigation.
 
 ## Reporting a Vulnerability
-Please report any security vulnerabilities in this project utilizing the guidelines [here](https://www.intel.com/content/www/us/en/security-center/vulnerability-handling-guidelines.html).
+Please report any security vulnerabilities in this project utilizing the
+guidelines
+[here](https://www.intel.com/content/www/us/en/security-center/vulnerability-handling-guidelines.html).

doc/1.2/language.md

@@ -93,7 +93,9 @@ identifiers are always prefixed by a `$` character.
 Constant Literals
 </dt><dd>
 
-DML has literals for strings, characters, integers, booleans, and floating-point numbers.  The integer literals can be written in decimal (`01234`), hexadecimal (`0x12af`), or binary (`0b110110`) form.
+DML has literals for strings, characters, integers, booleans, and floating-point
+numbers.  The integer literals can be written in decimal (`01234`), hexadecimal
+(`0x12af`), or binary (`0b110110`) form.
 
 Underscores (`_`) can be used between digits, or immediately
 following the `0b`, `0x` prefixes, in integer literals
@@ -805,14 +807,14 @@ Most object types (`bank`, `register`,
 in *arrays*. The general form of an object array declaration is
 
 <pre>
-<em>type</em> <em>name</em> [<em>variable</em> in 0..<em>max</em>]... <em>extras</em> { ... }
+<em>type</em> <em>name</em> [<em>variable</em> in 0..<em>max</em>]...
+<em>extras</em> { ... }
 </pre>
 
 Here, each *variable* defines the name of one index in the array and
-<code>0..<em>max</em></code> defines the size of the corresponding dimension of the
-array. Each *variable* defines a parameter in the object scope, and thus must
-be unique.
-*max* must be a compile time constant. For instance,
+<code>0..<em>max</em></code> defines the size of the corresponding dimension of
+the array. Each *variable* defines a parameter in the object scope, and thus
+must be unique. *max* must be a compile time constant. For instance,
 
 ```
 register regs[i in 0..15] size 2 {
@@ -856,12 +858,13 @@ object; multiple "`bank { ... }`" declarations are concatenated.
 The general form of a `register` declaration is
 
 <pre>
-register <em>name</em> size <em>n</em> @ <em>d</em> is (<em>templates</em>) { ... }
+register <em>name</em> size <em>n</em> @ <em>d</em> is (<em>templates</em>) {
+... }
 </pre>
 
-Each of the "<code>size <em>n</em></code>", "<code>@ <em>d</em></code>", and "<code>is
-(<em>templates</em>)</code>" sections is optional, but if present, they must
-be specified in the above order.
+Each of the "<code>size <em>n</em></code>", "<code>@ <em>d</em></code>", and
+"<code>is (<em>templates</em>)</code>" sections is optional, but if present,
+they must be specified in the above order.
 
 * A declaration
 
@@ -906,7 +909,8 @@ Templates are further described in Section [x](#template-declarations).
 The general form of a `field` declaration is
 
 <pre>
-field <em>name</em> [<em>highbit</em>:<em>lowbit</em>] is (<em>templates</em>) { ... }
+field <em>name</em> [<em>highbit</em>:<em>lowbit</em>] is (<em>templates</em>) {
+... }
 </pre>
 
 or simply
@@ -916,22 +920,24 @@ field <em>name</em> [<em>bit</em>] ... { ... }
 </pre>
 
 specifying a range of bits of the containing register, where the syntax
-<code>[<em>bit</em>]</code> is short for <code>[<em>bit</em>:<em>bit</em>]</code>.
-Both the "`[...]`" and the <code>is (<em>templates</em>)</code>
-sections are optional; in fact, the "`[...]`" syntax is merely a
-much more convenient way of defining the (required) field parameters
+<code>[<em>bit</em>]</code> is short for
+<code>[<em>bit</em>:<em>bit</em>]</code>. Both the "`[...]`" and the <code>is
+(<em>templates</em>)</code> sections are optional; in fact, the "`[...]`" syntax
+is merely a much more convenient way of defining the (required) field parameters
 `lsb` and `msb` (cf. Section [x](libraries.html#field-parameters)).
 
 * A declaration
 
   <pre>
-  field <em>name</em> [<em>high</em>:<em>low</em>] is (<em>t1</em>,...,<em>tN</em>) { ... }
+field <em>name</em> [<em>high</em>:<em>low</em>] is
+(<em>t1</em>,...,<em>tN</em>) { ... }
   </pre>
 
   is equivalent to
 
   <pre>
-  field <em>name</em> [<em>high</em>:<em>low</em>] { is <em>t1</em>; ... is <em>tN</em>; ... }
+field <em>name</em> [<em>high</em>:<em>low</em>] { is <em>t1</em>; ... is
+<em>tN</em>; ... }
   </pre>
 
 For a range of two or more bits, the first (leftmost) number always
@@ -1320,12 +1326,11 @@ later version of DML.
   }
   ```
 
-  (only one variable can be introduced per declaration). Static
-  variables have a similar meaning as in C, they retain value over function calls.
-  But note that a `static` variable in DML is per device object, it is not
-  globally shared between device instances.
-  For symmetry with C, the keyword
-  `auto` may be used as a synonym for `local`.
+(only one variable can be introduced per declaration). Static variables have a
+similar meaning as in C, they retain value over function calls. But note that a
+`static` variable in DML is per device object, it is not globally shared between
+device instances. For symmetry with C, the keyword `auto` may be used as a
+synonym for `local`.
 
 * Plain C functions (i.e., not DML methods) can be called using normal
   function call syntax, as in `f(x)`.
@@ -1334,7 +1339,8 @@ later version of DML.
   sections of the DML file, or in one or more C source code files that are
   compiled or linked to separately.
 
-  See sections [x](#header-declarations) and [x](#footer-declarations) for more detail on `header` and `footer`.
+See sections [x](#header-declarations) and [x](#footer-declarations) for more
+detail on `header` and `footer`.
 
   In either case, the functions must also be declared as `extern` in the
   DML source code. For example:
@@ -1479,7 +1485,8 @@ not possible to specify a value to be thrown. Furthermore, in DML,
 ### Call Statements
 
 <pre>
-call <em>method</em>(<em>e1</em>, ... <em>eN</em>) -&gt; (<em>d1</em>, ... <em>dM</em>);
+call <em>method</em>(<em>e1</em>, ... <em>eN</em>) -&gt; (<em>d1</em>, ...
+<em>dM</em>);
 </pre>
 
 Calls a DML method with input arguments *`e1`*, ...
@@ -1516,7 +1523,8 @@ call me;
 ### Inline Statements
 
 <pre>
-inline <em>method</em>(<em>e1</em>, ... <em>eN</em>) -&gt; (<em>d1</em>, ... <em>dM</em>);
+inline <em>method</em>(<em>e1</em>, ... <em>eN</em>) -&gt; (<em>d1</em>, ...
+<em>dM</em>);
 </pre>
 
 This is equivalent to <code>call <em>method</em>(<em>e1</em>, ... <em>eN</em>)
@@ -1570,7 +1578,8 @@ that e.g. have pointer parameters.
 ### Log Statements
 
 <pre>
-log <em>log-type</em>, <em>level</em>, <em>groups</em>: <em>format-string</em>, <em>e1</em>, ..., <em>eN</em>;
+log <em>log-type</em>, <em>level</em>, <em>groups</em>: <em>format-string</em>,
+<em>e1</em>, ..., <em>eN</em>;
 </pre>
 
 Outputs a formatted string to the Simics logging facility. The string
@@ -1714,16 +1723,15 @@ The `break` statement can be used within a `foreach` loop to exit it.
 ### Select Statements
 
 <pre>
-select <em>identifier</em> in (<em>expr</em>) where (<em>cond-expr</em>) <em>statement</em> else <em>default-statement</em>
+select <em>identifier</em> in (<em>expr</em>) where (<em>cond-expr</em>)
+<em>statement</em> else <em>default-statement</em>
 </pre>
 
-The `select` statement
-resembles a C `switch` statement and it
-is very similar to the `foreach`
-statement, but executes the *`statement`* exactly once for
-the first matching element in the *list*  given by *`expr`*, i.e., for the first element such that
-*`cond-expr`* is `true`; or if no element matches, it
-executes the *`default-statement`*.
+The `select` statement resembles a C `switch` statement and it is very similar
+to the `foreach` statement, but executes the *`statement`* exactly once for the
+first matching element in the *list*  given by *`expr`*, i.e., for the first
+element such that *`cond-expr`* is `true`; or if no element matches, it executes
+the *`default-statement`*.
 
 If *`expr`* is a list, *and* the
 *`cond-expr`* only depends on compile-time constants, apart

doc/1.2/libraries.md

@@ -961,7 +961,8 @@ to `true`, otherwise to `false`. Affected by
 the `miss_pattern` parameter.
 </dd><dt>
 
-read(generic\_transaction\_t \*memop, uint64 offset, uint64 size) -> (uint64 value)
+read(generic\_transaction\_t \*memop, uint64 offset, uint64 size) -> (uint64
+value)
 </dt><dd>
 
 Utility method; equivalent to calling `read_access`, but does

doc/1.2/object-model.md

@@ -17,11 +17,11 @@ Every object (including the device itself) can also have
 object, and *parameters*, which are constant-valued
 members that exist only during compilation.
 
-Each object is an instance of a *class*, often simply called the
-"object type"; the built-in object types are described in Section [x](#object-types). There is no way of adding user-defined classes
-in DML; however, each object is in general locally modified by
-adding (or overriding) members, methods and parameters - this can be
-viewed as creating a local one-shot subclass for each instance.
+Each object is an instance of a *class*, often simply called the "object type";
+the built-in object types are described in Section [x](#object-types). There is
+no way of adding user-defined classes in DML; however, each object is in general
+locally modified by adding (or overriding) members, methods and parameters -
+this can be viewed as creating a local one-shot subclass for each instance.
 
 Many parts of the DML object model are automatically mapped onto the
 Simics *configuration object* model; most

doc/1.4/deprecations-header.md

@@ -50,8 +50,8 @@ each individual change in a new API version can be enabled individually,
 without enabling the full API version. This has the following uses:
 
 * During migration to a new API version, enabling one breaking change at a time
-  across the whole system makes it easier to analyze errors, because you only know that
-  all errors come from the same change.
+  across the whole system makes it easier to analyze errors, because you only
+  know that all errors come from the same change.
 * When a breaking change is first introduced, it will be disabled by default in
   the latest API version, and only be enabled by default when the next API
   version is introduced.  Thus, until the next Simics major release, the
@@ -83,6 +83,6 @@ title `foo-bar` corresponds to the DMLC flag `--breaking-change=foo-bar`, and
 when that flag is passed, the global parameter `_breaking_change_foo_bar` to
 `true`.
 
-Each breaking change is also implicitly enabled when compiling with a Simics
-API version above a certain threshold. The breaking changes under the section for API
-_n_ are useful when migrating to API _n+1_.
+Each breaking change is also implicitly enabled when compiling with a Simics API
+version above a certain threshold. The breaking changes under the section for
+API _n_ are useful when migrating to API _n+1_.

doc/1.4/introduction.md

@@ -208,13 +208,13 @@ register. The hierarchy is composed of the following object types:
   device, which can contain its own ports, banks, and attributes.
 
 ## Methods and Mutable Variables
-[Methods](language.html#methods-detailed) are the DML representation of subroutines.
-They may be declared as members of any object or template. Any method may have
-multiple input parameters, specified similarly as C functions. Unlike C, DML
-methods may have multiple return values, and the lack of a return value is
-indicated through an empty list of return values rather than `void`. The
-following demonstrates a method declaration with no input parameters or return
-values:
+[Methods](language.html#methods-detailed) are the DML representation of
+subroutines. They may be declared as members of any object or template. Any
+method may have multiple input parameters, specified similarly as C functions.
+Unlike C, DML methods may have multiple return values, and the lack of a return
+value is indicated through an empty list of return values rather than `void`.
+The following demonstrates a method declaration with no input parameters or
+return values:
 
 ```
 method noop() -> () {
@@ -285,9 +285,9 @@ done as follows:
 <pre>
 template <em>name</em> { <em>body</em> }
 </pre>
-where *name* is the name of the template, and *body* is a set of object statements.
-A template may be instantiated through the `is` object statement, which
-can be used within either objects, or within templates. For example:
+where *name* is the name of the template, and *body* is a set of object
+statements. A template may be instantiated through the `is` object statement,
+which can be used within either objects, or within templates. For example:
 ```
 bank regs {
     // Instantiate a single template: templateA