aboutsummaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorAyke van Laethem <[email protected]>2018-10-09 13:55:54 +0200
committerAyke van Laethem <[email protected]>2018-10-09 15:32:40 +0200
commit823ecd5167ed012b12cf3d45ed7002ddb11048d3 (patch)
tree9c1508e53b22f5566576970a4052d5fc609ae9b8
parentec73bd6a26d3ef667ace6c9f7dfac97638074866 (diff)
downloadtinygo-823ecd5167ed012b12cf3d45ed7002ddb11048d3.tar.gz
tinygo-823ecd5167ed012b12cf3d45ed7002ddb11048d3.zip
docs: reorder internals sections
-rw-r--r--docs/internals.rst56
1 files changed, 28 insertions, 28 deletions
diff --git a/docs/internals.rst b/docs/internals.rst
index a4f519552..d04805463 100644
--- a/docs/internals.rst
+++ b/docs/internals.rst
@@ -3,6 +3,34 @@
Compiler internals
==================
+Differences from ``go``
+-----------------------
+
+ * A whole program is compiled in a single step, without intermediate linking.
+ This makes incremental development much slower for large programs but
+ enables far more optimization opportunities. In the future, an option should
+ be added for incremental compilation during edit-compile-test cycles.
+ * Interfaces are always represented as a ``{typecode, value}`` pair. `Unlike
+ Go <https://research.swtch.com/interfaces>`_, TinyGo will not precompute a
+ list of function pointers for fast interface method calls. Instead, all
+ interface method calls are looked up where they are used. This may sound
+ expensive, but it avoids memory allocation at interface creation.
+ * Global variables are computed during compilation whenever possible (unlike
+ Go, which does not have the equivalent of a ``.data`` section). This is an
+ important optimization for several reasons:
+ * Startup time is reduced. This is nice, but not the main reason.
+ * Initializing globals by copying the initial data from flash to RAM costs
+ much less flash space as only the actual data needs to be stored,
+ instead of all instructions to initialize these globals.
+ * Data can often be statically allocated instead of dynamically allocated
+ at startup.
+ * Dead globals are trivially optimized away by LLVM.
+ * Constant globals are trivially recognized by LLVM and marked
+ ``constant``. This makes sure they can be stored in flash instead of
+ RAM.
+ * Global constants are useful for constant propagation and thus for dead
+ code elimination (like an ``if`` that depends on a global variable).
+
Pipeline
--------
@@ -46,31 +74,3 @@ After this whole list of compiler phases, the Go source has been transformed
into object code. It can then be emitted directly to a file (for linking in a
different build system), or it can be linked directly or even be flashed to a
target by TinyGo (using external tools under the hood).
-
-Differences from ``go``
------------------------
-
- * A whole program is compiled in a single step, without intermediate linking.
- This makes incremental development much slower for large programs but
- enables far more optimization opportunities. In the future, an option should
- be added for incremental compilation during edit-compile-test cycles.
- * Interfaces are always represented as a ``{typecode, value}`` pair. `Unlike
- Go <https://research.swtch.com/interfaces>`_, TinyGo will not precompute a
- list of function pointers for fast interface method calls. Instead, all
- interface method calls are looked up where they are used. This may sound
- expensive, but it avoids memory allocation at interface creation.
- * Global variables are computed during compilation whenever possible (unlike
- Go, which does not have the equivalent of a ``.data`` section). This is an
- important optimization for several reasons:
- * Startup time is reduced. This is nice, but not the main reason.
- * Initializing globals by copying the initial data from flash to RAM costs
- much less flash space as only the actual data needs to be stored,
- instead of all instructions to initialize these globals.
- * Data can often be statically allocated instead of dynamically allocated
- at startup.
- * Dead globals are trivially optimized away by LLVM.
- * Constant globals are trivially recognized by LLVM and marked
- ``constant``. This makes sure they can be stored in flash instead of
- RAM.
- * Global constants are useful for constant propagation and thus for dead
- code elimination (like an ``if`` that depends on a global variable).