Minor change to have proper markdowns

docs/docs/internals/backend.md

@@ -4,7 +4,7 @@ title: "Backend Internals"
 ---
 
 The code for the backend is split up by functionality and assembled in the
-objet `GenBCode`.
+object `GenBCode`.
 
 ```none
 object GenBCode    --- [defines] -->        PlainClassBuilder       GenBCode also defines class BCodePhase, the compiler phase
@@ -61,29 +61,29 @@ ready for serialization to disk.
 
 Currently the queue subsystem is all sequential, but as can be seen in
 http://magarciaepfl.github.io/scala/ the above design enables overlapping (a.1)
-building of ClassNodes, (a.2) intra-method optimizations, and (a.3)
+building of `ClassNodes`, (a.2) intra-method optimizations, and (a.3)
 serialization to disk.
 
-This subsystem is described in detail in GenBCode.scala
+This subsystem is described in detail in `GenBCode.scala`
 
 #### (b) Bytecode-level types, BType ####
 The previous bytecode emitter goes to great lengths to reason about
 bytecode-level types in terms of Symbols.
 
-GenBCode uses BType as a more direct representation. A BType is immutable, and
+`GenBCode` uses `BType` as a more direct representation. A `BType` is immutable, and
 a value class (once the rest of GenBCode is merged from
 http://magarciaepfl.github.io/scala/ ).
 
 Whether value class or not, its API is the same. That API doesn't reach into
-the type checker. Instead, each method on a BType answers a question that can
-be answered based on the BType itself. Sounds too simple to be good? It's a
+the type checker. Instead, each method on a `BType` answers a question that can
+be answered based on the `BType` itself. Sounds too simple to be good? It's a
 good building block, that's what it is.
 
-The internal representation of a BType is based on what the JVM uses: internal
-names (eg Ljava/lang/String; ) and method descriptors; as defined in the JVM
-spec (that's why they aren't documented in GenBCode, just read the spec).
+The internal representation of a `BType` is based on what the JVM uses: internal
+names (e.g. `Ljava/lang/String;` ) and method descriptors; as defined in the JVM
+spec (that's why they aren't documented in `GenBCode`, just read the [JVM 8 spec](https://docs.oracle.com/javase/specs/jvms/se8/html/)).
 
-All things BType can be found in BCodeGlue.scala
+All things `BType` can be found in `BCodeGlue.scala`
 
 #### (c) Utilities offering a more "high-level" API to bytecode emission ####
 Bytecode can be emitted one opcode at a time, but there are recurring patterns
@@ -93,7 +93,7 @@ For example, when emitting a load-constant, a dedicated instruction exists for
 emitting load-zero. Similarly, emitting a switch can be done according to one
 of two strategies.
 
-All these utilities are encapsulated in file BCodeIdiomatic.scala. They know
+All these utilities are encapsulated in file `BCodeIdiomatic.scala`. They know
 nothing about the type checker (because, just between us, they don't need to).
 
 #### (d) Mapping between type-checker types and BTypes ####
@@ -109,10 +109,10 @@ To understand how it's built, see:
 final def exemplar(csym0: Symbol): Tracked = { ... }
 ```
 
-Details in BCodeTypes.scala
+Details in `BCodeTypes.scala`
 
 #### (e) More "high-level" utilities for bytecode emission ####
-In the spirit of BCodeIdiomatic, utilities are added in BCodeHelpers for
+In the spirit of `BCodeIdiomatic`, utilities are added in `BCodeHelpers` for
 emitting:
 
 - bean info class
@@ -122,4 +122,4 @@ emitting:
 
 
 #### (f) Building an ASM ClassNode given an AST TypeDef ####
-It's done by PlainClassBuilder
+It's done by `PlainClassBuilder`(see `GenBCode.scala`).