2 Prefixes to Instructions


These special values are reserved to precede specific instructions. They do not constitute full instructions in their own right. It is not valid CIL to branch to the instruction following the prefix, but the prefix itself is a valid branch target. It is not valid CIL to have a prefix without immediately following it by one of the instructions it is permitted to precede.

2.1 tail. (Prefix) Call Terminates Current Method

Format

Assembly Format

Description

FE 14

tail.

Subsequent call terminates current method.

Description:

The tail. instruction must immediately precede a call, calli, or callvirt instruction. It indicates that the current method's stack frame is no longer required and thus can be removed before the call instruction is executed. Because the value returned by the call will be the value returned by this method, the call can be converted into a cross-method jump.

The evaluation stack must be empty except for the arguments being transferred by the following call. The instruction following the call instruction must be a ret. Thus the only legal code sequence is

tail. call (or calli or callvirt) somewhere

ret

Correct CIL must not branch to the call instruction, but it is permitted to branch to the ret. The only values on the stack must be the arguments for the method being called.

The tail.call (or calli or callvirt) instruction cannot be used to transfer control out of a try, filter, catch, or finally block. See Partition I, section 12.4.2.6.

The current frame cannot be discarded when control is transferred from untrusted code to trusted code, since this would jeopardize code identity security. Security checks may therefore cause the tail. to be ignored, leaving a standard call instruction.

Similarly, in order to allow the exit of a synchronized region to occur after the call returns, the tail. prefix is ignored when used to exit a method that is marked synchronized.

There may also be implementation-specific restrictions that prevent the tail. prefix from being obeyed in certain cases. While an implementation is free to ignore the tail. prefix under these circumstances, they should be clearly documented as they can affect the behavior of programs.

CLI implementations are required to honor tail. call requests where caller and callee methods can be statically determined to lie in the same assembly; and where the caller is not in a synchronized region; and where caller and callee satisfy all conditions listed in the "Verifiability" rules below. (To "honor" the tail. prefix means to remove the caller's frame, rather than revert to a regular call sequence.) Consequently, a CLI implementation need not honor tail. calli or tail. callvirt sequences.

RATIONALE

tail. calls allow some linear space algorithms to be converted to constant space algorithms and are required by some languages. In the presence of ldloca and ldarga instructions it isn't always possible for a compiler from CIL to native code to optimally determine when a tail. can be automatically inserted.


Exceptions:

None.

Verifiability:

Correct CIL obeys the control transfer constraints listed above. In addition, no managed pointers can be passed to the method being called if they point into the stack frame that is about to be removed. The return type of the method being called must be compatible with the return type of the current method. Verification requires that no managed pointers are passed to the method being called, since it does not track pointers into the current frame.

2.2 unaligned. (Prefix) Pointer Instruction May Be Unaligned

Format

Assembly Format

Description

FE 12 <unsigned int8>

unaligned. alignment

Subsequent pointer instruction may be unaligned.

Stack Transition:

..., addr ..., addr

Description:

unaligned. specifies that address (an unmanaged pointer (&), or native int) on the stack may not be aligned to the natural size of the immediately following ldind, stind, ldfld, stfld, ldobj, stobj, initblk, or cpblk instruction. That is, for a ldind.i4 instruction the alignment of addr may not be to a 4-byte boundary. For initblk and cpblk the default alignment is architecture-dependent (4-byte on 32-bit CPUs, 8-byte on 64-bit CPUs). Code generators that do not restrict their output to a 32-bit word size (see Partitions I and II) must use unaligned. if the alignment is not known at compile time to be 8-byte.

The value of alignment shall be 1, 2, or 4 and means that the generated code should assume that addr is byte, double byte, or quad byte aligned, respectively.

RATIONALE

While the alignment for a cpblk instruction would logically require two numbers (one for the source and one for the destination), there is no noticeable impact on performance if only the lower number is specified.


The unaligned. and volatile. prefixes may be combined in either order. They must immediately precede a ldind, stind, ldfld, stfld, ldobj, stobj, initblk, or cpblk instruction. Only the volatile. prefix is allowed for the ldsfld and stsfld instructions.

NOTE

See Partition I, section 12.6 and its subsections for information about atomicity and data alignment.


Exceptions:

None.

Verifiability:

An unaligned. prefix shall be immediately followed by one of the instructions listed above.

2.3 volatile. (Prefix) Pointer Reference Is Volatile

Format

Assembly Format

Description

FE 13

volatile.

Subsequent pointer reference is volatile.

Stack Transition:

..., addr ..., addr

Description:

volatile. specifies that addr is a volatile address (i.e., it may be referenced externally to the current thread of execution) and the results of reading that location cannot be cached, or that multiple stores to that location cannot be suppressed. Marking an access as volatile. affects only that single access; other accesses to the same location must be marked separately. Access to volatile locations need not be performed atomically. (See Partition I [section 12.6, Memory Model and Optimizations

The unaligned. and volatile. prefixes may be combined in either order. They must immediately precede a ldind, stind, ldfld, stfld, ldobj, stobj, initblk, or cpblk instruction. Only the volatile. prefix is allowed for the ldsfld and stsfld instructions.

Exceptions:

None.

Verifiability:

A volatile. prefix should be immediately followed by one of the instructions listed above.



The Common Language Infrastructure Annotated Standard (Microsoft. NET Development Series)
The Common Language Infrastructure Annotated Standard (Microsoft. NET Development Series)
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 121

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net