@@ -54,14 +54,14 @@ use `u3m_soft_sure()`, `u3m_soft_slam()`, or `u3m_soft_nock()`
5454for C functions, Hoon function calls, and Nock invocations.
5555Caution - this returns just the result, and asserts globally.
5656
57−All the `u3m_soft` functions above work *only on the surface*.
57+All the `u3m_soft` functions above work **only on the surface**.
5858Within the surface, virtualize with `u3m_soft_run()`. Note that
5959this takes a `fly` (a namespace gate), thus activating the `11`
6060super-operator in the nock virtualizer, `++mock`. When actually
6161using the `fly`, call `u3m_soft_esc()`. Don't do either unless
6262you know what you're doing!
6363
64−For descending into a subroad *without* Nock virtualization,
64+For descending into a subroad **without** Nock virtualization,
6565use `u3m_hate()` and `u3m_love` respectively. Hating enters
6666a subroad; loving leaves it, copying out a product noun.
6767
@@ -87,7 +87,7 @@ dumber than most) - `u3j` is the most interesting code in `u3`.
8787
8888Let's consider the minor miracle of driver-to-battery binding
8989which lets `u3j` work - and decrement not be `O(n)` - without
90−violating the precisely defined semantics of pure Nock, *ever*.
90+violating the precisely defined semantics of pure Nock, **ever**.
9191
9292It's easy to assume that jets represent an architectural coupling
9393between Hoon language semantics and Nock interpreter internals.
@@ -108,7 +108,7 @@ code]`, any high-level language transforming itself to Nock would
108108use this design.
109109
110110So jets are in fact fully general. Broadly speaking, the jet
111−system works by matching a C *driver* to a battery. When the
111+system works by matching a C **driver** to a battery. When the
112112battery is invoked with Nock operator `9`, it must be found in
113113associative memory and linked to its driver. Then we link the
114114formula axis of the operation (`a` in `[9 a b]`) to a specific
@@ -141,7 +141,7 @@ nock(+.a -.a)
141141Then, naturally, when we go from Hoon or a high-level language
142142containing functions down to Nock, `[function arguments]` turns
143143into `[formula subject]`. This seems like an obvious design, and
144−we mention it only because it is *completely wrong*.
144+we mention it only because it is **completely wrong**.
145145
146146Rather, to execute a one-armed core like the above, we run
147147
@@ -250,7 +250,7 @@ in `j/tree.c`. The data structures:
250250 } u3j_dash;
251251```
252252
253−Warm and cold state is *per road*. In other words, as we nest
253+Warm and cold state is **per road**. In other words, as we nest
254254roads, we also nest jet state. The jet state in the road is:
255255
256256```
@@ -330,7 +330,7 @@ we don't need (cleaning these things up is tricky), but just gets
330330flattened into a term.
331331
332332The parent axis is a nock formula, but always reduces to a simple
333−axis, which is the address of this core's *parent*. Consider
333+axis, which is the address of this core's **parent**. Consider
334334again an ordinary gate
335335
336336```
@@ -340,13 +340,13 @@ again an ordinary gate
340340Typically the `context` is itself a library core, which itself
341341has a jet binding. If so, the parent axis of this gate is `7`.
342342
343−If the parent is already bound - and the parent *must* be already
343+If the parent is already bound - and the parent **must** be already
344344bound, in this road or a road containing it - we can hook this core
345345bottom-up into a tree hierarchy. Normally the child core is
346346produced by an arm of the parent core, so this is not a problem -
347347we wouldn't have the child if we hadn't already made the parent.
348348
349−The clue also contains a list of *hooks*, named nock formulas on
349+The clue also contains a list of **hooks**, named nock formulas on
350350the core. Usually these are arms, but they need not be. The
351351point is that we often want to call a core from C, in a situation
352352where we have no type or other source information. A common case
@@ -365,14 +365,14 @@ instance, if the core is a Hoon gate - a function - we will call
365365### u3j: the cold jet dashboard
366366
367367For even more fun, the jet tree is not actually a tree of
368−batteries. It's a tree of battery *labels*, where a label is
368+batteries. It's a tree of battery **labels**, where a label is
369369an [axis term] path from the root of the tree. (At the root,
370370if the core pattern is always followed properly, is a core whose
371371payload is an atomic constant, conventionally the Hoon version.)
372372
373373Under each of these labels, it's normal to have an arbitrary
374374number of different Nock batteries (not just multiple copies
375−of the same noun, a situation we *do* strive to avoid). For
375+of the same noun, a situation we **do** strive to avoid). For
376376instance, one might be compiled with debugging hints, one not.
377377
378378We might even have changed the semantics of the battery without
@@ -420,7 +420,7 @@ of information: the `++cope`, or per-location noun; and a map of
420420batteries to a per-battery `++club`.
421421
422422The `cope` is a triple of `++bane` (battery name, right now just
423−a `term`); `++axis`, the axis, within *this* core, of the parent;
423+a `term`); `++axis`, the axis, within **this** core, of the parent;
424424and `(each bash noun)`, which is either `[0 bash]` if the parent
425425is another core, or `[1 noun]`, for the constant noun (like
426426`164`) if there is no parent core.
@@ -453,7 +453,7 @@ validate with a single comparison. Otherwise, we have to recurse
453453upward by checking the parent.
454454
455455Note that there is at present no way to force a jet to depend on
456−static *data*.
456+static **data**.
457457
458458### u3j: the warm jet dashboard
459459
@@ -519,7 +519,7 @@ in the `u3j_harm` which tell us how to call the arm function.
519519
520520If `ice` is yes (`&`, `0`), the jet is known to be perfect and we
521521can just trust the product of `fun_f`. Otherwise, we need to run
522−*both* the Nock arm and `fun_f`, and compare their results.
522+**both** the Nock arm and `fun_f`, and compare their results.
523523
524524(Note that while executing the C side of this test, we have to
525525set `ice` to yes; on the Nock side, we have to set `liv` to no.
@@ -531,9 +531,9 @@ test is on the outermost layer of recursion.)
531531environment has a slight locking problem with these flags if arm
532532testing is multi-threaded.)
533533
534−If `tot` is yes, (`&`, `0`), the arm function is *total* and has
535−to return properly (though it can still return *u3_none*).
536−Otherwise, it is *partial* and can `u3_cm_bail()` out with
534+If `tot` is yes, (`&`, `0`), the arm function is **total** and has
535+to return properly (though it can still return **u3_none**).
536+Otherwise, it is **partial** and can `u3_cm_bail()` out with
537537c3__punt. This feature has a cost: the jet runs in a subroad.
538538
539539Finally, if `liv` is no (`|`, 1), the jet is off and doesn't run.
@@ -570,10 +570,10 @@ caller passes the entire core, which is retained if the function
570570returns `u3_none`, transferred otherwise. Why? Again, use
571571counts of 1 are special and precious for performance hackers.
572572
573−`u3q` interfaces break the core into C arguments, *retain* noun
574−arguments, and *transfer* noun returns. `u3k` interfaces are the
573+`u3q` interfaces break the core into C arguments, **retain** noun
574+arguments, and **transfer** noun returns. `u3k` interfaces are the
575575same, except with more use of `u3_none` and other simple C
576−variations on the Hoon original, but *transfer* both arguments
576+variations on the Hoon original, but **transfer** both arguments
577577and returns. Generally, `u3k` are most convenient for new code.
578578
579579Following `u3k/q/w` is `[a-f]`, corresponding to the 6 logical
@@ -586,7 +586,7 @@ For instance, `++add` is `u3wa_add(cor)`, `u3qa_add(a, b)`, or
586586`u3wdb_get(cor)`, `u3kdb_get(a, b)`, etc, in `j/d/by_get.c`.
587587
588588For historical reasons, all internal jet code in `j/[a-f]`
589−*retains* noun arguments, and *transfers* noun results. Please
589+**retains** noun arguments, and **transfers** noun results. Please
590590do not do this in new `g` jets! The new standard protocol is to
591591transfer both arguments and results.
592592
@@ -604,13 +604,13 @@ the macros `u3k()` and `u3z()` respectively.
604604Normally we create nouns through `u3i` functions, and don't call
605605the `u3a` allocators directly. But if you do:
606606
607−One, there are *two* sets of allocators: the word-aligned
607+One, there are **two** sets of allocators: the word-aligned
608608allocators and the fully-aligned (ie, malloc compatible)
609609allocators. For instance, on a typical OS X setup, malloc
610610produces 16-byte aligned results - needed for some SSE
611611instructions.
612612
613−These allocators are *not compatible*. For 32-bit alignment
613+These allocators are **not compatible**. For 32-bit alignment
614614as used in nouns, call
615615
616616```
@@ -670,7 +670,7 @@ allocate a block of raw space with `u3a_slab()`, then chop off
670670the end with `u3a_malt()` (which does the measuring itself)
671671or `u3a_mint()` in case you've measured it yourself.
672672
673−Once again, *do not call `malloc()`* (or C++ `new`) within any
673+Once again, **do not call `malloc()`** (or C++ `new`) within any
674674code that may be run within a jet. This will cause rare sporadic
675675corruption when we interrupt execution within a `malloc()`. We'd
676676just override the symbol, but `libuv` uses `malloc()` across
@@ -687,7 +687,7 @@ would expect, quite slow. (There is no such thing as a fast tree
687687interpreter.)
688688
689689There is only one Nock, but there are lots of ways to call it.
690−(Remember that all `u3n` functions *transfer* C arguments and
690+(Remember that all `u3n` functions **transfer** C arguments and
691691returns.)
692692
693693The simplest interpreter, `u3n_nock_on(u3_noun bus, u3_noun fol)`
@@ -696,7 +696,7 @@ invokes Nock on `bus` (the subject) and `fol` (the formula).
696696reason `0` is true and `1` is false.)
697697
698698A close relative is `u3n_slam_on(u3_noun gat, u3_noun sam)`,
699−which slams a *gate* (`gat`) on a sample (`sam`). (In a normal
699+which slams a **gate** (`gat`) on a sample (`sam`). (In a normal
700700programming language which didn't talk funny and was retarded,
701701`u3n_slam_on()` would call a function on an argument.) We could
702702write it most simply as:
@@ -715,7 +715,7 @@ write it most simply as:
715715```
716716
717717Simpler is `u3n_kick_on(u3_noun gat)`, which slams a gate (or,
718−more generally, a *trap* - because sample structure is not even
718+more generally, a **trap** - because sample structure is not even
719719needed here) without changing its sample:
720720
721721```
@@ -850,7 +850,7 @@ of `axis`, `u3_noun *`. For cells, triples, etc, decompose with
850850`u3r_pq()` and friends.
851851
852852`u3r_sing(u3_noun a, u3_noun b)` (true if `a` and `b` are a
853−*single* noun) are interesting because it uses mugs to help it
853+**single** noun) are interesting because it uses mugs to help it
854854out. Clearly, different nouns may have the same mug, but the
855855same nouns cannot have a different mug. It's important to
856856understand the performance characteristics of `u3r_sing()`:
@@ -907,7 +907,7 @@ the memoization facility is a general-purpose cache.
907907(It's also used for partial memoization - a feature that'll
908908probably be removed, in which conservative worklist algorithms
909909(which would otherwise be exponential) memoize everything in the
910−subject *except* the worklist. This is used heavily in the Hoon
910+subject **except** the worklist. This is used heavily in the Hoon
911911compiler jets (j/f/*.c). Unfortunately, it's probably not
912912possible to make this work perfectly in that it can't be abused
913913to violate Nock, so we'll probably remove it at a later date,