[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

VAX MACRO and Instruction Set Reference Manual


Previous Contents Index


INSQTI

Insert Entry into Queue at Tail, Interlocked

Format

opcode entry.ab, header.aq

Condition Codes

  if {insertion succeeded} then
  begin
  N <--- 0;
  Z <--- (entry) EQL (entry+4); ! First entry in queue
  V <--- 0;
  C <--- 0;
  end;
  else
  begin
  N <--- 0;
  Z <--- 0;
  V <--- 0;
  C <--- 1; ! Secondary interlock failed
  end;

Exceptions

Opcodes

5D INSQTI Insert Entry into Queue at Tail, Interlocked

Description

The entry specified by the entry operand is inserted into the queue preceding the header. If the entry inserted was the first one in the queue, the condition code Z-bit is set; otherwise, it is cleared. The insertion is a noninterruptible operation. The insertion is interlocked to prevent concurrent interlocked insertions or removals at the head or tail of the same queue by another process even in a multiprocessor environment. Before performing any part of the operation, the processor validates that the entire operation can be completed. This method ensures that if a memory management exception occurs (see Appendix E), queue is left in a consistent state. If the instruction fails to acquire the secondary interlock, then, if no exception conditions exist, the instruction sets condition codes and terminates.

Notes

  1. Because the insertion is noninterruptible, processes running in kernel mode can share queues with interrupt service routines.
  2. The INSQHI, INSQTI, REMQHI, and REMQTI instructions are implemented such that cooperating software processes in a multiprocessor may access a shared list without additional synchronization.
  3. To set a software interlock realized with a queue, you can use the following:


    INSERT: 
           INSQHI  ...            ; Was queue empty? 
           BEQL    1$             ; Yes 
           BCS     INSERT         ; Try inserting again 
           CALL    WAIT(...)      ; No, wait 
     
    1$: 
    

  4. During access validation, any access that cannot be completed results in a memory management exception even though the queue insertion is not started.
  5. A reserved operand fault occurs if entry, header, or (header+4) is an address that is not quadword aligned (that is, <2:0> NEQU 0) or if header<2:1> is not zero. A reserved operand fault also occurs if header equals entry. In this case, the queue is not altered.
  6. If the instruction encounters both the secondary interlock set and an exception condition resulting from instruction execution, then it is UNPREDICTABLE whether the exception occurs or the instruction terminates after setting the condition codes.

INSQUE

Insert Entry in Queue

Format

opcode entry.ab, pred.ab

Condition Codes

N||<--- (entry) LSS (entry+4);  
Z||<--- (entry) EQL (entry+4); ! First entry in queue  
V||<--- 0;  
C||<--- (entry) LSSU (entry+4);  

Exceptions

Opcodes

0E INSQUE Insert Entry in Queue

Description

The entry specified by the entry operand is inserted into the queue following the entry specified by the predecessor operand. If the entry inserted was the first one in the queue, the condition code Z-bit is set; otherwise it is cleared. The insertion is a noninterruptible operation. Before performing any part of the operation, the processor validates that the entire operation can be completed. This method ensures that if a memory management exception occurs (see Appendix E), the queue is left in a consistent state.

Notes

  1. The following three types of insertion can be performed by appropriate choice of the predecessor operand:
  2. Because the insertion is noninterruptible, processes running in kernel mode can share queues with interrupt service routines.
  3. The INSQUE and REMQUE instructions are implemented such that cooperating software processes in a single processor may access a shared list without additional synchronization, if the insertions and removals are only at the head or tail of the queue.
  4. To set a software interlock realized with a queue, you can use the following:


         INSQUE  ...             ; Was queue empty? 
         BEQL    1$              ; Yes 
         CALL    WAIT(...)       ; No, wait 
     
    1$: 
    

  5. During access validation, any access that cannot be completed results in a memory management exception, even though the queue insertion is not started.

REMQHI

Remove Entry from Queue at Head, Interlocked

Format

opcode header.aq, addr.wl

Condition Codes

  if {removal succeeded} then
  begin
  N <--- 0;
  Z <--- (header) EQL 0; ! Queue empty after removal
  V <--- {queue empty before this instruction};
  C <--- 0;
  end;
  else
  begin
  N <--- 0;
  Z <--- 0;
  V <--- 1; ! Did not remove anything
  C <--- 1; ! Secondary interlock failed
  end;

Exceptions

Opcodes

5E REMQHI Remove Entry from Queue at Head, Interlocked

Description

If the secondary interlock is clear, the queue entry following the header is removed from the queue and the address operand is replaced by the address of the entry removed. If the queue was empty prior to this instruction, or if the secondary interlock failed, the condition code V-bit is set; otherwise it is cleared.

If the interlock succeeded and the queue is empty at the end of this instruction, the condition code Z-bit is set; otherwise, it is cleared. The removal is interlocked to prevent concurrent interlocked insertions or removals at the head or tail of the same queue by another process even in a multiprocessor environment. The removal is a noninterruptible operation. Before performing any part of the operation, the processor validates that the entire operation can be completed. This ensures that if a memory management exception occurs (see Appendix E), the queue is left in a consistent state. If the instruction fails to acquire the secondary interlock, then, if no exception conditions exist, the instruction sets condition codes and terminates.

Notes

  1. Because the removal is noninterruptible, processes running in kernel mode can share queues with interrupt service routines.
  2. The INSQHI, INSQTI, REMQHI, and REMQTI instructions are implemented so that cooperating software processes in a multiprocessor may access a shared list without additional synchronization.
  3. To release a software interlock realized with a queue, you can use the following:


    1$:    REMQHI  ...             ; Removed last? 
           BEQL    2$              ; Yes 
           BCS     1$              ; Try removing again 
           CALL    ACTIVATE(...)   ; Activate other waiters 
     
    2$: 
    

  4. To remove entries until the queue is empty, you can use the following:


    1$:    REMQHI  ...             ; Anything removed? 
           BVS     2$              ; No 
             . 
           process removed entry 
             . 
           BR      1$              ; 
             . 
    2$     BCS     1$              ; Try removing again 
           queue empty 
    

  5. During access validation, any access that cannot be completed results in a memory management exception, even though the queue removal is not started.
  6. A reserved operand fault occurs if header or (header + (header)) is an address that is not quadword aligned (that is, <2:0> NEQU 0) or if (header)<2:1> is not zero. A reserved operand fault also occurs if the header address operand equals the address of the addr operand. In this case, the queue is not altered.
  7. If the instruction encounters both the secondary interlock set and an exception condition resulting from instruction execution, then it is UNPREDICTABLE whether the exception occurs or the instruction terminates after setting the condition codes.

REMQTI

Remove Entry from Queue at Tail, Interlocked

Format

opcode header.aq, addr.wl

Condition Codes

  if {removal succeeded} then
  begin
  N <--- 0;
  Z <--- (header + 4) EQL 0; ! Queue empty after removal
  V <--- {queue empty before this instruction};
  C <--- 0;
  end;
  else
  begin
  N <--- 0;
  Z <--- 0;
  V <--- 1; ! Did not remove anything
  C <--- 1; ! Secondary interlock failed
  end;

Exceptions

Opcodes

5F REMQTI Remove Entry from Queue at Tail, Interlocked

Description

If the secondary interlock is clear, the queue entry preceding the header is removed from the queue and the address operand is replaced by the address of the entry removed. If the queue was empty prior to this instruction, or if the secondary interlock failed, the condition code V-bit is set; otherwise it is cleared.

If the interlock succeeded and the queue is empty at the end of this instruction, the condition code Z-bit is set; otherwise it is cleared. The removal is interlocked to prevent concurrent interlocked insertions or removals at the head or tail of the same queue by another process, even in a multiprocessor environment. The removal is a noninterruptible operation. Before performing any part of the operation, the processor validates that the entire operation can be completed. This ensures that if a memory management exception occurs (see Appendix E), the queue is left in a consistent state. If the instruction fails to acquire the secondary interlock, then, if no exception conditions exist, the instruction sets condition codes and terminates.

Notes

  1. Because the removal is noninterruptible, processes running in kernel mode can share queues with interrupt service routines.
  2. The INSQHI, INSQTI, REMQHI, and REMQTI instructions are implemented to allow cooperating software processes in a multiprocessor system to access a shared list without additional synchronization.
  3. To release a software interlock realized with a queue, you can use the following:


    1$:    REMQTI  ...             ; Removed last? 
           BEQL    2$              ; Yes 
           BCS     1$              ; Try removing again 
           CALL    ACTIVATE(...)   ; Activate other waiters 
     
    2$: 
    

  4. To remove entries until the queue is empty, you can use the following:


    1$:    REMQTI  ...             ; Anything removed? 
           BVS     2$              ; No 
             . 
           process removed entry 
             . 
           BR      1$              ; 
             . 
    2$:    BCS     1$              ; Try removing again 
           queue empty 
    

  5. During access validation, any access that cannot be completed results in a memory management exception, even though the queue removal is not started.
  6. A reserved operand fault occurs if header, (header + 4), or (header + (header + 4)+4) is an address that is not quadword aligned (that is, <2:0> NEQU 0), or if (header)<2:1> is not zero. A reserved operand fault also occurs if the header address operand equals the address of the addr operand. In this case, the queue is not altered.
  7. If the instruction encounters both the secondary interlock set and an exception condition resulting from instruction execution, then it is UNPREDICTABLE whether the exception occurs or the instruction terminates after setting the condition codes.

REMQUE

Remove Entry from Queue

Format

opcode entry.ab,addr.wl

Condition Codes

N|| <--- (entry) LSS (entry+4);  
Z|| <--- (entry) EQL (entry+4); ! Queue empty  
V|| <--- (entry) EQL (entry+4); ! No entry to remove  
C|| <--- (entry) LSSU (entry+4);  

Exceptions

Opcodes

0F REMQUE Remove Entry from Queue

Description

The queue entry specified by the entry operand is removed from the queue. The address operand is replaced by the address of the entry removed. If there was no entry in the queue to be removed, the condition code V-bit is set; otherwise it is cleared. If the queue is empty at the end of this instruction, the condition code Z-bit is set; otherwise it is cleared. The removal is a noninterruptible operation. Before performing any part of the operation, the processor validates that the entire operation can be completed. This ensures that if a memory management exception occurs (see Appendix E), the queue is left in a consistent state.

Notes

  1. The following three types of removal can be performed by suitable choice of entry operand:
  2. Because the removal is noninterruptible, processes running in kernel mode can share queues with interrupt service routines.
  3. The INSQUE and REMQUE instructions are implemented so that cooperating software processes in a single processor may access a shared list without additional synchronization, if the insertions and removals are only at the head or tail of the queue.
  4. To release a software interlock realized with a queue, you can use the following:


           REMQUE  ...             ; Queue empty? 
           BEQL    1$              ; Yes 
           CALL    ACTIVATE(...)   ; Activate other waiters 
     
    1$: 
    

  5. To remove entries until the queue is empty, you can use the following:


    1$:    REMQUE  ...             ; Anything removed? 
           BVS     EMPTY           ; No 
             . 
             . 
             . 
           BR      1$ 
    

  6. During access validation, any access that cannot be completed results in a memory management exception, even though the queue removal is not started.

9.2.8 Floating-Point Instructions

Floating-point instructions operate on the following four data types:

To be consistent with the floating-point instruction set, which faults on reserved operands (see Chapter 8), software-implemented floating-point functions (for example, the absolute function) should verify that no input operands are reserved. An easy way to do this is a floating move or test of the input operands.

To make high-speed, floating-point operations easier, restrictions are placed on the addressing mode combinations usable within a single floating-point instruction. These combinations involve the logically inconsistent simultaneous use of a value as both a floating-point operand and an address.

If, within the same instruction, you use the contents of register Rn as both a part of a floating-point input operand (an .rf, .rd, .rg, .rh, .mf, .md, .mg, or .mh operand) and as an address in an addressing mode that modifies Rn (autoincrement, autodecrement, or autoincrement deferred), the value of the floating-point operand is UNPREDICTABLE.

9.2.8.1 Introduction

Mathematically, a floating-point number may be defined as having the following form:

(+ or -) (2**K)*f

where K is an integer and f is a nonnegative fraction. For a nonvanishing number, K and f are uniquely determined by imposing the following condition:


1/2 LEQ f LSS 1. 

The fractional factor, f, of the number is then said to be binary normalized. For the number 0, f must be assigned the value zero, and the value of K is indeterminate.

VAX derives these floating-point data formats from this mathematical representation for floating-point numbers. Four types of floating-point data are provided: the two standard PDP-11 formats (F_floating and D_floating), and two extended-range formats (G_floating and H_floating). Single-precision, or floating, data is 32 bits long. Double-precision, or D_floating, data is 64 bits long. Extended-range double-precision, or G_floating, data is 64 bits long. Extended-range quadruple-precision, or H_floating, data is 128 bits long. Use sign magnitude notation as follows:

  1. Nonzero floating-point numbers:
    The most significant bit of the floating-point data is the sign bit: 0 for positive and 1 for negative.
    The fractional factor f is assumed normalized, so that its most significant bit must be 1. This 1 is the "hidden" bit: it is not stored in the data word, but the hardware restores it before carrying out arithmetic operations. The F_floating and D_floating data types use 23 and 55 bits, respectively, for f, which, with the hidden bit, imply effective significance of 24 bits and 56 bits for arithmetic operations. The extended-range (G_floating and H_floating) data types use 52 and 112 bits, respectively, for f, which, with the hidden bit, imply effective significance of 53 and 113 bits for arithmetic operations.
    In the F_floating and D_floating data types, 8 bits are reserved for the storage of the exponent K in excess 128 notation. Thus, exponents from --128 to +127 could be represented, in biased form, by 0 to 255. For reasons given later, a biased exponent of zero (the true exponent of --128) is reserved for floating-point zero. Thus, for F_floating and D_floating data types, exponents are restricted to the range --127 to +127 inclusive or, in excess 128 notation, 1 to 255.
    In the G_floating data type, 11 bits are reserved for the storage of the exponent in excess 1024 notation. In the H_floating data type, 15 bits are reserved for the storage of the exponent in excess 16,384 notation. A biased exponent of zero is reserved for floating-point zero. Thus, exponents are restricted to --1023 to +1023 inclusive (in excess notation, 1 to 2047), and --16,383 to +16,383 inclusive (in excess notation, 1 to 32,767) for G_floating and H_floating data types, respectively.
  2. Floating-point 0:
    Because of the hidden bit, the fractional factor is not available to distinguish between zero and nonzero numbers whose fractional factor is exactly 1/2. Therefore, the VAX reserves a sign-exponent field of zero for this purpose. Any positive floating-point number with a biased exponent of zero is treated as if it were an exact zero by the floating-point instruction set. In particular, a floating-point operand whose bits are all zeros is treated as zero, and this is the format generated by all floating-point instructions for which the result is zero.
  3. The reserved operands:
    A reserved operand is defined to be any bit pattern with a sign bit of 1 and a biased exponent of zero. On the VAX, all floating-point instructions generate a fault if a reserved operand is encountered. A reserved operand is never generated as a result of a floating-point instruction. Scalar floating-point instructions never generate a reserved operand. However, vector floating-point instructions can generate reserved operands.


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
4515PRO_022.HTML