From 95b70ce834313e60fbe27466b8bb6c1658c5c086 Mon Sep 17 00:00:00 2001 From: Raymond Tay Date: Thu, 22 Dec 2016 22:59:10 +0800 Subject: Minor change to have proper markdowns --- docs/docs/internals/backend.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'docs') diff --git a/docs/docs/internals/backend.md b/docs/docs/internals/backend.md index f10cf1e82..47974b5ff 100644 --- a/docs/docs/internals/backend.md +++ b/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`). -- cgit v1.2.3