Commit 29d26bf5 authored by Kunshan Wang's avatar Kunshan Wang

More comments

parent 9e3e8ad4
......@@ -28,4 +28,8 @@ specification considers these parts as implementation-specific.
- `AMD64 Unix Native Interface <native-interface-x64-unix.rst>`__
- `Extensions for Boot-image Building <bootimage.rst>`__
Frequently asked questions:
- `FAQ <faq.rst>`__
.. vim: tw=80
=========================
Frequently Asked Question
=========================
Mu IR
=====
Mu API
======
Micro VM Implementation
=======================
Client Implementation
=====================
......@@ -554,8 +554,14 @@ A **constant constructor** can be the following:
..
For C programmers: Just like types, constants cannot be inlined. For
example::
For C programmers:
Constants are not part of the Mu memory. Although, in C, you can declare an
object with the "const" decorator: ``const int a = 42;`` and then have a
pointer to it: ``const int* pa = &a;``, you cannot do the same in Mu. Global
cells may be more appropriate if references to constants are ever taken.
Just like types, constants cannot be inlined. For example::
// Asssume @i64 is defined as int<64>
......@@ -621,9 +627,14 @@ may have multiple versions. A **version of function** has its control flow graph
which defines how it is executed. A version of function is also an identified
entity.
A **function definition** defines a *version of function* and, if the function
has not been declared, implicitly defines the *function*. It has the following
form::
A **function definition** defines a *version of function*. A *function version*
contains a control flow graph (CFG), but cannot be directly called. Calling a
*function* will actually call the most recent version a thread can see (see
`Bundle Loading`_ below for the exact visibility requirement).
In the text form, if a function has not been declared, a *function definition*
will implicitly define the *function*. In the `API <irbuilder.rst>`__,
*functions* and *function versions* are created separately. The text form is::
.funcdef Name VERSION VerName <Sig> { Body }
......@@ -636,9 +647,11 @@ where:
..
NOTE: The version is required for each definition. Although calling a
NOTE: The VerName is required for each definition. Although calling a
function will always call the most recent version, stack introspection and
on-stack replacement still need to know the concrete version.
on-stack replacement still need to know the concrete version. Although a
function can be redefined multiple times, existing activations in the stack
will continue to execute their respective versions.
..
......@@ -688,7 +701,7 @@ definitions of the same function name in the same bundle.
It is an error to declare a function which is previously declared or defined.
See the *Bundle Loading* section for the semantics of bundle loading and
See the `Bundle Loading`_ section for the semantics of bundle loading and
function redefinition.
Function Body
......@@ -719,8 +732,8 @@ type. Many instructions follow the colon ``:``.
%bb2() [%exc]:
...
The first basic block is the **entry block**. The entry block must have as many
parameters as the function parameters (determined by its signature). The
The first basic block is the **entry block**. The parameters of the entry block
must match the parameters of the function (determined by its signature). The
execution starts from the entry block, and its parameters receive the arguments
to the function. The entry block must not have the exception parameter.
......@@ -729,14 +742,14 @@ to the function. The entry block must not have the exception parameter.
NOTE: The name of the entry block is conventionally called ``%entry``, but
is not compulsory.
Other basic blocks are executed when branched to. The normal parameters receive
arguments from the branching sites. The exception parameter receives the
exception caught by the branching site as the argument. If the exception
parameter is omitted but the basic block is supposed to receive an exception,
the exception will be silently ignored. A basic block with an exception
parameter must only be used as the exceptional destination of instructions which
can catch exceptions, which currently include ``CALL``, ``TRAP``, ``WATCHPOINT``
and ``SWAPSTACK``.
The entry block must not be branched to from any basic blocks. Other basic
blocks are executed when branched to. The normal parameters receive arguments
from the branching sites. The exception parameter receives the exception caught
by the branching site as the argument. If the exception parameter is omitted but
the basic block is supposed to receive an exception, the exception will be
silently ignored. A basic block with an exception parameter must only be used as
the exceptional destination of instructions which can catch exceptions, which
currently include ``CALL``, ``TRAP``, ``WATCHPOINT`` and ``SWAPSTACK``.
An example of a basic block with an exception parameter::
......@@ -870,8 +883,18 @@ This definition exposes a Mu function *FuncName* as an exposed value, identified
by *Name*, using the calling convention *CallConv*. The *Cookie* is attached to
this exposed value.
NOTE: It is the **function** that is exposed, not the version. Like in Mu, C
programs can only directly call Mu functions rather than function versions.
When a Mu function is redefined, the exposed function will automatically
use the new version if called after redefining.
How such an exposed function can be called is implementation-specific.
NOTE: The spec is just trying to be general. In most cases, it will be
called from C, and the exposed function is seen by C as a function pointer,
and can be called using the same C calling convention (usually
``#DEFAULT``).
Example::
.expose @name = @func #DEFAULT @cookie
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment