Commit 5dc38b56 authored by Kunshan Wang's avatar Kunshan Wang

Hybrid with multiple fixed part fields.

parent e23a10ea
......@@ -47,10 +47,10 @@ instructions or changing the grammar.
implement those special high-level language functions in "ordinary" Mu IR
code, which may or may not involve common instructions. For example,
creating a thread is a "magic" in Java, but it is not more special than
executing an instruction (``@uvm.new_thread``) in Mu. Some Java libraries
require Mu to make a ``CCALL`` to some C functions which are provided by the
JVM, and they slip under the level of Mu. But Mu and the client always know
the fact that "it call C function" and it is not magic.
executing an instruction (``NEWTHREAD``) in Mu. Some Java libraries require
Mu to make a ``CCALL`` to some C functions which are provided by the JVM,
and they slip under the level of Mu. But Mu and the client always know the
fact that "it call C function" and it is not magic.
This document uses the following notation::
......@@ -86,14 +86,6 @@ of ``%func``.
This instruction continues exceptionally if Mu failed to create the stack. The
exception parameter receives NULL.
..
For LLVM users: There is no native facilities provided by the official LLVM,
but `Dolan, Muralidharan and Gregg
<http://dl.acm.org/citation.cfm?id=2400695>`__ proposed an extension to LLVM
to support the SWAPSTACK operation. The SWAPSTACK interface of Mu is
inspired by their works.
::
[0x202]@uvm.kill_stack (%s: stackref)
......
......@@ -5,7 +5,7 @@ Instruction Set
Overview
========
Mu uses the static single assignment (SSA) form and a comprehensive but
Mu uses a variant of static single assignment (SSA) form and a comprehensive but
low-level instruction set.
Conventions
......@@ -55,12 +55,14 @@ present::
SSA Variables
=============
Mu uses the static single assignment (SSA) form.
Mu uses a variant of static single assignment (SSA) form. The single-definition
rule still applies, but PHI-nodes are replaced with parameters at the beginning
of basic blocks. Variables also do not live across basic blocks, and must be
explicitly passed.
An **SSA variable**, or **variable** when unambiguous, holds a data value of a
specific type. In the SSA form, every variable is defined (assigned) in exactly
one place, but an SSA variable may hold different values in different contexts
at different times.
specific type. Every variable is defined (assigned) in exactly one place, but an
SSA variable may hold different values in different contexts at different times.
NOTE: The original publications about SSA used the term "SSA form" and
simply "variable". This specification uses the term "SSA variable" to
......@@ -194,7 +196,7 @@ In the binary form, types, signatures and arguments are all represented as IDs.
CALL <@sig> @func (%arg0 %arg1 %arg2)
TAILCALL <@sig> @func (%arg0 %arg1 %arg2)
CCALL #DEFAULT <@func_ty @sig> @func (%arg0 %arg1 %arg2)
NEWSTACK <@sig> @func (%arg0 %arg1 %arg2)
NEWTHREAD %stack PASS_VALUES <@T1 @T2 @T3> (%arg0 %arg1 %arg2)
COMMINST @some.common.instruction (%arg0 %arg1 %arg2)
Destination Clause
......@@ -1824,7 +1826,6 @@ Other Memory Addressing Instructions
- ``GETFIELDIREF`` ``PTR`` :sub:`opt` ``<`` *T1* *index* ``>`` opnd
- ``GETELEMIREF`` ``PTR`` :sub:`opt` ``<`` *T1* *T2* ``>`` *opnd* *index*
- ``SHIFTIREF`` ``PTR`` :sub:`opt` ``<`` *T1* *T2* ``>`` *opnd* *offset*
- ``GETFIXEDPARTIREF`` ``PTR`` :sub:`opt` ``<`` *T1* ``>`` *opnd*
- ``GETVARPARTIREF`` ``PTR`` :sub:`opt` ``<`` *T1* ``>`` *opnd*
PTR :sub:`opt`
......@@ -1834,9 +1835,9 @@ PTR :sub:`opt`
T1
*type*: The referent type of *opnd*.
- For ``GETFIELDIREF``, *T1* must be ``struct``.
- For ``GETFIELDIREF``, *T1* must be ``struct`` or ``hybrid``.
- For ``GETELEMIREF``, *T1* must be ``array``.
- For ``GETFIXEDPARTIREF`` and ``GETVARPARTIREF``, *T1* must be ``hybrid``.
- For ``GETVARPARTIREF``, *T1* must be ``hybrid``.
T2
*type*, must be ``int``: The type of *index* (for ``GETELEMIREF``) and
......@@ -1856,10 +1857,10 @@ opnd
result
Type is ``iref<U>`` or ``uptr<U>``: The derived reference/pointer.
- For ``GETFIELDIREF``, *U* is the type of the *index*-th field of *T1*.
- For ``GETFIELDIREF``, *U* is the type of the *index*-th field of struct
*T1* or the fixed part of hybrid *T1*.
- For ``GETELEMIREF``, *U* is the element type of *T1*.
- For ``SHIFTIREF``, *U* is the same as *T1*.
- For ``GETFIXEDPARTIREF``, *U* is the type of the fixed part of *T1*.
- For ``GETVARPARTIREF``, *U* is the type of the elements of the variable
part of *T1*.
......@@ -1887,14 +1888,6 @@ SHIFTIREF:
| 0x17 | PTR | T1 | T2 | opnd | offset |
+------+------+-----+-----+--------+--------+
GETFIXEDPARTIREF:
+------+------+-----+------+
| opct | opct | idt | idt |
+======+======+=====+======+
| 0x18 | PTR | T | opnd |
+------+------+-----+------+
GETVARPARTIREF:
+------+------+-----+------+
......@@ -1904,7 +1897,8 @@ GETVARPARTIREF:
+------+------+-----+------+
The ``GETFIELDIREF`` instruction gets an internal reference/pointer to the
*index*-th field of the struct referenced by *opnd*.
*index*-th field of the struct or the fixed part of the hybrid referenced by
*opnd*.
The ``GETELEMIREF`` instruction gets an internal reference/pointer to the
*index*-th element of the array referenced by *opnd*.
......@@ -1919,9 +1913,6 @@ For ``GETELEMIREF`` and ``SHIFTIREF``, *T2* can be any integer type and is
treated as signed. When working with internal references, if the resulting
memory location is outside the range of the array, it has undefined behaviour.
The ``GETFIXEDPARTIREF`` instruction gets an internal reference/pointer to the
fixed part of the hybrid referenced by *opnd*.
The ``GETVARPARTIREF`` instruction gets an internal reference/pointer to the
first (0-th) element in the variable part of the hybrid referenced by *opnd*.
When working with internal references, if the variable part of *opnd* has zero
......@@ -1946,18 +1937,27 @@ elements, the ``GETVARPARTIREF`` has undefined behaviour.
%bar_r = NEW <@Bar> // ref<@Bar>
%bar_i = GETIREF <@Bar> %bar_r // iref<@Bar>
%bar_5 = GETELEMIREF <@Bar @i64> %bar_i @I64_5 // iref<@i32> the 5-th element
%bar_6 = SHIFTIREF <@Bar @i64> %bar_5 @I64_1 // iref<@i32> the 6-th element
%bar_4 = SHIFTIREF <@Bar @i64> %bar_6 @I64_NEG_2 // iref<@i32> the 4-th element
%bar_5 = GETELEMIREF <@Bar @i64> %bar_i @I64_5 // iref<@i32> the 5th element
%bar_6 = SHIFTIREF <@Bar @i64> %bar_5 @I64_1 // iref<@i32> the 6th element
%bar_4 = SHIFTIREF <@Bar @i64> %bar_6 @I64_NEG_2 // iref<@i32> the 4th element
.typedef @Baz = hybrid <@Foo @i8>
.const @I64_42 <@i64> = 42
%baz_i = ALLOCAHYBRID <@Bar @i64> @I64_42 // iref<@Baz>
%baz_f = GETFIXEDPARTIREF <@Bar> %baz_i // iref<@Foo>
%baz_v = GETVARPARTIREF <@Bar> %baz_i // iref<@i8> the 0-th element
%baz_v5 = SHIFTIREF <@Bar @i64> %baz_i @I64_5 // iref<@i8> the 5-th element
%baz_f = GETFIELDIREF <@Bar 0> %baz_i // iref<@Foo>
%baz_v = GETVARPARTIREF <@Bar> %baz_i // iref<@i8> the 0th element
%baz_v5 = SHIFTIREF <@Bar @i64> %baz_i @I64_5 // iref<@i8> the 5th element
.typedef @BigHybrid = hybrid <@i32 @i64 @double @i8> // 3 fields in the fixed part.
%bh_i = ALLOCAHYBRID <@BigHybrid @i64> @I64_42 // iref<@BigHybrid>
%bh_0 = GETFIELDIREF <@BigHybrid 0> %bh_i // iref<@i32>
%bh_1 = GETFIELDIREF <@BigHybrid 1> %bh_i // iref<@i64>
%bh_2 = GETFIELDIREF <@BigHybrid 2> %bh_i // iref<@double>
%bh_v = GETVARPARTIREF <@BigHybrid> %bh_i // iref<@i8> the 0th element
%bh_v2 = SHIFTIREF <@i8 @i64> %bh_v @I64_2 // iref<@i8> the 1st element
..
......@@ -2599,7 +2599,7 @@ However, whether a native frame can be popped is implementation-defined.
// Define necessary constants and types
.const @FD = 1 // 1 is for stdout
.typedef @DynByteArray = hybrid<@void @i8>
.typedef @DynByteArray = hybrid<@i8> // No fixed part. Just a @i8 array of unknown length.
.typedef @irefi8 = iref<@i8>
.typedef @ptri8 = uptr<@i8>
.const @ARY_SZ <@i64> = 13
......@@ -2671,7 +2671,7 @@ exc
+------+--------+--------+
| opct | idList | idList |
+======+========+========+
| 0x01 | Ts | vals |
| 0x01 | Ts | vals |
+------+--------+--------+
*newStackClause* with ``THROW_EXC``:
......@@ -2807,7 +2807,11 @@ The ``SWAPSTACK`` instruction is an OSR point.
..
For LLVM users: See ``NEWSTACK``.
For LLVM users: There is no native facilities provided by the official LLVM,
but `Dolan, Muralidharan and Gregg
<http://dl.acm.org/citation.cfm?id=2400695>`__ proposed an extension to LLVM
to support the SWAPSTACK operation. The SWAPSTACK interface of Mu is
inspired by their works.
..
......
......@@ -302,8 +302,8 @@ An evaluation A **synchronises with** another evaluation B if:
..
NOTE: A thread can be created by the ``@uvm.new_thread`` common instruction
or the ``new_thread`` API function.
NOTE: A thread can be created by the ``NEWTHREAD`` instruction or the
``new_thread`` API function.
NOTE: Since there is no explicit heap memory management in Mu, the
"synchronises with" relation in C involving ``free`` and ``realloc`` does
......@@ -574,8 +574,8 @@ The rules of memory access applies to functions as if
1. calling a function by the ``CALL`` or ``TAILCALL`` instructions, or by
native programs through exposed Mu functions, or
2. creating a new stack by the ``NEWSTACK`` instruction or the ``new_stack``
API, or
2. creating a new stack by the ``@uvm.new_stack`` instruction or the
``new_stack`` API, or
3. pushing a new frame by the ``push_frame`` API or the
``@uvm.meta.push_frame`` instruction.
......
......@@ -190,7 +190,6 @@ struct MuCtx {
MuIRefValue (*get_field_iref )(MuCtx *ctx, MuIRefValue opnd, int field);
MuIRefValue (*get_elem_iref )(MuCtx *ctx, MuIRefValue opnd, MuIntValue index);
MuIRefValue (*shift_iref )(MuCtx *ctx, MuIRefValue opnd, MuIntValue offset);
MuIRefValue (*get_fixed_part_iref)(MuCtx *ctx, MuIRefValue opnd);
MuIRefValue (*get_var_part_iref )(MuCtx *ctx, MuIRefValue opnd);
// Memory accessing
......
......@@ -59,12 +59,12 @@ All non-native-safe types have unspecified sizes and alignments.
implementations are encouraged to support them in a way compatible with the
AMD64 ABI.
The structure type ``struct<...>`` and the hybrid type ``hybrid<F V>`` is
The structure type ``struct<...>`` and the hybrid type ``hybrid<Fs V>`` is
aligned to its most strictly aligned component. Each member is assigned to the
lowest available offset with the appropriate alignment. This rule applies to
hybrids as if the hybrid ``hybrid<F V>`` is a struct of ``F`` followed by an
array of ``V`` of the actual length. Arrays ``array<T>`` use the same alignment
as its elements.
hybrids as if the hybrid ``hybrid<Fs V>`` is a struct of fields ``Fs`` followed
by a flexible array member (as in C99) ``V fam[];``. Arrays ``array<T>`` use
the same alignment as its elements.
NOTE: There is no union types in Mu. Arrays do not have special rules of
16-byte alignment as the AMD64 ABI does. Mu arrays must be declared as an
......@@ -86,7 +86,8 @@ The Default Calling Convention
The *default* calling convention, denoted by the ``#DEFAULT`` flag in the IR,
follows the AMD64 ABI in register usage, stack frame structure, parameter
passing and returning. The parameter types and the return types are mapped to C
types according to the above table. As a special case, if the native function
types according to the above table. Functions in this calling convention can
return at most one value. As a special case, if the native function signature
returns void, the corresponding Mu signature returns no values ``(...) -> ()``.
Mu ``struct`` and ``array`` types are mapped to C structs of corresponding
members. ``array`` cannot be the type of parameters or return values because C
......
......@@ -324,7 +324,6 @@ See `Instruction Set <instruction-set.rest>`__ and `Common Instructions
* ``GETFIELDIREF``
* ``GETELEMIREF``
* ``SHIFTIREF``
* ``GETFIXEDPARTIREF``
* ``GETVARPARTIREF``
* ``LOAD``
* ``STORE``
......@@ -340,7 +339,6 @@ example:
* ``%new_ptr = GETFIELDIREF PTR <@some_struct 3> %ptr_to_some_struct``
* ``%new_ptr = GETELEMIREF PTR <@some_array @i64> %ptr_to_some_array @const1``
* ``%new_ptr = SHIFTIREF PTR <@some_elem @i64> %ptr_to_some_elem @const2``
* ``%new_ptr = GETFIXEDPARTIREF PTR <@some_hybrid> %ptr_to_some_hybrid``
* ``%new_ptr = GETVARPARTIREF PTR <@some_hybrid> %ptr_to_some_hybrid``
* ``%old_val = LOAD PTR SEQ_CST <@T> %ptr_to_T``
* ``%void = STORE PTR SEQ_CST <@T> %ptr_to_T %newval``
......
......@@ -57,7 +57,7 @@ An array type ``array<T n>`` is required if T is implemented and n is less than
However, arrays must be in the memory. Whether such an array can be
successfully allocated is a different story.
A hybrid type ``hybrid<F V>`` is required if both ``F`` and ``V`` are
A hybrid type ``hybrid<Fs V>`` is required if all fields in ``Fs`` and ``V`` are
implemented.
The void type ``void`` is required.
......@@ -158,7 +158,7 @@ in the memory, they have undefined behaviours.
its variable part.
All memory addressing instructions ``GETIREF``, ``GETFIELDIREF``,
``GETELEMIREF``, ``SHIFTIREF``, ``GETFIXEDPARTIREF`` and ``GETVARPARTIREF`` give
``GETELEMIREF``, ``SHIFTIREF`` and ``GETVARPARTIREF`` give
undefined behaviour when applied to ``NULL`` references. But when applied to
pointers, these instructions calculates the result by calculating the offset
according to the memory layout, which is implementation-defined.
......@@ -209,8 +209,8 @@ implemented using ``CMPXCHG`` or load-link store-conditional constructs.
``CCALL`` is required, but the behaviour is implementation-defined. The
available calling conventions are implementation-defined.
``NEWSTACK`` is allowed to result in error, in which case the exceptional
control flow is taken.
``@uvm.new_stack`` and ``NEWTHREAD`` is allowed to result in error, in which
case the exceptional control flow is taken.
The availability of ``COMMINST`` is specified in the next section.
......
......@@ -41,7 +41,7 @@ The following type constructors are available in Mu:
- weakref < T >
- struct < T1 T2 ... >
- array < T length >
- hybrid < F V >
- hybrid < F1 F2 ... V >
- void
- funcref < sig >
- threadref
......@@ -79,9 +79,9 @@ There are several kinds of types.
variant of themselves.
A **member** of a composite type T is either a field of T if T is a struct, or
an element of T if T is an array or a vector, or the fixed part or any element
in the variable part if T is a hybrid. A **component** of type T is either
itself or a member of any component of T.
an element of T if T is an array or a vector, or a field in the fixed part or
any element in the variable part if T is a hybrid. A **component** of type T is
either itself or a member of any component of T.
NOTE: This means a component is anything in a type, including itself and any
arbitrarily nested members.
......@@ -92,9 +92,9 @@ following:
* ``void``, ``int<n>``, ``float`` and ``double`` are *native-safe*.
* ``struct<T1 T2 ...>``, ``array<T n>``, ``vec<T n>`` and ``hybrid<F V>`` are
native-safe if all of their type arguments *T1*, *T2*, ..., *T*, *F*, *V* are
native-safe.
* ``struct<T1 T2 ...>``, ``array<T n>``, ``vec<T n>`` and ``hybrid<F1 F2 ...
V>`` are native-safe if all of their type arguments *T1*, *T2*, ..., *T*,
*F1*, *F2*, ..., *V* are native-safe.
* ``uptr<T>`` and ``ufuncptr<sig>`` are *native-safe* if *T* and the return type
and all parameter types in *sig* are native-safe. Otherwise the ``uptr`` or
......@@ -340,7 +340,7 @@ In the binary form, an integer literal ``nfields`` determines the number of
fields. Exactly that number of type IDs follows the ``nfields`` literal.
For LLVM users: This is the same as LLVM's structure type, except structures
with a "flexible array element" (a 0-length array as the last element)
with a "flexible array member" (a 0-length array as the last element)
corresponds to the ``hybrid`` type in Mu.
..
......@@ -412,30 +412,31 @@ It is not recommended to have SSA variables of ``array`` type.
Hybrid
------
``hybrid < F V >``
``hybrid < F1 F2 ... V >``
``F``
*type*: The type of the fixed part
``F1 F2 ...``
*list of types*: The types in the fixed part
``V``
*type*: The type of the elements of the variable part
+------+-----+-----+
| opct | idt | idt |
+======+=====+=====+
| 0x09 | F | V |
+------+-----+-----+
+------+---------+-----+-----+-----+-----+
| opct | lent | idt | idt | ... | idt |
+======+=========+=====+=====+=====+=====+
| 0x09 | nfields | F1 | F2 | ... | V |
+------+---------+-----+-----+-----+-----+
A hybrid is a combination of a fixed-length prefix, i.e. its ``fixed part``, and
a variable-length array suffix, i.e. its ``variable part``, whose length is
decided at allocation time. *F* is the type of the fixed part. *V* is the type
of the *elements* of the variable part.
decided at allocation time. *F1* *F2* ... are the types of fields in the fixed
part. *V* is the type of the *elements* of the variable part.
NOTE: This is intended to play the part of "struct with flexible array
member" in C99, i.e. ``struct { F fixedPart; V varPart[]; }``.
member" in C99, i.e. ``struct { F1 f1; F2 f2; ... V v[]; }``.
*F* can be ``void``. In this case, the fixed part is empty, and the variable
part is in the beginning of this ``hybrid`` memory location, like a
variable-length array without a header. *V* cannot be ``void``.
The fixed part may contain 0 fields. In this case, the fixed part is empty, and
the variable part is in the beginning of this ``hybrid`` memory location, like a
variable-length array without a header. The variable part cannot be omitted.
Neither any fixed-part field nor *V* can be ``void``.
``hybrid`` cannot be the type of any SSA variable.
......@@ -448,7 +449,6 @@ rather than determined by the type itself.
Example::
.typedef @void = void
.typedef @byte = int<8>
.typedef @long = int<64>
.typedef @double = double
......@@ -456,8 +456,9 @@ rather than determined by the type itself.
.typedef @struct1 = struct<@long @long @long>
.typedef @hybrid1 = hybrid<@long @byte> // one int<64> followed by many int<8>
.typedef @hybrid2 = hybrid<@struct1 @double> // one struct followed by many double
.typedef @hybrid3 = hybrid<@void @byte> // no header. Just many int<8>.
.typedef @hybrid2 = hybrid<@long @long @long @double> // three int<64>, followed by many double
.typedef @hybrid3 = hybrid<@struct1 @double> // similar to @hybrid2, but using struct as the header
.typedef @hybrid4 = hybrid<@byte> // no fixed-part header. Just many int<8>.
Void Type
---------
......@@ -472,19 +473,12 @@ Void Type
The ``void`` type has no value.
It can only be used in the following ways:
* As the type of allocation units that do not store any values.
This allows allocating ``void`` in the heap/stack/global memory. Particularly,
the ``NEW`` instruction with the type ``void`` creates a new empty heap object
which is not the same as any others. This is similar to the ``new Object()``
expression in Java.
``ref<void>``, ``iref<void>``, ``weakref<void>`` and ``uptr<void>`` are also
allowed.
* As the fixed part of a ``hybrid`` to indicate the absence of the fixed part.
It can only be used as the type of allocation units that do not store any
values. This allows allocating ``void`` in the heap/stack/global memory.
Particularly, the ``NEW`` instruction with the type ``void`` creates a new empty
heap object which is not the same as any others. This is similar to the ``new
Object()`` expression in Java. ``ref<void>``, ``iref<void>``, ``weakref<void>``
and ``uptr<void>`` are also allowed, which can refer/point to "anything".
Opaque Reference Type
---------------------
......@@ -522,7 +516,6 @@ A ``NULL`` value of a ``funcref`` type does not refer to any function.
Example::
.typedef @i64 = int<64>
.typedef @void = void
.funcsig @sig1 = (@i64 @i64) -> (@i64)
.funcsig @sig2 = () -> ()
......@@ -548,7 +541,7 @@ A ``NULL`` value of a ``funcref`` type does not refer to any function.
``threadref`` and ``stackref`` are opaque reference types to Mu threads and Mu
stacks, respectively. They are not interchangeable with reference types. Only
some special instructions (e.g. ``NEWSTACK``, ``@uvm.new_thread``) or API
some special instructions (e.g. ``@uvm.new_stack``, ``NEWTHREAD``) or API
calls can operate on them.
Both ``threadref`` and ``stackref`` values can be ``NULL``, which does not refer
......
......@@ -322,8 +322,9 @@ context and return handles to them. Specifically:
type ``int<len>``, truncated or zero-extended.
* ``handle_from_float``: Convert a C ``float`` value to a Mu ``float`` value.
* ``handle_from_double``: Convert a C ``double`` value to a Mu ``double``
value.
* ``handle_from_double``: Convert a C ``double`` value to a Mu ``double``
value.
* ``handle_from_ptr``: Convert a C object pointer to a Mu pointer value.
The Mu type is ``mu_type`` which must be ``uptr<T>`` for some type ``T``.
......@@ -566,14 +567,13 @@ Memory addressing
MuIRefValue (*get_field_iref )(MuCtx *ctx, MuIRefValue opnd, int field);
MuIRefValue (*get_elem_iref )(MuCtx *ctx, MuIRefValue opnd, MuIntValue index);
MuIRefValue (*shift_iref )(MuCtx *ctx, MuIRefValue opnd, MuIntValue offset);
MuIRefValue (*get_fixed_part_iref)(MuCtx *ctx, MuIRefValue opnd);
MuIRefValue (*get_var_part_iref )(MuCtx *ctx, MuIRefValue opnd);
* ``get_iref`` converts an object reference into an internal reference to the
memory location of the whole object.
* ``get_field_iref`` gets an iref to the ``field``-th field of the struct
referred by the iref ``opnd``.
or of the fixed part of a hybrid referred by the iref ``opnd``.
* ``get_elem_iref`` gets an iref to the ``index``-th element of the array or
vector referred by the iref ``opnd``.
......@@ -583,9 +583,6 @@ Memory addressing
`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
by iref ``opnd``.
* ``get_var_part_iref`` gets an iref to the 0-th element of the variable part of
the hybrid referred by iref ``opnd``.
......
......@@ -807,9 +807,11 @@ which is one of the following:
- ``NEW``, ``NEWHYBRID``, ``ALLOCA``, ``ALLOCAHYBRID``
- ``LOAD``, ``STORE``, ``CMPXCHG``, ``ATOMICRMW``
- ``TRAP``, ``WATCHPOINT``
- ``NEWSTACK``, ``SWAPSTACK``
- ``NEWTHREAD``, ``SWAPSTACK``
- Some `Common Instructions <common-insts.rest>`__ when having exception
clause (currently none)
clause
- ``@uvm.new_stack``
..
......@@ -861,10 +863,10 @@ function.
After a function definition redefines a function, all calls to the function that
happen after the bundle loading operation will call the newly defined version of
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.rest>`__.
(including function calls and the creation of stacks, i.e. the
``@uvm.new_stack`` 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.rest>`__.
All existing activations of any functions remain unchanged, that is, they remain
to be the old versions of the functions.
......
......@@ -129,8 +129,8 @@ the type of data value the memory location represents:
* The initial value of ``tagref64`` is a floating point number which is
positive zero.
* The initial values of all fields or elements in ``struct``, ``array``,
``vector`` and the variable part of ``hybrid`` are the initial values
according to their respective types.
``vector`` and the fixed and variable part of ``hybrid`` are the initial
values according to their respective types.
Garbage Collection
------------------
......@@ -385,7 +385,8 @@ A component C is a **prefix** of a type T if any of the following is true.
+ *C* is *T* itself.
+ *T* is a ``struct`` and *C* is its first field.
+ *T* is a ``hybrid`` and *C* is its fixed part.
+ *T* is a ``hybrid`` and *C* is its first field of the fixed part, or the fixed
part of *T* has no fields and *C* is the first element of the variable part.
+ *T* is an ``array<T n>`` or ``vector<T n>`` and n >= 1, and *C* is its first
element.
+ *C* is a prefix of another prefix of *T*.
......@@ -411,7 +412,7 @@ Nested ``array``, ``vector`` and variable part of ``hybrid`` can be considered
as a single memory array with the innermost element type of the nested type as
the element type.
Example: The variable part of ``hybrid<void array<array<vector<float 4> 10
Example: The variable part of ``hybrid<T array<array<vector<float 4> 10
20>>`` can be treated as:
+ a memory array of ``float``, or,
......
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