Commit e5848b32 authored by qinsoon's avatar qinsoon

initial commit for issue27.

parent ecef49cd
......@@ -56,7 +56,7 @@ instructions or changing the grammar.
This document uses the following notation::
[id]@name [F1 F2 ...] < T1 T2 ... > <[ sig1 sig2 ... ]> ( p1:t1, p2:t2, ... ) excClause KEEPALIVE -> RTs
- ``id`` is the ID and ``@name`` is the name.
- ``[F1 F2 ...]`` is a list of flag parameters.
......@@ -180,6 +180,28 @@ Return the created ``tagref64`` value.
They have undefined behaviours if ``%tr`` does not hold the value of the
expected type.
Garbage Collection Instructions
===============================
.. _finaliser:
Finaliser
---------
::
[0x280]@uvm.gc.prevent_death_once (%r: ref<T>) -> void
[0x281]@uvm.gc.next_object_to_finalise () -> ref<void>
- ``prevent_death_once`` tags an object reference as *finalisable*. When the GC
decided that the object of ``%r`` is a garbage, it will put the reference
to the **objects-to-finalise queue** instead of reclaiming the memory. The
object will remain alive in the queue. This instruction is *atomic*.
- ``next_object_to_finalise`` removes one reference from the
**objects-to-finalise queue** and returns it.
The current Mu thread blocks if this queue is empty.
This instruction is *atomic*.
Math Instructions
=================
......@@ -329,7 +351,7 @@ the calling convention and *sig*.
convention *callConv* with cookie *cookie*.
Example::
.funcdef @foo VERSION ... <@foo_sig> (...) { ... }
%ev = COMMINST @uvm.native.expose [#DEFAULT] <[@foo_sig]>
......
......@@ -43,7 +43,7 @@ refers to a memory location in *any* part of the Mu memory.
when pinning (discussed later). Even when pinned, the address may or may not
be the canonical address where the location is allocated in Mu. For example,
Mu objects can be replicated.
When allocating Mu memory locations (in the heap, stack or global memory),
Mu guarantee the location can hold Mu values of a particular type and, as
long as the type allows atomic access, the location can be accessed
......@@ -84,7 +84,7 @@ refers to a memory location in *any* part of the Mu memory.
In C, the word "memory location" must have scalar types, but Mu uses the
term "memory location" for composite types, too.
For a memory location L that represents type T, if c is a member (if applicable)
or a component of T, it also has a memory location which is a **member** or a
**component** of the memory location L, respectively. Memory location L1
......@@ -100,7 +100,7 @@ locations. When a heap object is moved by the garbage collector, it is still the
same object. Any memory locations within the same object remain the same.
NOTE: This means the memory of Mu is an abstraction over the memory space of
the process.
the process.
Native Memory
-------------
......@@ -126,11 +126,11 @@ components of a memory location which do not contain each other do not map to
overlapping regions in the address space.
For C programmers:
* Mu assumes 8-bit bytes.
* Mu assumes 8-bit bytes.
* Mu does not have the bit-field type, but a client can implement bit-fields
using integer types and bit operations.
using integer types and bit operations.
* Mu does not have union types. However, like C, directly casting an address
to a pointer has implementation-defined behaviours. If a Mu program
......@@ -207,6 +207,22 @@ references which refers to a weakly reachable object to ``NULL``.
The garbage collector may move objects.
Finaliser
---------
Mu does not invoke client-side finalisers upon object death for the client.
However, Mu maintains an
**objects-to-finalise queue**. Client can mark an object as finalisable with
the common instruction ``@uvm.gc.prevent_death_once``
(see `Common Instruction <common-insts.rst#finaliser>`__).
Mu guarantees that finalisable objects will be put to an **objects-to-finalise
queue** at the first time they are found dead,
and remain alive in the queue. Client can use ``@uvm.gc.next_object_to_finalise``
to fetch an object reference from the queue, and invoke its finaliser. This
instruction blocks the thread when the queue is empty. Client can consider starting
a dedicated finalising thread, which runs Mu code as a loop to fetch finalisable
objects, and invoke finalisers.
Memory Accessing
================
......@@ -334,7 +350,7 @@ When non-atomically loading from or storing to a region *R* of bytes which is
location, and
2. each byte in the region is part of any mapped byte region of any pinned Mu
memory location,
then such an operation loads or stores on a byte-by-byte basis. Specifically:
* Such a load operation *L*:
......@@ -416,7 +432,7 @@ represented in that region. A non-NULL internal reference of type *T* refers to
the memory location of type *T* at a specific beginning.
NOTE: There can only be one such memory location.
Specifically, there is a memory location of type ``void`` at the beginning of
any other memory location.
......
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