Commit ab9434e3 authored by Kunshan Wang's avatar Kunshan Wang

Fixed links.

parent 8913a345
......@@ -10,28 +10,28 @@ machine, including its architecture, instruction set and type system.
Main specification:
- `Overview <overview>`__
- `Intermediate Representation <uvm-ir>`__
- `Intermediate Representation (Binary Form) <uvm-ir-binary>`__
- `Type System <type-system>`__
- `Instruction Set <instruction-set>`__
- `Common Instructions <common-insts>`__
- `Client Interface <uvm-client-interface>`__
- `Threads and Stacks <threads-stacks>`__
- `Memory and Garbage Collection <uvm-memory>`__
- `Memory Model <memory-model>`__
- `Native Interface <native-interface>`__
- `Heap Allocation and Initialisation Language (HAIL) <hail>`__
- `Portability and Implementation Advices <portability>`__
- `Overview <overview.rest>`__
- `Intermediate Representation <uvm-ir.rest>`__
- `Intermediate Representation (Binary Form) <uvm-ir-binary.rest>`__
- `Type System <type-system.rest>`__
- `Instruction Set <instruction-set.rest>`__
- `Common Instructions <common-insts.rest>`__
- `Client Interface <uvm-client-interface.rest>`__
- `Threads and Stacks <threads-stacks.rest>`__
- `Memory and Garbage Collection <uvm-memory.rest>`__
- `Memory Model <memory-model.rest>`__
- `Native Interface <native-interface.rest>`__
- `Heap Allocation and Initialisation Language (HAIL) <hail.rest>`__
- `Portability and Implementation Advices <portability.rest>`__
Platform-specific parts: These extends the main specification. The main
specification considers these parts as implementation-specific.
- `AMD64 Unix Native Interface <native-interface-x64-unix>`__
- `AMD64 Unix Native Interface <native-interface-x64-unix.rest>`__
Old documents:
- `Client Interface (old) <uvm-client-interface-old>`__
- `Client Interface (old) <uvm-client-interface-old.rest>`__
.. vim: tw=80
......@@ -7,7 +7,7 @@ This document specifies Common Instructions.
**Common Instructions** are instructions that have a common format and are
used with the ``COMMINST`` super instruction. They have:
1. An ID and a name. (This means, they are *identified*. See `<uvm-ir>`__.)
1. An ID and a name. (This means, they are *identified*. See `<uvm-ir.rest>`__.)
2. A flag list.
3. A type parameter list.
4. A value parameter list.
......@@ -165,7 +165,7 @@ Math Instructions
Futex Instructions
==================
See `<threads-stacks>`__ for high-level descriptions about Futex.
See `<threads-stacks.rest>`__ for high-level descriptions about Futex.
Wait
----
......
......@@ -37,7 +37,7 @@ evaluated. Storing them to global cells is one way to keep references to the
allocated objects.
**Global name**, **integer literal**, **floating point literal** and **null
literal** are defined the same way as in `Mu IR <uvm-ir>`__.
literal** are defined the same way as in `Mu IR <uvm-ir.rest>`__.
Top-level Definitions
=====================
......@@ -98,7 +98,7 @@ The *rvalue* determines the value to write in the location:
``iref`` type) to the object just allocated;
- if it is a global name, it designates the value of the global SSA variable of
that name, as defined in `Instruction Set <instruction-set>`__. Specifically,
that name, as defined in `Instruction Set <instruction-set.rest>`__. Specifically,
* the name of a constant has the value of that constant;
......@@ -213,7 +213,7 @@ refer to different things even if their values are equal. HAIL IDs only refer to
heap-allocated objects in the current HAIL script.
In the following paragraphs, binary types defined in `Mu IR Binary Form
<uvm-ir-binary>`__ are used. For convenience, we use "hID" for HAIL ID and "mID"
<uvm-ir-binary.rest>`__ are used. For convenience, we use "hID" for HAIL ID and "mID"
for Mu ID.
A *fixed object allocation* definition has the form:
......
......@@ -148,7 +148,7 @@ subsequently. Otherwise it is **dead**.
The execution of an instruction is called an **evaluation**. An evaluation
determines the data value associated to an instruction and this process is
called **value computation**. Accessing the memory (see `<uvm-memory>`__) or
called **value computation**. Accessing the memory (see `<uvm-memory.rest>`__) or
changing the state of the execution environment is called **side effect**. An
evaluation may have side effects.
......@@ -180,7 +180,7 @@ destination**.
The exception clause can be omitted. In the binary form, an omitted exception
clause is expressed as *nor* and *exc* both being 0. Any instruction that may
have exception clauses is not a *terminator* (see `<uvm-ir>`__) if the exception
have exception clauses is not a *terminator* (see `<uvm-ir.rest>`__) if the exception
clause is omitted. Otherwise it is a *terminator*.
Any instruction that may have exception clause may **continue normally** or
......@@ -552,7 +552,7 @@ return value
In all comparison operations, both *op1* and *op2* must have type *T*.
For EQ and NE, *T* must be a EQ-comparable type (see `<type-system>`__) or a
For EQ and NE, *T* must be a EQ-comparable type (see `<type-system.rest>`__) or a
vector of EQ-comparable types.
For SGE, SGT, SLE, SLT, UGE, UGT, ULE and ULT, *T* must be ``int`` or a vector
......@@ -1266,7 +1266,7 @@ have any exception clause and is not an OSR point.
immediately return the returned value, but reuses the current frame.
Calling an undefined function is allowed. Such functions will trigger a trap so
that the client can handle it. See `Mu IR <uvm-ir>`__ for the behaviour of
that the client can handle it. See `Mu IR <uvm-ir.rest>`__ for the behaviour of
undefined functions.
..
......@@ -1853,7 +1853,7 @@ return value
..
NOTE: The cryptic description of the return value means the referent type
``T`` may be a prefix (see `<uvm-memory>`__) of the actual type represented
``T`` may be a prefix (see `<uvm-memory.rest>`__) of the actual type represented
in the object. In this case, this instruction only provides access to the
prefix part.
......@@ -1969,7 +1969,7 @@ The ``GETELEMIREF`` instruction gets an internal reference/pointer to the
The ``SHIFTIREF`` instruction assumes the *opnd* already refers to an element of
a *memory array* (including arrays, vectors and the variable part of hybrids,
see `Mu and the Memory <uvm-memory>`__). It moves *opnd* internal
see `Mu and the Memory <uvm-memory.rest>`__). It moves *opnd* internal
reference/pointer forward by *offset* elements. If *offset* is negative, it
moves the reference/pointer backwards by the absolute value of *offset*.
......@@ -2044,8 +2044,8 @@ Memory Order
~~~~~~~~~~~~
A **memory order** is one in the following table. Their semantics are described
in `<memory-model>`__. Different instructions have different requirements for
their *memory orders*. See `<memory-model>`__.
in `<memory-model.rest>`__. Different instructions have different requirements for
their *memory orders*. See `<memory-model.rest>`__.
=========== ====== =======================
Keyword Binary Semantic
......@@ -2086,7 +2086,7 @@ return value
+------+------+------+-----+------+-----------+
The ``LOAD`` instruction performs a *load* operation with argument (*ord*, *T*,
*loc*) as defined in `Mu and the Memory <uvm-memory>`__.
*loc*) as defined in `Mu and the Memory <uvm-memory.rest>`__.
In the text form, *ord* can be omitted and defaults to ``NOT_ATOMIC``.
......@@ -2132,7 +2132,7 @@ newVal
+------+------+------+-----+------+--------+-----------+
The ``STORE`` instruction performs a *store* operation with argument (*ord*,
*T*, *loc*, *newVal*) as defined in `Mu and the Memory <uvm-memory>`__.
*T*, *loc*, *newVal*) as defined in `Mu and the Memory <uvm-memory.rest>`__.
In the text form, *ord* can be omitted and defaults to ``NOT_ATOMIC``.
......@@ -2189,10 +2189,10 @@ return value:
The ``CMPXCHG`` instruction performs a *compare exchange* operation with
argument (*isWeak*, *ordSucc*, *ordFail*, *T*, *loc*, *expected*, *desired*),
where *isWeak* is true if ``WEAK`` is present, otherwise false. The operation
is defined in `Mu and the Memory <uvm-memory>`__.
is defined in `Mu and the Memory <uvm-memory.rest>`__.
The result is a struct. The two fields represents the *v* and *s* value as
defined in `Mu and the Memory <uvm-memory>`__. The second field is 1 for true
defined in `Mu and the Memory <uvm-memory.rest>`__. The second field is 1 for true
and 0 for false.
For LLVM users: This is the counterpart of the ``cmpxchg`` instruction.
......@@ -2285,7 +2285,7 @@ UMIN 0x0A int unsigned min
The ``ATOMICRMW`` instruction performs an *atomic-x* operation with argument
(*ord*, *T*, *loc*, *opnd*), where the *x* in *atomic-x* is *op*. The operation
is defined in `Mu and the Memory <uvm-memory>`__.
is defined in `Mu and the Memory <uvm-memory.rest>`__.
..
......@@ -2315,7 +2315,7 @@ ord
+------+------+
The ``FENCE`` is a fence of memory order *ord*. Its semantics is specified in
`<memory-model>`__.
`<memory-model.rest>`__.
For LLVM users: This is the counterpart of the ``fence`` instruction.
......@@ -2413,7 +2413,7 @@ enabled.
If the client disabled watch point 42 when handling this watchpoint and
rebinds the current stack passing VOID (see `Threads and Stacks
<threads-stacks>`__ for stack/thread rebinding), then it will branch to
<threads-stacks.rest>`__ for stack/thread rebinding), then it will branch to
``%ena``. The ``%wp`` instruction will branch to ``%dis`` if and only if
watch point 42 is disabled when it is executed.
......@@ -2592,7 +2592,7 @@ The ``CCALL`` instruction calls a native function.
The *callee* must have type *T*. The allowed type of ``T`` is
implementation-dependent and calling convention-dependent.
See `<native-interface>`__ for a detailed description of the native interface.
See `<native-interface.rest>`__ for a detailed description of the native interface.
The return value of ``CCALL`` is the return value of the native callee.
......@@ -2721,7 +2721,7 @@ This instruction continues exceptionally if Mu cannot allocate the new stack.
Which function version is used for the stack-bottom frame is determined by when
the stack is created, not when the stack is resumed. See `Memory Model
<memory-model>`__.
<memory-model.rest>`__.
NOTE: This means it may still run an old version if a newer version is
loaded by the client between when the stack is created and when the stack is
......@@ -2730,7 +2730,7 @@ the stack is created, not when the stack is resumed. See `Memory Model
TODO: Is this the most "implement-able" and most desirable way?
Creating a stack for an undefined function is allowed. It will trap when that
frame is executed. See `Mu IR <uvm-ir>`__ for the behaviour of undefined
frame is executed. See `Mu IR <uvm-ir.rest>`__ for the behaviour of undefined
functions.
..
......@@ -2837,7 +2837,7 @@ In the *newStackClause*:
+ If the *newStackClause* is ``THROW_EXC``, the exception object *exc* is thrown
to the *swappee* stack.
See `Thread and Stack <threads-stacks>`__ for more details about the SWAP-STACK
See `Thread and Stack <threads-stacks.rest>`__ for more details about the SWAP-STACK
operation.
When a stack in the ``READY<T>`` state is pausing on a ``SWAPSTACK`` instruction
......@@ -2983,7 +2983,7 @@ instruction must not have an exception clause unless the common instruction can
continue exceptionally. A ``COMMINST`` instruction must have an empty keep-alive
clause unless the common instruction is an OSR point.
See `<common-insts>`__ for a complete list of common instructions.
See `<common-insts.rest>`__ for a complete list of common instructions.
..
......
......@@ -67,24 +67,24 @@ Concepts
========
data value
See `Type System <type-system>`__
See `Type System <type-system.rest>`__
SSA variable, instruction and evaluation
See `Instruction Set <instruction-set>`__
See `Instruction Set <instruction-set.rest>`__
memory, initial value, load, store, access and conflict
See `Mu and the Memory <uvm-memory>`__
See `Mu and the Memory <uvm-memory.rest>`__
thread
A thread is the unit of CPU scheduling. In this memory model, threads
include but are not limited to Mu threads. See `Threads and Stacks <threads-stacks>`__ for the
include but are not limited to Mu threads. See `Threads and Stacks <threads-stacks.rest>`__ for the
definition of Mu threads.
stack, stack binding, stack unbinding, swap-stack
See `Threads and Stacks <threads-stacks>`__
See `Threads and Stacks <threads-stacks.rest>`__
futex, futex_wait, futex_wake
See `Threads and Stacks <threads-stacks>`__
See `Threads and Stacks <threads-stacks.rest>`__
Comparison of Terminology
-------------------------
......
......@@ -297,13 +297,13 @@ Changes in the Mu IR and the API introduced by the native interface
* ``uptr < T >``
* ``ufuncptr < sig >``
See `Type System <type-system>`__
See `Type System <type-system.rest>`__
**New top-level definitions**:
* function exposing definition
See `Mu IR <uvm-ir>`__.
See `Mu IR <uvm-ir.rest>`__.
**New instructions**:
......@@ -314,8 +314,8 @@ See `Mu IR <uvm-ir>`__.
* ``@uvm.native.unexpose``
* ``@uvm.native.get_cookie``
See `Instruction Set <instruction-set>`__ and `Common Instructions
<common-insts>`__.
See `Instruction Set <instruction-set.rest>`__ and `Common Instructions
<common-insts.rest>`__.
**Modified instructions**:
......@@ -347,7 +347,7 @@ example:
* ``%result = CMPXCHG PTR ACQ_REL ACQUIRE <@T> %ptr_to_T %expected %desired``
* ``%old_val = ATOMICRMW ADD PTR SEQ_CST <@T> %ptr_to_T %rhs``
See `Instruction Set <instruction-set>`__.
See `Instruction Set <instruction-set.rest>`__.
**New API functions**:
......
......@@ -133,7 +133,7 @@ Mu is agnostic of the type hierarchy in high-level languages, but the client can
implement its language-specific type system and run-time type information on top
of the Mu type system.
See `Type System <type-system>`__ for more details.
See `Type System <type-system.rest>`__ for more details.
The Mu Instruction Set
-----------------------
......@@ -157,8 +157,8 @@ cannot handle.
There are also instructions for handling stack and threads.
See `Instruction Set <instruction-set>`__ and `Common Instructions
<common-insts>`__ for more details.
See `Instruction Set <instruction-set.rest>`__ and `Common Instructions
<common-insts.rest>`__ for more details.
The Mu Client Interface
------------------------
......@@ -181,7 +181,7 @@ The client also handles trap events generated by the Mu IR code. The client can
introspect the selected local variables on the stack and perform on-stack
replacement (i.e. OSR. Discussed later.)
See `Client Interface <uvm-client-interface>`__ for more details.
See `Client Interface <uvm-client-interface.rest>`__ for more details.
Unsafe Native Interface
-----------------------
......@@ -198,7 +198,7 @@ This interface is different from the client API. The main purpose is to
implement the system-interfacing part of the high-level language, such as the IO
and the networking library.
See `Native Interface <native-interface>`__ for more details.
See `Native Interface <native-interface.rest>`__ for more details.
Multi-Threading
---------------
......@@ -216,8 +216,8 @@ Linux kernel. It is the client's responsibility to implement mutex locks,
semaphores, conditions, barriers and so on using atomic memory accesses and the
futex.
See `Threads and Stacks <threads-stacks>`__ for details about threads and
`Memory Model <memory-model>`__ for the Mu memory model.
See `Threads and Stacks <threads-stacks.rest>`__ for details about threads and
`Memory Model <memory-model.rest>`__ for the Mu memory model.
The Swap-stack Operation
------------------------
......@@ -243,7 +243,7 @@ It also allows the client to implement its own light-weight
thread. This is particularly useful for languages with massively many threads
(e.g. Erlang).
See `Threads and Stacks <threads-stacks>`__ for details.
See `Threads and Stacks <threads-stacks.rest>`__ for details.
Function Redefinition
---------------------
......@@ -265,8 +265,8 @@ If a function has zero versions, it is "undefined". Calling such a function will
"trap" to the client. Such functions behave like "stubs" and this gives the
client a chance to implement lazy code/class loading.
See `Intermediate Representation <uvm-ir.rest>`__ for the definition of
functions and versions, and see `Client Interface <uvm-client-interface>`__ for
See `Intermediate Representation <uvm-ir.rest.rest>`__ for the definition of
functions and versions, and see `Client Interface <uvm-client-interface.rest>`__ for
the code loading interface.
On-stack Replacement
......@@ -287,15 +287,15 @@ Note that Mu is oblivious about whether the new version is "equivalent to" or
"better than" the old version. The responsibility of optimisation is pushed to
the client.
See `Client Interface <uvm-client-interface>`__ for more details.
See `Client Interface <uvm-client-interface.rest>`__ for more details.
Miscellaneous Topics
--------------------
The `Memory <uvm-memory>`__ chapter provides more detail about garbage
The `Memory <uvm-memory.rest>`__ chapter provides more detail about garbage
collection and memory allocation/accessing.
The `Portability <portability.rest>`__ chapter describes the requirements of
The `Portability <portability.rest.rest>`__ chapter describes the requirements of
implementations. It summarises corner cases which may result in different or
undefined behaviours in different platforms.
......
......@@ -119,7 +119,7 @@ For shifting instructions ``SHL``, ``LSHR`` and ``ASHR`` for integer type
Conversions instructions are required between any two implemented types that can
be converted. Specifically, given two types T1 and T2 and a conversion operation
CONVOP, if both T1 and T2 are implemented and they satisfied the requirement of
the ``T1`` and ``T2`` parameters of CONVOP (see `<instruction-set>`__), then the
the ``T1`` and ``T2`` parameters of CONVOP (see `<instruction-set.rest>`__), then the
CONVOP operation converting from T1 to T2 is required.
Binary floating point operations round to nearest and round ties to even.
......
......@@ -9,7 +9,7 @@ threads.
On the other hand, Mu does allow multiple simultaneous threads. Mu threads, by
design, can be implemented as native OS threads and make use of parallel CPU
resources. Mu also has a memory model. See the `Memory Model <memory-model>`__
resources. Mu also has a memory model. See the `Memory Model <memory-model.rest>`__
chapter for more information.
This chapter discusses Mu threads and Mu stacks. In this chapter, "thread"
......@@ -28,7 +28,7 @@ A **stack** is the context of nested or recursive activations of functions.
A stack has many **frames**, each of which is the context of one function
activation. A frame contains the states of all local variables (parameters and
instructions), the program counter and alloca cells (see `Mu and the Memory
<uvm-memory>`__). Each frame is associated with a *version* of a function.
<uvm-memory.rest>`__). Each frame is associated with a *version* of a function.
NOTE: Because Mu allows function redefinition, a function may be redefined
by the client, and newly created function activations (newly called
......@@ -190,7 +190,7 @@ Swap-stack
that thread to a new stack. In a swap-stack operation, the stack to unbind from
is called the **swapper** and the stack to bind to is called the **swappee**.
The ``SWAPSTACK`` instruction (see `<instruction-set>`__) performs a
The ``SWAPSTACK`` instruction (see `<instruction-set.rest>`__) performs a
*swap-stack* operation.
A trap handler can do similar things as *swap-stack* by re-binding the current
......@@ -254,7 +254,7 @@ Mu provides a mechanism similar to the Futex in the Linux kernel for
implementing blocking locks and other synchronisation primitives.
There is a waiting queue for all memory locations that has some integer types.
(See `<portability>`__ for valid candidate types for Futex.)
(See `<portability.rest>`__ for valid candidate types for Futex.)
The ``@uvm.futex.wait`` and the ``@uvm.futex.wait_timeout`` instructions put the
current thread into the waiting queue of a memory location. Both
......
......@@ -53,7 +53,7 @@ The following type constructors are available in Mu:
Parameters of a type are in the angular brackets. They can be integer literals,
types and function signatures. In the text form, the latter two are global
names (See `<uvm-ir>`__). In the binary form, they are IDs.
names (See `<uvm-ir.rest>`__). In the binary form, they are IDs.
There are several kinds of types.
......
......@@ -95,8 +95,8 @@ can only be used by one client thread at a time.
what a Mu thread holds. For example, implementations may reserve blocks of
heap memory in client contexts so that memory allocation will not always
require global locks. This trick is used by many garbage collectors that
support parallel mutators, for example,
[Immix](http://users.cecs.anu.edu.au/~steveb/downloads/pdf/immix-pldi-2008.pdf).
support parallel mutators, for example, `Immix
<http://users.cecs.anu.edu.au/~steveb/downloads/pdf/immix-pldi-2008.pdf>`__.
It holds Mu values for the client. The values are referred by the client via
opaque **handles**. Those handles are defined as::
......@@ -155,7 +155,7 @@ location or other entities. This means a handle can keep Mu heap objects alive.
Lua 4.0, introduced a stack-based API to pass values to/from the C program.
That stack is unnecessary for Mu because Mu is not a stack-based VM. The API
is also not designed to frequently exchange data frequently with the client
(see the (unsafe) `Native Interface <native-interface>`__ for a more
(see the (unsafe) `Native Interface <native-interface.rest>`__ for a more
efficient (and less safe) interface).
..
......@@ -581,7 +581,7 @@ Memory addressing
* ``shift_iref`` assumes ``opnd`` refers to an element in a memory array
(including arrays, vectors and the variable part of hybrids in the memory, see
`Mu and the Memory <uvm-memory>`__). It returns the iref of ``opnd`` moved by
`Mu and the Memory <uvm-memory.rest>`__). It returns the iref of ``opnd`` moved by
``offset`` (forward if positive, backward if negative).
* ``get_fixed_part_iref`` gets an iref to the fixed part of the hybrid referred
......@@ -892,7 +892,7 @@ where::
``@uvm.native.expose`` instruction or the ``expose`` API function with calling
convention ``call_conv``.
See the `Native Interface <native-interface>`__ chapter for details of expose
See the `Native Interface <native-interface.rest>`__ chapter for details of expose
and unexpose. See the platform-specific native interface for the return value
type.
......@@ -909,7 +909,7 @@ It is unspecified on which stack the trap handler is run.
Mu is allowed to call these handlers concurrently. Mu does not guarantee the
order in which these handlers are called, but guarantees the happen-before
relation between the trap and the handler. See `Memory Model <memory-model>`__.
relation between the trap and the handler. See `Memory Model <memory-model.rest>`__.
The Mu thread that triggers the trap is temporarily unbound from the stack.
......
......@@ -3,12 +3,12 @@ Intermediate Representation (Binary Form)
=========================================
This document describes the binary form of the Mu intermediate representation.
For the text form, see `<uvm-ir>`__.
For the text form, see `<uvm-ir.rest>`__.
Overview
========
The Mu IR Binary Form is similar to the `Text Form <uvm-ir>`__ in structure,
The Mu IR Binary Form is similar to the `Text Form <uvm-ir.rest>`__ in structure,
but has notable differences.
Numerical IDs are used exclusively instead of textual names. The binary form
......@@ -94,7 +94,7 @@ Type definition has the following form:
+------+-----+------------------+
``id`` is the identifier of the defined type. A type constructor follows the
opcode 0x01 and the ID. See `<type-system>`__ for a complete list of type
opcode 0x01 and the ID. See `<type-system.rest>`__ for a complete list of type
constructors.
NOTE: this is equivalent to: ``.typedef id = cons``.
......@@ -287,7 +287,7 @@ An **instruction** has the following form:
+-----+------------------+
``id`` is the ID of the instruction. ``instbody`` is instruction body which is
specific to each instruction. See `<instruction-set>`__ for an exhaustive list.
specific to each instruction. See `<instruction-set.rest>`__ for an exhaustive list.
Function Exposing Definition
============================
......@@ -323,7 +323,7 @@ A name binding has the following form:
``bytex`` is the value of each byte.
The name is encoded in ASCII and must follow the rules of global names, local
names and allowed characters as defined in `<uvm-ir>`__.
names and allowed characters as defined in `<uvm-ir.rest>`__.
Example
=======
......
......@@ -15,12 +15,12 @@ introduce their own formats as long as they are equivalent, in which case the
interface to use and to load them is implementation-specific.
This document describes the text form and the aspects not specific to the binary
form. For the binary form, see `<uvm-ir-binary>`__.
form. For the binary form, see `<uvm-ir-binary.rest>`__.
For the documents of the type system and the instruction set, see:
- `<type-system>`__
- `<instruction-set>`__
- `<type-system.rest>`__
- `<instruction-set.rest>`__
Example
=======
......@@ -227,7 +227,7 @@ implementation for extension purposes.
Type Definition
===============
Types and the **type constructor** syntax are documented in `<type-system>`__.
Types and the **type constructor** syntax are documented in `<type-system.rest>`__.
A **type definition** gives a name to a type. It has the following form::
......@@ -365,7 +365,7 @@ A **constant constructor** can be the following:
A constant must not be recursive.
- A **null constructor** create a null value of *general reference types* except
``weakref`` (defined in `<type-system>`__). It is written as the **null
``weakref`` (defined in `<type-system.rest>`__). It is written as the **null
literal**: ``NULL``.
..
......@@ -376,7 +376,7 @@ A **constant constructor** can be the following:
..
NOTE: ``weakref`` cannot be the type of an SSA variable, but all constants
are SSA variables. (See `<type-system>`__ and `<instruction-set>`__).
are SSA variables. (See `<type-system.rest>`__ and `<instruction-set.rest>`__).
..
......@@ -479,7 +479,7 @@ Global Cell Definition
======================
A **global cell definition** defines a **global cell**. A global cell is the
memory allocation unit in the *global memory*. See `<uvm-memory>`__ for more
memory allocation unit in the *global memory*. See `<uvm-memory.rest>`__ for more
information about the global memory.
NOTE: The global memory is the counterpart of static or global variables in
......@@ -622,7 +622,7 @@ where:
The name of an instruction can be omitted in the text form, in which case the
instruction has no name. The grammar of the ``InstBody`` part for each
instruction is defined separately in `<instruction-set>`__.
instruction is defined separately in `<instruction-set.rest>`__.
Example::
......@@ -686,7 +686,7 @@ which is one of the following:
- ``LOAD``, ``STORE``, ``CMPXCHG``, ``ATOMICRMW``
- ``TRAP``, ``WATCHPOINT``
- ``NEWSTACK``, ``SWAPSTACK``
- Some `common instructions <common-insts>`__ via the generic ``COMMINST``
- Some `common instructions <common-insts.rest>`__ via the generic ``COMMINST``
instruction:
- ``@uvm.thread_exit``
......@@ -746,7 +746,7 @@ Bundle Loading
==============
The API provides a ``load_bundle`` function. See `the API
<uvm-client-interface>`__. This function can be called by multiple client
<uvm-client-interface.rest>`__. This function can be called by multiple client
threads on their client contexts, and the result is always equivalent to as if
they were loaded in a specific sequence.
......@@ -765,7 +765,7 @@ the function. Defines of functions (bundle loading) and uses of functions
(including function calls and the creation of stacks, i.e. the ``NEWSTACK``
instruction or the ``new_stack`` API) obey the memory model of the ``RELAXED``
order as if the definition is a store and the use is a load. See `Memory Model
<memory-model>`__.
<memory-model.rest>`__.
All existing activations of any functions remain unchanged, that is, they remain
to be the old versions of the functions.
......
......@@ -96,7 +96,7 @@ overlapping regions in the address space.
* Mu forces the 2's complement representation, though the byte order and
alignment requirement are implementation-defined.
See `Native Interface <native-interface>`__ for details about the pinning and
See `Native Interface <native-interface.rest>`__ for details about the pinning and
unpinning operations.
Memory Allocation and Deallocation
......@@ -169,8 +169,8 @@ have both a load and a store operation, but may have special atomic properties.
abstract operations are in lower case: load, store and access.
Memory access operations can be performed by some Mu instructions (see
`Instruction Set <instruction-set>`__, API functions (see `Client Interface
<uvm-client-interface>`__), native programs which accesses the pinned Mu memory,
`Instruction Set <instruction-set.rest>`__, API functions (see `Client Interface
<uvm-client-interface.rest>`__), native programs which accesses the pinned Mu memory,
or in other implementation-specific ways.
Two memory accesses **conflict** if one stores to a memory location and the
......@@ -181,7 +181,7 @@ Parameters and Semantics of Memory Operations
Generally speaking, load operations copy values from the memory and store
operations copy values into the memory. The exact results are determined by the
memory model. See `Memory Model <memory-model>`__.
memory model. See `Memory Model <memory-model.rest>`__.
A **load** operation has parameters ``(ord, T, loc)``. *ord* is the memory order
of the operation. *T* is the type of *loc*, a memory location. The result is a
......@@ -260,7 +260,7 @@ operation.
All operators other than ``XCHG`` are only applicable for integer types.
``XCHG`` is allowed for any type. However, a Mu implementation may only
implement some combinations of operators and operand types according to the
requirements specified in `Portability <portability>`__
requirements specified in `Portability <portability.rest>`__
Memory Operations on Pointers
-----------------------------
......@@ -274,7 +274,7 @@ represented as ``uptr<T>``) rather than memory locations (usually represented as
Only *native-safe* types can be accessed via pointers.
When accessing the memory via pointers, if the bytes are mapped to a Mu memory
location via pinning (see `Native Interface <native-interface>`__), then if the
location via pinning (see `Native Interface <native-interface.rest>`__), then if the
referent type of the pointer is the same as the Mu memory location, it has the
same effect as accessing the corresponding Mu memory location.
......@@ -397,7 +397,7 @@ All prefixes of a memory location have the same beginning.
The ``REFCAST`` instruction or the ``refcast`` API function preserves the
beginning of the operand. If it casts ``iref<T1>`` to ``iref<T2>``, the result
is an internal reference to the memory location of type ``T2`` at the same
beginning. (see `Instruction Set <instruction-set>`__)
beginning. (see `Instruction Set <instruction-set.rest>`__)
Array Rule
----------
......
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