home *** CD-ROM | disk | FTP | other *** search
/ CD-X 1 / cdx_01.iso / demodisc / tyrant / docs / 386code / 11.386 < prev    next >
Encoding:
Text File  |  1994-01-20  |  13.5 KB  |  314 lines

  1. Chapter 11  Coprocessing and Multiprocessing
  2.  
  3. ────────────────────────────────────────────────────────────────────────────
  4.  
  5. The 80386 has two levels of support for multiple parallel processing units:
  6.  
  7.   ■  A highly specialized interface for very closely coupled processors of
  8.      a type known as coprocessors.
  9.  
  10.   ■  A more general interface for more loosely coupled processors of
  11.      unspecified type.
  12.  
  13.  
  14. 11.1  Coprocessing
  15.  
  16. The components of the coprocessor interface include:
  17.  
  18.   ■  ET bit of control register zero (CR0)
  19.   ■  The EM, and MP bits of CR0
  20.   ■  The ESC instructions
  21.   ■  The WAIT instruction
  22.   ■  The TS bit of CR0
  23.   ■  Exceptions
  24.  
  25.  
  26. 11.1.1  Coprocessor Identification
  27.  
  28. The 80386 is designed to operate with either an 80287 or 80387 math
  29. coprocessor. The ET bit of CR0 indicates which type of coprocessor is
  30. present. ET is set automatically by the 80386 after RESET according to the
  31. level detected on the ERROR# input. If desired, ET may also be set or reset
  32. by loading CR0 with a MOV instruction. If ET is set, the 80386 uses the
  33. 32-bit protocol of the 80387; if reset, the 80386 uses the 16-bit protocol
  34. of the 80287.
  35.  
  36.  
  37. 11.1.2  ESC and WAIT Instructions
  38.  
  39. The 80386 interprets the pattern 11011B in the first five bits of an
  40. instruction as an opcode intended for a coprocessor. Instructions thus
  41. marked are called ESCAPE or ESC instructions. The CPU performs the following
  42. functions upon encountering an ESC instruction before sending the
  43. instruction to the coprocessor:
  44.  
  45.   ■  Tests the emulation mode (EM) flag to determine whether coprocessor
  46.      functions are being emulated by software.
  47.  
  48.   ■  Tests the TS flag to determine whether there has been a context change
  49.      since the last ESC instruction.
  50.  
  51.   ■  For some ESC instructions, tests the ERROR# pin to determine whether
  52.      the coprocessor detected an error in the previous ESC instruction.
  53.  
  54. The WAIT instruction is not an ESC instruction, but WAIT causes the CPU to
  55. perform some of the same tests that it performs upon encountering an ESC
  56. instruction. The processor performs the following actions for a WAIT
  57. instruction:
  58.  
  59.   ■  Waits until the coprocessor no longer asserts the BUSY# pin.
  60.  
  61.   ■  Tests the ERROR# pin (after BUSY# goes inactive). If ERROR# is active,
  62.      the 80386 signals exception 16, which indicates that the coprocessor
  63.      encountered an error in the previous ESC instruction.
  64.  
  65.   ■  WAIT can therefore be used to cause exception 16 if an error is
  66.      pending from a previous ESC instruction. Note that, if no coprocessor
  67.      is present, the ERROR# and BUSY# pins should be tied inactive to
  68.      prevent WAIT from waiting forever or causing spurious exceptions.
  69.  
  70.  
  71. 11.1.3  EM and MP Flags
  72.  
  73. The EM and MP flags of CR0 control how the processor reacts to coprocessor
  74. instructions.
  75.  
  76. The EM bit indicates whether coprocessor functions are to be emulated. If
  77. the processor finds EM set when executing an ESC instruction, it signals
  78. exception 7, giving the exception handler an opportunity to emulate the ESC
  79. instruction.
  80.  
  81. The MP (monitor coprocessor) bit indicates whether a coprocessor is
  82. actually attached. The MP flag controls the function of the WAIT
  83. instruction. If, when executing a WAIT instruction, the CPU finds MP set,
  84. then it tests the TS flag; it does not otherwise test TS during a WAIT
  85. instruction. If it finds TS set under these conditions, the CPU signals
  86. exception 7.
  87.  
  88. The EM and MP flags can be changed with the aid of a MOV instruction using
  89. CR0 as the destination operand and read with the aid of a MOV instruction
  90. with CR0 as the source operand. These forms of the MOV instruction can be
  91. executed only at privilege level zero.
  92.  
  93.  
  94. 11.1.4  The Task-Switched Flag
  95.  
  96. The TS bit of CR0 helps to determine when the context of the coprocessor
  97. does not match that of the task being executed by the 80386 CPU. The 80386
  98. sets TS each time it performs a task switch (whether triggered by software
  99. or by hardware interrupt). If, when interpreting one of the ESC
  100. instructions, the CPU finds TS already set, it causes exception 7. The WAIT
  101. instruction also causes exception 7 if both TS and MP are set. Operating
  102. systems can use this exception to switch the context of the coprocessor to
  103. correspond to the current task. Refer to the 80386 System Software Writer's
  104. Guide for an example.
  105.  
  106. The CLTS instruction (legal only at privilege level zero) resets the TS
  107. flag.
  108.  
  109.  
  110. 11.1.5  Coprocessor Exceptions
  111.  
  112. Three exceptions aid in interfacing to a coprocessor: interrupt 7
  113. (coprocessor not available), interrupt 9 (coprocessor segment overrun), and
  114. interrupt 16 (coprocessor error).
  115.  
  116.  
  117. 11.1.5.1  Interrupt 7 ── Coprocessor Not Available
  118.  
  119. This exception occurs in either of two conditions:
  120.  
  121.   1.  The CPU encounters an ESC instruction and EM is set. In this case,
  122.       the exception handler should emulate the instruction that caused the
  123.       exception. TS may also be set.
  124.  
  125.   2.  The CPU encounters either the WAIT instruction or an ESC instruction
  126.       when both MP and TS are set. In this case, the exception handler
  127.       should update the state of the coprocessor, if necessary.
  128.  
  129.  
  130. 11.1.5.2  Interrupt 9 ── Coprocessor Segment Overrun
  131.  
  132. This exception occurs in protected mode under the following conditions:
  133.  
  134.   ■  An operand of a coprocessor instruction wraps around an addressing
  135.      limit (0FFFFH for small segments, 0FFFFFFFFH for big segments, zero for
  136.      expand-down segments). An operand may wrap around an addressing limit
  137.      when the segment limit is near an addressing limit and the operand is
  138.      near the largest valid address in the segment. Because of the
  139.      wrap-around, the beginning and ending addresses of such an operand
  140.      will be near opposite ends of the segment.
  141.  
  142.   ■  Both the first byte and the last byte of the operand (considering
  143.      wrap-around) are at addresses located in the segment and in present and
  144.      accessible pages.
  145.  
  146.   ■  The operand spans inaccessible addresses. There are two ways that such
  147.      an operand may also span inaccessible addresses:
  148.  
  149.      1.  The segment limit is not equal to the addressing limit (e.g.,
  150.          addressing limit is FFFFH and segment limit is FFFDH); therefore,
  151.          the operand will span addresses that are not within the segment
  152.          (e.g., an 8-byte operand that starts at valid offset FFFC will span
  153.          addresses FFFC-FFFF and 0000-0003; however, addresses FFFE and FFFF
  154.          are not valid, because they exceed the limit);
  155.  
  156.      2.  The operand begins and ends in present and accessible pages but
  157.          intermediate bytes of the operand fall either in a not-present page
  158.          or in a page to which the current procedure does not have access
  159.          rights.
  160.  
  161. The address of the failing numerics instruction and data operand may be
  162. lost; an FSTENV does not return reliable addresses. As with the 80286/80287,
  163. the segment overrun exception should be handled by executing an FNINIT
  164. instruction (i.e., an FINIT without a preceding WAIT). The return address on
  165. the stack does not necessarily point to the failing instruction nor to the
  166. following instruction. The failing numerics instruction is not restartable.
  167.  
  168. Case 2 can be avoided by either aligning all segments on page boundaries or
  169. by not starting them within 108 bytes of the start or end of a page. (The
  170. maximum size of a coprocessor operand is 108 bytes.) Case 1 can be avoided
  171. by making sure that the gap between the last valid offset and the first
  172. valid offset of a segment is either no less than 108 bytes or is zero (i.e.,
  173. the segment is of full size). If neither software system design constraint
  174. is acceptable, the exception handler should execute FNINIT and should
  175. probably terminate the task.
  176.  
  177.  
  178. 11.1.5.3  Interrupt 16 ── Coprocessor Error
  179.  
  180. The numerics coprocessors can detect six different exception conditions
  181. during instruction execution. If the detected exception is not masked by a
  182. bit in the control word, the coprocessor communicates the fact that an error
  183. occurred to the CPU by a signal at the ERROR# pin. The CPU causes interrupt
  184. 16 the next time it checks the ERROR# pin, which is only at the beginning of
  185. a subsequent WAIT or certain ESC instructions. If the exception is masked,
  186. the numerics coprocessor handles the exception according to on-board logic;
  187. it does not assert the ERROR# pin in this case.
  188.  
  189.  
  190. 11.2  General Multiprocessing
  191.  
  192. The components of the general multiprocessing interface include:
  193.  
  194.   ■  The LOCK# signal
  195.  
  196.   ■  The LOCK instruction prefix, which gives programmed control of the
  197.      LOCK# signal.
  198.  
  199.   ■  Automatic assertion of the LOCK# signal with implicit memory updates
  200.      by the processor
  201.  
  202.  
  203. 11.2.1  LOCK and the LOCK# Signal
  204.  
  205. The LOCK instruction prefix and its corresponding output signal LOCK# can
  206. be used to prevent other bus masters from interrupting a data movement
  207. operation. LOCK may only be used with the following 80386 instructions when
  208. they modify memory. An undefined-opcode exception results from using LOCK
  209. before any instruction other than:
  210.  
  211.   ■  Bit test and change: BTS, BTR, BTC.
  212.   ■  Exchange: XCHG.
  213.   ■  Two-operand arithmetic and logical: ADD, ADC, SUB, SBB, AND, OR, XOR.
  214.   ■  One-operand arithmetic and logical: INC, DEC, NOT, and NEG.
  215.  
  216. A locked instruction is only guaranteed to lock the area of memory defined
  217. by the destination operand, but it may lock a larger memory area. For
  218. example, typical 8086 and 80286 configurations lock the entire physical
  219. memory space. The area of memory defined by the destination operand is
  220. guaranteed to be locked against access by a processor executing a locked
  221. instruction on exactly the same memory area, i.e., an operand with
  222. identical starting address and identical length.
  223.  
  224. The integrity of the lock is not affected by the alignment of the memory
  225. field. The LOCK signal is asserted for as many bus cycles as necessary to
  226. update the entire operand.
  227.  
  228.  
  229. 11.2.2  Automatic Locking
  230.  
  231. In several instances, the processor itself initiates activity on the data
  232. bus. To help ensure that such activities function correctly in
  233. multiprocessor configurations, the processor automatically asserts the LOCK#
  234. signal. These instances include:
  235.  
  236.   ■  Acknowledging interrupts.
  237.  
  238.      After an interrupt request, the interrupt controller uses the data bus
  239.      to send the interrupt ID of the interrupt source to the CPU. The CPU
  240.      asserts LOCK# to ensure that no other data appears on the data bus
  241.      during this time.
  242.  
  243.   ■  Setting busy bit of TSS descriptor.
  244.  
  245.      The processor tests and sets the busy-bit in the type field of the TSS
  246.      descriptor when switching to a task. To ensure that two different
  247.      processors cannot simultaneously switch to the same task, the processor
  248.      asserts LOCK# while testing and setting this bit.
  249.  
  250.   ■  Loading of descriptors.
  251.  
  252.      While copying the contents of a descriptor from a descriptor table into
  253.      a segment register, the processor asserts LOCK# so that the descriptor
  254.      cannot be modified by another processor while it is being loaded. For
  255.      this action to be effective, operating-system procedures that update
  256.      descriptors should adhere to the following steps:
  257.  
  258.      ──  Use a locked update to the access-rights byte to mark the
  259.          descriptor not-present.
  260.  
  261.      ──  Update the fields of the descriptor.  (This may require several
  262.          memory accesses; therefore, LOCK cannot be used.)
  263.  
  264.      ──  Use a locked update to the access-rights byte to mark the
  265.          descriptor present again.
  266.  
  267.   ■  Updating page-table A and D bits.
  268.  
  269.      The processor exerts LOCK# while updating the A (accessed) and D 
  270.      (dirty) bits of page-table entries.  Also the processor bypasses the
  271.      page-table cache and directly updates these bits in memory.
  272.  
  273.   ■  Executing XCHG instruction.
  274.  
  275.      The 80386 always asserts LOCK during an XCHG instruction that
  276.      references memory (even if the LOCK prefix is not used).
  277.  
  278.  
  279. 11.2.3  Cache Considerations
  280.  
  281. Systems programmers must take care when updating shared data that may also
  282. be stored in on-chip registers and caches.  With the 80386, such  shared
  283. data includes:
  284.  
  285.   ■  Descriptors, which may be held in segment registers.
  286.  
  287.      A change to a descriptor that is shared among processors should be
  288.      broadcast to all processors.  Segment registers are effectively
  289.      "descriptor caches".  A change to a descriptor will not be utilized by
  290.      another processor if that processor already has a copy of the old
  291.      version of the descriptor in a segment register.
  292.  
  293.   ■  Page tables, which may be held in the page-table cache.
  294.  
  295.      A change to a page table that is shared among processors should be
  296.      broadcast to all processors, so that others can flush their page-table
  297.      caches and reload them with up-to-date page tables from memory.
  298.  
  299. Systems designers can employ an interprocessor interrupt to handle the
  300. above cases. When one processor changes data that may be cached by other
  301. processors, it can send an interrupt signal to all other processors that may
  302. be affected by the change. If the interrupt is serviced by an interrupt
  303. task, the task switch automatically flushes the segment registers. The task
  304. switch also flushes the page-table cache if the PDBR (the contents of CR3)
  305. of the interrupt task is different from the PDBR of every other task.
  306.  
  307. In multiprocessor systems that need a cacheability signal from the CPU, it
  308. is recommended that physical address pin A31 be used to indicate
  309. cacheability. Such a system can then possess up to 2 Gbytes of physical
  310. memory. The virtual address range available to the programmer is not
  311. affected by this convention.
  312.  
  313.  
  314.