diff options
author | Ayke van Laethem <[email protected]> | 2018-10-09 13:55:54 +0200 |
---|---|---|
committer | Ayke van Laethem <[email protected]> | 2018-10-09 15:32:40 +0200 |
commit | 823ecd5167ed012b12cf3d45ed7002ddb11048d3 (patch) | |
tree | 9c1508e53b22f5566576970a4052d5fc609ae9b8 | |
parent | ec73bd6a26d3ef667ace6c9f7dfac97638074866 (diff) | |
download | tinygo-823ecd5167ed012b12cf3d45ed7002ddb11048d3.tar.gz tinygo-823ecd5167ed012b12cf3d45ed7002ddb11048d3.zip |
docs: reorder internals sections
-rw-r--r-- | docs/internals.rst | 56 |
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). |