Contains bytecode and class names, as well as information related to the originating sources. @since 1.0 @author Alain Stalder @author Made in Switzerland.
Every local variable has a fixed type. This is either a primitive type (of any size) or a reference type. This class emits instructions appropriate to the types they operate on. Not all operations are local on all types; attempting to emit such an operation will fail with an unchecked exception.
Most methods should contain a return instruction. Void methods should use {@link #returnVoid()}; non-void methods should use {@link #returnValue returnValue()} with a local whose return type matches themethod's return type. Constructors are considered void methods and should call {@link #returnVoid()}. Methods may make multiple returns. Methods containing no return statements must either loop infinitely or throw unconditionally; it is not legal to end a sequence of instructions without a jump, return or throw.
Throw an throwable by first assigning it to a local and then calling {@link #throwValue throwValue()}. Control flow will jump to the nearest label assigned to a type assignable to the thrown type. In this context, "nearest" means the label requiring the fewest stack frames to be popped.
This is NOT part of any supported API. If you write code that depends on this, you do so at your own risk. This code and its internal interfaces are subject to change or deletion without notice.
The following features are supported:
Here, a value in a code table is modeled with one required item (text), and four optional items (id, short form, long form, and order index). The id is optional, since for 'add' operations it is not yet specified. This class is offered as a convenience for implementing Code Tables. Applications are not required to use it.
Please see the example application for an example of one way of implementing code tables.
A code table is an informal term describing a set of related values. It resembles an enumeration. Simple examples :
In a single language app, it's usually safe to render a Code by simply using ${code}. This calls {@link #toString()}, which returns escaped text, safe for direct rendering in a JSP.
In a multilingual app, however, the various translation tags (<w:txt>, <w:txtFlow>, <w:tooltip>) already escape special characters. So, if a translation tag encounters a Code somewhere its body, the Code must be in an unescaped form, otherwise it wil be escaped twice, which undesirable. In a multilingual app, you should usually render a Code using ${code.text.rawString}.
This asymmetry between single-language and many-language apps is somewhat displeasing, and constitutes a pitfall of using this class. If desired, you could define an alternate Code class whose toString returns a String instead of {@link SafeText}.
Code class models a block of code.
@author Sami Koivu
The following features are supported:
Code blocks are usually obtained from a {@link BCMethod}, but can also be constructed via the default constructor. Blocks created this way can be used to provide template instructions to the various search/replace methods in this class.
The code class contains methods named after most JVM instructions, each of which adds the matching opcode to the code block at the current iterator position. It also contains generic versions of various JVM instructions whose opcodes are not set until their properties are set with additional information. Almost all instruction types are able to 'morph' their opcode on the fly as the arguments to the instruction change. Thus the developer can initially call, for example, the aload opcode, but later change the type to load to int and the opcode will automatically morph to the iload opcode.
Code with the following attributes: Code which encode additional information (e.g. constant values, variable indices, etc).
@author David J. Pearce
@param < T>
function sum([int] data) => int: int r = 0 for item in data: r = r + item return rThis function is compiled into the following WyIL bytecode:
function sum([int] data) => int: body: const %1 = 0 : int assign %2 = %0 : [int] forall %3 in %2 () : [int] assign %4 = %1 : int add %1 = %4, %3 : int return %1 : int
Here, we can see that every bytecode is associated with one (or more) types. These types are inferred by the compiler during type propagation.
Each bytecode has a binary format which identifies the opcode, registers used and pool items used (e.g. names, constants, etc). The generic organisation of a bytecode is as follows:
+--------+-----------+------------+ | opcode | registers | pool items | +--------+-----------+------------+
The opcode is currently always 1 byte, whilst the remainder varies between instructions. Many bytecodes assign to a target register and read values from operand registers. Such bytecodes are organised as follows:
+--------+--------+----------+------------+ | opcode | target | operands | pool items | +--------+--------+----------+------------+@author David J. Pearce
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |