📄 x-sparc4.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Sun SPARC, SPARClite </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="x-sparc.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="x-sparc3.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="x-960.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="84721">B.4 Architecture Considerations</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84722"> </a>This section describes the following characteristics of the SPARC and SPARClite architectures that you should keep in mind as you write a VxWorks application:</p></dl><dl class="margin"><ul class="BulletSingle" type="disc"><li><a name="84723"> </a>Reserved registers</li></ul><ul class="BulletSingle" type="disc"><li><a name="84724"> </a>Processor mode</li></ul><ul class="BulletSingle" type="disc"><li><a name="84725"> </a>Vector table initialization</li></ul><ul class="BulletSingle" type="disc"><li><a name="84726"> </a>Double-word Integers</li></ul><ul class="BulletSingle" type="disc"><li><a name="84727"> </a>Interrupt handling</li></ul><ul class="BulletSingle" type="disc"><li><a name="84728"> </a>Floating-point support</li></ul><ul class="BulletSingle" type="disc"><li><a name="84729"> </a>Stack pointer usage</li></ul><ul class="BulletSingle" type="disc"><li><a name="84730"> </a>SPARClite overview</li></ul><ul class="BulletSingle" type="disc"><li><a name="84731"> </a>Memory layout</li></ul></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84733">Reserved Registers </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84734"> </a>Following the SPARC specification (<i class="title">Appendix D, Software Considerations</i>, in <i class="title">The SPARC Architecture Manual, Version 8</i> from Sun Microsystems), registers <b class="symbol_lc">g5</b>, <b class="symbol_lc">g6</b>, and <b class="symbol_lc">g7</b> are reserved for VxWorks kernel use. Avoid using these registers in your applications.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84736">Processor Mode</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84737"> </a>VxWorks for SPARC and SPARClite always runs in Supervisor mode.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84739">Vector Table Initialization</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84741"> </a>After the VxWorks for SPARC or SPARClite has completed initialization, traps are enabled and the PIL (Processor Interrupt Level) is set to zero. All 15 interrupt levels are active with the coprocessor enables set according to hardware availability and application use. </p><dd><p class="Body"><a name="84743"> </a>The TBR (Trap Base Register) points to the active vector table at address 0x1000 in local memory. </p><dd><p class="Body"><a name="84744"> </a>Make sure that vectors are not reserved for the processor or the kernel before acquiring them for an application.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84745">Double-word Integers: <b class="symbol_lc">long long</b></a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84747"> </a>The double-word integer <b class="symbol_lc">long long</b> is not supported, except as an artifact of your particular architecture and compiler. For more information about handling unsupported features, please see the <i class="title">Customer Support User's Guide</i>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84749">Interrupt Handling</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84750"> </a>For VxWorks for SPARC and SPARClite, an interrupt stack allows all interrupt processing to be performed on a separate stack. The interrupt stack is implemented in software because the SPARC family does not support such a stack in hardware.</p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84752">SPARC Interrupts</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84753"> </a>The SPARC microprocessor allows 15 levels of interrupts. The level is encoded by external hardware on the four interrupt signal lines. The integer unit (CPU) decodes this level and passes control directly to the entry in the vector table at an offset of 0x100 plus the interrupt level times 16 bytes. This corresponds to vectors 16 through 31 (addresses 0x100 to 0x1F0). Each 16-byte entry in the vector table contains up to four instructions. Typically, control passes to an interrupt service routine (ISR) with a call or branch instruction.</p><dd><p class="Body"><a name="84754"> </a>The SPARC uses auto-vectored interrupts. The chip does not perform any type of interrupt acknowledge (IACK) cycle. The address in the Trap Base Register (TBR) concatenated with the interrupt level vector displacement allows the SPARC to begin interrupt processing. </p><dd><p class="Body"><a name="84756"> </a>The alternative is vectored interrupts. The CPU responds to the interrupt with an IACK cycle so that an interrupt controller chip or individual device can return a value that clears and identifies the source of the interrupt. This is extremely useful for multiple sources of interrupts on a single-interrupt level.</p><dd><p class="Body"><a name="84757"> </a>The ability to perform an interrupt acknowledge cycle is a function of the microprocessor (not the software or board-level hardware). However, a target board can synthesize an IACK cycle by accessing an area created in its address space. This is often necessary to clear the interrupt pending bit in an interrupting device. An IACK cycle also differs from a normal read cycle in that the value returned is an interrupt vector. This vector is used to select an offset in the vector table that has the device's ISR connected to that table entry.</p><dd><p class="Body"><a name="84758"> </a>VxWorks allows an application to connect ISRs to vectors with the routine <b class="routine"><i class="routine">intConnect</i></b><b>( )</b>. A stub is built dynamically that calls an interrupt entry routine, calls the ISR, and then calls an exit routine. The SPARC, like other RISC processors, delegates to software the task of building an exception stack frame (ESF) to save volatile information. The kernel builds up two types of exception stack frames: one for interrupts and one for all other exceptions. The code execution sequence following an interrupt is as follows: </p></dl><dl class="margin"><p><ol class="List"><li value="1."><a name="84760"> </a>Vector table </li></ol></p><p><ol class="List"><li value="2."><a name="84761"> </a>Exception stack frame building </li></ol></p><p><ol class="List"><li value="3."><a name="84762"> </a>Overflow exception handling </li></ol></p><p><ol class="List"><li value="4."><a name="84763"> </a>Interrupt entry code </li></ol></p><p><ol class="List"><li value="5."><a name="84764"> </a>ISR </li></ol></p><p><ol class="List"><li value="6."><a name="84765"> </a>Interrupt exit code </li></ol></p><p><ol class="List"><li value="7."><a name="84766"> </a>Rescheduling, if the interrupt added work for the kernel (such as a <b class="routine"><i class="routine">semGive</i></b><b>( )</b>)</li></ol></p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84768">Vectored Interrupts </a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84769"> </a>The SPARC kernel was designed to handle vectored interrupts as an option. Because this implementation varies with every target board, the kernel must work with the board support package (BSP). The implementation of vectored interrupts on a processor that does not support them must be done in software. </p><dd><p class="Body"><a name="84770"> </a>A table in the BSP allows an IACK for each of the 15 interrupt levels. A NULL (0) entry corresponds to no interrupt acknowledge. If an IACK is required, the table entry corresponds to a routine that performs the necessary operations. Because the SPARC vector table contains 256 entries, a byte-sized vector can select any exception handler. </p><dd><p class="Body"><a name="84771"> </a>Note that the microprocessor, the board, and the kernel reserve certain vector table entries. The kernel appends this vector to the TBR and continues execution with the selected ISR. All checking for the IACK condition and performing of the operation is done by the kernel and is transparent. The interrupt connection mechanism is the same, and checking for and clearing the pending interrupt is done before the ISR attached by <b class="routine"><i class="routine">intConnect</i></b><b>(</b> <b>)</b> is called.</p><dd><p class="Body"><a name="84772"> </a>The following shows the structure used on the SPARCengine 1E (also known as a Sun 1E) SPARC board in <i class="textVariable">installDir</i><b class="file">/target/config/sun1e/sysLib.c</b>. It illustrates the use of vectored interrupts for VME, but does not require an IACK cycle for local (on-board) interrupts:</p></dl><dl class="margin"><dd><pre class="Code"><b><a name="84773">extern sysVmeAck(); /* IACK Leaf Functions, code in sysALib */</a></b><dd> <b><a name="84775">int (*sysIntAckTable [16])() = { NULL, /* Reserved for Kernel */ NULL, /* Interrupt Level 1 - Software 1 */ sysVmeAck, /* Interrupt Level 2 - VME 1 */ sysVmeAck, /* Interrupt Level 3 - VME 2 */ NULL, /* Interrupt Level 4 - SCSI */ sysVmeAck, /* Interrupt Level 5 - VME 3 */ NULL, /* Interrupt Level 6 - Ethernet */ NULL, /* Interrupt Level 7 - P2 Bus */ sysVmeAck, /* Interrupt Level 8 - VME 4 */ sysVmeAck, /* Interrupt Level 9 - VME 5 */ NULL, /* Interrupt Level 10 - Timer 0 */ sysVmeAck, /* Interrupt Level 11 - VME 6 */ NULL, /* Interrupt Level 12 - Serial Ports */ NULL, /* Interrupt Level 13 - Mailbox */ NULL, /* Interrupt Level 14 - Timer 1 */ NULL /* Interrupt Level 15 - NMI */ };</a></b></pre></dl><dl class="margin"><dd><p class="Body"><a name="84794"> </a>The performance penalty for this added feature is negligible. When vectored interrupts are used, this penalty increases, because an operation is being handled in software that the SPARC microprocessor was not designed to do. There are some restrictions on these vector routines because they are called in a critical section of code. Again, the Sun 1E SPARC board is used as an example. Note that you must use special "leaf" procedures.</p><dd><p class="Body"><a name="84795"> </a>The corresponding code for the function table is in <i class="textVariable">installDir</i><b class="file">/target/config/sun1e/sysALib.s</b>:</p></dl><dl class="margin"><dd><pre class="Code"><b><a name="84796">/* IACK Function Call Template /* Input: %l5 - return address /* Volatile: %l4, %l6 (DO NOT USE OTHER REGISTERS !!!) /* Return: %l5 - vector table index */</a></b></pre><dl class="margin"><dd><pre class="Code2"><b><a name="84801">.global _sysVmeAck</a></b></pre></dl><dd><pre class="Code"><b><a name="84803">_sysVmeAck: sethi %hi(SUN_VME_ACK),%l6 /* VMEbus IACK - 0xFFD18001 */ or %l6,%lo(SUN_VME_ACK),%l6 rd %tbr,%l4 /* Extract interrupt level */ and %l4,0x00F0,%l4 add %l4,0x0010,%l4 /* Sun 1E to VME level conversion */ srl %l4,5,%l4 /* Add 1, divide by 2 (no remainder) */ sll %l4,1,%l4 /* Multiply VME level by 2 */ ldub [%l6 + %l4],%l4 /* VMEbus IACK and get vector */ jmpl %l5,%g0 /* Return address - leaf routine */ mov %l4,%l5 /* Interrupt vector to %l5 */</a></b></pre></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84816">VMEbus Interrupt Handling</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84817"> </a>SPARC uses fifteen interrupt levels instead of the seven used by VMEbus. The mapping of the seven VMEbus interrupts to the fifteen SPARC levels is board dependent. VMEbus interrupts must be acknowledged. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84820">Floating-Point Support</a></i></h4></font><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84822">Floating-Point Contexts</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84824"> </a>A task can be spawned with floating-point support by setting the <b class="symbol_UC">VX_FP_TASK</b> option. This causes switch hooks to initialize, save, and restore a floating-point context. This option increases the task's context switch time and memory consumption, so only spawn tasks with <b class="symbol_UC">VX_FP_TASK</b> if they must perform floating-point operations. </p><dd><p class="Body"><a name="84825"> </a>The floating-point data registers are initialized to NaN (Not-a-Number), which is 0xFFFFFFFF. You can change the FSR's (Floating-point Status Register) value using the global variable <b class="symbol_lc">fppFsrDefault</b>.</p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84828">Floating-Point Exceptions</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84841"> </a>The following are SPARC floating-point exceptions (most are deferred):</p><dl class="margin"><ul class="DashSingle2" type="circle"><li><a name="84831"> </a>FPU Disabled (or not present)</li></ul><ul class="DashSingle2" type="circle"><li><a name="84832"> </a>Unfinished Operation</li></ul><ul class="DashSingle2" type="circle"><li><a name="84833"> </a>Unimplemented Operation</li></ul><ul class="DashSingle2" type="circle"><li><a name="84834"> </a>Sequence Error</li></ul><ul class="DashSingle2" type="circle"><li><a name="84835"> </a>Invalid Operation</li></ul><ul class="DashSingle2" type="circle"><li><a name="84837"> </a>Overflow</li></ul><ul class="DashSingle2" type="circle"><li><a name="84838"> </a>Underflow</li></ul><ul class="DashSingle2" type="circle"><li><a name="84839"> </a>Divide-by-Zero</li></ul><ul class="DashSingle2" type="circle"><li><a name="84840"> </a>Inexact</li></ul></dl></dl><dl class="margin"><b class="HU-bullet"><li><a name="84842"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Exception Options </font></li></b></dl><dl class="margin"><dd><p class="Body"><a name="84843"> </a>The application can configure the types of floating-point exceptions that VxWorks handles. The ideal solution is to not generate any floating-point exceptions in the application tasks. However, a more realistic scheme is to mask all exceptions globally (all tasks) in the TEM (Trap Enable Mask) field of the FSR (Floating-point Status Register). Alternatively, this can be done locally (on a per task basis) as tasks are spawned and the FSR is initialized. In addition to global and local masks, individual exceptions (invalid operation, overflow, underflow, divide-by-zero, inexact) can be masked in the TEM. The masked exception continues to accrue (for example, become more inexact, continue to overflow, and so on). The default for VxWorks is to mask only the inexact exception. </p></dl><dl class="margin"><b class="HU-bullet"><li><a name="84844"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Exception Handlers </font></li></b></dl><dl class="margin">⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -