Changeset f233256 in rtems-docs
- Timestamp:
- Oct 6, 2016, 10:13:16 PM (5 years ago)
- Branches:
- 4.11, 5, am, master
- Children:
- be428d1
- Parents:
- e6fe68d
- Location:
- cpu_supplement
- Files:
-
- 19 edited
Legend:
- Unmodified
- Added
- Removed
-
cpu_supplement/altera_nios_ii.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 2014 Hesham ALMatary <heshamelmatary@gmail.com> 4 .. COMMENT: All rights reserved. 2 5 3 6 Altera Nios II Specific Information … … 13 16 14 17 Thread-local storage is not implemented. 15 16 .. COMMENT: COPYRIGHT (c) 2014 Hesham ALMatary <heshamelmatary@gmail.com>17 18 .. COMMENT: All rights reserved.19 -
cpu_supplement/arm.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2009. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 ARM Specific Information 4 8 ######################## 5 9 6 This chapter discusses the `ARM architecture <http://en.wikipedia.org/wiki/ARM_architecture>`_7 dependencies in this port of RTEMS. The ARMv4T (and compatible), ARMv7-A, 8 ARMv7-R and ARMv7-M architecture versions are supported by RTEMS. Processors 9 with a MMU use a static configuration which is set up during system start. SMP 10 is supported.10 This chapter discusses the *ARM architecture* 11 (http://en.wikipedia.org/wiki/ARM_architecture) dependencies in this port of 12 RTEMS. The ARMv4T (and compatible), ARMv7-A, ARMv7-R and ARMv7-M architecture 13 versions are supported by RTEMS. Processors with a MMU use a static 14 configuration which is set up during system start. SMP is supported. 11 15 12 16 **Architecture Documents** 13 17 14 For information on the ARM architecture refer to the`ARM Infocenter <http://infocenter.arm.com>`_. 18 For information on the ARM architecture refer to the *ARM Infocenter* 19 (http://infocenter.arm.com/). 15 20 16 21 CPU Model Dependent Features 17 22 ============================ 18 23 19 This section presents the set of features which vary 20 a cross ARM implementations and are of importance to RTEMS. The set of CPU21 model feature macros are defined in the file:file:`cpukit/score/cpu/arm/rtems/score/arm.h` based upon the particular CPU 22 model flags specified on the compilation command line.24 This section presents the set of features which vary across ARM implementations 25 and are of importance to RTEMS. The set of CPU model feature macros are 26 defined in the file :file:`cpukit/score/cpu/arm/rtems/score/arm.h` based upon 27 the particular CPU model flags specified on the compilation command line. 23 28 24 29 CPU Model Name 25 30 -------------- 26 31 27 The macro ``CPU_MODEL_NAME`` is a string which designates 28 the architectural level of this CPU model. See in:file:`cpukit/score/cpu/arm/rtems/score/arm.h` for the values. 32 The macro ``CPU_MODEL_NAME`` is a string which designates the architectural 33 level of this CPU model. See in :file:`cpukit/score/cpu/arm/rtems/score/arm.h` 34 for the values. 29 35 30 36 Count Leading Zeroes Instruction … … 52 58 The following multilibs are available: 53 59 54 # ``.``: ARMv4T, ARM instruction set60 #. ``.``: ARMv4T, ARM instruction set 55 61 56 # ``thumb``: ARMv4T, Thumb-1 instruction set62 #. ``thumb``: ARMv4T, Thumb-1 instruction set 57 63 58 # ``thumb/armv6-m``: ARMv6M, subset of Thumb-2 instruction set64 #. ``thumb/armv6-m``: ARMv6M, subset of Thumb-2 instruction set 59 65 60 # ``thumb/armv7-a``: ARMv7-A, Thumb-2 instruction set66 #. ``thumb/armv7-a``: ARMv7-A, Thumb-2 instruction set 61 67 62 # ``thumb/armv7-a/neon/hard``: ARMv7-A, Thumb-2 instruction set with63 hard-float ABI Neon and VFP-D32 support68 #. ``thumb/armv7-a/neon/hard``: ARMv7-A, Thumb-2 instruction set with 69 hard-float ABI Neon and VFP-D32 support 64 70 65 # ``thumb/armv7-r``: ARMv7-R, Thumb-2 instruction set71 #. ``thumb/armv7-r``: ARMv7-R, Thumb-2 instruction set 66 72 67 # ``thumb/armv7-r/vfpv3-d16/hard``: ARMv7-R, Thumb-2 instruction set68 withhard-float ABI VFP-D16 support73 #. ``thumb/armv7-r/vfpv3-d16/hard``: ARMv7-R, Thumb-2 instruction set with 74 hard-float ABI VFP-D16 support 69 75 70 # ``thumb/armv7-m``: ARMv7-M, Thumb-2 instruction set with hardware71 integer division (SDIV/UDIV)76 #. ``thumb/armv7-m``: ARMv7-M, Thumb-2 instruction set with hardware 77 integer division (SDIV/UDIV) 72 78 73 # ``thumb/armv7-m/fpv4-sp-d16``: ARMv7-M, Thumb-2 instruction set with74 hardware integer division (SDIV/UDIV) and hard-float ABI FPv4-SP support79 #. ``thumb/armv7-m/fpv4-sp-d16``: ARMv7-M, Thumb-2 instruction set with 80 hardware integer division (SDIV/UDIV) and hard-float ABI FPv4-SP support 75 81 76 # ``eb/thumb/armv7-r``: ARMv7-R, Big-endian Thumb-2 instruction set82 #. ``eb/thumb/armv7-r``: ARMv7-R, Big-endian Thumb-2 instruction set 77 83 78 # ``eb/thumb/armv7-r/vfpv3-d16/hard``: ARMv7-R, Big-endian Thumb-279 instructionset with hard-float ABI VFP-D16 support84 #. ``eb/thumb/armv7-r/vfpv3-d16/hard``: ARMv7-R, Big-endian Thumb-2 instruction 85 set with hard-float ABI VFP-D16 support 80 86 81 87 Multilib 1. and 2. support the standard ARM7TDMI and ARM926EJ-S targets. … … 94 100 big-endian variants are available. 95 101 96 Use for example the following GCC options 97 .. code:: c 102 Use for example the following GCC options: 103 104 .. code-block:: shell 98 105 99 106 -mthumb -march=armv7-a -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 … … 101 108 to build an application or BSP for the ARMv7-A architecture and tune the code 102 109 for a Cortex-A9 processor. It is important to select the options used for the 103 multilibs. For example 104 .. code:: c 110 multilibs. For example: 111 112 .. code-block:: shell 105 113 106 114 -mthumb -mcpu=cortex-a9 … … 111 119 =================== 112 120 113 Please refer to the`Procedure Call Standard for the ARM Architecture <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf>`_. 121 Please refer to the *Procedure Call Standard for the ARM Architecture* 122 (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf). 114 123 115 124 Memory Model … … 144 153 145 154 The ARMv7-M architecture has a completely different exception model. Here 146 interrupts are disabled with a write of 0x80 to the ``basepri_max`` 147 register. This means that all exceptions and interrupts with a priority value 148 of greater than or equal to 0x80 are disabled. Thus exceptions and interrupts 149 with a priority value of less than 0x80 are non-maskable with respect to the 150 operating system and therefore must not use operating system services. Several 151 support libraries of chip vendors implicitly shift the priority value somehow 152 beforethe value is written to the NVIC IPR register. This can easily lead to155 interrupts are disabled with a write of 0x80 to the ``basepri_max`` register. 156 This means that all exceptions and interrupts with a priority value of greater 157 than or equal to 0x80 are disabled. Thus exceptions and interrupts with a 158 priority value of less than 0x80 are non-maskable with respect to the operating 159 system and therefore must not use operating system services. Several support 160 libraries of chip vendors implicitly shift the priority value somehow before 161 the value is written to the NVIC IPR register. This can easily lead to 153 162 confusion. 154 163 … … 169 178 ============================== 170 179 171 The default fatal error handler for this architecture performs the 172 followingactions:180 The default fatal error handler for this architecture performs the following 181 actions: 173 182 174 183 - disables operating system supported interrupts (IRQ), … … 188 197 189 198 Thread-local storage is supported. 190 191 .. COMMENT: COPYRIGHT (c) 1988-2009.192 193 .. COMMENT: On-Line Applications Research Corporation (OAR).194 195 .. COMMENT: All rights reserved.196 -
cpu_supplement/atmel_avr.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2006. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 Atmel AVR Specific Information 4 8 ############################## 5 9 6 This chapter discusses the AVR architecture dependencies in this 7 port of RTEMS. 10 This chapter discusses the AVR architecture dependencies in this port of RTEMS. 8 11 9 12 **Architecture Documents** 10 13 11 For information on the AVR architecture, refer to the following 12 documentsavailable from Atmel.14 For information on the AVR architecture, refer to the following documents 15 available from Atmel. 13 16 14 17 TBD … … 19 22 ============================ 20 23 21 CPUs of the AVR 53X only differ in the peripherals and thus in the 22 d evice drivers. This port does not yet support the 56X dual core variants.24 CPUs of the AVR 53X only differ in the peripherals and thus in the device 25 drivers. This port does not yet support the 56X dual core variants. 23 26 24 27 Count Leading Zeroes Instruction 25 28 -------------------------------- 26 29 27 The AVR CPU has the XXX instruction which could be used to speed 28 up the find first bit operation. The use of this instruction should 29 significantly speed upthe scheduling associated with a thread blocking.30 The AVR CPU has the XXX instruction which could be used to speed up the find 31 first bit operation. The use of this instruction should significantly speed up 32 the scheduling associated with a thread blocking. 30 33 31 34 Calling Conventions … … 35 38 -------------------- 36 39 37 The AVR architecture supports a simple call and return mechanism. 38 A subroutine is invoked via the call (``call``) instruction. 39 This instruction saves the return address in the ``RETS`` register 40 and transfers the execution to thegiven address.40 The AVR architecture supports a simple call and return mechanism. A subroutine 41 is invoked via the call (``call``) instruction. This instruction saves the 42 return address in the ``RETS`` register and transfers the execution to the 43 given address. 41 44 42 It is the called funcions responsability to use the link instruction 43 to reserve space on the stack for the local variables. Returning from 44 a subroutine is done by using the RTS (``RTS``) instruction which 45 loads the PC with the adressstored in RETS.45 It is the called funcions responsability to use the link instruction to reserve 46 space on the stack for the local variables. Returning from a subroutine is 47 done by using the RTS (``RTS``) instruction which loads the PC with the adress 48 stored in RETS. 46 49 47 It is is important to note that the ``call`` instruction does not 48 automatically save or restore any registers. It is the responsibility 49 of the high-level language compiler to define the register preservation 50 and usage convention. 50 It is is important to note that the ``call`` instruction does not automatically 51 save or restore any registers. It is the responsibility of the high-level 52 language compiler to define the register preservation and usage convention. 51 53 52 54 Register Usage 53 55 -------------- 54 56 55 A called function may clobber all registers, except RETS, R4-R7, P3-P5, 56 FP and SP. It may also modify the first 12 bytes in the caller's stack 57 frame which is used as an argument area for the first three arguments 58 (which are passed in R0...R3 but may be placed on the stack by the 59 called function). 57 A called function may clobber all registers, except RETS, R4-R7, P3-P5, FP and 58 SP. It may also modify the first 12 bytes in the caller's stack frame which is 59 used as an argument area for the first three arguments (which are passed in 60 R0...R3 but may be placed on the stack by the called function). 60 61 61 62 Parameter Passing 62 63 ----------------- 63 64 64 RTEMS assumes that the AVR GCC calling convention is followed. 65 The first three parameters are stored in registers R0, R1, and R2. 66 All other parameters are put pushed on the stack. The result is returned 67 through register R0. 65 RTEMS assumes that the AVR GCC calling convention is followed. The first three 66 parameters are stored in registers R0, R1, and R2. All other parameters are 67 put pushed on the stack. The result is returned through register R0. 68 68 69 69 Memory Model 70 70 ============ 71 71 72 The AVR family architecutre support a single unified 4 GB byte 73 address space using 32-bit addresses. It maps all resources like internal 74 and external memory and IO registers into separate sections of this 75 common address space. 72 The AVR family architecutre support a single unified 4 GB byte address space 73 using 32-bit addresses. It maps all resources like internal and external memory 74 and IO registers into separate sections of this common address space. 76 75 77 The AVR architcture supports some form of memory 78 protection via its Memory Management Unit. Since the 79 AVR port runs in supervisior mode this memory 76 The AVR architcture supports some form of memory protection via its Memory 77 Management Unit. Since the AVR port runs in supervisior mode this memory 80 78 protection mechanisms are not used. 81 79 … … 83 81 ==================== 84 82 85 Discussed in this chapter are the AVR's interrupt response and 86 controlmechanisms as they pertain to RTEMS.83 Discussed in this chapter are the AVR's interrupt response and control 84 mechanisms as they pertain to RTEMS. 87 85 88 86 Vectoring of an Interrupt Handler … … 94 92 -------------------------------- 95 93 96 During interrupt disable critical sections, RTEMS disables interrupts to 97 level N (N) before the execution of this section and restores them 98 to the previous level upon completion of the section. RTEMS uses the 99 instructions CLI and STI to enable and disable Interrupts. Emulation, 100 Reset, NMI and ExceptionInterrupts are never disabled.94 During interrupt disable critical sections, RTEMS disables interrupts to level 95 N (N) before the execution of this section and restores them to the previous 96 level upon completion of the section. RTEMS uses the instructions CLI and STI 97 to enable and disable Interrupts. Emulation, Reset, NMI and Exception 98 Interrupts are never disabled. 101 99 102 100 Interrupt Stack 103 101 --------------- 104 102 105 The AVR Architecture works with two different kind of stacks, 106 User and Supervisor Stack. Since RTEMS and its Application run 107 in supervisor mode, all interrupts will use the interrupted 108 tasks stack for execution. 103 The AVR Architecture works with two different kind of stacks, User and 104 Supervisor Stack. Since RTEMS and its Application run in supervisor mode, all 105 interrupts will use the interrupted tasks stack for execution. 109 106 110 107 Default Fatal Error Processing … … 138 135 139 136 TBD 140 141 .. COMMENT: COPYRIGHT (c) 1988-2006.142 143 .. COMMENT: On-Line Applications Research Corporation (OAR).144 145 .. COMMENT: All rights reserved.146 -
cpu_supplement/blackfin.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: Copyright (c) 2015 University of York. 4 .. COMMENT: Hesham ALMatary <hmka501@york.ac.uk> 2 5 3 6 Blackfin Specific Information 4 7 ############################# 5 8 6 This chapter discusses the Blackfin architecture dependencies in this 7 port ofRTEMS.9 This chapter discusses the Blackfin architecture dependencies in this port of 10 RTEMS. 8 11 9 12 **Architecture Documents** 10 13 11 For information on the Blackfin architecture, refer to the following 12 documentsavailable from Analog Devices.14 For information on the Blackfin architecture, refer to the following documents 15 available from Analog Devices. 13 16 14 17 TBD 15 18 16 - *"ADSP-BF533 Blackfin Processor Hardware Reference."* :file:`http://www.analog.com/UploadedFiles/Associated_Docs/892485982bf533_hwr.pdf`19 - *"ADSP-BF533 Blackfin Processor Hardware Reference."* http://www.analog.com/UploadedFiles/Associated_Docs/892485982bf533_hwr.pdf 17 20 18 21 CPU Model Dependent Features 19 22 ============================ 20 23 21 CPUs of the Blackfin 53X only differ in the peripherals and thus in the 22 d evice drivers. This port does not yet support the 56X dual core variants.24 CPUs of the Blackfin 53X only differ in the peripherals and thus in the device 25 drivers. This port does not yet support the 56X dual core variants. 23 26 24 27 Count Leading Zeroes Instruction 25 28 -------------------------------- 26 29 27 The Blackfin CPU has the BITTST instruction which could be used to speed 28 up the find first bit operation. The use of this instruction should 29 s ignificantly speed up the scheduling associated with a thread blocking.30 The Blackfin CPU has the BITTST instruction which could be used to speed up the 31 find first bit operation. The use of this instruction should significantly 32 speed up the scheduling associated with a thread blocking. 30 33 31 34 Calling Conventions … … 33 36 34 37 This section is heavily based on content taken from the Blackfin uCLinux 35 documentation wiki which is edited by Analog Devices and Arcturus 36 Networks. :file:`http://docs.blackfin.uclinux.org/` 38 documentation wiki which is edited by Analog Devices and Arcturus Networks. 39 http://docs.blackfin.uclinux.org/ 37 40 38 41 Processor Background 39 42 -------------------- 40 43 41 The Blackfin architecture supports a simple call and return mechanism. 42 A subroutine is invoked via the call (``call``) instruction. 43 This instruction saves the return address in the ``RETS`` register 44 and transfers the executionto the given address.44 The Blackfin architecture supports a simple call and return mechanism. A 45 subroutine is invoked via the call (``call``) instruction. This instruction 46 saves the return address in the ``RETS`` register and transfers the execution 47 to the given address. 45 48 46 It is the called funcions responsability to use the link instruction 47 to reserve space on the stack for the local variables. Returning from 48 a subroutine is done by using the RTS (``RTS``) instruction which 49 loads the PC with the adressstored in RETS.49 It is the called funcions responsability to use the link instruction to reserve 50 space on the stack for the local variables. Returning from a subroutine is 51 done by using the RTS (``RTS``) instruction which loads the PC with the adress 52 stored in RETS. 50 53 51 It is is important to note that the ``call`` instruction does not 52 automatically save or restore any registers. It is the responsibility 53 of the high-level language compiler to define the register preservation 54 and usage convention. 54 It is is important to note that the ``call`` instruction does not automatically 55 save or restore any registers. It is the responsibility of the high-level 56 language compiler to define the register preservation and usage convention. 55 57 56 58 Register Usage 57 59 -------------- 58 60 59 A called function may clobber all registers, except RETS, R4-R7, P3-P5, 60 FP and SP. It may also modify the first 12 bytes in the caller's stack 61 frame which is used as an argument area for the first three arguments 62 (which are passed in R0...R3 but may be placed on the stack by the 63 called function). 61 A called function may clobber all registers, except RETS, R4-R7, P3-P5, FP and 62 SP. It may also modify the first 12 bytes in the caller's stack frame which is 63 used as an argument area for the first three arguments (which are passed in 64 R0...R3 but may be placed on the stack by the called function). 64 65 65 66 Parameter Passing 66 67 ----------------- 67 68 68 RTEMS assumes that the Blackfin GCC calling convention is followed. 69 The first three parameters are stored in registers R0, R1, and R2. 70 All other parameters are put pushed on the stack. The result is returned 71 through register R0. 69 RTEMS assumes that the Blackfin GCC calling convention is followed. The first 70 three parameters are stored in registers R0, R1, and R2. All other parameters 71 are put pushed on the stack. The result is returned through register R0. 72 72 73 73 Memory Model 74 74 ============ 75 75 76 The Blackfin family architecutre support a single unified 4 GB byte 77 address space using 32-bit addresses. It maps all resources like internal 78 and external memory and IO registers into separate sections of this 79 common address space. 76 The Blackfin family architecutre support a single unified 4 GB byte address 77 space using 32-bit addresses. It maps all resources like internal and external 78 memory and IO registers into separate sections of this common address space. 80 79 81 The Blackfin architcture supports some form of memory 82 protection via its Memory Management Unit. Since the 83 Blackfin port runs in supervisior mode this memory 80 The Blackfin architcture supports some form of memory protection via its Memory 81 Management Unit. Since the Blackfin port runs in supervisior mode this memory 84 82 protection mechanisms are not used. 85 83 … … 87 85 ==================== 88 86 89 Discussed in this chapter are the Blackfin's interrupt response and 90 control mechanisms as they pertain to RTEMS. The Blackfin architecture 91 support 16 kinds of interrupts broken down into Core and general-purpose 92 interrupts. 87 Discussed in this chapter are the Blackfin's interrupt response and control 88 mechanisms as they pertain to RTEMS. The Blackfin architecture support 16 kinds 89 of interrupts broken down into Core and general-purpose interrupts. 93 90 94 91 Vectoring of an Interrupt Handler 95 92 --------------------------------- 96 93 97 RTEMS maps levels 0 -15 directly to Blackfins event vectors EVT0 - 98 EVT15. Since EVT0 - EVT6 are core events and it is suggested to use 99 EVT15 and EVT15 for Software interrupts, 7 Interrupts (EVT7-EVT13) 100 are left for periferical use. 94 RTEMS maps levels 0 -15 directly to Blackfins event vectors EVT0 - EVT15. Since 95 EVT0 - EVT6 are core events and it is suggested to use EVT15 and EVT15 for 96 Software interrupts, 7 Interrupts (EVT7-EVT13) are left for periferical use. 101 97 102 When installing an RTEMS interrupt handler RTEMS installs a generic 103 Interrupt Handler which saves some context and enables nested interrupt 104 servicing andthen vectors to the users interrupt handler.98 When installing an RTEMS interrupt handler RTEMS installs a generic Interrupt 99 Handler which saves some context and enables nested interrupt servicing and 100 then vectors to the users interrupt handler. 105 101 106 102 Disabling of Interrupts by RTEMS 107 103 -------------------------------- 108 104 109 During interrupt disable critical sections, RTEMS disables interrupts to 110 level four (4) before the execution of this section and restores them 111 to the previous level upon completion of the section. RTEMS uses the 112 instructions CLI and STI to enable and disable Interrupts. Emulation, 113 Reset, NMI and ExceptionInterrupts are never disabled.105 During interrupt disable critical sections, RTEMS disables interrupts to level 106 four (4) before the execution of this section and restores them to the previous 107 level upon completion of the section. RTEMS uses the instructions CLI and STI 108 to enable and disable Interrupts. Emulation, Reset, NMI and Exception 109 Interrupts are never disabled. 114 110 115 111 Interrupt Stack 116 112 --------------- 117 113 118 The Blackfin Architecture works with two different kind of stacks, 119 User and Supervisor Stack. Since RTEMS and its Application run 120 in supervisor mode, all interrupts will use the interrupted 121 tasks stack for execution. 114 The Blackfin Architecture works with two different kind of stacks, User and 115 Supervisor Stack. Since RTEMS and its Application run in supervisor mode, all 116 interrupts will use the interrupted tasks stack for execution. 122 117 123 118 Default Fatal Error Processing … … 151 146 152 147 TBD 153 154 .. COMMENT: Copyright (c) 2015 University of York.155 156 .. COMMENT: Hesham ALMatary <hmka501@york.ac.uk>157 -
cpu_supplement/ephiphany.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2002. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 Epiphany Specific Information 4 8 ############################# 5 9 6 This chapter discusses the`Epiphany Architecture <http://adapteva.com/docs/epiphany_sdk_ref.pdf>`_7 dependencies in this port of RTEMS. Epiphany is a chip that can come with 16 and 8 64 cores, each of which can run RTEMS separately or they can work together to 9 run a SMP RTEMS application.10 This chapter discusses the`Epiphany Architecture 11 http://adapteva.com/docs/epiphany_sdk_ref.pdf dependencies in this port of 12 RTEMS. Epiphany is a chip that can come with 16 and 64 cores, each of which can 13 run RTEMS separately or they can work together to run a SMP RTEMS application. 10 14 11 15 **Architecture Documents** 12 16 13 For information on the Epiphany architecture refer to the`Epiphany Architecture Reference <http://adapteva.com/docs/epiphany_arch_ref.pdf>`_. 17 For information on the Epiphany architecture refer to the *Epiphany 18 Architecture Reference* http://adapteva.com/docs/epiphany_arch_ref.pdf. 14 19 15 20 Calling Conventions 16 21 =================== 17 22 18 Please refer to the`Epiphany SDK <http://adapteva.com/docs/epiphany_sdk_ref.pdf>`_ 19 Appendix A: Application Binary Interface 23 Please refer to the *Epiphany SDK* 24 http://adapteva.com/docs/epiphany_sdk_ref.pdf Appendix A: Application Binary 25 Interface 20 26 21 27 Floating Point Unit … … 27 33 ============ 28 34 29 A flat 32-bit memory model is supported, no caches. Each core has its own 32 KiB30 strictly ordered local memory along with an access to a shared 32 MiB external 31 DRAM.35 A flat 32-bit memory model is supported, no caches. Each core has its own 32 36 KiB strictly ordered local memory along with an access to a shared 32 MiB 37 external DRAM. 32 38 33 39 Interrupt Processing … … 64 70 --------------- 65 71 66 The Epiphany RTEMS port uses a dedicated software interrupt stack. 67 The stack for interrupts is allocated during interrupt driver initialization. 68 When an interrupt is entered, the _ISR_Handler routine is responsible for 69 switchingfrom the interrupted task stack to RTEMS software interrupt stack.72 The Epiphany RTEMS port uses a dedicated software interrupt stack. The stack 73 for interrupts is allocated during interrupt driver initialization. When an 74 interrupt is entered, the _ISR_Handler routine is responsible for switching 75 from the interrupted task stack to RTEMS software interrupt stack. 70 76 71 77 Default Fatal Error Processing 72 78 ============================== 73 79 74 The default fatal error handler for this architecture performs the 75 followingactions:80 The default fatal error handler for this architecture performs the following 81 actions: 76 82 77 83 - disables operating system supported interrupts (IRQ), … … 85 91 86 92 SMP is not supported. 87 88 .. COMMENT: COPYRIGHT (c) 1988-2002.89 90 .. COMMENT: On-Line Applications Research Corporation (OAR).91 92 .. COMMENT: All rights reserved.93 -
cpu_supplement/index.rst
re6fe68d rf233256 5 5 ================================= 6 6 7 COPYRIGHT (c) 1988 - 2015. 7 | COPYRIGHT (c) 1988 - 2015. 8 | On-Line Applications Research Corporation (OAR). 8 9 9 On-Line Applications Research Corporation (OAR). 10 The authors have used their best efforts in preparing this material. These 11 efforts include the development, research, and testing of the theories and 12 programs to determine their effectiveness. No warranty of any kind, expressed 13 or implied, with regard to the software or the material contained in this 14 document is provided. No liability arising out of the application or use of 15 any product described in this document is assumed. The authors reserve the 16 right to revise this material and to make changes from time to time in the 17 content hereof without obligation to notify anyone of such revision or changes. 10 18 11 The authors have used their best efforts in preparing 12 this material. These efforts include the development, research, 13 and testing of the theories and programs to determine their 14 effectiveness. No warranty of any kind, expressed or implied, 15 with regard to the software or the material contained in this 16 document is provided. No liability arising out of the 17 application or use of any product described in this document is 18 assumed. The authors reserve the right to revise this material 19 and to make changes from time to time in the content hereof 20 without obligation to notify anyone of such revision or changes. 19 The RTEMS Project is hosted at http://www.rtems.org/. Any inquiries concerning 20 RTEMS, its related support components, or its documentation should be directed 21 to the Community Project hosted at http://www.rtems.org/. 21 22 22 The RTEMS Project is hosted at http://www.rtems.org. Any 23 inquiries concerning RTEMS, its related support components, or its 24 documentation should be directed to the Community Project hosted athttp://www.rtems.org. 23 .. topic:: RTEMS Online Resources 25 24 26 Any inquiries for commercial services including training, support, custom 27 development, application development assistance should be directed tohttp://www.rtems.com. 28 29 30 Table of Contents 31 ----------------- 32 33 .. toctree:: 34 35 preface 36 25 ================ ============================= 26 Home https://www.rtems.org/ 27 Developers https://devel.rtems.org/ 28 Documentation https://docs.rtems.org/ 29 Bug Reporting https://devel.rtems.org/query 30 Mailing Lists https://lists.rtems.org/ 31 Git Repositories https://git.rtems.org/ 32 ================ ============================= 37 33 38 34 .. toctree:: … … 40 36 :numbered: 41 37 38 preface 42 39 port 43 40 arm … … 59 56 command 60 57 61 62 58 * :ref:`genindex` 63 59 * :ref:`search` 64 -
cpu_supplement/intel_amd_x86.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2002. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 6 .. COMMENT: Jukka Pietarinen <jukka.pietarinen@mrf.fi>, 2008, 7 .. COMMENT: Micro-Research Finland Oy 2 8 3 9 Intel/AMD x86 Specific Information 4 10 ################################## 5 11 6 This chapter discusses the Intel x86 architecture dependencies 7 in this port of RTEMS. This family has multiple implementations 8 from multiple vendors and suffers more from having evolved rather 9 than being designed for growth. 10 11 For information on the i386 processor, refer to the 12 following documents: 12 This chapter discusses the Intel x86 architecture dependencies in this port of 13 RTEMS. This family has multiple implementations from multiple vendors and 14 suffers more from having evolved rather than being designed for growth. 15 16 For information on the i386 processor, refer to the following documents: 13 17 14 18 - *386 Programmer's Reference Manual, Intel, Order No. 230985-002*. … … 24 28 ============================ 25 29 26 This section presents the set of features which vary 27 across i386 implementations and are of importance to RTEMS. 28 The set of CPU model feature macros are defined in the file``cpukit/score/cpu/i386/i386.h`` based upon the particular CPU 29 model specified on the compilation command line.30 This section presents the set of features which vary across i386 31 implementations and are of importance to RTEMS. The set of CPU model feature 32 macros are defined in the :file:`cpukit/score/cpu/i386/i386.h` based upon the 33 particular CPU model specified on the compilation command line. 30 34 31 35 bswap Instruction 32 36 ----------------- 33 37 34 The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that 35 this CPU model has the ``bswap`` instruction which 36 endian swaps a thirty-two bit quantity. This instruction 37 appears to be present in all CPU models 38 i486's and above. 38 The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that this CPU model has 39 the ``bswap`` instruction which endian swaps a thirty-two bit quantity. This 40 instruction appears to be present in all CPU models i486's and above. 39 41 40 42 Calling Conventions … … 44 46 -------------------- 45 47 46 The i386 architecture supports a simple yet effective 47 call and return mechanism. A subroutine is invoked via the call 48 (``call``) instruction. This instruction pushes the return address 49 on the stack. The return from subroutine (``ret``) instruction pops 50 the return address off the current stack and transfers control 51 to that instruction. It is is important to note that the i386 52 call and return mechanism does not automatically save or restore 53 any registers. It is the responsibility of the high-level 54 language compiler to define the register preservation and usage 55 convention. 48 The i386 architecture supports a simple yet effective call and return 49 mechanism. A subroutine is invoked via the call (``call``) instruction. This 50 instruction pushes the return address on the stack. The return from subroutine 51 (``ret``) instruction pops the return address off the current stack and 52 transfers control to that instruction. It is is important to note that the 53 i386 call and return mechanism does not automatically save or restore any 54 registers. It is the responsibility of the high-level language compiler to 55 define the register preservation and usage convention. 56 56 57 57 Calling Mechanism 58 58 ----------------- 59 59 60 All RTEMS directives are invoked using a call instruction and return to 61 theuser application via the ret instruction.60 All RTEMS directives are invoked using a call instruction and return to the 61 user application via the ret instruction. 62 62 63 63 Register Usage 64 64 -------------- 65 65 66 As discussed above, the call instruction does not automatically save 67 any registers. RTEMS uses the registers EAX, ECX, and EDX as scratch 68 registers. These registers are not preserved by RTEMS directives 69 therefore, the contents of these registers should not be assumed upon 70 return from any RTEMS directive. 66 As discussed above, the call instruction does not automatically save any 67 registers. RTEMS uses the registers EAX, ECX, and EDX as scratch registers. 68 These registers are not preserved by RTEMS directives therefore, the contents 69 of these registers should not be assumed upon return from any RTEMS directive. 71 70 72 71 Parameter Passing 73 72 ----------------- 74 73 75 RTEMS assumes that arguments are placed on the 76 current stack before the directive is invoked via the call 77 instruction. The first argument is assumed to be closest to the 78 return address on the stack. This means that the first argument 79 of the C calling sequence is pushed last. The following 80 pseudo-code illustrates the typical sequence used to call a 81 RTEMS directive with three (3) arguments: 82 .. code :: c74 RTEMS assumes that arguments are placed on the current stack before the 75 directive is invoked via the call instruction. The first argument is assumed 76 to be closest to the return address on the stack. This means that the first 77 argument of the C calling sequence is pushed last. The following pseudo-code 78 illustrates the typical sequence used to call a RTEMS directive with three (3) 79 arguments: 80 81 .. code-block:: c 83 82 84 83 push third argument … … 88 87 remove arguments from the stack 89 88 90 The arguments to RTEMS are typically pushed onto the 91 stack using a push instruction. These arguments must be removed 92 from the stack after control is returned to the caller. This 93 removal is typically accomplished by adding the size of the 94 argument list in bytes to the stack pointer. 89 The arguments to RTEMS are typically pushed onto the stack using a push 90 instruction. These arguments must be removed from the stack after control is 91 returned to the caller. This removal is typically accomplished by adding the 92 size of the argument list in bytes to the stack pointer. 95 93 96 94 Memory Model … … 100 98 ----------------- 101 99 102 RTEMS supports the i386 protected mode, flat memory 103 model with paging disabled. In this mode, the i386 104 automatically converts every address from a logical to a 105 physical address each time it is used. The i386 uses 106 information provided in the segment registers and the Global 107 Descriptor Table to convert these addresses. RTEMS assumes the 108 existence of the following segments: 109 110 - a single code segment at protection level (0) which 111 contains all application and executive code. 112 113 - a single data segment at protection level zero (0) which 114 contains all application and executive data. 115 116 The i386 segment registers and associated selectors 117 must be initialized when the initialize_executive directive is 118 invoked. RTEMS treats the segment registers as system registers 119 and does not modify or context switch them. 120 121 This i386 memory model supports a flat 32-bit address 122 space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 123 gigabytes). Each address is represented by a 32-bit value and 124 is byte addressable. The address may be used to reference a 125 single byte, half-word (2-bytes), or word (4 bytes). 100 RTEMS supports the i386 protected mode, flat memory model with paging disabled. 101 In this mode, the i386 automatically converts every address from a logical to a 102 physical address each time it is used. The i386 uses information provided in 103 the segment registers and the Global Descriptor Table to convert these 104 addresses. RTEMS assumes the existence of the following segments: 105 106 - a single code segment at protection level (0) which contains all application 107 and executive code. 108 109 - a single data segment at protection level zero (0) which contains all 110 application and executive data. 111 112 The i386 segment registers and associated selectors must be initialized when 113 the initialize_executive directive is invoked. RTEMS treats the segment 114 registers as system registers and does not modify or context switch them. 115 116 This i386 memory model supports a flat 32-bit address space with addresses 117 ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is 118 represented by a 32-bit value and is byte addressable. The address may be used 119 to reference a single byte, half-word (2-bytes), or word (4 bytes). 126 120 127 121 Interrupt Processing 128 122 ==================== 129 123 130 Although RTEMS hides many of the processor 131 dependent details of interrupt processing, it is important to 132 understand how the RTEMS interrupt manager is mapped onto the 133 processor's unique architecture. Discussed in this chapter are 134 the the processor's response and control mechanisms as they 135 pertain to RTEMS. 124 Although RTEMS hides many of the processor dependent details of interrupt 125 processing, it is important to understand how the RTEMS interrupt manager is 126 mapped onto the processor's unique architecture. Discussed in this chapter are 127 the the processor's response and control mechanisms as they pertain to RTEMS. 136 128 137 129 Vectoring of Interrupt Handler 138 130 ------------------------------ 139 131 140 Although the i386 supports multiple privilege levels, 141 RTEMS and all user software executes at privilege level 0. This 142 decision was made by the RTEMS designers to enhance 143 compatibility with processors which do not provide sophisticated 144 protection facilities like those of the i386. This decision 145 greatly simplifies the discussion of i386 processing, as one 146 need only consider interrupts without privilege transitions. 147 148 Upon receipt of an interrupt the i386 automatically 149 performs the following actions: 132 Although the i386 supports multiple privilege levels, RTEMS and all user 133 software executes at privilege level 0. This decision was made by the RTEMS 134 designers to enhance compatibility with processors which do not provide 135 sophisticated protection facilities like those of the i386. This decision 136 greatly simplifies the discussion of i386 processing, as one need only consider 137 interrupts without privilege transitions. 138 139 Upon receipt of an interrupt the i386 automatically performs the following 140 actions: 150 141 151 142 - pushes the EFLAGS register … … 155 146 - vectors to the interrupt service routine (ISR). 156 147 157 A nested interrupt is processed similarly by the 158 i386. 148 A nested interrupt is processed similarly by the i386. 159 149 160 150 Interrupt Stack Frame 161 151 --------------------- 162 152 163 The structure of the Interrupt Stack Frame for the 164 i386 which is placed on the interrupt stack by the processor in 165 response to an interrupt is as follows: 153 The structure of the Interrupt Stack Frame for the i386 which is placed on the 154 interrupt stack by the processor in response to an interrupt is as follows: 166 155 167 156 +----------------------+-------+ … … 177 166 ---------------- 178 167 179 Although RTEMS supports 256 interrupt levels, the 180 i386 only supports two - enabled and disabled. Interrupts are 181 enabled when the interrupt-enable flag (IF) in the extended 182 flags (EFLAGS) is set. Conversely, interrupt processing is 183 inhibited when the IF is cleared. During a non-maskable 184 interrupt, all other interrupts, including other non-maskable 185 ones, are inhibited. 168 Although RTEMS supports 256 interrupt levels, the i386 only supports two - 169 enabled and disabled. Interrupts are enabled when the interrupt-enable flag 170 (IF) in the extended flags (EFLAGS) is set. Conversely, interrupt processing 171 is inhibited when the IF is cleared. During a non-maskable interrupt, all 172 other interrupts, including other non-maskable ones, are inhibited. 186 173 187 174 RTEMS interrupt levels 0 and 1 such that level zero 188 (0) indicates that interrupts are fully enabled and level one 189 that interrupts are disabled. All other RTEMS interrupt levels 190 are undefined and theirbehavior is unpredictable.175 (0) indicates that interrupts are fully enabled and level one that interrupts 176 are disabled. All other RTEMS interrupt levels are undefined and their 177 behavior is unpredictable. 191 178 192 179 Interrupt Stack 193 180 --------------- 194 181 195 The i386 family does not support a dedicated hardware 196 interrupt stack. On this processor, RTEMS allocates and manages 197 a dedicated interrupt stack. As part of vectoring a non-nested 198 interrupt service routine, RTEMS switches from the stack of the 199 interrupted task to a dedicated interrupt stack. When a 200 non-nested interrupt returns, RTEMS switches back to the stack 201 of the interrupted stack. The current stack pointer is not 202 altered by RTEMS on nested interrupt. 182 The i386 family does not support a dedicated hardware interrupt stack. On this 183 processor, RTEMS allocates and manages a dedicated interrupt stack. As part of 184 vectoring a non-nested interrupt service routine, RTEMS switches from the stack 185 of the interrupted task to a dedicated interrupt stack. When a non-nested 186 interrupt returns, RTEMS switches back to the stack of the interrupted stack. 187 The current stack pointer is not altered by RTEMS on nested interrupt. 203 188 204 189 Default Fatal Error Processing … … 206 191 207 192 The default fatal error handler for this architecture disables processor 208 interrupts, places the error code in EAX, and executes a HLT instruction 209 tohalt the processor.193 interrupts, places the error code in EAX, and executes a HLT instruction to 194 halt the processor. 210 195 211 196 Symmetric Multiprocessing … … 225 210 ------------ 226 211 227 An RTEMS based application is initiated when the i386 processor is reset. 228 Whenthe i386 is reset,229 230 - The EAX register is set to indicate the results of the processor's 231 power-up self test. If the self-test was not executed, the contents of232 this register are undefined. Otherwise, a non-zero value indicates the233 processor is faultyand a zero value indicates a successful self-test.234 235 - The DX register holds a component identifier and revision level. DH 236 contains 3 to indicate an i386 component and DL contains a unique revision237 levelindicator.238 239 - Control register zero (CR0) is set such that the processor is in real 240 modewith paging disabled. Other portions of CR0 are used to indicate the212 An RTEMS based application is initiated when the i386 processor is reset. When 213 the i386 is reset, 214 215 - The EAX register is set to indicate the results of the processor's power-up 216 self test. If the self-test was not executed, the contents of this register 217 are undefined. Otherwise, a non-zero value indicates the processor is faulty 218 and a zero value indicates a successful self-test. 219 220 - The DX register holds a component identifier and revision level. DH contains 221 3 to indicate an i386 component and DL contains a unique revision level 222 indicator. 223 224 - Control register zero (CR0) is set such that the processor is in real mode 225 with paging disabled. Other portions of CR0 are used to indicate the 241 226 presence of a numeric coprocessor. 242 227 243 - All bits in the extended flags register (EFLAG) which are not 244 permanently set are cleared. This inhibits all maskable interrupts. 245 246 - The Interrupt Descriptor Register (IDTR) is set to point at address 247 zero. 228 - All bits in the extended flags register (EFLAG) which are not permanently set 229 are cleared. This inhibits all maskable interrupts. 230 231 - The Interrupt Descriptor Register (IDTR) is set to point at address zero. 248 232 249 233 - All segment registers are set to zero. 250 234 251 - The instruction pointer is set to 0x0000FFF0. The first instruction 252 executed after a reset is actually at 0xFFFFFFF0 because the i386 asserts 253 the upper twelve address until the first intersegment (FAR) JMP or CALL 254 instruction. When a JMP or CALL is executed, the upper twelve address 255 lines are lowered and the processor begins executing in the first megabyte 256 of memory. 235 - The instruction pointer is set to 0x0000FFF0. The first instruction executed 236 after a reset is actually at 0xFFFFFFF0 because the i386 asserts the upper 237 twelve address until the first intersegment (FAR) JMP or CALL instruction. 238 When a JMP or CALL is executed, the upper twelve address lines are lowered 239 and the processor begins executing in the first megabyte of memory. 257 240 258 241 Typically, an intersegment JMP to the application's initialization code is … … 262 245 ------------------------ 263 246 264 This initialization code is responsible for initializing all data 265 structures required by the i386 in protected mode and for actually entering 266 protected mode. The i386 must be placed in protected mode and the segment 267 registers and associated selectors must be initialized before the 268 initialize_executive directive is invoked. 269 270 The initialization code is responsible for initializing the Global 271 Descriptor Table such that the i386 is in the thirty-two bit flat memory 272 model with paging disabled. In this mode, the i386 automatically converts 273 every address from a logical to a physical address each time it is used. 274 For more information on the memory model used by RTEMS, please refer to the 275 Memory Model chapter in this document. 276 277 Since the processor is in real mode upon reset, the processor must be 278 switched to protected mode before RTEMS can execute. Before switching to 279 protected mode, at least one descriptor table and two descriptors must be 280 created. Descriptors are needed for a code segment and a data segment. ( 281 This will give you the flat memory model.) The stack can be placed in a 282 normal read/write data segment, so no descriptor for the stack is needed. 283 Before the GDT can be used, the base address and limit must be loaded into 284 the GDTR register using an LGDT instruction. 285 286 If the hardware allows an NMI to be generated, you need to create the IDT 287 and a gate for the NMI interrupt handler. Before the IDT can be used, the 288 base address and limit for the idt must be loaded into the IDTR register 289 using an LIDT instruction. 290 291 Protected mode is entered by setting thye PE bit in the CR0 register. 292 Either a LMSW or MOV CR0 instruction may be used to set this bit. Because 293 the processor overlaps the interpretation of several instructions, it is 294 necessary to discard the instructions from the read-ahead cache. A JMP 295 instruction immediately after the LMSW changes the flow and empties the 296 processor if intructions which have been pre-fetched and/or decoded. At 297 this point, the processor is in protected mode and begins to perform 298 protected mode application initialization. 299 300 If the application requires that the IDTR be some value besides zero, then 301 it should set it to the required value at this point. All tasks share the 302 same i386 IDTR value. Because interrupts are enabled automatically by 303 RTEMS as part of the initialize_executive directive, the IDTR MUST be set 304 properly before this directive is invoked to insure correct interrupt 305 vectoring. If processor caching is to be utilized, then it should be 306 enabled during the reset application initialization code. The reset code 307 which is executed before the call to initialize_executive has the following 308 requirements: 309 310 For more information regarding the i386 data structures and their 311 contents, refer to Intel's 386 Programmer's Reference Manual. 312 313 .. COMMENT: COPYRIGHT (c) 1988-2002. 314 315 .. COMMENT: On-Line Applications Research Corporation (OAR). 316 317 .. COMMENT: All rights reserved. 318 319 .. COMMENT: Jukka Pietarinen <jukka.pietarinen@mrf.fi>, 2008, 320 321 .. COMMENT: Micro-Research Finland Oy 322 247 This initialization code is responsible for initializing all data structures 248 required by the i386 in protected mode and for actually entering protected 249 mode. The i386 must be placed in protected mode and the segment registers and 250 associated selectors must be initialized before the initialize_executive 251 directive is invoked. 252 253 The initialization code is responsible for initializing the Global Descriptor 254 Table such that the i386 is in the thirty-two bit flat memory model with paging 255 disabled. In this mode, the i386 automatically converts every address from a 256 logical to a physical address each time it is used. For more information on 257 the memory model used by RTEMS, please refer to the Memory Model chapter in 258 this document. 259 260 Since the processor is in real mode upon reset, the processor must be switched 261 to protected mode before RTEMS can execute. Before switching to protected 262 mode, at least one descriptor table and two descriptors must be created. 263 Descriptors are needed for a code segment and a data segment. ( This will give 264 you the flat memory model.) The stack can be placed in a normal read/write 265 data segment, so no descriptor for the stack is needed. Before the GDT can be 266 used, the base address and limit must be loaded into the GDTR register using an 267 LGDT instruction. 268 269 If the hardware allows an NMI to be generated, you need to create the IDT and a 270 gate for the NMI interrupt handler. Before the IDT can be used, the base 271 address and limit for the idt must be loaded into the IDTR register using an 272 LIDT instruction. 273 274 Protected mode is entered by setting thye PE bit in the CR0 register. Either a 275 LMSW or MOV CR0 instruction may be used to set this bit. Because the processor 276 overlaps the interpretation of several instructions, it is necessary to discard 277 the instructions from the read-ahead cache. A JMP instruction immediately after 278 the LMSW changes the flow and empties the processor if intructions which have 279 been pre-fetched and/or decoded. At this point, the processor is in protected 280 mode and begins to perform protected mode application initialization. 281 282 If the application requires that the IDTR be some value besides zero, then it 283 should set it to the required value at this point. All tasks share the same 284 i386 IDTR value. Because interrupts are enabled automatically by RTEMS as part 285 of the initialize_executive directive, the IDTR MUST be set properly before 286 this directive is invoked to insure correct interrupt vectoring. If processor 287 caching is to be utilized, then it should be enabled during the reset 288 application initialization code. The reset code which is executed before the 289 call to initialize_executive has the following requirements: 290 291 For more information regarding the i386 data structures and their contents, 292 refer to Intel's 386 Programmer's Reference Manual. -
cpu_supplement/lattice_micro32.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved. 2 4 3 5 Lattice Mico32 Specific Information 4 6 ################################### 5 7 6 This chaper discusses the Lattice Mico32 architecture dependencies in 7 this port of RTEMS. The Lattice Mico32 is a 32-bit Harvard, RISC 8 architecture "soft" microprocessor, available for free with an open IP 9 core licensing agreement. Although mainly targeted for Lattice FPGA 10 devices the microprocessor can be implemented on other vendors' FPGAs, 11 too. 8 This chaper discusses the Lattice Mico32 architecture dependencies in this port 9 of RTEMS. The Lattice Mico32 is a 32-bit Harvard, RISC architecture "soft" 10 microprocessor, available for free with an open IP core licensing 11 agreement. Although mainly targeted for Lattice FPGA devices the microprocessor 12 can be implemented on other vendors' FPGAs, too. 12 13 13 14 **Architecture Documents** 14 15 15 For information on the Lattice Mico32 architecture, refer to the 16 following documents available from Lattice Semiconductor:file:`http://www.latticesemi.com/`. 17 18 - *"LatticeMico32 Processor Reference Manual"*:file:`http://www.latticesemi.com/dynamic/view_document.cfm?document_id=20890` 16 For information on the Lattice Mico32 architecture, refer to the following 17 documents available from Lattice Semiconductor http://www.latticesemi.com/. 18 19 - *"LatticeMico32 Processor Reference Manual"* 20 http://www.latticesemi.com/dynamic/view_document.cfm?document_id=20890 19 21 20 22 CPU Model Dependent Features 21 23 ============================ 22 24 23 The Lattice Mico32 architecture allows for different configurations of 24 the processor. This port is based on the assumption that the following options are implemented: 25 The Lattice Mico32 architecture allows for different configurations of the 26 processor. This port is based on the assumption that the following options are 27 implemented: 25 28 26 29 - hardware multiplier … … 41 44 ===================== 42 45 43 This section gives a brief introduction to the register architecture 44 of theLattice Mico32 processor.45 46 The Lattice Mico32 is a RISC archictecture processor with a 47 32- register file of 32-bit registers.46 This section gives a brief introduction to the register architecture of the 47 Lattice Mico32 processor. 48 49 The Lattice Mico32 is a RISC archictecture processor with a 32-register file of 50 32-bit registers. 48 51 49 52 Register Name … … 83 86 breakpoint address 84 87 85 Note that on processor startup all register values are undefined 86 including r0,thus r0 has to be initialized to zero.88 Note that on processor startup all register values are undefined including r0, 89 thus r0 has to be initialized to zero. 87 90 88 91 Calling Conventions … … 92 95 ----------------- 93 96 94 A call instruction places the return address to register r29 and a 95 return fromsubroutine (ret) is actually a branch to r29/ra.97 A call instruction places the return address to register r29 and a return from 98 subroutine (ret) is actually a branch to r29/ra. 96 99 97 100 Register Usage 98 101 -------------- 99 102 100 A subroutine may freely use registers r1 to r10 which are *not* 101 preservedacross subroutine invocations.103 A subroutine may freely use registers r1 to r10 which are *not* preserved 104 across subroutine invocations. 102 105 103 106 Parameter Passing 104 107 ----------------- 105 108 106 When calling a C function the first eight arguments are stored in 107 registers r1to r8. Registers r1 and r2 hold the return value.109 When calling a C function the first eight arguments are stored in registers r1 110 to r8. Registers r1 and r2 hold the return value. 108 111 109 112 Memory Model 110 113 ============ 111 114 112 The Lattice Mico32 processor supports a flat memory model with a 4 113 Gbyteaddress space with 32-bit addresses.115 The Lattice Mico32 processor supports a flat memory model with a 4 Gbyte 116 address space with 32-bit addresses. 114 117 115 118 The following data types are supported: 116 119 117 Type 118 119 Bits 120 121 C Compiler Type 122 123 unsigned byte 124 125 8 126 127 unsigned char 128 129 signed byte 130 131 8 132 133 char 134 135 unsigned half-word 136 137 16 138 139 unsigned short 140 141 signed half-word 142 143 16 144 145 short 146 147 unsigned word 148 149 32 150 151 unsigned int / unsigned long 152 153 signed word 154 155 32 156 157 int / long 158 159 Data accesses need to be aligned, with unaligned accesses result are 160 undefined. 120 ================== ==== ====================== 121 Type Bits C Compiler Type 122 ================== ==== ====================== 123 unsigned byte 8 unsigned char 124 signed byte 8 char 125 unsigned half-word 16 unsigned short 126 signed half-word 16 short 127 unsigned word 32 unsigned int / unsigned long 128 signed word 32 int / long 129 ================== ==== ====================== 130 131 Data accesses need to be aligned, with unaligned accesses result are undefined. 161 132 162 133 Interrupt Processing 163 134 ==================== 164 135 165 The Lattice Mico32 has 32 interrupt lines which are however served by 166 only oneexception vector. When an interrupt occurs following happens:136 The Lattice Mico32 has 32 interrupt lines which are however served by only one 137 exception vector. When an interrupt occurs following happens: 167 138 168 139 - address of next instruction placed in r30/ea 169 140 170 - IE field of IE CSR saved to EIE field and IE field cleared preventing further exceptions from occuring. 141 - IE field of IE CSR saved to EIE field and IE field cleared preventing further 142 exceptions from occuring. 171 143 172 144 - branch to interrupt exception address EBA CSR + 0xC0 173 145 174 The interrupt exception handler determines from the state of the 175 interrupt pending registers (IP CSR) and interrupt enable register (IE 176 CSR) which interrupt to serve and jumps to the interrupt routine 177 pointed to by the corresponding interrupt vector. 178 179 For now there is no dedicated interrupt stack so every task in 180 the system MUST have enough stack space to accommodate the worst 181 case stack usage of that particular task and the interrupt 182 service routines COMBINED. 146 The interrupt exception handler determines from the state of the interrupt 147 pending registers (IP CSR) and interrupt enable register (IE CSR) which 148 interrupt to serve and jumps to the interrupt routine pointed to by the 149 corresponding interrupt vector. 150 151 For now there is no dedicated interrupt stack so every task in the system MUST 152 have enough stack space to accommodate the worst case stack usage of that 153 particular task and the interrupt service routines COMBINED. 183 154 184 155 Nested interrupts are not supported. … … 188 159 189 160 Upon detection of a fatal error by either the application or RTEMS during 190 initialization the ``rtems_fatal_error_occurred`` directive supplied 191 by the Fatal Error Manager is invoked. The Fatal Error Manager will 192 invoke the user-supplied fatal error handlers. If no user-supplied 193 handlers are configured or all of them return without taking action to 194 shutdown theprocessor or reset, a default fatal error handler is invoked.161 initialization the ``rtems_fatal_error_occurred`` directive supplied by the 162 Fatal Error Manager is invoked. The Fatal Error Manager will invoke the 163 user-supplied fatal error handlers. If no user-supplied handlers are 164 configured or all of them return without taking action to shutdown the 165 processor or reset, a default fatal error handler is invoked. 195 166 196 167 Most of the action performed as part of processing the fatal error are 197 described in detail in the Fatal Error Manager chapter in the User's 198 Guide. However, the if no user provided extension or BSP specific fatal 199 error handler takes action, the final default action is to invoke a 200 CPU architecture specific function. Typically this function disables 201 interrupts and halts the processor. 168 described in detail in the Fatal Error Manager chapter in the User's Guide. 169 However, the if no user provided extension or BSP specific fatal error handler 170 takes action, the final default action is to invoke a CPU architecture specific 171 function. Typically this function disables interrupts and halts the processor. 202 172 203 173 In each of the architecture specific chapters, this describes the precise … … 217 187 ====================== 218 188 219 An RTEMS Board Support Package (BSP) must be designed to support a 220 particular processor model and target board combination. 221 222 In each of the architecture specific chapters, this section will present 223 a discussion of architecture specific BSP issues. For more information 224 on developing a BSP, refer to BSP and Device Driver Development Guide 225 and the chapter titled Board Support Packages in the RTEMS 226 Applications User's Guide. 189 An RTEMS Board Support Package (BSP) must be designed to support a particular 190 processor model and target board combination. 191 192 In each of the architecture specific chapters, this section will present a 193 discussion of architecture specific BSP issues. For more information on 194 developing a BSP, refer to BSP and Device Driver Development Guide and the 195 chapter titled Board Support Packages in the RTEMS Applications User's Guide. 227 196 228 197 System Reset 229 198 ------------ 230 199 231 An RTEMS based application is initiated or re-initiated when the processor 232 is reset. 233 234 .. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved. 235 200 An RTEMS based application is initiated or re-initiated when the processor is 201 reset. -
cpu_supplement/m68xxx_and_coldfire.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved. 2 4 3 5 M68xxx and Coldfire Specific Information 4 6 ######################################## 5 7 6 This chapter discusses the Freescale (formerly Motorola) MC68xxx 7 and Coldfire architectural dependencies. The MC68xxx family has a 8 wide variety of CPU models within it based upon different CPU core 9 implementations. Ignoring the Coldfire parts, the part numbers for 10 these models are generally divided into MC680xx and MC683xx. The MC680xx 11 models are more general purpose processors with no integrated peripherals. 12 The MC683xx models, on the other hand, are more specialized and have a 13 variety of peripherals on chip including sophisticated timers and serial 14 communications controllers. 8 This chapter discusses the Freescale (formerly Motorola) MC68xxx and Coldfire 9 architectural dependencies. The MC68xxx family has a wide variety of CPU 10 models within it based upon different CPU core implementations. Ignoring the 11 Coldfire parts, the part numbers for these models are generally divided into 12 MC680xx and MC683xx. The MC680xx models are more general purpose processors 13 with no integrated peripherals. The MC683xx models, on the other hand, are 14 more specialized and have a variety of peripherals on chip including 15 sophisticated timers and serial communications controllers. 15 16 16 17 **Architecture Documents** 17 18 18 For information on the MC68xxx and Coldfire architecture, refer to the following documents available from Freescale website (:file:`http//www.freescale.com/`): 19 For information on the MC68xxx and Coldfire architecture, refer to the 20 following documents available from Freescale website 21 (http//www.freescale.com/): 19 22 20 23 - *M68000 Family Reference, Motorola, FR68K/D*. … … 28 31 ============================ 29 32 30 This section presents the set of features which vary 31 across m68k/Coldfire implementations that are of importance to RTEMS. 32 The set of CPU model feature macros are defined in the file``cpukit/score/cpu/m68k/m68k.h`` based upon the particular CPU 33 model selected on the compilation command line.33 This section presents the set of features which vary across m68k/Coldfire 34 implementations that are of importance to RTEMS. The set of CPU model feature 35 macros are defined in the file :file:`cpukit/score/cpu/m68k/m68k.h` based upon 36 the particular CPU model selected on the compilation command line. 34 37 35 38 BFFFO Instruction 36 39 ----------------- 37 40 38 The macro ``M68K_HAS_BFFFO`` is set to 1 to indicate that 39 th is CPU model has the bfffo instruction.41 The macro ``M68K_HAS_BFFFO`` is set to 1 to indicate that this CPU model has 42 the bfffo instruction. 40 43 41 44 Vector Base Register 42 45 -------------------- 43 46 44 The macro ``M68K_HAS_VBR`` is set to 1 to indicate that 45 this CPU model has avector base register (vbr).47 The macro ``M68K_HAS_VBR`` is set to 1 to indicate that this CPU model has a 48 vector base register (vbr). 46 49 47 50 Separate Stacks 48 51 --------------- 49 52 50 The macro ``M68K_HAS_SEPARATE_STACKS`` is set to 1 to 51 indicate that this CPU model has separate interrupt, user, and 52 supervisor mode stacks. 53 The macro ``M68K_HAS_SEPARATE_STACKS`` is set to 1 to indicate that this CPU 54 model has separate interrupt, user, and supervisor mode stacks. 53 55 54 56 Pre-Indexing Address Mode 55 57 ------------------------- 56 58 57 The macro ``M68K_HAS_PREINDEXING`` is set to 1 to indicate that 58 this CPU modelhas the pre-indexing address mode.59 The macro ``M68K_HAS_PREINDEXING`` is set to 1 to indicate that this CPU model 60 has the pre-indexing address mode. 59 61 60 62 Extend Byte to Long Instruction 61 63 ------------------------------- 62 64 63 The macro ``M68K_HAS_EXTB_L`` is set to 1 to indicate that this CPU model 64 has the extb.l instruction. This instruction is supposed to be available 65 in allmodels based on the cpu32 core as well as mc68020 and up models.65 The macro ``M68K_HAS_EXTB_L`` is set to 1 to indicate that this CPU model has 66 the extb.l instruction. This instruction is supposed to be available in all 67 models based on the cpu32 core as well as mc68020 and up models. 66 68 67 69 Calling Conventions 68 70 =================== 69 71 70 The MC68xxx architecture supports a simple yet effective call and 71 return mechanism. A subroutine is invoked via the branch to subroutine 72 (``bsr``) or the jump to subroutine (``jsr``) instructions. 73 These instructions push the return address on the current stack. 74 The return from subroutine (``rts``) instruction pops the return 75 address off the current stack and transfers control to that instruction. 76 It is is important to note that the MC68xxx call and return mechanism does 77 not automatically save or restore any registers. It is the responsibility 78 of the high-level language compiler to define the register preservation 79 and usage convention. 72 The MC68xxx architecture supports a simple yet effective call and return 73 mechanism. A subroutine is invoked via the branch to subroutine (``bsr``) or 74 the jump to subroutine (``jsr``) instructions. These instructions push the 75 return address on the current stack. The return from subroutine (``rts``) 76 instruction pops the return address off the current stack and transfers control 77 to that instruction. It is is important to note that the MC68xxx call and 78 return mechanism does not automatically save or restore any registers. It is 79 the responsibility of the high-level language compiler to define the register 80 preservation and usage convention. 80 81 81 82 Calling Mechanism 82 83 ----------------- 83 84 84 All RTEMS directives are invoked using either a ``bsr`` or ``jsr`` 85 instructionand return to the user application via the rts instruction.85 All RTEMS directives are invoked using either a ``bsr`` or ``jsr`` instruction 86 and return to the user application via the rts instruction. 86 87 87 88 Register Usage 88 89 -------------- 89 90 90 As discussed above, the ``bsr`` and ``jsr`` instructions do not 91 automatically save any registers. RTEMS uses the registers D0, D1, 92 A0, and A1 as scratch registers. These registers are not preserved by 93 RTEMS directives therefore, the contents of these registers should not 94 be assumed upon return from anyRTEMS directive.91 As discussed above, the ``bsr`` and ``jsr`` instructions do not automatically 92 save any registers. RTEMS uses the registers D0, D1, A0, and A1 as scratch 93 registers. These registers are not preserved by RTEMS directives therefore, 94 the contents of these registers should not be assumed upon return from any 95 RTEMS directive. 95 96 96 97 Parameter Passing 97 98 ----------------- 98 99 99 RTEMS assumes that arguments are placed on the current stack before 100 the directive is invoked via the bsr or jsr instruction. The first 101 argument is assumed to be closest to the return address on the stack. 102 This means that the first argument of the C calling sequence is pushed 103 last. The following pseudo-code illustrates the typical sequence used 104 to call a RTEMS directive with three (3) arguments: 105 .. code:: c 100 RTEMS assumes that arguments are placed on the current stack before the 101 directive is invoked via the bsr or jsr instruction. The first argument is 102 assumed to be closest to the return address on the stack. This means that the 103 first argument of the C calling sequence is pushed last. The following 104 pseudo-code illustrates the typical sequence used to call a RTEMS directive 105 with three (3) arguments: 106 107 .. code-block:: c 106 108 107 109 push third argument … … 112 114 113 115 The arguments to RTEMS are typically pushed onto the stack using a move 114 instruction with a pre-decremented stack pointer as the destination. 115 These arguments must be removed from the stack after control is returned 116 to the caller. This removal is typically accomplished by addingthe117 size of theargument list in bytes to the current stack pointer.116 instruction with a pre-decremented stack pointer as the destination. These 117 arguments must be removed from the stack after control is returned to the 118 caller. This removal is typically accomplished by adding the size of the 119 argument list in bytes to the current stack pointer. 118 120 119 121 Memory Model 120 122 ============ 121 123 122 The MC68xxx family supports a flat 32-bit address 123 space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 124 gigabytes). Each address is represented by a 32-bit value and 125 is byte addressable. The address may be used to reference a 126 single byte, word (2-bytes), or long word (4 bytes). Memory 127 accesses within this address space are performed in big endian 128 fashion by the processors in this family. 129 130 Some of the MC68xxx family members such as the 131 MC68020, MC68030, and MC68040 support virtual memory and 132 segmentation. The MC68020 requires external hardware support 133 such as the MC68851 Paged Memory Management Unit coprocessor 134 which is typically used to perform address translations for 135 these systems. RTEMS does not support virtual memory or 136 segmentation on any of the MC68xxx family members. 124 The MC68xxx family supports a flat 32-bit address space with addresses ranging 125 from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is represented by a 126 32-bit value and is byte addressable. The address may be used to reference a 127 single byte, word (2-bytes), or long word (4 bytes). Memory accesses within 128 this address space are performed in big endian fashion by the processors in 129 this family. 130 131 Some of the MC68xxx family members such as the MC68020, MC68030, and MC68040 132 support virtual memory and segmentation. The MC68020 requires external 133 hardware support such as the MC68851 Paged Memory Management Unit coprocessor 134 which is typically used to perform address translations for these systems. 135 RTEMS does not support virtual memory or segmentation on any of the MC68xxx 136 family members. 137 137 138 138 Interrupt Processing 139 139 ==================== 140 140 141 Discussed in this section are the MC68xxx's interrupt response and 142 controlmechanisms as they pertain to RTEMS.141 Discussed in this section are the MC68xxx's interrupt response and control 142 mechanisms as they pertain to RTEMS. 143 143 144 144 Vectoring of an Interrupt Handler 145 145 --------------------------------- 146 146 147 Depending on whether or not the particular CPU supports a separate 148 interrupt stack, the MC68xxx family has two different interrupt handling 149 models. 147 Depending on whether or not the particular CPU supports a separate interrupt 148 stack, the MC68xxx family has two different interrupt handling models. 150 149 151 150 Models Without Separate Interrupt Stacks … … 153 152 154 153 Upon receipt of an interrupt the MC68xxx family members without separate 155 interrupt stacks automatically perform the following actions: 156 157 - To Be Written 154 interrupt stacks automatically use software to switch stacks. 158 155 159 156 Models With Separate Interrupt Stacks 160 157 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 161 158 162 Upon receipt of an interrupt the MC68xxx family members with separate 163 interruptstacks automatically perform the following actions:159 Upon receipt of an interrupt the MC68xxx family members with separate interrupt 160 stacks automatically perform the following actions: 164 161 165 162 - saves the current status register (SR), 166 163 167 - clears the master/interrupt (M) bit of the SR to 168 indicate the switch frommaster state to interrupt state,164 - clears the master/interrupt (M) bit of the SR to indicate the switch from 165 master state to interrupt state, 169 166 170 167 - sets the privilege mode to supervisor, … … 172 169 - suppresses tracing, 173 170 174 - sets the interrupt mask level equal to the level of the 175 interrupt being serviced, 176 177 - pushes an interrupt stack frame (ISF), which includes 178 the program counter (PC), the status register (SR), and the 179 format/exception vector offset (FVO) word, onto the supervisor 180 and interrupt stacks, 181 182 - switches the current stack to the interrupt stack and 183 vectors to an interrupt service routine (ISR). If the ISR was 184 installed with the interrupt_catch directive, then the RTEMS 185 interrupt handler will begin execution. The RTEMS interrupt 186 handler saves all registers which are not preserved according to 171 - sets the interrupt mask level equal to the level of the interrupt being 172 serviced, 173 174 - pushes an interrupt stack frame (ISF), which includes the program counter 175 (PC), the status register (SR), and the format/exception vector offset (FVO) 176 word, onto the supervisor and interrupt stacks, 177 178 - switches the current stack to the interrupt stack and vectors to an interrupt 179 service routine (ISR). If the ISR was installed with the interrupt_catch 180 directive, then the RTEMS interrupt handler will begin execution. The RTEMS 181 interrupt handler saves all registers which are not preserved according to 187 182 the calling conventions and invokes the application's ISR. 188 183 189 A nested interrupt is processed similarly by these 190 CPU models with the exception that only a single ISF is placed 191 on the interrupt stack and the current stack need not be 192 switched. 193 194 The FVO word in the Interrupt Stack Frame is examined 195 by RTEMS to determine when an outer most interrupt is being 196 exited. Since the FVO is used by RTEMS for this purpose, the 197 user application code MUST NOT modify this field. 198 199 The following shows the Interrupt Stack Frame for 200 MC68xxx CPU models with separate interrupt stacks: 184 A nested interrupt is processed similarly by these CPU models with the 185 exception that only a single ISF is placed on the interrupt stack and the 186 current stack need not be switched. 187 188 The FVO word in the Interrupt Stack Frame is examined by RTEMS to determine 189 when an outer most interrupt is being exited. Since the FVO is used by RTEMS 190 for this purpose, the user application code MUST NOT modify this field. 191 192 The following shows the Interrupt Stack Frame for MC68xxx CPU models with 193 separate interrupt stacks: 201 194 202 195 +----------------------+-----+ … … 214 207 ----------------------------------- 215 208 216 This is from a post by Zoltan Kocsi <zoltan@bendor.com.au> and is 217 a nice trickin certain situations. In his words:218 219 I think somebody on this list asked about the interupt vector handling 220 w/o VBR and RAM at 0. The usual trick is to initialise the vector table221 (except the first 2 two entries, of course) to point to the same location 222 BUT you also add the vector number times 0x1000000 to them. That is, 223 bits 31-24 contain the vector number and 23-0 the address of the common 224 handler. Since the PC is 32 bit wide but the actual address bus is only 225 24, the top byte will be in the PC but will be ignored when jumping onto 226 your routine. 227 228 Then your common interrupt routine gets this info by loading the PC 229 into some register and based on that info, you can jump to a vector in 230 a vector table pointed by a virtual VBR: 231 .. code :: c209 This is from a post by Zoltan Kocsi <zoltan@bendor.com.au> and is a nice trick 210 in certain situations. In his words: 211 212 I think somebody on this list asked about the interupt vector handling w/o VBR 213 and RAM at 0. The usual trick is to initialise the vector table (except the 214 first 2 two entries, of course) to point to the same location BUT you also add 215 the vector number times 0x1000000 to them. That is, bits 31-24 contain the 216 vector number and 23-0 the address of the common handler. Since the PC is 32 217 bit wide but the actual address bus is only 24, the top byte will be in the PC 218 but will be ignored when jumping onto your routine. 219 220 Then your common interrupt routine gets this info by loading the PC into some 221 register and based on that info, you can jump to a vector in a vector table 222 pointed by a virtual VBR: 223 224 .. code-block:: c 232 225 233 226 // … … 248 241 // directly from the HW vector table at 0. 249 242 // 250 .comm VBR,4,2 // This defines the 'virtual' VBR251 // From C: extern void \*VBR;243 .comm VBR,4,2 // This defines the 'virtual' VBR 244 // From C: extern void *VBR; 252 245 myhandler: // At entry, PC contains the full vector 253 move.l %d0,-(%sp) // Save d0254 move.l %a0,-(%sp) // Save a0255 lea 0(%pc),%a0 // Get the value of the PC256 move.l %a0,%d0 // Copy it to a data reg, d0 is VV??????257 swap %d0 // Now d0 is ????VV??258 and.w #0xff00,%d0 // Now d0 is ????VV00 (1)259 lsr.w #6,%d0 // Now d0.w contains the VBR table offset260 move.l VBR,%a0 // Get the address from VBR to a0261 move.l (%a0,%d0.w),%a0 // Fetch the vector262 move.l 4(%sp),%d0 // Restore d0263 move.l %a0,4(%sp) // Place target address to the stack264 move.l (%sp)+,%a0 // Restore a0, target address is on TOS265 ret // This will jump to the handler and246 move.l %d0,-(%sp) // Save d0 247 move.l %a0,-(%sp) // Save a0 248 lea 0(%pc),%a0 // Get the value of the PC 249 move.l %a0,%d0 // Copy it to a data reg, d0 is VV?????? 250 swap %d0 // Now d0 is ????VV?? 251 and.w #0xff00,%d0 // Now d0 is ????VV00 (1) 252 lsr.w #6,%d0 // Now d0.w contains the VBR table offset 253 move.l VBR,%a0 // Get the address from VBR to a0 254 move.l (%a0,%d0.w),%a0 // Fetch the vector 255 move.l 4(%sp),%d0 // Restore d0 256 move.l %a0,4(%sp) // Place target address to the stack 257 move.l (%sp)+,%a0 // Restore a0, target address is on TOS 258 ret // This will jump to the handler and 266 259 // restore the stack 267 (1) If 'myhandler' is guaranteed to be in the first 64K, e.g. just 260 261 (1) If 'myhandler' is guaranteed to be in the first 64K, e.g. just 268 262 after the vector table then that insn is not needed. 269 263 270 There are probably shorter ways to do this, but it I believe is enough 271 to illustrate the trick. Optimisation is left as an exercise to the 272 reader :-) 264 There are probably shorter ways to do this, but it I believe is enough to 265 illustrate the trick. Optimisation is left as an exercise to the reader :-) 273 266 274 267 Interrupt Levels 275 268 ---------------- 276 269 277 Eight levels (0-7) of interrupt priorities are 278 supported by MC68xxx family members with level seven (7) being 279 the highest priority. Level zero (0) indicates that interrupts 280 are fully enabled. Interrupt requests for interrupts with 281 priorities less than or equal to the current interrupt mask 282 level are ignored. 283 284 Although RTEMS supports 256 interrupt levels, the 285 MC68xxx family only supports eight. RTEMS interrupt levels 0 286 through 7 directly correspond to MC68xxx interrupt levels. All 287 other RTEMS interrupt levels are undefined and their behavior is 288 unpredictable. 270 Eight levels (0-7) of interrupt priorities are supported by MC68xxx family 271 members with level seven (7) being the highest priority. Level zero (0) 272 indicates that interrupts are fully enabled. Interrupt requests for interrupts 273 with priorities less than or equal to the current interrupt mask level are 274 ignored. 275 276 Although RTEMS supports 256 interrupt levels, the MC68xxx family only supports 277 eight. RTEMS interrupt levels 0 through 7 directly correspond to MC68xxx 278 interrupt levels. All other RTEMS interrupt levels are undefined and their 279 behavior is unpredictable. 289 280 290 281 Default Fatal Error Processing … … 292 283 293 284 The default fatal error handler for this architecture disables processor 294 interrupts to level 7, places the error code in D0, and executes a``stop`` instruction to simulate a halt processor instruction. 285 interrupts to level 7, places the error code in D0, and executes a ``stop`` 286 instruction to simulate a halt processor instruction. 295 287 296 288 Symmetric Multiprocessing … … 311 303 312 304 An RTEMS based application is initiated or re-initiated when the MC68020 313 processor is reset. When the MC68020 is reset, the processor performs 314 the following actions: 315 316 - The tracing bits of the status register are cleared to 317 disable tracing. 318 319 - The supervisor interrupt state is entered by setting the 320 supervisor (S) bit and clearing the master/interrupt (M) bit of 321 the status register. 322 323 - The interrupt mask of the status register is set to 324 level 7 to effectively disable all maskable interrupts. 305 processor is reset. When the MC68020 is reset, the processor performs the 306 following actions: 307 308 - The tracing bits of the status register are cleared to disable tracing. 309 310 - The supervisor interrupt state is entered by setting the supervisor (S) bit 311 and clearing the master/interrupt (M) bit of the status register. 312 313 - The interrupt mask of the status register is set to level 7 to effectively 314 disable all maskable interrupts. 325 315 326 316 - The vector base register (VBR) is set to zero. 327 317 328 - The cache control register (CACR) is set to zero to 329 disable and freeze the processor cache. 330 331 - The interrupt stack pointer (ISP) is set to the value 332 stored at vector 0 (bytes 0-3) of the exception vector table 333 (EVT). 334 335 - The program counter (PC) is set to the value stored at 336 vector 1 (bytes 4-7) of the EVT. 337 338 - The processor begins execution at the address stored in 339 the PC. 318 - The cache control register (CACR) is set to zero to disable and freeze the 319 processor cache. 320 321 - The interrupt stack pointer (ISP) is set to the value stored at vector 0 322 (bytes 0-3) of the exception vector table (EVT). 323 324 - The program counter (PC) is set to the value stored at vector 1 (bytes 4-7) 325 of the EVT. 326 327 - The processor begins execution at the address stored in the PC. 340 328 341 329 Processor Initialization 342 330 ------------------------ 343 331 344 The address of the application's initialization code should be stored in 345 the first vector of the EVT which will allow the immediate vectoring to 346 the application code. If the application requires that the VBR be some 347 value besides zero, then it should be set to the required value at this 348 point. All tasks share the same MC68020's VBR value. Because interrupts 349 are enabled automatically by RTEMS as part of the context switch to the 350 first task, the VBR MUST be set by either RTEMS of the BSP before this 351 occurs ensure correct interrupt vectoring. If processor caching is 352 to be utilized, then it should be enabled during the reset application 353 initialization code. 354 355 In addition to the requirements described in the 356 Board Support Packages chapter of the Applications User's 357 Manual for the reset code which is executed before the call to 358 initialize executive, the MC68020 version has the following 332 The address of the application's initialization code should be stored in the 333 first vector of the EVT which will allow the immediate vectoring to the 334 application code. If the application requires that the VBR be some value 335 besides zero, then it should be set to the required value at this point. All 336 tasks share the same MC68020's VBR value. Because interrupts are enabled 337 automatically by RTEMS as part of the context switch to the first task, the VBR 338 MUST be set by either RTEMS of the BSP before this occurs ensure correct 339 interrupt vectoring. If processor caching is to be utilized, then it should be 340 enabled during the reset application initialization code. 341 342 In addition to the requirements described in the Board Support Packages chapter 343 of the Applications User's Manual for the reset code which is executed before 344 the call to initialize executive, the MC68020 version has the following 359 345 specific requirements: 360 346 361 - Must leave the S bit of the status register set so that 362 the MC68020 remains in the supervisor state. 363 364 - Must set the M bit of the status register to remove the 365 MC68020 from the interrupt state. 366 367 - Must set the master stack pointer (MSP) such that a 368 minimum stack size of MINIMUM_STACK_SIZE bytes is provided for 369 the initialize executive directive. 347 - Must leave the S bit of the status register set so that the MC68020 remains 348 in the supervisor state. 349 350 - Must set the M bit of the status register to remove the MC68020 from the 351 interrupt state. 352 353 - Must set the master stack pointer (MSP) such that a minimum stack size of 354 MINIMUM_STACK_SIZE bytes is provided for the initialize executive directive. 370 355 371 356 - Must initialize the MC68020's vector table. 372 373 .. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved.374 -
cpu_supplement/mips.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved. 2 4 3 5 MIPS Specific Information 4 6 ######################### 5 7 6 This chapter discusses the MIPS architecture dependencies 7 in this port of RTEMS. The MIPS family has a wide variety 8 of implementations by a wide range of vendors. Consequently, 9 there are many, many CPU models within it. 8 This chapter discusses the MIPS architecture dependencies in this port of 9 RTEMS. The MIPS family has a wide variety of implementations by a wide range 10 of vendors. Consequently, there are many, many CPU models within it. 10 11 11 12 **Architecture Documents** … … 13 14 IDT docs are online at http://www.idt.com/products/risc/Welcome.html 14 15 15 For information on the XXX architecture, refer to the following documents16 available from VENDOR (:file:`http//www.XXX.com/`):17 18 - *XXX Family Reference, VENDOR, PART NUMBER*.19 20 16 CPU Model Dependent Features 21 17 ============================ 22 18 23 This section presents the set of features which vary 24 across MIPS implementations and are of importance to RTEMS. 25 The set of CPU model feature macros are defined in the file``cpukit/score/cpu/mips/mips.h`` based upon the particular CPU 26 model specified on the compilation command line.19 This section presents the set of features which vary across MIPS 20 implementations and are of importance to RTEMS. The set of CPU model feature 21 macros are defined in the file ``cpukit/score/cpu/mips/mips.h`` based upon the 22 particular CPU model specified on the compilation command line. 27 23 28 24 Another Optional Feature … … 60 56 ----------------- 61 57 62 The MIPS family supports a flat 32-bit address 63 space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 64 gigabytes). Each address is represented by a 32-bit value and 65 is byte addressable. The address may be used to reference a 66 single byte, word (2-bytes), or long word (4 bytes). Memory 67 accesses within this address space are performed in big endian 68 fashion by the processors in this family. 58 The MIPS family supports a flat 32-bit address space with addresses ranging 59 from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is represented by a 60 32-bit value and is byte addressable. The address may be used to reference a 61 single byte, word (2-bytes), or long word (4 bytes). Memory accesses within 62 this address space are performed in big endian fashion by the processors in 63 this family. 69 64 70 65 Some of the MIPS family members such as the support virtual memory and 71 segmentation. RTEMS does not support virtual memory or 72 segmentation on any ofthese family members.66 segmentation. RTEMS does not support virtual memory or segmentation on any of 67 these family members. 73 68 74 69 Interrupt Processing 75 70 ==================== 76 71 77 Although RTEMS hides many of the processor dependent 78 details of interrupt processing, it is important to understand 79 how the RTEMS interrupt manager is mapped onto the processor's 80 unique architecture. Discussed in this chapter are the MIPS's 81 interrupt response and control mechanisms as they pertain to 82 RTEMS. 72 Although RTEMS hides many of the processor dependent details of interrupt 73 processing, it is important to understand how the RTEMS interrupt manager is 74 mapped onto the processor's unique architecture. Discussed in this chapter are 75 the MIPS's interrupt response and control mechanisms as they pertain to RTEMS. 83 76 84 77 Vectoring of an Interrupt Handler 85 78 --------------------------------- 86 79 87 Upon receipt of an interrupt the XXX family 88 members with separate interrupt stacks automatically perform the 89 following actions: 80 Upon receipt of an interrupt the XXX family members with separate interrupt 81 stacks automatically perform the following actions: 90 82 91 83 - TBD 92 84 93 A nested interrupt is processed similarly by these 94 CPU models with the exception that only a single ISF is placed 95 on the interrupt stack and the current stack need not be 96 switched. 85 A nested interrupt is processed similarly by these CPU models with the 86 exception that only a single ISF is placed on the interrupt stack and the 87 current stack need not be switched. 97 88 98 89 Interrupt Levels … … 104 95 ============================== 105 96 106 The default fatal error handler for this target architecture disables 107 processor interrupts, places the error code in *XXX*, and executes a``XXX`` instruction to simulate a halt processor instruction. 97 The default fatal error handler for this target architecture disables processor 98 interrupts, places the error code in *XXX*, and executes a``XXX`` instruction 99 to simulate a halt processor instruction. 108 100 109 101 Symmetric Multiprocessing … … 123 115 ------------ 124 116 125 An RTEMS based application is initiated or 126 re-initiated when the processor is reset. When the 127 processor is reset, it performs the following actions: 117 An RTEMS based application is initiated or re-initiated when the processor is 118 reset. When the processor is reset, it performs the following actions: 128 119 129 120 - TBD … … 133 124 134 125 TBD 135 136 .. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved.137 -
cpu_supplement/openrisc_1000.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1989-2007. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 OpenRISC 1000 Specific Information 4 8 ################################## 5 9 6 This chapter discusses the`OpenRISC 1000 architecture <http://opencores.org/or1k/Main_Page>`_7 dependencies in this port of RTEMS. There are many implementations 8 for OpenRISC like or1200 and mor1kx. Currently RTEMS supports basic 9 features that all implementations should have.10 This chapter discusses the`OpenRISC 1000 architecture 11 http://opencores.org/or1k/Main_Page dependencies in this port of RTEMS. There 12 are many implementations for OpenRISC like or1200 and mor1kx. Currently RTEMS 13 supports basic features that all implementations should have. 10 14 11 15 **Architecture Documents** 12 16 13 For information on the OpenRISC 1000 architecture refer to the`OpenRISC 1000 architecture manual <http://openrisc.github.io/or1k.html>`_. 17 For information on the OpenRISC 1000 architecture refer to the`OpenRISC 1000 18 architecture manual http://openrisc.github.io/or1k.html. 14 19 15 20 Calling Conventions 16 21 =================== 17 22 18 Please refer to the`Function Calling Sequence <http://openrisc.github.io/or1k.html#__RefHeading__504887_595890882>`_. 23 Please refer to the`Function Calling Sequence 24 http://openrisc.github.io/or1k.html#__RefHeading__504887_595890882. 19 25 20 26 Floating Point Unit … … 69 75 --------------- 70 76 71 The OpenRISC RTEMS port uses a dedicated software interrupt stack. 72 The stack for interrupts is allocated during interrupt driver initialization. 73 When an interrupt is entered, the _ISR_Handler routine is responsible for 74 switchingfrom the interrupted task stack to RTEMS software interrupt stack.77 The OpenRISC RTEMS port uses a dedicated software interrupt stack. The stack 78 for interrupts is allocated during interrupt driver initialization. When an 79 interrupt is entered, the _ISR_Handler routine is responsible for switching 80 from the interrupted task stack to RTEMS software interrupt stack. 75 81 76 82 Default Fatal Error Processing 77 83 ============================== 78 84 79 The default fatal error handler for this architecture performs the 80 followingactions:85 The default fatal error handler for this architecture performs the following 86 actions: 81 87 82 88 - disables operating system supported interrupts (IRQ), … … 90 96 91 97 SMP is not supported. 92 93 .. COMMENT: COPYRIGHT (c) 1989-2007.94 95 .. COMMENT: On-Line Applications Research Corporation (OAR).96 97 .. COMMENT: All rights reserved.98 -
cpu_supplement/port.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2002. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 Port Specific Information 4 8 ######################### 5 9 6 This chaper provides a general description of the type of 7 architecture specific information which is in each of 8 the architecture specific chapters that follow. The outline 9 of this chapter is identical to that of the architecture 10 specific chapters. 11 12 In each of the architecture specific chapters, this 13 introductory section will provide an overview of the 14 architecture 10 This chaper provides a general description of the type of architecture specific 11 information which is in each of the architecture specific chapters that follow. 12 The outline of this chapter is identical to that of the architecture specific 13 chapters. 14 15 In each of the architecture specific chapters, this introductory section will 16 provide an overview of the architecture: 15 17 16 18 **Architecture Documents** 17 19 18 In each of the architecture specific chapters, this 19 section will provide pointers on where to obtain 20 documentation. 20 In each of the architecture specific chapters, this section will provide 21 pointers on where to obtain documentation. 21 22 22 23 CPU Model Dependent Features 23 24 ============================ 24 25 25 Microprocessors are generally classified into families with a variety of 26 CPU models or implementations within that family. Within a processor 27 family, there is a high level of binary compatibility. This family 28 may be based on either an architectural specification or on maintaining 29 compatibility with a popular processor. Recent microprocessor families 30 such as the SPARC or PowerPC are based on an architectural specification 31 which is independent or any particular CPU model or implementation. 32 Older families such as the Motorola 68000 and the Intel x86 evolved as the 33 manufacturer strived to produce higher performance processor models which 34 maintained binary compatibility with older models. 35 36 RTEMS takes advantage of the similarity of the various models within a 37 CPU family. Although the models do vary in significant ways, the high 38 level of compatibility makes it possible to share the bulk of the CPU 39 dependent executive code across the entire family. Each processor family 40 supported by RTEMS has a list of features which vary between CPU models 41 within a family. For example, the most common model dependent feature 42 regardless of CPU family is the presence or absence of a floating point 43 unit or coprocessor. When defining the list of features present on a 44 particular CPU model, one simply notes that floating point hardware 45 is or is not present and defines a single constant appropriately. 46 Conditional compilation is utilized to include the appropriate source 47 code for this CPU model's feature set. It is important to note that 48 this means that RTEMS is thus compiled using the appropriate feature set 49 and compilation flags optimal for this CPU model used. The alternative 50 would be to generate a binary which would execute on all family members 51 using only the features which were always present. 52 53 The set of CPU model feature macros are defined in the file``cpukit/score/cpu/CPU/rtems/score/cpu.h`` based upon the GNU tools 54 multilib variant that is appropriate for the particular CPU model defined 55 on the compilation command line. 56 57 In each of the architecture specific chapters, this section presents 58 the set of features which vary across various implementations of the 59 architecture that may be of importance to RTEMS application developers. 60 61 The subsections will vary amongst the target architecture chapters as 62 the specific features may vary. However, each port will include a few 63 common features such as the CPU Model Name and presence of a hardware 64 Floating Point Unit. The common features are described here. 26 Microprocessors are generally classified into families with a variety of CPU 27 models or implementations within that family. Within a processor family, there 28 is a high level of binary compatibility. This family may be based on either an 29 architectural specification or on maintaining compatibility with a popular 30 processor. Recent microprocessor families such as the SPARC or PowerPC are 31 based on an architectural specification which is independent or any particular 32 CPU model or implementation. Older families such as the Motorola 68000 and the 33 Intel x86 evolved as the manufacturer strived to produce higher performance 34 processor models which maintained binary compatibility with older models. 35 36 RTEMS takes advantage of the similarity of the various models within a CPU 37 family. Although the models do vary in significant ways, the high level of 38 compatibility makes it possible to share the bulk of the CPU dependent 39 executive code across the entire family. Each processor family supported by 40 RTEMS has a list of features which vary between CPU models within a family. 41 For example, the most common model dependent feature regardless of CPU family 42 is the presence or absence of a floating point unit or coprocessor. When 43 defining the list of features present on a particular CPU model, one simply 44 notes that floating point hardware is or is not present and defines a single 45 constant appropriately. Conditional compilation is utilized to include the 46 appropriate source code for this CPU model's feature set. It is important to 47 note that this means that RTEMS is thus compiled using the appropriate feature 48 set and compilation flags optimal for this CPU model used. The alternative 49 would be to generate a binary which would execute on all family members using 50 only the features which were always present. 51 52 The set of CPU model feature macros are defined in the 53 :file:`cpukit/score/cpu/CPU/rtems/score/cpu.h` based upon the GNU tools 54 multilib variant that is appropriate for the particular CPU model defined on 55 the compilation command line. 56 57 In each of the architecture specific chapters, this section presents the set of 58 features which vary across various implementations of the architecture that may 59 be of importance to RTEMS application developers. 60 61 The subsections will vary amongst the target architecture chapters as the 62 specific features may vary. However, each port will include a few common 63 features such as the CPU Model Name and presence of a hardware Floating Point 64 Unit. The common features are described here. 65 65 66 66 CPU Model Name 67 67 -------------- 68 68 69 The macro ``CPU_MODEL_NAME`` is a string which designates 70 the name of this CPU model. For example, for the MC68020 71 processor model from the m68k architecture, this macro 72 is set to the string "mc68020". 69 The macro ``CPU_MODEL_NAME`` is a string which designates the name of this CPU 70 model. For example, for the MC68020 processor model from the m68k 71 architecture, this macro is set to the string "mc68020". 73 72 74 73 Floating Point Unit 75 74 ------------------- 76 75 77 In most architectures, the presence of a floating point unit is an option. 78 It does not matter whether the hardware floating point support is 79 incorporated on-chip or is an external coprocessor as long as it 80 appears an FPU per the ISA. However, if a hardware FPU is not present, 81 it is possible that the floating point emulation library for this 82 CPU is not reentrant and thus context switchedby RTEMS.76 In most architectures, the presence of a floating point unit is an option. It 77 does not matter whether the hardware floating point support is incorporated 78 on-chip or is an external coprocessor as long as it appears an FPU per the ISA. 79 However, if a hardware FPU is not present, it is possible that the floating 80 point emulation library for this CPU is not reentrant and thus context switched 81 by RTEMS. 83 82 84 83 RTEMS provides two feature macros to indicate the FPU configuration: … … 88 87 89 88 - CPU_SOFTWARE_FP 90 is set to TRUE to indicate that a hardware FPU is not present and that 91 the FPsoftware emulation will be context switched.89 is set to TRUE to indicate that a hardware FPU is not present and that the FP 90 software emulation will be context switched. 92 91 93 92 Multilibs 94 93 ========= 95 94 96 Newlib and GCC provide several target libraries like the :file:`libc.a`,:file:`libm.a` and :file:`libgcc.a`. These libraries are artifacts of the GCC 95 Newlib and GCC provide several target libraries like the :file:`libc.a`, 96 :file:`libm.a` and :file:`libgcc.a`. These libraries are artifacts of the GCC 97 97 build process. Newlib is built together with GCC. To provide optimal support 98 98 for various chip derivatives and instruction set revisions multiple variants of … … 111 111 Invoking the GCC with the ``-print-multi-lib`` option lists the available 112 112 multilibs. Each line of the output describes one multilib variant. The 113 default variant is denoted by ``.`` which is selected when no or 114 contradicting GCC machine options are selected. The multilib selection for a 115 target is specified by target makefile fragments (see file :file:`t-rtems` in 116 the GCC sources and section`The Target Makefile Fragment <https://gcc.gnu.org/onlinedocs/gccint/Target-Fragment.html#Target-Fragment>`_ 117 in the `GCC Internals Manual <https://gcc.gnu.org/onlinedocs/gccint/>`_. 113 default variant is denoted by ``.`` which is selected when no or contradicting 114 GCC machine options are selected. The multilib selection for a target is 115 specified by target makefile fragments (see file :file:`t-rtems` in the GCC 116 sources and section *The Target Makefile Fragment* 117 (https://gcc.gnu.org/onlinedocs/gccint/Target-Fragment.html#Target-Fragment) 118 in the *GCC Internals Manual* (https://gcc.gnu.org/onlinedocs/gccint/). 118 119 119 120 Calling Conventions 120 121 =================== 121 122 122 Each high-level language compiler generates subroutine entry and exit 123 code based upon a set of rules known as the compiler's calling convention. 124 Theserules address the following issues:123 Each high-level language compiler generates subroutine entry and exit code 124 based upon a set of rules known as the compiler's calling convention. These 125 rules address the following issues: 125 126 126 127 - register preservation and usage … … 130 131 - call and return mechanism 131 132 132 A compiler's calling convention is of importance when 133 interfacing to subroutines written in another language either 134 assembly or high-level. Even when the high-level language and 135 target processor are the same, different compilers may use 136 different calling conventions. As a result, calling conventions 137 are both processor and compiler dependent. 133 A compiler's calling convention is of importance when interfacing to 134 subroutines written in another language either assembly or high-level. Even 135 when the high-level language and target processor are the same, different 136 compilers may use different calling conventions. As a result, calling 137 conventions are both processor and compiler dependent. 138 138 139 139 Calling Mechanism 140 140 ----------------- 141 141 142 In each of the architecture specific chapters, this subsection will 143 describe the instruction(s) used to perform a *normal* subroutine 144 invocation. All RTEMS directives are invoked as *normal* C language 145 functions so it is important to the user application to understand the 146 call and return mechanism. 142 In each of the architecture specific chapters, this subsection will describe 143 the instruction(s) used to perform a *normal* subroutine invocation. All RTEMS 144 directives are invoked as *normal* C language functions so it is important to 145 the user application to understand the call and return mechanism. 147 146 148 147 Register Usage 149 148 -------------- 150 149 151 In each of the architecture specific chapters, this subsection will 152 detail the set of registers which are *NOT* preserved across subroutine153 invocations. The registers which are not preserved are assumed to be 154 available for use as scratch registers. Therefore, the contents of these155 registers should not beassumed upon return from any RTEMS directive.150 In each of the architecture specific chapters, this subsection will detail the 151 set of registers which are *NOT* preserved across subroutine invocations. The 152 registers which are not preserved are assumed to be available for use as 153 scratch registers. Therefore, the contents of these registers should not be 154 assumed upon return from any RTEMS directive. 156 155 157 156 In some architectures, there may be a set of registers made available 158 automatically as a side-effect of the subroutine invocation 159 mechanism. 157 automatically as a side-effect of the subroutine invocation mechanism. 160 158 161 159 Parameter Passing 162 160 ----------------- 163 161 164 In each of the architecture specific chapters, this subsection will 165 describe the mechanism by which the parameters or arguments are passed 166 by the caller to a subroutine. In some architectures, all parameters 167 are passed on the stackwhile in others some are passed in registers.162 In each of the architecture specific chapters, this subsection will describe 163 the mechanism by which the parameters or arguments are passed by the caller to 164 a subroutine. In some architectures, all parameters are passed on the stack 165 while in others some are passed in registers. 168 166 169 167 User-Provided Routines 170 168 ---------------------- 171 169 172 All user-provided routines invoked by RTEMS, such as 173 user extensions, device drivers, and MPCI routines, must also 174 adhere to these calling conventions. 170 All user-provided routines invoked by RTEMS, such as user extensions, device 171 drivers, and MPCI routines, must also adhere to these calling conventions. 175 172 176 173 Memory Model 177 174 ============ 178 175 179 A processor may support any combination of memory 180 models ranging from pure physical addressing to complex demand 181 paged virtual memory systems. RTEMS supports a flat memory 182 model which ranges contiguously over the processor's allowable 183 address space. RTEMS does not support segmentation or virtual 184 memory of any kind. The appropriate memory model for RTEMS 185 provided by the targeted processor and related characteristics 186 of that model are described in this chapter. 176 A processor may support any combination of memory models ranging from pure 177 physical addressing to complex demand paged virtual memory systems. RTEMS 178 supports a flat memory model which ranges contiguously over the processor's 179 allowable address space. RTEMS does not support segmentation or virtual memory 180 of any kind. The appropriate memory model for RTEMS provided by the targeted 181 processor and related characteristics of that model are described in this 182 chapter. 187 183 188 184 Flat Memory Model … … 190 186 191 187 Most RTEMS target processors can be initialized to support a flat address 192 space. Although the size of addresses varies between architectures, on 193 most RTEMS targets, an address is 32-bits wide which defines addresses 194 ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is 195 represented by a 32-bit value and is byte addressable. The address may be 196 used to reference a single byte, word (2-bytes), or long word (4 bytes). 197 Memory accesses within this address space may be performed in little or 198 big endian fashion. 199 200 On smaller CPU architectures supported by RTEMS, the address space 201 may only be 20 or 24 bits wide. 202 203 If the CPU model has support for virtual memory or segmentation, it is 204 the responsibility of the Board Support Package (BSP) to initialize the 205 MMU hardware to perform address translations which correspond to flat 206 memory model. 207 208 In each of the architecture specific chapters, this subsection will 209 describe any architecture characteristics that differ from this general 210 description. 188 space. Although the size of addresses varies between architectures, on most 189 RTEMS targets, an address is 32-bits wide which defines addresses ranging from 190 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is represented by a 191 32-bit value and is byte addressable. The address may be used to reference a 192 single byte, word (2-bytes), or long word (4 bytes). Memory accesses within 193 this address space may be performed in little or big endian fashion. 194 195 On smaller CPU architectures supported by RTEMS, the address space may only be 196 20 or 24 bits wide. 197 198 If the CPU model has support for virtual memory or segmentation, it is the 199 responsibility of the Board Support Package (BSP) to initialize the MMU 200 hardware to perform address translations which correspond to flat memory model. 201 202 In each of the architecture specific chapters, this subsection will describe 203 any architecture characteristics that differ from this general description. 211 204 212 205 Interrupt Processing 213 206 ==================== 214 207 215 Different types of processors respond to the occurrence of an interrupt 216 in its own unique fashion. In addition, each processor type provides 217 a control mechanism to allow for the proper handling of an interrupt. 218 The processor dependent response to the interrupt modifies the current 219 execution state and results in a change in the execution stream. Most 220 processors require that an interrupt handler utilize some special control 221 mechanisms to return to the normal processing stream. Although RTEMS 222 hides many of the processor dependent details of interrupt processing, 223 it is important to understand how the RTEMS interrupt manager is mapped 224 onto the processor's unique architecture. 225 226 RTEMS supports a dedicated interrupt stack for all architectures. 227 On architectures with hardware support for a dedicated interrupt stack, 228 it will be initialized such that when an interrupt occurs, the processor 229 automatically switches to this dedicated stack. On architectures without 230 hardware support for a dedicated interrupt stack which is separate from 231 those of the tasks, RTEMS will support switching to a dedicated stack 232 for interrupt processing. 233 234 Without a dedicated interrupt stack, every task in 235 the system MUST have enough stack space to accommodate the worst 236 case stack usage of that particular task and the interrupt 237 service routines COMBINED. By supporting a dedicated interrupt 238 stack, RTEMS significantly lowers the stack requirements for 239 each task. 240 241 A nested interrupt is processed similarly with the exception that since 242 the CPU is already executing on the interrupt stack, there is no need 243 to switch to the interrupt stack. 244 245 In some configurations, RTEMS allocates the interrupt stack from the 246 Workspace Area. The amount of memory allocated for the interrupt stack 247 is user configured and based upon the ``confdefs.h`` parameter``CONFIGURE_INTERRUPT_STACK_SIZE``. This parameter is described 248 in detail in the Configuring a System chapter of the User's Guide. 249 On configurations in which RTEMS allocates the interrupt stack, during 250 the initialization process, RTEMS will also install its interrupt stack. 251 In other configurations, the interrupt stack is allocated and installed 252 by the Board Support Package (BSP). 253 254 In each of the architecture specific chapters, this section discesses 255 the interrupt response and control mechanisms of the architecture as 256 they pertain to RTEMS. 208 Different types of processors respond to the occurrence of an interrupt in its 209 own unique fashion. In addition, each processor type provides a control 210 mechanism to allow for the proper handling of an interrupt. The processor 211 dependent response to the interrupt modifies the current execution state and 212 results in a change in the execution stream. Most processors require that an 213 interrupt handler utilize some special control mechanisms to return to the 214 normal processing stream. Although RTEMS hides many of the processor dependent 215 details of interrupt processing, it is important to understand how the RTEMS 216 interrupt manager is mapped onto the processor's unique architecture. 217 218 RTEMS supports a dedicated interrupt stack for all architectures. On 219 architectures with hardware support for a dedicated interrupt stack, it will be 220 initialized such that when an interrupt occurs, the processor automatically 221 switches to this dedicated stack. On architectures without hardware support 222 for a dedicated interrupt stack which is separate from those of the tasks, 223 RTEMS will support switching to a dedicated stack for interrupt processing. 224 225 Without a dedicated interrupt stack, every task in the system MUST have enough 226 stack space to accommodate the worst case stack usage of that particular task 227 and the interrupt service routines COMBINED. By supporting a dedicated 228 interrupt stack, RTEMS significantly lowers the stack requirements for each 229 task. 230 231 A nested interrupt is processed similarly with the exception that since the CPU 232 is already executing on the interrupt stack, there is no need to switch to the 233 interrupt stack. 234 235 In some configurations, RTEMS allocates the interrupt stack from the Workspace 236 Area. The amount of memory allocated for the interrupt stack is user 237 configured and based upon the ``confdefs.h`` parameter 238 ``CONFIGURE_INTERRUPT_STACK_SIZE``. This parameter is described in detail in 239 the Configuring a System chapter of the User's Guide. On configurations in 240 which RTEMS allocates the interrupt stack, during the initialization process, 241 RTEMS will also install its interrupt stack. In other configurations, the 242 interrupt stack is allocated and installed by the Board Support Package (BSP). 243 244 In each of the architecture specific chapters, this section discesses the 245 interrupt response and control mechanisms of the architecture as they pertain 246 to RTEMS. 257 247 258 248 Vectoring of an Interrupt Handler 259 249 --------------------------------- 260 250 261 In each of the architecture specific chapters, this subsection will 262 describe the architecture specific details of the interrupt vectoring 263 process. In particular, it should include a description of the 264 Interrupt Stack Frame (ISF). 251 In each of the architecture specific chapters, this subsection will describe 252 the architecture specific details of the interrupt vectoring process. In 253 particular, it should include a description of the Interrupt Stack Frame (ISF). 265 254 266 255 Interrupt Levels 267 256 ---------------- 268 257 269 In each of the architecture specific chapters, this subsection will 270 describe how the interrupt levels available on this particular architecture 271 are mapped onto the 255 reserved in the task mode. The interrupt level 272 value of zero (0)should always mean that interrupts are enabled.273 274 Any use of an 258 In each of the architecture specific chapters, this subsection will describe 259 how the interrupt levels available on this particular architecture are mapped 260 onto the 255 reserved in the task mode. The interrupt level value of zero (0) 261 should always mean that interrupts are enabled. 262 263 Any use of an interrupt level that is is not undefined on a particular 275 264 architecture may result in behavior that is unpredictable. 276 265 … … 278 267 -------------------------------- 279 268 280 During the execution of directive calls, critical sections of code may 281 be executed. When these sections are encountered, RTEMS disables all 282 external interrupts before the execution of this section and restores 283 them to the previous level upon completion of the section. RTEMS has 284 been optimized to ensure that interrupts are disabled for the shortest 285 number of instructions possible. Since the precise number of instructions 286 and their execution time varies based upon target CPU family, CPU model, 287 board memory speed, compiler version, and optimization level, it is 288 not practical to provide the precise number for all possible RTEMS 289 configurations. 290 291 Historically, the measurements were made by hand analyzing and counting 292 the execution time of instruction sequences during interrupt disable 293 critical sections. For reference purposes, on a 16 Mhz Motorola 294 MC68020, the maximum interrupt disable period was typically approximately 295 ten (10) to thirteen (13) microseconds. This architecture was memory bound 296 and had a slow bit scan instruction. In contrast, during the same 297 period a 14 Mhz SPARC would have a worst case disable time of approximately 298 two (2) to three (3) microseconds because it had a single cycle bit scan 299 instruction and used fewer cycles for memory accesses. 300 301 If you are interested in knowing the worst case execution time for 302 a particular version of RTEMS, please contact OAR Corporation and 303 we will be happy to product the results as a consulting service. 304 305 Non-maskable interrupts (NMI) cannot be disabled, and 306 ISRs which execute at this level MUST NEVER issue RTEMS system 307 calls. If a directive is invoked, unpredictable results may 308 occur due to the inability of RTEMS to protect its critical 309 sections. However, ISRs that make no system calls may safely 310 execute as non-maskable interrupts. 269 During the execution of directive calls, critical sections of code may be 270 executed. When these sections are encountered, RTEMS disables all external 271 interrupts before the execution of this section and restores them to the 272 previous level upon completion of the section. RTEMS has been optimized to 273 ensure that interrupts are disabled for the shortest number of instructions 274 possible. Since the precise number of instructions and their execution time 275 varies based upon target CPU family, CPU model, board memory speed, compiler 276 version, and optimization level, it is not practical to provide the precise 277 number for all possible RTEMS configurations. 278 279 Historically, the measurements were made by hand analyzing and counting the 280 execution time of instruction sequences during interrupt disable critical 281 sections. For reference purposes, on a 16 Mhz Motorola MC68020, the maximum 282 interrupt disable period was typically approximately ten (10) to thirteen (13) 283 microseconds. This architecture was memory bound and had a slow bit scan 284 instruction. In contrast, during the same period a 14 Mhz SPARC would have a 285 worst case disable time of approximately two (2) to three (3) microseconds 286 because it had a single cycle bit scan instruction and used fewer cycles for 287 memory accesses. 288 289 If you are interested in knowing the worst case execution time for a particular 290 version of RTEMS, please contact OAR Corporation and we will be happy to 291 product the results as a consulting service. 292 293 Non-maskable interrupts (NMI) cannot be disabled, and ISRs which execute at 294 this level MUST NEVER issue RTEMS system calls. If a directive is invoked, 295 unpredictable results may occur due to the inability of RTEMS to protect its 296 critical sections. However, ISRs that make no system calls may safely execute 297 as non-maskable interrupts. 311 298 312 299 Default Fatal Error Processing … … 314 301 315 302 Upon detection of a fatal error by either the application or RTEMS during 316 initialization the ``rtems_fatal_error_occurred`` directive supplied 317 by the Fatal Error Manager is invoked. The Fatal Error Manager will 318 invoke the user-supplied fatal error handlers. If no user-supplied 319 handlers are configured or all of them return without taking action to 320 shutdown theprocessor or reset, a default fatal error handler is invoked.303 initialization the ``rtems_fatal_error_occurred`` directive supplied by the 304 Fatal Error Manager is invoked. The Fatal Error Manager will invoke the 305 user-supplied fatal error handlers. If no user-supplied handlers are 306 configured or all of them return without taking action to shutdown the 307 processor or reset, a default fatal error handler is invoked. 321 308 322 309 Most of the action performed as part of processing the fatal error are 323 described in detail in the Fatal Error Manager chapter in the User's 324 Guide. However, the if no user provided extension or BSP specific fatal 325 error handler takes action, the final default action is to invoke a 326 CPU architecture specific function. Typically this function disables 327 interrupts and halts the processor. 310 described in detail in the Fatal Error Manager chapter in the User's Guide. 311 However, the if no user provided extension or BSP specific fatal error handler 312 takes action, the final default action is to invoke a CPU architecture specific 313 function. Typically this function disables interrupts and halts the processor. 328 314 329 315 In each of the architecture specific chapters, this describes the precise … … 341 327 In order to support thread-local storage (TLS) the CPU port must implement the 342 328 facilities mandated by the application binary interface (ABI) of the CPU 343 architecture. The CPU port must initialize the TLS area in the``_CPU_Context_Initialize()`` function. There are support functions available 329 architecture. The CPU port must initialize the TLS area in the 330 ``_CPU_Context_Initialize()`` function. There are support functions available 344 331 via ``#include <rtems/score/tls.h>`` which implement Variants I and II 345 332 according to Ulrich Drepper, *ELF Handling For Thread-Local Storage*. 346 333 347 334 ``_TLS_TCB_at_area_begin_initialize()`` 348 Uses Variant I, TLS offsets emitted by linker takes the TCB into account. For349 a reference implementation see :file:`cpukit/score/cpu/arm/cpu.c`.335 Uses Variant I, TLS offsets emitted by linker takes the TCB into account. 336 For a reference implementation see :file:`cpukit/score/cpu/arm/cpu.c`. 350 337 351 338 ``_TLS_TCB_before_TLS_block_initialize()`` 352 339 Uses Variant I, TLS offsets emitted by linker neglects the TCB. For a 353 reference implementation see:file:`c/src/lib/libcpu/powerpc/new-exceptions/cpu.c`. 340 reference implementation see 341 :file:`c/src/lib/libcpu/powerpc/new-exceptions/cpu.c`. 354 342 355 343 ``_TLS_TCB_after_TLS_block_initialize()`` 356 Uses Variant II. For a reference implementation see:file:`cpukit/score/cpu/sparc/cpu.c`. 344 Uses Variant II. For a reference implementation see 345 :file:`cpukit/score/cpu/sparc/cpu.c`. 357 346 358 347 The board support package (BSP) must provide the following sections and symbols 359 348 in its linker command file: 360 .. code:: c 349 350 .. code-block:: c 361 351 362 352 .tdata : { 363 _TLS_Data_begin = .;364 \*(.tdata .tdata.* .gnu.linkonce.td.*)365 _TLS_Data_end = .;353 _TLS_Data_begin = .; 354 *(.tdata .tdata.* .gnu.linkonce.td.*) 355 _TLS_Data_end = .; 366 356 } 367 357 .tbss : { 368 _TLS_BSS_begin = .;369 \*(.tbss .tbss.* .gnu.linkonce.tb.*) \*(.tcommon)370 _TLS_BSS_end = .;358 _TLS_BSS_begin = .; 359 *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) 360 _TLS_BSS_end = .; 371 361 } 372 362 _TLS_Data_size = _TLS_Data_end - _TLS_Data_begin; … … 384 374 or system bus clock. On some architectures the actual implementation is board 385 375 support package dependent. The CPU counter is used for profiling of low-level 386 functions. It is also used to implement two busy wait functions``rtems_counter_delay_ticks()`` and ``rtems_counter_delay_nanoseconds()`` 387 which may be used in device drivers. It may be also used as an entropy source 388 for random number generators. 389 390 The CPU counter interface uses a CPU port specific unsigned integer type``CPU_Counter_ticks`` to represent CPU counter values. The CPU port must 376 functions. It is also used to implement two busy wait functions 377 ``rtems_counter_delay_ticks()`` and ``rtems_counter_delay_nanoseconds()`` which 378 may be used in device drivers. It may be also used as an entropy source for 379 random number generators. 380 381 The CPU counter interface uses a CPU port specific unsigned integer type 382 ``CPU_Counter_ticks`` to represent CPU counter values. The CPU port must 391 383 provide the following two functions 392 384 … … 401 393 The RTEMS profiling needs support by the CPU port for the interrupt entry and 402 394 exit times. In case profiling is enabled via the RTEMS build configuration 403 option ``--enable-profiling`` (in this case the pre-processor symbol``RTEMS_PROFILING`` is defined) the CPU port may provide data for the 404 interrupt entry and exit times of the outer-most interrupt. The CPU port can 405 feed interrupt entry and exit times with the``_Profiling_Outer_most_interrupt_entry_and_exit()`` function 406 (``#include <rtems/score/profiling.h>``). For an example please have a look 407 at ``cpukit/score/cpu/arm/arm_exc_interrupt.S``. 395 option ``--enable-profiling`` (in this case the pre-processor symbol 396 ``RTEMS_PROFILING`` is defined) the CPU port may provide data for the interrupt 397 entry and exit times of the outer-most interrupt. The CPU port can feed 398 interrupt entry and exit times with the 399 ``_Profiling_Outer_most_interrupt_entry_and_exit()`` function (``#include 400 <rtems/score/profiling.h>``). For an example please have a look at 401 :file:`cpukit/score/cpu/arm/arm_exc_interrupt.S`. 408 402 409 403 Board Support Packages 410 404 ====================== 411 405 412 An RTEMS Board Support Package (BSP) must be designed to support a 413 particular processor model and target board combination. 414 415 In each of the architecture specific chapters, this section will present 416 a discussion of architecture specific BSP issues. For more information 417 on developing a BSP, refer to BSP and Device Driver Development Guide 418 and the chapter titled Board Support Packages in the RTEMS 419 Applications User's Guide. 406 An RTEMS Board Support Package (BSP) must be designed to support a particular 407 processor model and target board combination. 408 409 In each of the architecture specific chapters, this section will present a 410 discussion of architecture specific BSP issues. For more information on 411 developing a BSP, refer to BSP and Device Driver Development Guide and the 412 chapter titled Board Support Packages in the RTEMS Applications User's Guide. 420 413 421 414 System Reset 422 415 ------------ 423 416 424 An RTEMS based application is initiated or re-initiated when the processor 425 is reset or transfer is passed to it from a boot monitor or ROM monitor. 426 427 In each of the architecture specific chapters, this subsection describes 428 the actions that the BSP must tak assuming the application gets control 429 when the microprocessor is reset. 430 431 .. COMMENT: COPYRIGHT (c) 1988-2002. 432 433 .. COMMENT: On-Line Applications Research Corporation (OAR). 434 435 .. COMMENT: All rights reserved. 436 417 An RTEMS based application is initiated or re-initiated when the processor is 418 reset or transfer is passed to it from a boot monitor or ROM monitor. 419 420 In each of the architecture specific chapters, this subsection describes the 421 actions that the BSP must tak assuming the application gets control when the 422 microprocessor is reset. -
cpu_supplement/powerpc.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2002. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 PowerPC Specific Information 4 8 ############################ 5 9 6 This chapter discusses the PowerPC architecture dependencies 7 in this port of RTEMS. The PowerPC family has a wide variety 8 of implementations by a range of vendors. Consequently, 9 there are many, many CPU models within it. 10 11 It is highly recommended that the PowerPC RTEMS 12 application developer obtain and become familiar with the 13 documentation for the processor being used as well as the 14 specification for the revision of the PowerPC architecture which 10 This chapter discusses the PowerPC architecture dependencies in this port of 11 RTEMS. The PowerPC family has a wide variety of implementations by a range of 12 vendors. Consequently, there are many, many CPU models within it. 13 14 It is highly recommended that the PowerPC RTEMS application developer obtain 15 and become familiar with the documentation for the processor being used as well 16 as the specification for the revision of the PowerPC architecture which 15 17 corresponds to that processor. 16 18 17 19 **PowerPC Architecture Documents** 18 20 19 For information on the PowerPC architecture, refer to 20 the following documentsavailable from Motorola and IBM:21 For information on the PowerPC architecture, refer to the following documents 22 available from Motorola and IBM: 21 23 22 24 - *PowerPC Microprocessor Family: The Programming Environment* … … 43 45 (Motorola Document MPC821UM/AD). 44 46 45 - *PowerQUICC MPC860 User's Manual* (Motorola Document MPC860UM/AD). 46 47 Motorola maintains an on-line electronic library for the PowerPC 48 at the following URL: 47 - *PowerQUICC MPC860 User's Manual* 48 (Motorola Document MPC860UM/AD). 49 50 Motorola maintains an on-line electronic library for the PowerPC at the 51 following URL: 49 52 50 53 - http://www.mot.com/powerpc/library/library.html 51 54 52 This site has a a wealth of information and examples. Many of the 53 manuals areavailable from that site in electronic format.55 This site has a a wealth of information and examples. Many of the manuals are 56 available from that site in electronic format. 54 57 55 58 **PowerPC Processor Simulator Information** 56 59 57 PSIM is a program which emulates the Instruction Set Architecture 58 of the PowerPC microprocessor family. It is reely available in source 59 code form under the terms of the GNU General Public License (version 60 2 or later). PSIM can be integrated with the GNU Debugger (gdb) to 61 execute and debug PowerPC executables on non-PowerPC hosts. PSIM 62 supports the addition of user provided device models which can be 63 used to allow one to develop and debug embedded applications using 64 the simulator. 65 66 The latest version of PSIM is included in GDB and enabled on pre-built 67 binaries provided by the RTEMS Project. 60 PSIM is a program which emulates the Instruction Set Architecture of the 61 PowerPC microprocessor family. It is reely available in source code form under 62 the terms of the GNU General Public License (version 2 or later). PSIM can be 63 integrated with the GNU Debugger (gdb) to execute and debug PowerPC executables 64 on non-PowerPC hosts. PSIM supports the addition of user provided device 65 models which can be used to allow one to develop and debug embedded 66 applications using the simulator. 67 68 The latest version of PSIM is included in GDB and enabled on pre-built binaries 69 provided by the RTEMS Project. 68 70 69 71 CPU Model Dependent Features 70 72 ============================ 71 73 72 This section presents the set of features which vary 73 across PowerPC implementations and are of importance to RTEMS. 74 The set of CPU model feature macros are defined in the file``cpukit/score/cpu/powerpc/powerpc.h`` based upon the particular CPU 75 model specified on the compilation command line.74 This section presents the set of features which vary across PowerPC 75 implementations and are of importance to RTEMS. The set of CPU model feature 76 macros are defined in the file ``cpukit/score/cpu/powerpc/powerpc.h`` based 77 upon the particular CPU model specified on the compilation command line. 76 78 77 79 Alignment … … 79 81 80 82 The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment 81 requirement for data types on a byte boundary. This value is used 82 to derive the alignment restrictions for memory allocated from 83 regions and partitions. 83 requirement for data types on a byte boundary. This value is used to derive 84 the alignment restrictions for memory allocated from regions and partitions. 84 85 85 86 Cache Alignment 86 87 --------------- 87 88 88 The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is 89 used to align the entry point of critical routines so that as much code90 as possible can be retrieved with the initial read into cache. This 91 i s done for the interrupt handler as well as the context switch routines.89 The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is used 90 to align the entry point of critical routines so that as much code as possible 91 can be retrieved with the initial read into cache. This is done for the 92 interrupt handler as well as the context switch routines. 92 93 93 94 In addition, the "shortcut" data structure used by the PowerPC implementation … … 98 99 ------------------ 99 100 100 The macro PPC_INTERRUPT_MAX is set to the number of exception sources 101 supportedby this PowerPC model.101 The macro PPC_INTERRUPT_MAX is set to the number of exception sources supported 102 by this PowerPC model. 102 103 103 104 Has Double Precision Floating Point 104 105 ----------------------------------- 105 106 106 The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model 107 has support for double precision floating point numbers. This is 108 important because the floating point registers need only be four bytes 109 wide (not eight) if doubleprecision is not supported.107 The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model has 108 support for double precision floating point numbers. This is important because 109 the floating point registers need only be four bytes wide (not eight) if double 110 precision is not supported. 110 111 111 112 Critical Interrupts 112 113 ------------------- 113 114 114 The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model 115 has theCritical Interrupt capability as defined by the IBM 403 models.115 The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model has the 116 Critical Interrupt capability as defined by the IBM 403 models. 116 117 117 118 Use Multiword Load/Store Instructions … … 119 120 120 121 The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and 121 store instructions should be used to perform context switch operations. 122 The relative efficiency of multiword load and store instructions versus 123 an equivalent set of single word load and store instructions varies based 124 upon thePowerPC model.122 store instructions should be used to perform context switch operations. The 123 relative efficiency of multiword load and store instructions versus an 124 equivalent set of single word load and store instructions varies based upon the 125 PowerPC model. 125 126 126 127 Instruction Cache Size … … 137 138 ----------- 138 139 139 The macro PPC_DEBUG_MODEL is set to indicate the debug support features 140 present in this CPU model. The following debug support feature sets 141 are currentlysupported:140 The macro PPC_DEBUG_MODEL is set to indicate the debug support features present 141 in this CPU model. The following debug support feature sets are currently 142 supported: 142 143 143 144 *``PPC_DEBUG_MODEL_STANDARD``* 144 indicates that the single-step trace enable (SE) and branch trace 145 enable(BE) bits in the MSR are supported by this CPU model.145 indicates that the single-step trace enable (SE) and branch trace enable 146 (BE) bits in the MSR are supported by this CPU model. 146 147 147 148 *``PPC_DEBUG_MODEL_SINGLE_STEP_ONLY``* 148 indicates that only the single-step trace enable (SE) bit in the MSR 149 issupported by this CPU model.149 indicates that only the single-step trace enable (SE) bit in the MSR is 150 supported by this CPU model. 150 151 151 152 *``PPC_DEBUG_MODEL_IBM4xx``* 152 153 indicates that the debug exception enable (DE) bit in the MSR is supported 153 by this CPU model. At this time, this particular debug feature set 154 hasonly been seen in the IBM 4xx series.154 by this CPU model. At this time, this particular debug feature set has 155 only been seen in the IBM 4xx series. 155 156 156 157 Low Power Model 157 158 ~~~~~~~~~~~~~~~ 158 159 159 The macro PPC_LOW_POWER_MODE is set to indicate the low power model 160 supported by this CPU model. The following low power modes are currently 161 supported. 160 The macro PPC_LOW_POWER_MODE is set to indicate the low power model supported 161 by this CPU model. The following low power modes are currently supported. 162 162 163 163 *``PPC_LOW_POWER_MODE_NONE``* … … 165 165 166 166 *``PPC_LOW_POWER_MODE_STANDARD``* 167 indicates that this CPU model follows the low power model defined for 168 thePPC603e.167 indicates that this CPU model follows the low power model defined for the 168 PPC603e. 169 169 170 170 Multilibs … … 216 216 =================== 217 217 218 RTEMS supports the Embedded Application Binary Interface (EABI) 219 c alling convention. Documentation for EABI is available by sending220 a message with asubject line of "EABI" to eabi@goth.sis.mot.com.218 RTEMS supports the Embedded Application Binary Interface (EABI) calling 219 convention. Documentation for EABI is available by sending a message with a 220 subject line of "EABI" to eabi@goth.sis.mot.com. 221 221 222 222 Programming Model 223 223 ----------------- 224 224 225 This section discusses the programming model for the 226 PowerPC architecture. 225 This section discusses the programming model for the PowerPC architecture. 227 226 228 227 Non-Floating Point Registers … … 236 235 These registers are referred to as ``gpr0`` to ``gpr31``. 237 236 238 Some of the registers serve defined roles in the EABI programming model. 239 The following table describes the role of each of these registers: 240 .. code:: c 241 242 +---------------+----------------+------------------------------+ 243 | Register Name | Alternate Name | Description | 244 +---------------+----------------+------------------------------+ 245 | r1 | sp | stack pointer | 246 +---------------+----------------+------------------------------+ 247 | | | global pointer to the Small | 248 | r2 | na | Constant Area (SDA2) | 249 +---------------+----------------+------------------------------+ 250 | r3 - r12 | na | parameter and result passing | 251 +---------------+----------------+------------------------------+ 252 | | | global pointer to the Small | 253 | r13 | na | Data Area (SDA) | 254 +---------------+----------------+------------------------------+ 237 Some of the registers serve defined roles in the EABI programming model. The 238 following table describes the role of each of these registers: 239 240 +---------------+----------------+------------------------------+ 241 | Register Name | Alternate Name | Description | 242 +---------------+----------------+------------------------------+ 243 | r1 | sp | stack pointer | 244 +---------------+----------------+------------------------------+ 245 | | | global pointer to the Small | 246 | r2 | na | Constant Area (SDA2) | 247 +---------------+----------------+------------------------------+ 248 | r3 - r12 | na | parameter and result passing | 249 +---------------+----------------+------------------------------+ 250 | | | global pointer to the Small | 251 | r13 | na | Data Area (SDA) | 252 +---------------+----------------+------------------------------+ 255 253 256 254 Floating Point Registers 257 255 ~~~~~~~~~~~~~~~~~~~~~~~~ 258 256 259 The PowerPC architecture includes thirty-two, sixty-four bit 260 floating point registers. All PowerPC floating point instructions261 interpret these registers as 32 double precision floating point registers, 262 regardless of whether theprocessor has 64-bit or 32-bit implementation.263 264 The floating point status and control register (fpscr) records exceptions 265 and the type of result generated by floating-point operations. 266 Additionally, it controls the rounding mode of operations and allows the 267 reporting of floatingexceptions to be enabled or disabled.257 The PowerPC architecture includes thirty-two, sixty-four bit floating point 258 registers. All PowerPC floating point instructions interpret these registers 259 as 32 double precision floating point registers, regardless of whether the 260 processor has 64-bit or 32-bit implementation. 261 262 The floating point status and control register (fpscr) records exceptions and 263 the type of result generated by floating-point operations. Additionally, it 264 controls the rounding mode of operations and allows the reporting of floating 265 exceptions to be enabled or disabled. 268 266 269 267 Special Registers 270 268 ~~~~~~~~~~~~~~~~~ 271 269 272 The PowerPC architecture includes a number of special registers 273 which arecritical to the programming model:270 The PowerPC architecture includes a number of special registers which are 271 critical to the programming model: 274 272 275 273 *Machine State Register* 276 274 The MSR contains the processor mode, power management mode, endian mode, 277 275 exception information, privilege level, floating point available and 278 floating point excepiton mode, address translation information and 279 theexception prefix.276 floating point excepiton mode, address translation information and the 277 exception prefix. 280 278 281 279 *Link Register* 282 280 The LR contains the return address after a function call. This register 283 must be saved before a subsequent subroutine call can be made. The 284 use of this register is discussed further in the *Call and Return285 Mechanism*section below.281 must be saved before a subsequent subroutine call can be made. The use of 282 this register is discussed further in the *Call and Return Mechanism* 283 section below. 286 284 287 285 *Count Register* 288 The CTR contains the iteration variable for some loops. It may also be used289 for indirect function calls and jumps.286 The CTR contains the iteration variable for some loops. It may also be 287 used for indirect function calls and jumps. 290 288 291 289 Call and Return Mechanism 292 290 ------------------------- 293 291 294 The PowerPC architecture supports a simple yet effective call 295 and return mechanism. A subroutine is invoked 296 via the "branch and link" (``bl``) and 297 "brank and link absolute" (``bla``) 298 instructions. This instructions place the return address 299 in the Link Register (LR). The callee returns to the caller by 300 executing a "branch unconditional to the link register" (``blr``) 301 instruction. Thus the callee returns to the caller via a jump 302 to the return address which is stored in the LR. 303 304 The previous contents of the LR are not automatically saved 305 by either the ``bl`` or ``bla``. It is the responsibility 306 of the callee to save the contents of the LR before invoking 307 another subroutine. If the callee invokes another subroutine, 308 it must restore the LR before executing the ``blr`` instruction 309 to return to the caller. 310 311 It is important to note that the PowerPC subroutine 312 call and return mechanism does not automatically save and 313 restore any registers. 314 315 The LR may be accessed as special purpose register 8 (``SPR8``) using the 316 "move from special register" (``mfspr``) and 317 "move to special register" (``mtspr``) instructions. 292 The PowerPC architecture supports a simple yet effective call and return 293 mechanism. A subroutine is invoked via the "branch and link" (``bl``) and 294 "brank and link absolute" (``bla``) instructions. This instructions place the 295 return address in the Link Register (LR). The callee returns to the caller by 296 executing a "branch unconditional to the link register" (``blr``) instruction. 297 Thus the callee returns to the caller via a jump to the return address which is 298 stored in the LR. 299 300 The previous contents of the LR are not automatically saved by either the 301 ``bl`` or ``bla``. It is the responsibility of the callee to save the contents 302 of the LR before invoking another subroutine. If the callee invokes another 303 subroutine, it must restore the LR before executing the ``blr`` instruction to 304 return to the caller. 305 306 It is important to note that the PowerPC subroutine call and return mechanism 307 does not automatically save and restore any registers. 308 309 The LR may be accessed as special purpose register 8 (``SPR8``) using the "move 310 from special register" (``mfspr``) and "move to special register" (``mtspr``) 311 instructions. 318 312 319 313 Calling Mechanism 320 314 ----------------- 321 315 322 All RTEMS directives are invoked using the regular 323 PowerPC EABI callingconvention via the ``bl`` or``bla`` instructions.316 All RTEMS directives are invoked using the regular PowerPC EABI calling 317 convention via the ``bl`` or``bla`` instructions. 324 318 325 319 Register Usage 326 320 -------------- 327 321 328 As discussed above, the call instruction does not 329 automatically save any registers. It is the responsibility 330 of the callee to save and restore any registers which must be preserved 331 across subroutine calls. The callee is responsible for saving 332 callee-preserved registers to the program stack and restoring them 333 before returning to the caller. 322 As discussed above, the call instruction does not automatically save any 323 registers. It is the responsibility of the callee to save and restore any 324 registers which must be preserved across subroutine calls. The callee is 325 responsible for saving callee-preserved registers to the program stack and 326 restoring them before returning to the caller. 334 327 335 328 Parameter Passing 336 329 ----------------- 337 330 338 RTEMS assumes that arguments are placed in the 339 general purpose registers with the first argument in 340 register 3 (``r3``), the second argument in general purpose 341 register 4 (``r4``), and so forth until the seventh 342 argument is in general purpose register 10 (``r10``). 343 If there are more than seven arguments, then subsequent arguments 344 are placed on the program stack. The following pseudo-code 345 illustrates the typical sequence used to call a RTEMS directive 331 RTEMS assumes that arguments are placed in the general purpose registers with 332 the first argument in register 3 (``r3``), the second argument in general 333 purpose register 4 (``r4``), and so forth until the seventh argument is in 334 general purpose register 10 (``r10``). If there are more than seven arguments, 335 then subsequent arguments are placed on the program stack. The following 336 pseudo-code illustrates the typical sequence used to call a RTEMS directive 346 337 with three (3) arguments: 347 .. code:: c 338 339 .. code-block:: c 348 340 349 341 load third argument into r5 … … 358 350 ----------------- 359 351 360 The PowerPC architecture supports a variety of memory models. 361 RTEMS supports the PowerPC using a flat memory model with 362 paging disabled. In this mode, the PowerPC automatically 363 converts every address from a logical to a physical address 364 each time it is used. The PowerPC uses information provided 365 in the Block Address Translation (BAT) to convert these addresses. 366 367 Implementations of the PowerPC architecture may be thirty-two or sixty-four bit. 368 The PowerPC architecture supports a flat thirty-two or sixty-four bit address 369 space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 370 gigabytes) in thirty-two bit implementations or to 0xFFFFFFFFFFFFFFFF 371 in sixty-four bit implementations. Each address is represented 372 by either a thirty-two bit or sixty-four bit value and is byte addressable. 373 The address may be used to reference a single byte, half-word 374 (2-bytes), word (4 bytes), or in sixty-four bit implementations a 375 doubleword (8 bytes). Memory accesses within the address space are 376 performed in big or little endian fashion by the PowerPC based 377 upon the current setting of the Little-endian mode enable bit (LE) 378 in the Machine State Register (MSR). While the processor is in 379 big endian mode, memory accesses which are not properly aligned 380 generate an "alignment exception" (vector offset 0x00600). In 381 little endian mode, the PowerPC architecture does not require 382 the processor to generate alignment exceptions. 383 384 The following table lists the alignment requirements for a variety 385 of data accesses: 386 387 .. code:: c 388 389 +--------------+-----------------------+ 390 | Data Type | Alignment Requirement | 391 +--------------+-----------------------+ 392 | byte | 1 | 393 | half-word | 2 | 394 | word | 4 | 395 | doubleword | 8 | 396 +--------------+-----------------------+ 397 398 Doubleword load and store operations are only available in 399 PowerPC CPU models which are sixty-four bit implementations. 400 401 RTEMS does not directly support any PowerPC Memory Management 402 Units, therefore, virtual memory or segmentation systems 403 involving the PowerPC are not supported. 404 405 .. COMMENT: COPYRIGHT (c) 1989-2007. 406 407 .. COMMENT: On-Line Applications Research Corporation (OAR). 408 409 .. COMMENT: All rights reserved. 352 The PowerPC architecture supports a variety of memory models. RTEMS supports 353 the PowerPC using a flat memory model with paging disabled. In this mode, the 354 PowerPC automatically converts every address from a logical to a physical 355 address each time it is used. The PowerPC uses information provided in the 356 Block Address Translation (BAT) to convert these addresses. 357 358 Implementations of the PowerPC architecture may be thirty-two or sixty-four 359 bit. The PowerPC architecture supports a flat thirty-two or sixty-four bit 360 address space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 361 gigabytes) in thirty-two bit implementations or to 0xFFFFFFFFFFFFFFFF in 362 sixty-four bit implementations. Each address is represented by either a 363 thirty-two bit or sixty-four bit value and is byte addressable. The address 364 may be used to reference a single byte, half-word (2-bytes), word (4 bytes), or 365 in sixty-four bit implementations a doubleword (8 bytes). Memory accesses 366 within the address space are performed in big or little endian fashion by the 367 PowerPC based upon the current setting of the Little-endian mode enable bit 368 (LE) in the Machine State Register (MSR). While the processor is in big endian 369 mode, memory accesses which are not properly aligned generate an "alignment 370 exception" (vector offset 0x00600). In little endian mode, the PowerPC 371 architecture does not require the processor to generate alignment exceptions. 372 373 The following table lists the alignment requirements for a variety of data 374 accesses: 375 376 +--------------+-----------------------+ 377 | Data Type | Alignment Requirement | 378 +--------------+-----------------------+ 379 | byte | 1 | 380 | half-word | 2 | 381 | word | 4 | 382 | doubleword | 8 | 383 +--------------+-----------------------+ 384 385 Doubleword load and store operations are only available in PowerPC CPU models 386 which are sixty-four bit implementations. 387 388 RTEMS does not directly support any PowerPC Memory Management Units, therefore, 389 virtual memory or segmentation systems involving the PowerPC are not supported. 410 390 411 391 Interrupt Processing 412 392 ==================== 413 393 414 Although RTEMS hides many of the processor dependent 415 details of interrupt processing, it is important to understand 416 how the RTEMS interrupt manager is mapped onto the processor's 417 unique architecture. Discussed in this chapter are the PowerPC's 418 interrupt response and control mechanisms as they pertain to 394 Although RTEMS hides many of the processor dependent details of interrupt 395 processing, it is important to understand how the RTEMS interrupt manager is 396 mapped onto the processor's unique architecture. Discussed in this chapter are 397 the PowerPC's interrupt response and control mechanisms as they pertain to 419 398 RTEMS. 420 399 421 RTEMS and associated documentation uses the terms interrupt and vector. 422 In the PowerPC architecture, these terms correspond to exception and 423 exception handler, respectively. The terms will be used interchangeably 424 in this manual. 400 RTEMS and associated documentation uses the terms interrupt and vector. In the 401 PowerPC architecture, these terms correspond to exception and exception 402 handler, respectively. The terms will be used interchangeably in this manual. 425 403 426 404 Synchronous Versus Asynchronous Exceptions 427 405 ------------------------------------------ 428 406 429 In the PowerPC architecture exceptions can be either precise or 430 imprecise and either synchronous or asynchronous. Asynchronous 431 exceptions occur when an external event interrupts the processor. 432 Synchronous exceptions are caused by the actions of an 433 instruction. During an exception SRR0 is used to calculate where 434 instruction processing should resume. All instructions prior to 435 the resume instruction will have completed execution. SRR1 is used to 436 store the machine status. 437 438 There are two asynchronous nonmaskable, highest-priority exceptions 439 system reset and machine check. There are two asynchrononous maskable 440 low-priority exceptions external interrupt and decrementer. Nonmaskable 441 execptions are never delayed, therefore if two nonmaskable, asynchronous 442 exceptions occur in immediate succession, the state information saved by 443 the first exception may be overwritten when the subsequent exception occurs. 444 445 The PowerPC arcitecure defines one imprecise exception, the imprecise 446 floating point enabled exception. All other synchronous exceptions are 447 precise. The synchronization occuring during asynchronous precise 448 exceptions conforms to the requirements for context synchronization. 407 In the PowerPC architecture exceptions can be either precise or imprecise and 408 either synchronous or asynchronous. Asynchronous exceptions occur when an 409 external event interrupts the processor. Synchronous exceptions are caused by 410 the actions of an instruction. During an exception SRR0 is used to calculate 411 where instruction processing should resume. All instructions prior to the 412 resume instruction will have completed execution. SRR1 is used to store the 413 machine status. 414 415 There are two asynchronous nonmaskable, highest-priority exceptions system 416 reset and machine check. There are two asynchrononous maskable low-priority 417 exceptions external interrupt and decrementer. Nonmaskable execptions are 418 never delayed, therefore if two nonmaskable, asynchronous exceptions occur in 419 immediate succession, the state information saved by the first exception may be 420 overwritten when the subsequent exception occurs. 421 422 The PowerPC arcitecure defines one imprecise exception, the imprecise floating 423 point enabled exception. All other synchronous exceptions are precise. The 424 synchronization occuring during asynchronous precise exceptions conforms to the 425 requirements for context synchronization. 449 426 450 427 Vectoring of Interrupt Handler … … 456 433 - an instruction address is loaded into SRR0 457 434 458 - bits 33-36 and 42-47 of SRR1 are loaded with information 459 specific to theexception.460 461 - bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding 462 bits fromthe MSR.435 - bits 33-36 and 42-47 of SRR1 are loaded with information specific to the 436 exception. 437 438 - bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding bits from 439 the MSR. 463 440 464 441 - the MSR is set based upon the exception type. 465 442 466 - instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type.467 468 If the interrupt handler was installed as an RTEMS 469 interrupt handler, then upon receipt of the interrupt, the 470 processor passes control to the RTEMS interrupt handler which 471 performs the following actions:443 - instruction fetch and execution resumes, using the new MSR value, at a 444 location specific to the execption type. 445 446 If the interrupt handler was installed as an RTEMS interrupt handler, then upon 447 receipt of the interrupt, the processor passes control to the RTEMS interrupt 448 handler which performs the following actions: 472 449 473 450 - saves the state of the interrupted task on it's stack, 474 451 475 - saves all registers which are not normally preserved 476 by the calling sequence so the user's interrupt service 477 routine can be written in a high-level language. 478 479 - if this is the outermost (i.e. non-nested) interrupt, 480 then the RTEMS interrupt handler switches from the current stack 481 to the interrupt stack, 452 - saves all registers which are not normally preserved by the calling sequence 453 so the user's interrupt service routine can be written in a high-level 454 language. 455 456 - if this is the outermost (i.e. non-nested) interrupt, then the RTEMS 457 interrupt handler switches from the current stack to the interrupt stack, 482 458 483 459 - enables exceptions, … … 485 461 - invokes the vectors to a user interrupt service routine (ISR). 486 462 487 Asynchronous interrupts are ignored while exceptions are 488 disabled. Synchronous interrupts which occur while are 489 disabled result in the CPU being forced into an error mode. 490 491 A nested interrupt is processed similarly with the 492 exception that the current stack need not be switched to the 493 interrupt stack. 463 Asynchronous interrupts are ignored while exceptions are disabled. Synchronous 464 interrupts which occur while are disabled result in the CPU being forced into 465 an error mode. 466 467 A nested interrupt is processed similarly with the exception that the current 468 stack need not be switched to the interrupt stack. 494 469 495 470 Interrupt Levels 496 471 ---------------- 497 472 498 The PowerPC architecture supports only a single external 499 asynchronous interrupt source. This interrupt source 500 may be enabled and disabled via the External Interrupt Enable (EE) 501 bit in the Machine State Register (MSR). Thus only two level (enabled 502 and disabled) of external device interrupt priorities are 473 The PowerPC architecture supports only a single external asynchronous interrupt 474 source. This interrupt source may be enabled and disabled via the External 475 Interrupt Enable (EE) bit in the Machine State Register (MSR). Thus only two 476 level (enabled and disabled) of external device interrupt priorities are 503 477 directly supported by the PowerPC architecture. 504 478 505 Some PowerPC implementations include a Critical Interrupt capability 506 which is often used to receive interrupts from high priority external 507 devices. 508 509 The RTEMS interrupt level mapping scheme for the PowerPC is not 510 a numeric level as on most RTEMS ports. It is a bit mapping in 511 which the least three significiant bits of the interrupt level 512 are mapped directly to the enabling of specific interrupt 513 sources as follows: 479 Some PowerPC implementations include a Critical Interrupt capability which is 480 often used to receive interrupts from high priority external devices. 481 482 The RTEMS interrupt level mapping scheme for the PowerPC is not a numeric level 483 as on most RTEMS ports. It is a bit mapping in which the least three 484 significiant bits of the interrupt level are mapped directly to the enabling of 485 specific interrupt sources as follows: 514 486 515 487 *Critical Interrupt* 516 Setting bit 0 (the least significant bit) of the interrupt level 517 enables the Critical Interrupt source, if it is available on this 518 CPU model. 488 Setting bit 0 (the least significant bit) of the interrupt level enables 489 the Critical Interrupt source, if it is available on this CPU model. 519 490 520 491 *Machine Check* … … 529 500 ============================== 530 501 531 The default fatal error handler for this architecture performs the 532 followingactions:502 The default fatal error handler for this architecture performs the following 503 actions: 533 504 534 505 - places the error code in r3, and … … 559 530 ------------ 560 531 561 An RTEMS based application is initiated or 562 re-initiated when the PowerPC processor is reset. The PowerPC 563 architecture defines a Reset Exception, but leaves the 564 details of the CPU state as implementation specific. Please 565 refer to the User's Manual for the CPU model in question. 566 567 In general, at power-up the PowerPC begin execution at address 568 0xFFF00100 in supervisor mode with all exceptions disabled. For 569 soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100 570 depending upon the setting of the Exception Prefix bit in the MSR. 571 If during a soft reset, a Machine Check Exception occurs, then the 572 CPU may execute a hard reset. 532 An RTEMS based application is initiated or re-initiated when the PowerPC 533 processor is reset. The PowerPC architecture defines a Reset Exception, but 534 leaves the details of the CPU state as implementation specific. Please refer 535 to the User's Manual for the CPU model in question. 536 537 In general, at power-up the PowerPC begin execution at address 0xFFF00100 in 538 supervisor mode with all exceptions disabled. For soft resets, the CPU will 539 vector to either 0xFFF00100 or 0x00000100 depending upon the setting of the 540 Exception Prefix bit in the MSR. If during a soft reset, a Machine Check 541 Exception occurs, then the CPU may execute a hard reset. 573 542 574 543 Processor Initialization 575 544 ------------------------ 576 545 577 If this PowerPC implementation supports on-chip caching 578 and this is to be utilized, then it should be enabled during the 579 reset application initialization code. On-chip caching has been 580 observed to prevent some emulators from working properly, so it 581 may be necessary to run with caching disabled to use these emulators. 582 583 In addition to the requirements described in the*Board Support Packages* chapter of the RTEMS C 584 Applications User's Manual for the reset code 585 which is executed before the call to ``rtems_initialize_executive``, 586 the PowrePC version has the following specific requirements: 587 588 - Must leave the PR bit of the Machine State Register (MSR) set 589 to 0 so the PowerPC remains in the supervisor state. 590 591 - Must set stack pointer (sp or r1) such that a minimum stack 592 size of MINIMUM_STACK_SIZE bytes is provided for the RTEMS initialization 593 sequence. 594 595 - Must disable all external interrupts (i.e. clear the EI (EE) 596 bit of the machine state register). 597 598 - Must enable traps so window overflow and underflow 599 conditions can be properly handled. 600 601 - Must initialize the PowerPC's initial Exception Table with default 602 handlers. 603 604 .. COMMENT: COPYRIGHT (c) 1988-2002. 605 606 .. COMMENT: On-Line Applications Research Corporation (OAR). 607 608 .. COMMENT: All rights reserved. 609 546 If this PowerPC implementation supports on-chip caching and this is to be 547 utilized, then it should be enabled during the reset application initialization 548 code. On-chip caching has been observed to prevent some emulators from working 549 properly, so it may be necessary to run with caching disabled to use these 550 emulators. 551 552 In addition to the requirements described in the*Board Support Packages* 553 chapter of the RTEMS C Applications User's Manual for the reset code which is 554 executed before the call to ``rtems_initialize_executive``, the PowrePC version 555 has the following specific requirements: 556 557 - Must leave the PR bit of the Machine State Register (MSR) set to 0 so the 558 PowerPC remains in the supervisor state. 559 560 - Must set stack pointer (sp or r1) such that a minimum stack size of 561 MINIMUM_STACK_SIZE bytes is provided for the RTEMS initialization sequence. 562 563 - Must disable all external interrupts (i.e. clear the EI (EE) bit of the 564 machine state register). 565 566 - Must enable traps so window overflow and underflow conditions can be properly 567 handled. 568 569 - Must initialize the PowerPC's initial Exception Table with default handlers. -
cpu_supplement/preface.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2002. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 ======= … … 5 9 ======= 6 10 11 The Real Time Executive for Multiprocessor Systems (RTEMS) is designed to be 12 portable across multiple processor architectures. However, the nature of 13 real-time systems makes it essential that the application designer understand 14 certain processor dependent implementation details. These processor 15 dependencies include calling convention, board support package issues, 16 interrupt processing, exact RTEMS memory requirements, performance data, header 17 files, and the assembly language interface to the executive. 7 18 8 The Real Time Executive for Multiprocessor Systems 9 (RTEMS) is designed to be portable across multiple processor 10 architectures. However, the nature of real-time systems makes 11 it essential that the application designer understand certain 12 processor dependent implementation details. These processor 13 dependencies include calling convention, board support package 14 issues, interrupt processing, exact RTEMS memory requirements, 15 performance data, header files, and the assembly language 16 interface to the executive. 19 Each architecture represents a CPU family and usually there are a wide variety 20 of CPU models within it. These models share a common Instruction Set 21 Architecture (ISA) which often varies based upon some well-defined rules. 22 There are often multiple implementations of the ISA and these may be from one 23 or multiple vendors. 17 24 18 Each architecture represents a CPU family and usually there are 19 a wide variety of CPU models within it. These models share a 20 common Instruction Set Architecture (ISA) which often varies 21 based upon some well-defined rules. There are often 22 multiple implementations of the ISA and these may be from 23 one or multiple vendors. 25 On top of variations in the ISA, there may also be variations which occur when 26 a CPU core implementation is combined with a set of peripherals to form a 27 system on chip. For example, there are many ARM CPU models from numerous 28 semiconductor vendors and a wide variety of peripherals. But at the ISA level, 29 they share a common compatibility. 24 30 25 On top of variations in the ISA, there may also be variations 26 which occur when a CPU core implementation is combined with 27 a set of peripherals to form a system on chip. For example, 28 there are many ARM CPU models from numerous semiconductor 29 vendors and a wide variety of peripherals. But at the 30 ISA level, they share a common compatibility. 31 RTEMS depends upon this core similarity across the CPU models and leverages 32 that to minimize the source code that is specific to any particular CPU core 33 implementation or CPU model. 31 34 32 RTEMS depends upon this core similarity across the CPU models 33 and leverages that to minimize the source code that is specific 34 to any particular CPU core implementation or CPU model. 35 This manual is separate and distinct from the RTEMS Porting Guide. That manual 36 is a guide on porting RTEMS to a new architecture. This manual is focused on 37 the more mundane CPU architecture specific issues that may impact application 38 development. For example, if you need to write a subroutine in assembly 39 language, it is critical to understand the calling conventions for the target 40 architecture. 35 41 36 This manual is separate and distinct from the RTEMS Porting 37 Guide. That manual is a guide on porting RTEMS to a new 38 architecture. This manual is focused on the more mundane 39 CPU architecture specific issues that may impact 40 application development. For example, if you need to write 41 a subroutine in assembly language, it is critical to understand 42 the calling conventions for the target architecture. 43 44 The first chapter in this manual describes these issues 45 in general terms. In a sense, it is posing the questions 46 one should be aware may need to be answered and understood 47 when porting an RTEMS application to a new architecture. 48 Each subsequent chapter gives the answers to those questions 49 for a particular CPU architecture. 50 51 .. COMMENT: COPYRIGHT (c) 1988-2002. 52 53 .. COMMENT: On-Line Applications Research Corporation (OAR). 54 55 .. COMMENT: All rights reserved. 56 42 The first chapter in this manual describes these issues in general terms. In a 43 sense, it is posing the questions one should be aware may need to be answered 44 and understood when porting an RTEMS application to a new architecture. Each 45 subsequent chapter gives the answers to those questions for a particular CPU 46 architecture. -
cpu_supplement/renesas_m32c.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2002. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 Renesas M32C Specific Information … … 13 17 14 18 Thread-local storage is not implemented. 15 16 .. COMMENT: COPYRIGHT (c) 1988-2002.17 18 .. COMMENT: On-Line Applications Research Corporation (OAR).19 20 .. COMMENT: All rights reserved.21 -
cpu_supplement/sparc.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2002. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 SPARC Specific Information 4 8 ########################## 5 9 6 The Real Time Executive for Multiprocessor Systems 7 (RTEMS) is designed to be portable across multiple processor 8 architectures. However, the nature of real-time systems makes 9 it essential that the application designer understand certain 10 processor dependent implementation details. These processor 11 dependencies include calling convention, board support package 12 issues, interrupt processing, exact RTEMS memory requirements, 13 performance data, header files, and the assembly language 14 interface to the executive. 15 16 This document discusses the SPARC architecture dependencies in this 17 port of RTEMS. This architectural port is for SPARC Version 7 and 10 The Real Time Executive for Multiprocessor Systems (RTEMS) is designed to be 11 portable across multiple processor architectures. However, the nature of 12 real-time systems makes it essential that the application designer understand 13 certain processor dependent implementation details. These processor 14 dependencies include calling convention, board support package issues, 15 interrupt processing, exact RTEMS memory requirements, performance data, header 16 files, and the assembly language interface to the executive. 17 18 This document discusses the SPARC architecture dependencies in this port of 19 RTEMS. This architectural port is for SPARC Version 7 and 18 20 8. Implementations for SPARC V9 are in the sparc64 target. 19 21 20 It is highly recommended that the SPARC RTEMS 21 application developer obtain and become familiar with the 22 documentation for the processor being used as well as the 23 specification for the revision of the SPARC architecture which 24 corresponds to that processor. 22 It is highly recommended that the SPARC RTEMS application developer obtain and 23 become familiar with the documentation for the processor being used as well as 24 the specification for the revision of the SPARC architecture which corresponds 25 to that processor. 25 26 26 27 **SPARC Architecture Documents** 27 28 28 For information on the SPARC architecture, refer to 29 the following documents available from SPARC International, Inc. 30 (http://www.sparc.com): 29 For information on the SPARC architecture, refer to the following documents 30 available from SPARC International, Inc. (http://www.sparc.com): 31 31 32 32 - SPARC Standard Version 7. … … 36 36 **ERC32 Specific Information** 37 37 38 The European Space Agency's ERC32 is a three chip 39 computing core implementing a SPARC V7 processor and associated 40 support circuitry for embedded space applications. The integer 41 and floating-point units (90C601E & 90C602E) are based on the 42 Cypress 7C601 and 7C602, with additional error-detection and 43 recovery functions. The memory controller (MEC) implements 44 system support functions such as address decoding, memory 45 interface, DMA interface, UARTs, timers, interrupt control, 46 write-protection, memory reconfiguration and error-detection. 47 The core is designed to work at 25MHz, but using space qualified 48 memories limits the system frequency to around 15 MHz, resulting 49 in a performance of 10 MIPS and 2 MFLOPS. 50 51 Information on the ERC32 and a number of development 52 support tools, such as the SPARC Instruction Simulator (SIS), 53 are freely available on the Internet. The following documents 54 and SIS are available via anonymous ftp or pointing your web 55 browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. 38 The European Space Agency's ERC32 is a three chip computing core implementing a 39 SPARC V7 processor and associated support circuitry for embedded space 40 applications. The integer and floating-point units (90C601E & 90C602E) are 41 based on the Cypress 7C601 and 7C602, with additional error-detection and 42 recovery functions. The memory controller (MEC) implements system support 43 functions such as address decoding, memory interface, DMA interface, UARTs, 44 timers, interrupt control, write-protection, memory reconfiguration and 45 error-detection. The core is designed to work at 25MHz, but using space 46 qualified memories limits the system frequency to around 15 MHz, resulting in a 47 performance of 10 MIPS and 2 MFLOPS. 48 49 Information on the ERC32 and a number of development support tools, such as the 50 SPARC Instruction Simulator (SIS), are freely available on the Internet. The 51 following documents and SIS are available via anonymous ftp or pointing your 52 web browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. 56 53 57 54 - ERC32 System Design Document … … 59 56 - MEC Device Specification 60 57 61 Additionally, the SPARC RISC User's Guide from Matra 62 MHS documents the functionality of the integer and floating 63 point units including the instruction set information. To 64 obtain this document as well as ERC32 components and VHDL models 65 contact: 66 .. code:: c 58 Additionally, the SPARC RISC User's Guide from Matra MHS documents the 59 functionality of the integer and floating point units including the instruction 60 set information. To obtain this document as well as ERC32 components and VHDL 61 models contact: 67 62 68 63 Matra MHS SA … … 75 70 Amar Guennon (amar.guennon@matramhs.fr) is familiar with the ERC32. 76 71 77 .. COMMENT: COPYRIGHT (c) 1988-2002.78 79 .. COMMENT: On-Line Applications Research Corporation (OAR).80 81 .. COMMENT: All rights reserved.82 83 72 CPU Model Dependent Features 84 73 ============================ 85 74 86 Microprocessors are generally classified into 87 families with a variety of CPU models or implementations within 88 that family. Within a processor family, there is a high level 89 of binary compatibility. This family may be based on either an 90 architectural specification or on maintaining compatibility with 91 a popular processor. Recent microprocessor families such as the 92 SPARC or PowerPC are based on an architectural specification 93 which is independent or any particular CPU model or 94 implementation. Older families such as the M68xxx and the iX86 95 evolved as the manufacturer strived to produce higher 96 performance processor models which maintained binary 97 compatibility with older models. 98 99 RTEMS takes advantage of the similarity of the 100 various models within a CPU family. Although the models do vary 101 in significant ways, the high level of compatibility makes it 102 possible to share the bulk of the CPU dependent executive code 103 across the entire family. 75 Microprocessors are generally classified into families with a variety of CPU 76 models or implementations within that family. Within a processor family, there 77 is a high level of binary compatibility. This family may be based on either an 78 architectural specification or on maintaining compatibility with a popular 79 processor. Recent microprocessor families such as the SPARC or PowerPC are 80 based on an architectural specification which is independent or any particular 81 CPU model or implementation. Older families such as the M68xxx and the iX86 82 evolved as the manufacturer strived to produce higher performance processor 83 models which maintained binary compatibility with older models. 84 85 RTEMS takes advantage of the similarity of the various models within a CPU 86 family. Although the models do vary in significant ways, the high level of 87 compatibility makes it possible to share the bulk of the CPU dependent 88 executive code across the entire family. 104 89 105 90 CPU Model Feature Flags 106 91 ----------------------- 107 92 108 Each processor family supported by RTEMS has a 109 list of features which vary between CPU models 110 within a family. For example, the most common model dependent 111 feature regardless of CPU family is the presence or absence of a 112 floating point unit or coprocessor. When defining the list of 113 features present on a particular CPU model, one simply notes 114 that floating point hardware is or is not present and defines a 115 single constant appropriately. Conditional compilation is 116 utilized to include the appropriate source code for this CPU 117 model's feature set. It is important to note that this means 118 that RTEMS is thus compiled using the appropriate feature set 119 and compilation flags optimal for this CPU model used. The 120 alternative would be to generate a binary which would execute on 121 all family members using only the features which were always 93 Each processor family supported by RTEMS has a list of features which vary 94 between CPU models within a family. For example, the most common model 95 dependent feature regardless of CPU family is the presence or absence of a 96 floating point unit or coprocessor. When defining the list of features present 97 on a particular CPU model, one simply notes that floating point hardware is or 98 is not present and defines a single constant appropriately. Conditional 99 compilation is utilized to include the appropriate source code for this CPU 100 model's feature set. It is important to note that this means that RTEMS is 101 thus compiled using the appropriate feature set and compilation flags optimal 102 for this CPU model used. The alternative would be to generate a binary which 103 would execute on all family members using only the features which were always 122 104 present. 123 105 124 This section presents the set of features which vary 125 across SPARC implementations and are of importance to RTEMS. 126 The set of CPU model feature macros are defined in the file 127 cpukit/score/cpu/sparc/sparc.h based upon the particular CPU 128 model defined on the compilation command line. 106 This section presents the set of features which vary across SPARC 107 implementations and are of importance to RTEMS. The set of CPU model feature 108 macros are defined in the file cpukit/score/cpu/sparc/sparc.h based upon the 109 particular CPU model defined on the compilation command line. 129 110 130 111 CPU Model Name 131 112 ~~~~~~~~~~~~~~ 132 113 133 The macro CPU_MODEL_NAME is a string which designates 134 the name of this CPU model. For example, for the European Space 135 Agency's ERC32 SPARC model, this macro is set to the string 136 "erc32". 114 The macro CPU_MODEL_NAME is a string which designates the name of this CPU 115 model. For example, for the European Space Agency's ERC32 SPARC model, this 116 macro is set to the string "erc32". 137 117 138 118 Floating Point Unit 139 119 ~~~~~~~~~~~~~~~~~~~ 140 120 141 The macro SPARC_HAS_FPU is set to 1 to indicate that 142 this CPU model has a hardware floating point unit and 0 143 otherwise. 121 The macro SPARC_HAS_FPU is set to 1 to indicate that this CPU model has a 122 hardware floating point unit and 0 otherwise. 144 123 145 124 Bitscan Instruction 146 125 ~~~~~~~~~~~~~~~~~~~ 147 126 148 The macro SPARC_HAS_BITSCAN is set to 1 to indicate 149 that this CPU model has the bitscan instruction. For example, 150 this instruction is supported by the FujitsuSPARClite family.127 The macro SPARC_HAS_BITSCAN is set to 1 to indicate that this CPU model has the 128 bitscan instruction. For example, this instruction is supported by the Fujitsu 129 SPARClite family. 151 130 152 131 Number of Register Windows 153 132 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 154 133 155 The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to 156 indicate the number of register window sets implemented by this 157 CPU model. The SPARC architecture allows a for a maximum of 158 thirty-two register window sets although most implementations 159 only include eight. 134 The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to indicate the number of 135 register window sets implemented by this CPU model. The SPARC architecture 136 allows a for a maximum of thirty-two register window sets although most 137 implementations only include eight. 160 138 161 139 Low Power Mode 162 140 ~~~~~~~~~~~~~~ 163 141 164 The macro SPARC_HAS_LOW_POWER_MODE is set to one to 165 indicate that this CPU model has a low power mode. If low power 166 is enabled, then there must be CPU model specific implementation 167 of the IDLE task in cpukit/score/cpu/sparc/cpu.c. The low 168 power mode IDLE task should be of the form: 169 .. code :: c142 The macro SPARC_HAS_LOW_POWER_MODE is set to one to indicate that this CPU 143 model has a low power mode. If low power is enabled, then there must be CPU 144 model specific implementation of the IDLE task in cpukit/score/cpu/sparc/cpu.c. 145 The low power mode IDLE task should be of the form: 146 147 .. code-block:: c 170 148 171 149 while ( TRUE ) { 172 enter low power mode150 enter low power mode 173 151 } 174 152 … … 203 181 provided in erc32.h which promote the view that the two timers are completely 204 182 independent. By exclusively using these routines to access the Timer Control 205 Register, the application can view the system as having a General Purpose 206 Timer Control Register and a Real Time Clock Timer Control Register 207 rather than thesingle shared value.183 Register, the application can view the system as having a General Purpose Timer 184 Control Register and a Real Time Clock Timer Control Register rather than the 185 single shared value. 208 186 209 187 The RTEMS Idle thread take advantage of the low power mode provided by the … … 211 189 initialization time. 212 190 213 .. COMMENT: COPYRIGHT (c) 1988-2002.214 215 .. COMMENT: On-Line Applications Research Corporation (OAR).216 217 .. COMMENT: All rights reserved.218 219 191 Calling Conventions 220 192 =================== … … 222 194 Each high-level language compiler generates subroutine entry and exit code 223 195 based upon a set of rules known as the application binary interface (ABI) 224 calling convention. 196 calling convention. These rules address the following issues: 225 197 226 198 - register preservation and usage … … 241 213 ----------------- 242 214 243 This section discusses the programming model for the 244 SPARC architecture. 215 This section discusses the programming model for the SPARC architecture. 245 216 246 217 Non-Floating Point Registers 247 218 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 248 219 249 The SPARC architecture defines thirty-two 250 non-floating point registers directly visible to the programmer. 251 These are divided into four sets: 220 The SPARC architecture defines thirty-two non-floating point registers directly 221 visible to the programmer. These are divided into four sets: 252 222 253 223 - input registers … … 259 229 - global registers 260 230 261 Each register is referred to by either two or three 262 names in the SPARC reference manuals. First, the registers are 263 referred to as r0 through r31 or with the alternate notation 264 r[0] through r[31]. Second, each register is a member of one of 265 the four sets listed above. Finally, some registers have an 266 architecturally defined role in the programming model which 267 provides an alternate name. The following table describes the 268 mapping between the 32 registers and the register sets: 269 270 .. code:: c 271 272 +-----------------+----------------+------------------+ 273 | Register Number | Register Names | Description | 274 +-----------------+----------------+------------------+ 275 | 0 - 7 | g0 - g7 | Global Registers | 276 +-----------------+----------------+------------------+ 277 | 8 - 15 | o0 - o7 | Output Registers | 278 +-----------------+----------------+------------------+ 279 | 16 - 23 | l0 - l7 | Local Registers | 280 +-----------------+----------------+------------------+ 281 | 24 - 31 | i0 - i7 | Input Registers | 282 +-----------------+----------------+------------------+ 283 284 As mentioned above, some of the registers serve 285 defined roles in the programming model. The following table 286 describes the role of each of these registers: 287 288 .. code:: c 289 290 +---------------+----------------+----------------------+ 291 | Register Name | Alternate Name | Description | 292 +---------------+----------------+----------------------+ 293 | g0 | na | reads return 0 | 294 | | | writes are ignored | 295 +---------------+----------------+----------------------+ 296 | o6 | sp | stack pointer | 297 +---------------+----------------+----------------------+ 298 | i6 | fp | frame pointer | 299 +---------------+----------------+----------------------+ 300 | i7 | na | return address | 301 +---------------+----------------+----------------------+ 231 Each register is referred to by either two or three names in the SPARC 232 reference manuals. First, the registers are referred to as r0 through r31 or 233 with the alternate notation r[0] through r[31]. Second, each register is a 234 member of one of the four sets listed above. Finally, some registers have an 235 architecturally defined role in the programming model which provides an 236 alternate name. The following table describes the mapping between the 32 237 registers and the register sets: 238 239 +-----------------+----------------+------------------+ 240 | Register Number | Register Names | Description | 241 +-----------------+----------------+------------------+ 242 | 0 - 7 | g0 - g7 | Global Registers | 243 +-----------------+----------------+------------------+ 244 | 8 - 15 | o0 - o7 | Output Registers | 245 +-----------------+----------------+------------------+ 246 | 16 - 23 | l0 - l7 | Local Registers | 247 +-----------------+----------------+------------------+ 248 | 24 - 31 | i0 - i7 | Input Registers | 249 +-----------------+----------------+------------------+ 250 251 As mentioned above, some of the registers serve defined roles in the 252 programming model. The following table describes the role of each of these 253 registers: 254 255 +---------------+----------------+----------------------+ 256 | Register Name | Alternate Name | Description | 257 +---------------+----------------+----------------------+ 258 | g0 | na | reads return 0 | 259 | | | writes are ignored | 260 +---------------+----------------+----------------------+ 261 | o6 | sp | stack pointer | 262 +---------------+----------------+----------------------+ 263 | i6 | fp | frame pointer | 264 +---------------+----------------+----------------------+ 265 | i7 | na | return address | 266 +---------------+----------------+----------------------+ 302 267 303 268 The registers g2 through g4 are reserved for applications. GCC uses them as … … 316 281 ~~~~~~~~~~~~~~~~~~~~~~~~ 317 282 318 The SPARC V7 architecture includes thirty-two, 319 thirty-two bit registers. These registers may be viewed as 320 follows: 321 322 - 32 single precision floating point or integer registers 323 (f0, f1, ... f31) 324 325 - 16 double precision floating point registers (f0, f2, 326 f4, ... f30) 327 328 - 8 extended precision floating point registers (f0, f4, 329 f8, ... f28) 330 331 The floating point status register (FSR) specifies 332 the behavior of the floating point unit for rounding, contains 333 its condition codes, version specification, and trap information. 283 The SPARC V7 architecture includes thirty-two, thirty-two bit registers. These 284 registers may be viewed as follows: 285 286 - 32 single precision floating point or integer registers (f0, f1, ... f31) 287 288 - 16 double precision floating point registers (f0, f2, f4, ... f30) 289 290 - 8 extended precision floating point registers (f0, f4, f8, ... f28) 291 292 The floating point status register (FSR) specifies the behavior of the floating 293 point unit for rounding, contains its condition codes, version specification, 294 and trap information. 334 295 335 296 According to the ABI all floating point registers and the floating point status 336 register (FSR) are volatile. Thus the floating point context of a thread is the337 empty set. The rounding direction is a system global state and must not be297 register (FSR) are volatile. Thus the floating point context of a thread is 298 the empty set. The rounding direction is a system global state and must not be 338 299 modified by threads. 339 300 340 A queue of the floating point instructions which have 341 started execution but not yet completed is maintained. This 342 queue is needed to support the multiple cycle nature of floating 343 point operations and to aid floating point exception trap 344 handlers. Once a floating point exception has been encountered, 345 the queue is frozen until it is emptied by the trap handler. 346 The floating point queue is loaded by launching instructions. 347 It is emptied normally when the floating point completes all 348 outstanding instructions and by floating point exception 349 handlers with the store double floating point queue (stdfq) 350 instruction. 301 A queue of the floating point instructions which have started execution but not 302 yet completed is maintained. This queue is needed to support the multiple 303 cycle nature of floating point operations and to aid floating point exception 304 trap handlers. Once a floating point exception has been encountered, the queue 305 is frozen until it is emptied by the trap handler. The floating point queue is 306 loaded by launching instructions. It is emptied normally when the floating 307 point completes all outstanding instructions and by floating point exception 308 handlers with the store double floating point queue (stdfq) instruction. 351 309 352 310 Special Registers 353 311 ~~~~~~~~~~~~~~~~~ 354 312 355 The SPARC architecture includes two special registers 356 which are critical to the programming model: the Processor State 357 Register (psr) and the Window Invalid Mask (wim). The psr 358 contains the condition codes, processor interrupt level, trap 359 enable bit, supervisor mode and previous supervisor mode bits, 360 version information, floating point unit and coprocessor enable 361 bits, and the current window pointer (cwp). The cwp field of 362 the psr and wim register are used to manage the register windows 363 in the SPARC architecture. The register windows are discussed 364 in more detail below. 313 The SPARC architecture includes two special registers which are critical to the 314 programming model: the Processor State Register (psr) and the Window Invalid 315 Mask (wim). The psr contains the condition codes, processor interrupt level, 316 trap enable bit, supervisor mode and previous supervisor mode bits, version 317 information, floating point unit and coprocessor enable bits, and the current 318 window pointer (cwp). The cwp field of the psr and wim register are used to 319 manage the register windows in the SPARC architecture. The register windows 320 are discussed in more detail below. 365 321 366 322 Register Windows 367 323 ---------------- 368 324 369 The SPARC architecture includes the concept of 370 register windows. An overly simplistic way to think of these 371 windows is to imagine them as being an infinite supply of 372 "fresh" register sets available for each subroutine to use. In 373 reality, they are much more complicated. 374 375 The save instruction is used to obtain a new register 376 window. This instruction decrements the current window pointer, 377 thus providing a new set of registers for use. This register 378 set includes eight fresh local registers for use exclusively by 379 this subroutine. When done with a register set, the restore 380 instruction increments the current window pointer and the 381 previous register set is once again available. 382 383 The two primary issues complicating the use of 384 register windows are that (1) the set of register windows is 385 finite, and (2) some registers are shared between adjacent 386 registers windows. 387 388 Because the set of register windows is finite, it is 389 possible to execute enough save instructions without 390 corresponding restore's to consume all of the register windows. 391 This is easily accomplished in a high level language because 392 each subroutine typically performs a save instruction upon 393 entry. Thus having a subroutine call depth greater than the 394 number of register windows will result in a window overflow 395 condition. The window overflow condition generates a trap which 396 must be handled in software. The window overflow trap handler 397 is responsible for saving the contents of the oldest register 398 window on the program stack. 399 400 Similarly, the subroutines will eventually complete 401 and begin to perform restore's. If the restore results in the 402 need for a register window which has previously been written to 403 memory as part of an overflow, then a window underflow condition 404 results. Just like the window overflow, the window underflow 405 condition must be handled in software by a trap handler. The 406 window underflow trap handler is responsible for reloading the 407 contents of the register window requested by the restore 408 instruction from the program stack. 409 410 The Window Invalid Mask (wim) and the Current Window 411 Pointer (cwp) field in the psr are used in conjunction to manage 412 the finite set of register windows and detect the window 413 overflow and underflow conditions. The cwp contains the index 414 of the register window currently in use. The save instruction 415 decrements the cwp modulo the number of register windows. 416 Similarly, the restore instruction increments the cwp modulo the 417 number of register windows. Each bit in the wim represents 418 represents whether a register window contains valid information. 419 The value of 0 indicates the register window is valid and 1 420 indicates it is invalid. When a save instruction causes the cwp 421 to point to a register window which is marked as invalid, a 422 window overflow condition results. Conversely, the restore 423 instruction may result in a window underflow condition. 424 425 Other than the assumption that a register window is 426 always available for trap (i.e. interrupt) handlers, the SPARC 427 architecture places no limits on the number of register windows 428 simultaneously marked as invalid (i.e. number of bits set in the 429 wim). However, RTEMS assumes that only one register window is 430 marked invalid at a time (i.e. only one bit set in the wim). 431 This makes the maximum possible number of register windows 432 available to the user while still meeting the requirement that 433 window overflow and underflow conditions can be detected. 434 435 The window overflow and window underflow trap 436 handlers are a critical part of the run-time environment for a 437 SPARC application. The SPARC architectural specification allows 438 for the number of register windows to be any power of two less 439 than or equal to 32. The most common choice for SPARC 440 implementations appears to be 8 register windows. This results 441 in the cwp ranging in value from 0 to 7 on most implementations. 442 443 The second complicating factor is the sharing of 444 registers between adjacent register windows. While each 445 register window has its own set of local registers, the input 446 and output registers are shared between adjacent windows. The 447 output registers for register window N are the same as the input 448 registers for register window ((N - 1) modulo RW) where RW is 449 the number of register windows. An alternative way to think of 450 this is to remember how parameters are passed to a subroutine on 451 the SPARC. The caller loads values into what are its output 452 registers. Then after the callee executes a save instruction, 453 those parameters are available in its input registers. This is 454 a very efficient way to pass parameters as no data is actually 455 moved by the save or restore instructions. 325 The SPARC architecture includes the concept of register windows. An overly 326 simplistic way to think of these windows is to imagine them as being an 327 infinite supply of "fresh" register sets available for each subroutine to use. 328 In reality, they are much more complicated. 329 330 The save instruction is used to obtain a new register window. This instruction 331 decrements the current window pointer, thus providing a new set of registers 332 for use. This register set includes eight fresh local registers for use 333 exclusively by this subroutine. When done with a register set, the restore 334 instruction increments the current window pointer and the previous register set 335 is once again available. 336 337 The two primary issues complicating the use of register windows are that (1) 338 the set of register windows is finite, and (2) some registers are shared 339 between adjacent registers windows. 340 341 Because the set of register windows is finite, it is possible to execute enough 342 save instructions without corresponding restore's to consume all of the 343 register windows. This is easily accomplished in a high level language because 344 each subroutine typically performs a save instruction upon entry. Thus having 345 a subroutine call depth greater than the number of register windows will result 346 in a window overflow condition. The window overflow condition generates a trap 347 which must be handled in software. The window overflow trap handler is 348 responsible for saving the contents of the oldest register window on the 349 program stack. 350 351 Similarly, the subroutines will eventually complete and begin to perform 352 restore's. If the restore results in the need for a register window which has 353 previously been written to memory as part of an overflow, then a window 354 underflow condition results. Just like the window overflow, the window 355 underflow condition must be handled in software by a trap handler. The window 356 underflow trap handler is responsible for reloading the contents of the 357 register window requested by the restore instruction from the program stack. 358 359 The Window Invalid Mask (wim) and the Current Window Pointer (cwp) field in the 360 psr are used in conjunction to manage the finite set of register windows and 361 detect the window overflow and underflow conditions. The cwp contains the 362 index of the register window currently in use. The save instruction decrements 363 the cwp modulo the number of register windows. Similarly, the restore 364 instruction increments the cwp modulo the number of register windows. Each bit 365 in the wim represents represents whether a register window contains valid 366 information. The value of 0 indicates the register window is valid and 1 367 indicates it is invalid. When a save instruction causes the cwp to point to a 368 register window which is marked as invalid, a window overflow condition 369 results. Conversely, the restore instruction may result in a window underflow 370 condition. 371 372 Other than the assumption that a register window is always available for trap 373 (i.e. interrupt) handlers, the SPARC architecture places no limits on the 374 number of register windows simultaneously marked as invalid (i.e. number of 375 bits set in the wim). However, RTEMS assumes that only one register window is 376 marked invalid at a time (i.e. only one bit set in the wim). This makes the 377 maximum possible number of register windows available to the user while still 378 meeting the requirement that window overflow and underflow conditions can be 379 detected. 380 381 The window overflow and window underflow trap handlers are a critical part of 382 the run-time environment for a SPARC application. The SPARC architectural 383 specification allows for the number of register windows to be any power of two 384 less than or equal to 32. The most common choice for SPARC implementations 385 appears to be 8 register windows. This results in the cwp ranging in value 386 from 0 to 7 on most implementations. 387 388 The second complicating factor is the sharing of registers between adjacent 389 register windows. While each register window has its own set of local 390 registers, the input and output registers are shared between adjacent windows. 391 The output registers for register window N are the same as the input registers 392 for register window ((N - 1) modulo RW) where RW is the number of register 393 windows. An alternative way to think of this is to remember how parameters are 394 passed to a subroutine on the SPARC. The caller loads values into what are its 395 output registers. Then after the callee executes a save instruction, those 396 parameters are available in its input registers. This is a very efficient way 397 to pass parameters as no data is actually moved by the save or restore 398 instructions. 456 399 457 400 Call and Return Mechanism 458 401 ------------------------- 459 402 460 The SPARC architecture supports a simple yet 461 effective call and return mechanism. A subroutine is invoked 462 via the call (call) instruction. This instruction places the 463 return address in the caller's output register 7 (o7). After 464 the callee executes a save instruction, this value is available 465 in input register 7 (i7) until the corresponding restore 466 instruction is executed. 467 468 The callee returns to the caller via a jmp to the 469 return address. There is a delay slot following this 470 instruction which is commonly used to execute a restore 471 instruction - if a register window was allocated by this 472 subroutine. 473 474 It is important to note that the SPARC subroutine 475 call and return mechanism does not automatically save and 476 restore any registers. This is accomplished via the save and 477 restore instructions which manage the set of registers windows. 403 The SPARC architecture supports a simple yet effective call and return 404 mechanism. A subroutine is invoked via the call (call) instruction. This 405 instruction places the return address in the caller's output register 7 (o7). 406 After the callee executes a save instruction, this value is available in input 407 register 7 (i7) until the corresponding restore instruction is executed. 408 409 The callee returns to the caller via a jmp to the return address. There is a 410 delay slot following this instruction which is commonly used to execute a 411 restore instruction - if a register window was allocated by this subroutine. 412 413 It is important to note that the SPARC subroutine call and return mechanism 414 does not automatically save and restore any registers. This is accomplished 415 via the save and restore instructions which manage the set of registers 416 windows. 478 417 479 418 In case a floating-point unit is supported, then floating-point return values … … 486 425 ----------------- 487 426 488 All RTEMS directives are invoked using the regular 489 SPARC calling convention viathe call instruction.427 All RTEMS directives are invoked using the regular SPARC calling convention via 428 the call instruction. 490 429 491 430 Register Usage 492 431 -------------- 493 432 494 As discussed above, the call instruction does not 495 automatically save any registers. The save and restore 496 instructions are used to allocate and deallocate register 497 windows. When a register window is allocated, the new set of 498 local registers are available for the exclusive use of the 499 subroutine which allocated this register set. 433 As discussed above, the call instruction does not automatically save any 434 registers. The save and restore instructions are used to allocate and 435 deallocate register windows. When a register window is allocated, the new set 436 of local registers are available for the exclusive use of the subroutine which 437 allocated this register set. 500 438 501 439 Parameter Passing 502 440 ----------------- 503 441 504 RTEMS assumes that arguments are placed in the 505 caller's output registers with the first argument in output 506 register 0 (o0), the second argument in output register 1 (o1), 507 and so forth. Until the callee executes a save instruction, the 508 parameters are still visible in the output registers. After the 509 callee executes a save instruction, the parameters are visible 510 in the corresponding input registers. The following pseudo-code 511 illustrates the typical sequence used to call a RTEMS directive 512 with three (3) arguments: 513 .. code:: c 442 RTEMS assumes that arguments are placed in the caller's output registers with 443 the first argument in output register 0 (o0), the second argument in output 444 register 1 (o1), and so forth. Until the callee executes a save instruction, 445 the parameters are still visible in the output registers. After the callee 446 executes a save instruction, the parameters are visible in the corresponding 447 input registers. The following pseudo-code illustrates the typical sequence 448 used to call a RTEMS directive with three (3) arguments: 449 450 .. code-block:: c 514 451 515 452 load third argument into o2 … … 521 458 ---------------------- 522 459 523 All user-provided routines invoked by RTEMS, such as 524 user extensions, device drivers, and MPCI routines, must also 525 adhere to these calling conventions. 526 527 .. COMMENT: COPYRIGHT (c) 1988-2002. 528 529 .. COMMENT: On-Line Applications Research Corporation (OAR). 530 531 .. COMMENT: All rights reserved. 460 All user-provided routines invoked by RTEMS, such as user extensions, device 461 drivers, and MPCI routines, must also adhere to these calling conventions. 532 462 533 463 Memory Model 534 464 ============ 535 465 536 A processor may support any combination of memory 537 models ranging from pure physical addressing to complex demand 538 paged virtual memory systems. RTEMS supports a flat memory 539 model which ranges contiguously over the processor's allowable 540 address space. RTEMS does not support segmentation or virtual 541 memory of any kind. The appropriate memory model for RTEMS 542 provided by the targeted processor and related characteristics 543 of that model are described in this chapter. 466 A processor may support any combination of memory models ranging from pure 467 physical addressing to complex demand paged virtual memory systems. RTEMS 468 supports a flat memory model which ranges contiguously over the processor's 469 allowable address space. RTEMS does not support segmentation or virtual memory 470 of any kind. The appropriate memory model for RTEMS provided by the targeted 471 processor and related characteristics of that model are described in this 472 chapter. 544 473 545 474 Flat Memory Model 546 475 ----------------- 547 476 548 The SPARC architecture supports a flat 32-bit address 549 space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 550 gigabytes). Each address is represented by a 32-bit value and 551 is byte addressable. The address may be used to reference a 552 single byte, half-word (2-bytes), word (4 bytes), or doubleword 553 (8 bytes). Memory accesses within this address space are 554 performed in big endian fashion by the SPARC. Memory accesses 555 which are not properly aligned generate a "memory address not 556 aligned" trap (type number 7). The following table lists the 557 alignment requirements for a variety of data accesses: 558 559 .. code:: c 477 The SPARC architecture supports a flat 32-bit address space with addresses 478 ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is 479 represented by a 32-bit value and is byte addressable. The address may be used 480 to reference a single byte, half-word (2-bytes), word (4 bytes), or doubleword 481 (8 bytes). Memory accesses within this address space are performed in big 482 endian fashion by the SPARC. Memory accesses which are not properly aligned 483 generate a "memory address not aligned" trap (type number 7). The following 484 table lists the alignment requirements for a variety of data accesses: 560 485 561 486 +--------------+-----------------------+ … … 568 493 +--------------+-----------------------+ 569 494 570 Doubleword load and store operations must use a pair 571 of registers as their source or destination. This pair of 572 registers must be an adjacent pair of registers with the first 573 of the pair being even numbered. For example, a valid 574 destination for a doubleword load might be input registers 0 and 575 1 (i0 and i1). The pair i1 and i2 would be invalid. \[NOTE: 576 Some assemblers for the SPARC do not generate an error if an odd 577 numbered register is specified as the beginning register of the 578 pair. In this case, the assembler assumes that what the 579 programmer meant was to use the even-odd pair which ends at the 580 specified register. This may or may not have been a correct 581 assumption.] 582 583 RTEMS does not support any SPARC Memory Management 584 Units, therefore, virtual memory or segmentation systems 585 involving the SPARC are not supported. 586 587 .. COMMENT: COPYRIGHT (c) 1988-2002. 588 589 .. COMMENT: On-Line Applications Research Corporation (OAR). 590 591 .. COMMENT: All rights reserved. 495 Doubleword load and store operations must use a pair of registers as their 496 source or destination. This pair of registers must be an adjacent pair of 497 registers with the first of the pair being even numbered. For example, a valid 498 destination for a doubleword load might be input registers 0 and 1 (i0 and i1). 499 The pair i1 and i2 would be invalid. \[NOTE: Some assemblers for the SPARC do 500 not generate an error if an odd numbered register is specified as the beginning 501 register of the pair. In this case, the assembler assumes that what the 502 programmer meant was to use the even-odd pair which ends at the specified 503 register. This may or may not have been a correct assumption.] 504 505 RTEMS does not support any SPARC Memory Management Units, therefore, virtual 506 memory or segmentation systems involving the SPARC are not supported. 592 507 593 508 Interrupt Processing 594 509 ==================== 595 510 596 Different types of processors respond to the 597 occurrence of an interrupt in its own unique fashion. In 598 addition, each processor type provides a control mechanism to 599 allow for the proper handling of an interrupt. The processor 600 dependent response to the interrupt modifies the current 601 execution state and results in a change in the execution stream. 602 Most processors require that an interrupt handler utilize some 603 special control mechanisms to return to the normal processing 604 stream. Although RTEMS hides many of the processor dependent 605 details of interrupt processing, it is important to understand 606 how the RTEMS interrupt manager is mapped onto the processor's 607 unique architecture. Discussed in this chapter are the SPARC's 608 interrupt response and control mechanisms as they pertain to 609 RTEMS. 610 611 RTEMS and associated documentation uses the terms 612 interrupt and vector. In the SPARC architecture, these terms 613 correspond to traps and trap type, respectively. The terms will 614 be used interchangeably in this manual. 511 Different types of processors respond to the occurrence of an interrupt in its 512 own unique fashion. In addition, each processor type provides a control 513 mechanism to allow for the proper handling of an interrupt. The processor 514 dependent response to the interrupt modifies the current execution state and 515 results in a change in the execution stream. Most processors require that an 516 interrupt handler utilize some special control mechanisms to return to the 517 normal processing stream. Although RTEMS hides many of the processor dependent 518 details of interrupt processing, it is important to understand how the RTEMS 519 interrupt manager is mapped onto the processor's unique architecture. Discussed 520 in this chapter are the SPARC's interrupt response and control mechanisms as 521 they pertain to RTEMS. 522 523 RTEMS and associated documentation uses the terms interrupt and vector. In the 524 SPARC architecture, these terms correspond to traps and trap type, 525 respectively. The terms will be used interchangeably in this manual. 615 526 616 527 Synchronous Versus Asynchronous Traps 617 528 ------------------------------------- 618 529 619 The SPARC architecture includes two classes of traps: 620 synchronous and asynchronous. Asynchronous traps occur when an 621 external event interrupts the processor. These traps are not 622 associated with any instruction executed by the processor and 623 logically occur between instructions. The instruction currently 624 in the execute stage of the processor is allowed to complete 625 although subsequent instructions are annulled. The return 626 address reported by the processor for asynchronous traps is the 627 pair of instructions following the current instruction. 628 629 Synchronous traps are caused by the actions of an 630 instruction. The trap stimulus in this case either occurs 631 internally to the processor or is from an external signal that 632 was provoked by the instruction. These traps are taken 633 immediately and the instruction that caused the trap is aborted 634 before any state changes occur in the processor itself. The 635 return address reported by the processor for synchronous traps 636 is the instruction which caused the trap and the following 637 instruction. 530 The SPARC architecture includes two classes of traps: synchronous and 531 asynchronous. Asynchronous traps occur when an external event interrupts the 532 processor. These traps are not associated with any instruction executed by the 533 processor and logically occur between instructions. The instruction currently 534 in the execute stage of the processor is allowed to complete although 535 subsequent instructions are annulled. The return address reported by the 536 processor for asynchronous traps is the pair of instructions following the 537 current instruction. 538 539 Synchronous traps are caused by the actions of an instruction. The trap 540 stimulus in this case either occurs internally to the processor or is from an 541 external signal that was provoked by the instruction. These traps are taken 542 immediately and the instruction that caused the trap is aborted before any 543 state changes occur in the processor itself. The return address reported by 544 the processor for synchronous traps is the instruction which caused the trap 545 and the following instruction. 638 546 639 547 Vectoring of Interrupt Handler 640 548 ------------------------------ 641 549 642 Upon receipt of an interrupt the SPARC automatically 643 performs the followingactions:550 Upon receipt of an interrupt the SPARC automatically performs the following 551 actions: 644 552 645 553 - disables traps (sets the ET bit of the psr to 0), 646 554 647 - the S bit of the psr is copied into the Previous 648 Supervisor Mode (PS) bit of the psr, 649 650 - the cwp is decremented by one (modulo the number of 651 register windows) to activate a trap window, 652 653 - the PC and nPC are loaded into local register 1 and 2 654 (l0 and l1), 655 656 - the trap type (tt) field of the Trap Base Register (TBR) 657 is set to the appropriate value, and 658 659 - if the trap is not a reset, then the PC is written with 660 the contents of the TBR and the nPC is written with TBR + 4. If 661 the trap is a reset, then the PC is set to zero and the nPC is 662 set to 4. 663 664 Trap processing on the SPARC has two features which 665 are noticeably different than interrupt processing on other 666 architectures. First, the value of psr register in effect 667 immediately before the trap occurred is not explicitly saved. 668 Instead only reversible alterations are made to it. Second, the 669 Processor Interrupt Level (pil) is not set to correspond to that 670 of the interrupt being processed. When a trap occurs, ALL 671 subsequent traps are disabled. In order to safely invoke a 672 subroutine during trap handling, traps must be enabled to allow 673 for the possibility of register window overflow and underflow 674 traps. 675 676 If the interrupt handler was installed as an RTEMS 677 interrupt handler, then upon receipt of the interrupt, the 678 processor passes control to the RTEMS interrupt handler which 679 performs the following actions: 555 - the S bit of the psr is copied into the Previous Supervisor Mode (PS) bit of 556 the psr, 557 558 - the cwp is decremented by one (modulo the number of register windows) to 559 activate a trap window, 560 561 - the PC and nPC are loaded into local register 1 and 2 (l0 and l1), 562 563 - the trap type (tt) field of the Trap Base Register (TBR) is set to the 564 appropriate value, and 565 566 - if the trap is not a reset, then the PC is written with the contents of the 567 TBR and the nPC is written with TBR + 4. If the trap is a reset, then the PC 568 is set to zero and the nPC is set to 4. 569 570 Trap processing on the SPARC has two features which are noticeably different 571 than interrupt processing on other architectures. First, the value of psr 572 register in effect immediately before the trap occurred is not explicitly 573 saved. Instead only reversible alterations are made to it. Second, the 574 Processor Interrupt Level (pil) is not set to correspond to that of the 575 interrupt being processed. When a trap occurs, ALL subsequent traps are 576 disabled. In order to safely invoke a subroutine during trap handling, traps 577 must be enabled to allow for the possibility of register window overflow and 578 underflow traps. 579 580 If the interrupt handler was installed as an RTEMS interrupt handler, then upon 581 receipt of the interrupt, the processor passes control to the RTEMS interrupt 582 handler which performs the following actions: 680 583 681 584 - saves the state of the interrupted task on it's stack, 682 585 683 - insures that a register window is available for 684 subsequent traps, 685 686 - if this is the outermost (i.e. non-nested) interrupt, 687 then the RTEMS interrupt handler switches from the current stack 688 to the interrupt stack, 586 - insures that a register window is available for subsequent traps, 587 588 - if this is the outermost (i.e. non-nested) interrupt, then the RTEMS 589 interrupt handler switches from the current stack to the interrupt stack, 689 590 690 591 - enables traps, … … 692 593 - invokes the vectors to a user interrupt service routine (ISR). 693 594 694 Asynchronous interrupts are ignored while traps are 695 disabled. Synchronous traps which occur while traps are 696 disabled result in the CPU being forced into an error mode. 697 698 A nested interrupt is processed similarly with the 699 exception that the current stack need not be switched to the 700 interrupt stack. 595 Asynchronous interrupts are ignored while traps are disabled. Synchronous 596 traps which occur while traps are disabled result in the CPU being forced into 597 an error mode. 598 599 A nested interrupt is processed similarly with the exception that the current 600 stack need not be switched to the interrupt stack. 701 601 702 602 Traps and Register Windows 703 603 -------------------------- 704 604 705 One of the register windows must be reserved at all 706 times for trap processing. This is critical to the proper 707 operation of the trap mechanism in the SPARC architecture. It 708 is the responsibility of the trap handler to insure that there 709 is a register window available for a subsequent trap before 710 re-enabling traps. It is likely that any high level language 711 routines invoked by the trap handler (such as a user-provided 712 RTEMS interrupt handler) will allocate a new register window. 713 The save operation could result in a window overflow trap. This 714 trap cannot be correctly processed unless (1) traps are enabled 715 and (2) a register window is reserved for traps. Thus, the 716 RTEMS interrupt handler insures that a register window is 717 available for subsequent traps before enabling traps and 718 invoking the user's interrupt handler. 605 One of the register windows must be reserved at all times for trap processing. 606 This is critical to the proper operation of the trap mechanism in the SPARC 607 architecture. It is the responsibility of the trap handler to insure that 608 there is a register window available for a subsequent trap before re-enabling 609 traps. It is likely that any high level language routines invoked by the trap 610 handler (such as a user-provided RTEMS interrupt handler) will allocate a new 611 register window. The save operation could result in a window overflow trap. 612 This trap cannot be correctly processed unless (1) traps are enabled and (2) a 613 register window is reserved for traps. Thus, the RTEMS interrupt handler 614 insures that a register window is available for subsequent traps before 615 enabling traps and invoking the user's interrupt handler. 719 616 720 617 Interrupt Levels 721 618 ---------------- 722 619 723 Sixteen levels (0-15) of interrupt priorities are 724 supported by the SPARC architecture with level fifteen (15) 725 being the highest priority. Level zero (0) indicates that 726 interrupts are fully enabled. Interrupt requests for interrupts 727 with priorities less than or equal to the current interrupt mask 728 level are ignored. Level fifteen (15) is a non-maskable interrupt 729 (NMI), which makes it unsuitable for standard usage since it can 730 affect the real-time behaviour by interrupting critical sections 731 and spinlocks. Disabling traps stops also the NMI interrupt from 732 happening. It can however be used for power-down or other 733 critical events. 734 735 Although RTEMS supports 256 interrupt levels, the 736 SPARC only supports sixteen. RTEMS interrupt levels 0 through 737 15 directly correspond to SPARC processor interrupt levels. All 738 other RTEMS interrupt levels are undefined and their behavior is 739 unpredictable. 740 741 Many LEON SPARC v7/v8 systems features an extended interrupt controller 742 which adds an extra step of interrupt decoding to allow handling of 743 interrupt 16-31. When such an extended interrupt is generated the CPU 744 traps into a specific interrupt trap level 1-14 and software reads out from 745 the interrupt controller which extended interrupt source actually caused the 746 interrupt. 620 Sixteen levels (0-15) of interrupt priorities are supported by the SPARC 621 architecture with level fifteen (15) being the highest priority. Level 622 zero (0) indicates that interrupts are fully enabled. Interrupt requests for 623 interrupts with priorities less than or equal to the current interrupt mask 624 level are ignored. Level fifteen (15) is a non-maskable interrupt (NMI), which 625 makes it unsuitable for standard usage since it can affect the real-time 626 behaviour by interrupting critical sections and spinlocks. Disabling traps 627 stops also the NMI interrupt from happening. It can however be used for 628 power-down or other critical events. 629 630 Although RTEMS supports 256 interrupt levels, the SPARC only supports sixteen. 631 RTEMS interrupt levels 0 through 15 directly correspond to SPARC processor 632 interrupt levels. All other RTEMS interrupt levels are undefined and their 633 behavior is unpredictable. 634 635 Many LEON SPARC v7/v8 systems features an extended interrupt controller which 636 adds an extra step of interrupt decoding to allow handling of interrupt 637 16-31. When such an extended interrupt is generated the CPU traps into a 638 specific interrupt trap level 1-14 and software reads out from the interrupt 639 controller which extended interrupt source actually caused the interrupt. 747 640 748 641 Disabling of Interrupts by RTEMS 749 642 -------------------------------- 750 643 751 During the execution of directive calls, critical 752 sections of code may be executed. When these sections are 753 encountered, RTEMS disables interrupts to level fifteen (15) 754 before the execution of the section and restores them to the 755 previous level upon completion of the section. RTEMS has been 756 optimized to ensure that interrupts are disabled for less than 757 RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 758 Mhz ERC32 with zero wait states. 759 These numbers will vary based the number of wait states and 760 processor speed present on the target board. 761 \[NOTE: The maximum period with interrupts disabled is hand calculated. This 762 calculation was last performed for Release 644 During the execution of directive calls, critical sections of code may be 645 executed. When these sections are encountered, RTEMS disables interrupts to 646 level fifteen (15) before the execution of the section and restores them to the 647 previous level upon completion of the section. RTEMS has been optimized to 648 ensure that interrupts are disabled for less than RTEMS_MAXIMUM_DISABLE_PERIOD 649 microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz ERC32 with zero wait 650 states. These numbers will vary based the number of wait states and processor 651 speed present on the target board. [NOTE: The maximum period with interrupts 652 disabled is hand calculated. This calculation was last performed for Release 763 653 RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] 764 654 765 [NOTE: It is thought that the length of time at which 766 the processor interrupt level is elevated to fifteen by RTEMS is 767 not anywhere near as long as the length of time ALL traps are 768 disabled as part of the "flush all register windows" operation.] 769 770 Non-maskable interrupts (NMI) cannot be disabled, and 771 ISRs which execute at this level MUST NEVER issue RTEMS system 772 calls. If a directive is invoked, unpredictable results may 773 occur due to the inability of RTEMS to protect its critical 774 sections. However, ISRs that make no system calls may safely 775 execute as non-maskable interrupts. 776 777 Interrupts are disabled or enabled by performing a system call 778 to the Operating System reserved software traps 9 779 (SPARC_SWTRAP_IRQDIS) or 10 (SPARC_SWTRAP_IRQDIS). The trap is 780 generated by the software trap (Ticc) instruction or indirectly 781 by calling sparc_disable_interrupts() or sparc_enable_interrupts() 782 functions. Disabling interrupts return the previous interrupt level 783 (on trap entry) in register G1 and sets PSR.PIL to 15 to disable 784 all maskable interrupts. The interrupt level can be restored by 785 trapping into the enable interrupt handler with G1 containing the 786 new interrupt level. 655 [NOTE: It is thought that the length of time at which the processor interrupt 656 level is elevated to fifteen by RTEMS is not anywhere near as long as the 657 length of time ALL traps are disabled as part of the "flush all register 658 windows" operation.] 659 660 Non-maskable interrupts (NMI) cannot be disabled, and ISRs which execute at 661 this level MUST NEVER issue RTEMS system calls. If a directive is invoked, 662 unpredictable results may occur due to the inability of RTEMS to protect its 663 critical sections. However, ISRs that make no system calls may safely execute 664 as non-maskable interrupts. 665 666 Interrupts are disabled or enabled by performing a system call to the Operating 667 System reserved software traps 9 (SPARC_SWTRAP_IRQDIS) or 10 668 (SPARC_SWTRAP_IRQDIS). The trap is generated by the software trap (Ticc) 669 instruction or indirectly by calling sparc_disable_interrupts() or 670 sparc_enable_interrupts() functions. Disabling interrupts return the previous 671 interrupt level (on trap entry) in register G1 and sets PSR.PIL to 15 to 672 disable all maskable interrupts. The interrupt level can be restored by 673 trapping into the enable interrupt handler with G1 containing the new interrupt 674 level. 787 675 788 676 Interrupt Stack 789 677 --------------- 790 678 791 The SPARC architecture does not provide for a 792 dedicated interrupt stack. Thus by default, trap handlers would 793 execute on the stack of the RTEMS task which they interrupted. 794 This artificially inflates the stack requirements for each task 795 since EVERY task stack would have to include enough space to 796 account for the worst case interrupt stack requirements in 797 addition to it's own worst case usage. RTEMS addresses this 798 problem on the SPARC by providing a dedicated interrupt stack 799 managed by software. 800 801 During system initialization, RTEMS allocates the 802 interrupt stack from the Workspace Area. The amount of memory 803 allocated for the interrupt stack is determined by the 804 interrupt_stack_size field in the CPU Configuration Table. As 805 part of processing a non-nested interrupt, RTEMS will switch to 806 the interrupt stack before invoking the installed handler. 807 808 .. COMMENT: COPYRIGHT (c) 1988-2002. 809 810 .. COMMENT: On-Line Applications Research Corporation (OAR). 811 812 .. COMMENT: All rights reserved. 679 The SPARC architecture does not provide for a dedicated interrupt stack. Thus 680 by default, trap handlers would execute on the stack of the RTEMS task which 681 they interrupted. This artificially inflates the stack requirements for each 682 task since EVERY task stack would have to include enough space to account for 683 the worst case interrupt stack requirements in addition to it's own worst case 684 usage. RTEMS addresses this problem on the SPARC by providing a dedicated 685 interrupt stack managed by software. 686 687 During system initialization, RTEMS allocates the interrupt stack from the 688 Workspace Area. The amount of memory allocated for the interrupt stack is 689 determined by the interrupt_stack_size field in the CPU Configuration Table. 690 As part of processing a non-nested interrupt, RTEMS will switch to the 691 interrupt stack before invoking the installed handler. 813 692 814 693 Default Fatal Error Processing 815 694 ============================== 816 695 817 Upon detection of a fatal error by either the 818 application or RTEMS the fatal error manager is invoked. The 819 fatal error manager will invoke the user-supplied fatal error 820 handlers. If no user-supplied handlers are configured, the 821 RTEMS provided default fatal error handler is invoked. If the 822 user-supplied fatal error handlers return to the executive the 823 default fatal error handler is then invoked. This chapter 824 describes the precise operations of the default fatal error 825 handler. 696 Upon detection of a fatal error by either the application or RTEMS the fatal 697 error manager is invoked. The fatal error manager will invoke the 698 user-supplied fatal error handlers. If no user-supplied handlers are 699 configured, the RTEMS provided default fatal error handler is invoked. If the 700 user-supplied fatal error handlers return to the executive the default fatal 701 error handler is then invoked. This chapter describes the precise operations 702 of the default fatal error handler. 826 703 827 704 Default Fatal Error Handler Operations 828 705 -------------------------------------- 829 706 830 The default fatal error handler which is invoked by 831 the fatal_error_occurred directive when there is no user handler 832 con figured or the user handler returns control to RTEMS.833 834 If the BSP has been configured with ``BSP_POWER_DOWN_AT_FATAL_HALT`` 835 set to true, the default handler will disable interrupts 836 and enter power down mode. If power down mode is not available, 837 it goes into an infinite loop to simulate ahalt processor instruction.838 839 If ``BSP_POWER_DOWN_AT_FATAL_HALT`` is set to false, the default 840 handler will place the value ``1`` in register ``g1``, the 841 error source in register ``g2``, and the error code in register``g3``. It will then generate a system error which will 842 hand over control to the debugger, simulator, etc.707 The default fatal error handler which is invoked by the fatal_error_occurred 708 directive when there is no user handler configured or the user handler returns 709 control to RTEMS. 710 711 If the BSP has been configured with ``BSP_POWER_DOWN_AT_FATAL_HALT`` set to 712 true, the default handler will disable interrupts and enter power down mode. If 713 power down mode is not available, it goes into an infinite loop to simulate a 714 halt processor instruction. 715 716 If ``BSP_POWER_DOWN_AT_FATAL_HALT`` is set to false, the default handler will 717 place the value ``1`` in register ``g1``, the error source in register ``g2``, 718 and the error code in register``g3``. It will then generate a system error 719 which will hand over control to the debugger, simulator, etc. 843 720 844 721 Symmetric Multiprocessing … … 853 730 Thread-local storage is supported. 854 731 855 .. COMMENT: COPYRIGHT (c) 1988-2002.856 857 .. COMMENT: On-Line Applications Research Corporation (OAR).858 859 .. COMMENT: All rights reserved.860 861 732 Board Support Packages 862 733 ====================== 863 734 864 An RTEMS Board Support Package (BSP) must be designed 865 to support a particular processor and target board combination. 866 This chapter presents a discussion of SPARC specific BSP issues. 867 For more information on developing a BSP, refer to the chapter 868 titled Board Support Packages in the RTEMS 869 Applications User's Guide. 735 An RTEMS Board Support Package (BSP) must be designed to support a particular 736 processor and target board combination. This chapter presents a discussion of 737 SPARC specific BSP issues. For more information on developing a BSP, refer to 738 the chapter titled Board Support Packages in the RTEMS Applications User's 739 Guide. 870 740 871 741 System Reset 872 742 ------------ 873 743 874 An RTEMS based application is initiated or 875 re-initiated when the SPARC processor is reset. When the SPARC 876 is reset, the processor performs the following actions: 877 878 - the enable trap (ET) of the psr is set to 0 to disable 879 traps, 880 881 - the supervisor bit (S) of the psr is set to 1 to enter 882 supervisor mode, and 744 An RTEMS based application is initiated or re-initiated when the SPARC 745 processor is reset. When the SPARC is reset, the processor performs the 746 following actions: 747 748 - the enable trap (ET) of the psr is set to 0 to disable traps, 749 750 - the supervisor bit (S) of the psr is set to 1 to enter supervisor mode, and 883 751 884 752 - the PC is set 0 and the nPC is set to 4. 885 753 886 The processor then begins to execute the code at 887 location 0. It is important to note that all fields in the psr 888 are not explicitly set by the above steps and all other 889 registers retain their value from the previous execution mode. 890 This is true even of the Trap Base Register (TBR) whose contents 891 reflect the last trap which occurred before the reset. 754 The processor then begins to execute the code at location 0. It is important 755 to note that all fields in the psr are not explicitly set by the above steps 756 and all other registers retain their value from the previous execution mode. 757 This is true even of the Trap Base Register (TBR) whose contents reflect the 758 last trap which occurred before the reset. 892 759 893 760 Processor Initialization 894 761 ------------------------ 895 762 896 It is the responsibility of the application's 897 initialization code to initialize the TBR and install trap 898 handlers for at least the register window overflow and register 899 window underflow conditions. Traps should be enabled before 900 invoking any subroutines to allow for register window 901 management. However, interrupts should be disabled by setting 902 the Processor Interrupt Level (pil) field of the psr to 15. 903 RTEMS installs it's own Trap Table as part of initialization 904 which is initialized with the contents of the Trap Table in 905 place when the ``rtems_initialize_executive`` directive was invoked. 906 Upon completion of executive initialization, interrupts are 907 enabled. 908 909 If this SPARC implementation supports on-chip caching 910 and this is to be utilized, then it should be enabled during the 911 reset application initialization code. 912 913 In addition to the requirements described in the 914 Board Support Packages chapter of the C 915 Applications Users Manual for the reset code 916 which is executed before the call to``rtems_initialize_executive``, the SPARC version has the following 763 It is the responsibility of the application's initialization code to initialize 764 the TBR and install trap handlers for at least the register window overflow and 765 register window underflow conditions. Traps should be enabled before invoking 766 any subroutines to allow for register window management. However, interrupts 767 should be disabled by setting the Processor Interrupt Level (pil) field of the 768 psr to 15. RTEMS installs it's own Trap Table as part of initialization which 769 is initialized with the contents of the Trap Table in place when the 770 ``rtems_initialize_executive`` directive was invoked. Upon completion of 771 executive initialization, interrupts are enabled. 772 773 If this SPARC implementation supports on-chip caching and this is to be 774 utilized, then it should be enabled during the reset application initialization 775 code. 776 777 In addition to the requirements described in the Board Support Packages chapter 778 of the C Applications Users Manual for the reset code which is executed before 779 the call to``rtems_initialize_executive``, the SPARC version has the following 917 780 specific requirements: 918 781 919 - Must leave the S bit of the status register set so that 920 the SPARC remains in the supervisor state. 921 922 - Must set stack pointer (sp) such that a minimum stack 923 size of MINIMUM_STACK_SIZE bytes is provided for the``rtems_initialize_executive`` directive. 924 925 - Must disable all external interrupts (i.e. set the pil 926 to 15). 927 928 - Must enable traps so window overflow and underflow 929 conditions can be properly handled. 930 931 - Must initialize the SPARC's initial trap table with at 932 least trap handlers for register window overflow and register 933 window underflow. 934 935 .. COMMENT: COPYRIGHT (c) 1988-2002. 936 937 .. COMMENT: On-Line Applications Research Corporation (OAR). 938 939 .. COMMENT: All rights reserved. 940 782 - Must leave the S bit of the status register set so that the SPARC remains in 783 the supervisor state. 784 785 - Must set stack pointer (sp) such that a minimum stack size of 786 MINIMUM_STACK_SIZE bytes is provided for the``rtems_initialize_executive`` 787 directive. 788 789 - Must disable all external interrupts (i.e. set the pil to 15). 790 791 - Must enable traps so window overflow and underflow conditions can be properly 792 handled. 793 794 - Must initialize the SPARC's initial trap table with at least trap handlers 795 for register window overflow and register window underflow. -
cpu_supplement/sparc64.rst
re6fe68d rf233256 1 1 .. comment SPDX-License-Identifier: CC-BY-SA-4.0 2 3 .. COMMENT: COPYRIGHT (c) 1988-2002. 4 .. COMMENT: On-Line Applications Research Corporation (OAR). 5 .. COMMENT: All rights reserved. 2 6 3 7 SPARC-64 Specific Information … … 22 26 (http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf) 23 27 24 - UltraSPARC IIIi Processor ( datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf)28 - UltraSPARC IIIi Processor (http://datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf) 25 29 26 30 **sun4v Specific Information** 27 31 28 sun4v is the subset of the SPARC V9 implementations comprising the 29 UltraSPARCT1 or T2 processors.32 sun4v is the subset of the SPARC V9 implementations comprising the UltraSPARC 33 T1 or T2 processors. 30 34 31 35 The following documents were used in developing the SPARC-64 sun4v port: … … 37 41 (http://opensparc-t1.sunsource.net/specs/UST1-UASuppl-current-draft-P-EXT.pdf) 38 42 39 The defining feature that separates the sun4v architecture from its 40 predecessor is the existence of a super-privileged hypervisor that 41 is responsible for providing virtualized execution environments. The impact 42 of the hypervisor on the real-time guarantees available with sun4v has not 43 yet been determined. 43 The defining feature that separates the sun4v architecture from its predecessor 44 is the existence of a super-privileged hypervisor that is responsible for 45 providing virtualized execution environments. The impact of the hypervisor on 46 the real-time guarantees available with sun4v has not yet been determined. 44 47 45 48 CPU Model Dependent Features … … 49 52 ----------------------- 50 53 51 This section presents the set of features which vary across 52 SPARC-64 implementations and 53 are of importance to RTEMS. The set of CPU model feature macros 54 are defined in the file 55 cpukit/score/cpu/sparc64/sparc64.h based upon the particular 56 CPU model defined on the compilation command line. 54 This section presents the set of features which vary across SPARC-64 55 implementations and are of importance to RTEMS. The set of CPU model feature 56 macros are defined in the file cpukit/score/cpu/sparc64/sparc64.h based upon 57 the particular CPU model defined on the compilation command line. 57 58 58 59 CPU Model Name 59 60 ~~~~~~~~~~~~~~ 60 61 61 The macro CPU MODEL NAME is a string which designates 62 the name of this CPU model. 63 For example, for the UltraSPARC T1 SPARC V9 model, 64 this macro is set to the string "sun4v". 62 The macro CPU MODEL NAME is a string which designates the name of this CPU 63 model. For example, for the UltraSPARC T1 SPARC V9 model, this macro is set to 64 the string "sun4v". 65 65 66 66 Floating Point Unit 67 67 ~~~~~~~~~~~~~~~~~~~ 68 68 69 The macro SPARC_HAS_FPU is set to 1 to indicate that 70 this CPU model has a hardware floating point unit and 0 71 otherwise. 69 The macro SPARC_HAS_FPU is set to 1 to indicate that this CPU model has a 70 hardware floating point unit and 0 otherwise. 72 71 73 72 Number of Register Windows 74 73 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 75 74 76 The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to 77 indicate the number of register window sets implemented by this 78 CPU model. The SPARC architecture allows for a maximum of 79 thirty-two register window sets although most implementations 80 only include eight. 75 The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to indicate the number of 76 register window sets implemented by this CPU model. The SPARC architecture 77 allows for a maximum of thirty-two register window sets although most 78 implementations only include eight. 81 79 82 80 CPU Model Implementation Notes 83 81 ------------------------------ 84 82 85 This section describes the implemenation dependencies of the 86 CPU Models sun4uand sun4v of the SPARC V9 architecture.83 This section describes the implemenation dependencies of the CPU Models sun4u 84 and sun4v of the SPARC V9 architecture. 87 85 88 86 sun4u Notes … … 96 94 XXX 97 95 98 .. COMMENT: COPYRIGHT (c) 1988-2002.99 100 .. COMMENT: On-Line Applications Research Corporation (OAR).101 102 .. COMMENT: All rights reserved.103 104 96 Calling Conventions 105 97 =================== 106 98 107 Each high-level language compiler generates 108 subroutine entry and exit code based upon a set of rules known 109 as the compiler's calling convention. These rules address the 110 following issues: 99 Each high-level language compiler generates subroutine entry and exit code 100 based upon a set of rules known as the compiler's calling convention. These 101 rules address the following issues: 111 102 112 103 - register preservation and usage … … 123 114 are both processor and compiler dependent. 124 115 125 The following document also provides some conventions on the 126 global register usage in SPARC V9: 127 http://developers.sun.com/solaris/articles/sparcv9abi.html 116 The following document also provides some conventions on the global register 117 usage in SPARC V9: http://developers.sun.com/solaris/articles/sparcv9abi.html 128 118 129 119 Programming Model 130 120 ----------------- 131 121 132 This section discusses the programming model for the 133 SPARC architecture. 122 This section discusses the programming model for the SPARC architecture. 134 123 135 124 Non-Floating Point Registers 136 125 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 137 126 138 The SPARC architecture defines thirty-two 139 non-floating point registers directly visible to the programmer. 140 These are divided into four sets: 127 The SPARC architecture defines thirty-two non-floating point registers directly 128 visible to the programmer. These are divided into four sets: 141 129 142 130 - input registers … … 148 136 - global registers 149 137 150 Each register is referred to by either two or three 151 names in the SPARC reference manuals. First, the registers are 152 referred to as r0 through r31 or with the alternate notation 153 r[0] through r[31]. Second, each register is a member of one of 154 the four sets listed above. Finally, some registers have an 155 architecturally defined role in the programming model which 156 provides an alternate name. The following table describes the 157 mapping between the 32 registers and the register sets: 158 159 .. code:: c 138 Each register is referred to by either two or three names in the SPARC 139 reference manuals. First, the registers are referred to as r0 through r31 or 140 with the alternate notation r[0] through r[31]. Second, each register is a 141 member of one of the four sets listed above. Finally, some registers have an 142 architecturally defined role in the programming model which provides an 143 alternate name. The following table describes the mapping between the 32 144 registers and the register sets: 160 145 161 146 +-----------------+----------------+------------------+ … … 171 156 +-----------------+----------------+------------------+ 172 157 173 As mentioned above, some of the registers serve 174 defined roles in the programming model. The following table 175 describes the role of each of these registers: 176 177 .. code:: c 158 As mentioned above, some of the registers serve defined roles in the 159 programming model. The following table describes the role of each of these 160 registers: 178 161 179 162 +---------------+----------------+----------------------+ … … 193 176 ~~~~~~~~~~~~~~~~~~~~~~~~ 194 177 195 The SPARC V9 architecture includes sixty-four, 196 thirty-two bit registers. These registers may be viewed as 197 follows: 198 199 - 32 32-bit single precision floating point or integer registers 200 (f0, f1, ... f31) 201 202 - 32 64-bit double precision floating point registers (f0, f2, 203 f4, ... f62) 204 205 - 16 128-bit extended precision floating point registers (f0, f4, 206 f8, ... f60) 207 208 The floating point state register (fsr) specifies 209 the behavior of the floating point unit for rounding, contains 210 its condition codes, version specification, and trap information. 178 The SPARC V9 architecture includes sixty-four, thirty-two bit registers. These 179 registers may be viewed as follows: 180 181 - 32 32-bit single precision floating point or integer registers (f0, f1, 182 ... f31) 183 184 - 32 64-bit double precision floating point registers (f0, f2, f4, ... f62) 185 186 - 16 128-bit extended precision floating point registers (f0, f4, f8, ... f60) 187 188 The floating point state register (fsr) specifies the behavior of the floating 189 point unit for rounding, contains its condition codes, version specification, 190 and trap information. 211 191 212 192 Special Registers … … 216 196 217 197 *``Ancillary State Registers (ASRs)``* 218 The ancillary state registers (ASRs) are optional state registers that 219 maybe privileged or nonprivileged. ASRs 16-31 are implementation-220 dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs. 221 The sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr,222 softint, and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft-223 int set,softint clr, softint, tick cmpr, stick, and stick cmpr.198 The ancillary state registers (ASRs) are optional state registers that may 199 be privileged or nonprivileged. ASRs 16-31 are implementation- 200 dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs. The 201 sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr, softint, 202 and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft- int set, 203 softint clr, softint, tick cmpr, stick, and stick cmpr. 224 204 225 205 *``Processor State Register (pstate)``* … … 233 213 234 214 *``Trap Registers``* 235 The trap handling mechanism of the SPARC V9 includes a number of 236 registers, including: trap program counter (tpc), trap next pc (tnpc), 237 trap state (tstate), trap type (tt), trap base address (tba), and trap 238 level (tl). 215 The trap handling mechanism of the SPARC V9 includes a number of registers, 216 including: trap program counter (tpc), trap next pc (tnpc), trap state 217 (tstate), trap type (tt), trap base address (tba), and trap level (tl). 239 218 240 219 *``Alternate Globals``* 241 The AG bit of the pstate register provides access to an alternate set 242 of global registers. On sun4v, the AG bit is replaced by the global243 level (gl) register, providing access to at least two and at most eight244 alternate setsof globals.220 The AG bit of the pstate register provides access to an alternate set of 221 global registers. On sun4v, the AG bit is replaced by the global level (gl) 222 register, providing access to at least two and at most eight alternate sets 223 of globals. 245 224 246 225 *``Register Window registers``* 247 A number of registers assist in register window management. 248 These include the current window pointer (cwp), savable windows249 (cansave), restorable windows (canrestore), clean windows (clean-250 win), other windows (otherwin),and window state (wstate).226 A number of registers assist in register window management. These include 227 the current window pointer (cwp), savable windows (cansave), restorable 228 windows (canrestore), clean windows (clean- win), other windows (otherwin), 229 and window state (wstate). 251 230 252 231 Register Windows 253 232 ---------------- 254 233 255 The SPARC architecture includes the concept of 256 register windows. An overly simplistic way to think of these 257 windows is to imagine them as being an infinite supply of 258 "fresh" register sets available for each subroutine to use. In 259 reality, they are much more complicated. 260 261 The save instruction is used to obtain a new register window. 262 This instruction increments the current window pointer, thus 263 providing a new set of registers for use. This register set 264 includes eight fresh local registers for use exclusively by 265 this subroutine. When done with a register set, the restore 266 instruction decrements the current window pointer and the 267 previous register set is once again available. 268 269 The two primary issues complicating the use of register windows 270 are that (1) the set of register windows is finite, and (2) some 271 registers are shared between adjacent registers windows. 272 273 Because the set of register windows is finite, it is 274 possible to execute enough save instructions without 275 corresponding restore's to consume all of the register windows. 276 This is easily accomplished in a high level language because 277 each subroutine typically performs a save instruction upon 278 entry. Thus having a subroutine call depth greater than the 279 number of register windows will result in a window overflow 280 condition. The window overflow condition generates a trap which 281 must be handled in software. The window overflow trap handler 282 is responsible for saving the contents of the oldest register 283 window on the program stack. 284 285 Similarly, the subroutines will eventually complete 286 and begin to perform restore's. If the restore results in the 287 need for a register window which has previously been written to 288 memory as part of an overflow, then a window underflow condition 289 results. Just like the window overflow, the window underflow 290 condition must be handled in software by a trap handler. The 291 window underflow trap handler is responsible for reloading the 292 contents of the register window requested by the restore 293 instruction from the program stack. 294 295 The cansave, canrestore, otherwin, and cwp are used in conjunction 296 to manage the finite set of register windows and detect the window 297 overflow and underflow conditions. The first three of these 298 registers must satisfy the invariant cansave + canrestore + otherwin = 299 nwindow - 2, where nwindow is the number of register windows. 300 The cwp contains the index of the register window currently in use. 301 RTEMS does not use the cleanwin and otherwin registers. 302 303 The save instruction increments the cwp modulo the number of 304 register windows, and if cansave is 0 then it also generates a 305 window overflow. Similarly, the restore instruction decrements the 306 cwp modulo the number of register windows, and if canrestore is 0 then it 307 also generates a window underflow. 308 309 Unlike with the SPARC model, the SPARC-64 port does not assume that 310 a register window is available for a trap. The window overflow 311 and underflow conditions are not detected without hardware generating 312 the trap. (These conditions can be detected by reading the register window 313 registers and doing some simple arithmetic.) 314 315 The window overflow and window underflow trap 316 handlers are a critical part of the run-time environment for a 317 SPARC application. The SPARC architectural specification allows 318 for the number of register windows to be any power of two less 319 than or equal to 32. The most common choice for SPARC 320 implementations appears to be 8 register windows. This results 321 in the cwp ranging in value from 0 to 7 on most implementations. 322 323 The second complicating factor is the sharing of 324 registers between adjacent register windows. While each 325 register window has its own set of local registers, the input 326 and output registers are shared between adjacent windows. The 327 output registers for register window N are the same as the input 328 registers for register window ((N + 1) modulo RW) where RW is 329 the number of register windows. An alternative way to think of 330 this is to remember how parameters are passed to a subroutine on 331 the SPARC. The caller loads values into what are its output 332 registers. Then after the callee executes a save instruction, 333 those parameters are available in its input registers. This is 334 a very efficient way to pass parameters as no data is actually 335 moved by the save or restore instructions. 234 The SPARC architecture includes the concept of register windows. An overly 235 simplistic way to think of these windows is to imagine them as being an 236 infinite supply of "fresh" register sets available for each subroutine to use. 237 In reality, they are much more complicated. 238 239 The save instruction is used to obtain a new register window. This instruction 240 increments the current window pointer, thus providing a new set of registers 241 for use. This register set includes eight fresh local registers for use 242 exclusively by this subroutine. When done with a register set, the restore 243 instruction decrements the current window pointer and the previous register set 244 is once again available. 245 246 The two primary issues complicating the use of register windows are that (1) 247 the set of register windows is finite, and (2) some registers are shared 248 between adjacent registers windows. 249 250 Because the set of register windows is finite, it is possible to execute enough 251 save instructions without corresponding restore's to consume all of the 252 register windows. This is easily accomplished in a high level language because 253 each subroutine typically performs a save instruction upon entry. Thus having 254 a subroutine call depth greater than the number of register windows will result 255 in a window overflow condition. The window overflow condition generates a trap 256 which must be handled in software. The window overflow trap handler is 257 responsible for saving the contents of the oldest register window on the 258 program stack. 259 260 Similarly, the subroutines will eventually complete and begin to perform 261 restore's. If the restore results in the need for a register window which has 262 previously been written to memory as part of an overflow, then a window 263 underflow condition results. Just like the window overflow, the window 264 underflow condition must be handled in software by a trap handler. The window 265 underflow trap handler is responsible for reloading the contents of the 266 register window requested by the restore instruction from the program stack. 267 268 The cansave, canrestore, otherwin, and cwp are used in conjunction to manage 269 the finite set of register windows and detect the window overflow and underflow 270 conditions. The first three of these registers must satisfy the invariant 271 cansave + canrestore + otherwin = nwindow - 2, where nwindow is the number of 272 register windows. The cwp contains the index of the register window currently 273 in use. RTEMS does not use the cleanwin and otherwin registers. 274 275 The save instruction increments the cwp modulo the number of register windows, 276 and if cansave is 0 then it also generates a window overflow. Similarly, the 277 restore instruction decrements the cwp modulo the number of register windows, 278 and if canrestore is 0 then it also generates a window underflow. 279 280 Unlike with the SPARC model, the SPARC-64 port does not assume that a register 281 window is available for a trap. The window overflow and underflow conditions 282 are not detected without hardware generating the trap. (These conditions can be 283 detected by reading the register window registers and doing some simple 284 arithmetic.) 285 286 The window overflow and window underflow trap handlers are a critical part of 287 the run-time environment for a SPARC application. The SPARC architectural 288 specification allows for the number of register windows to be any power of two 289 less than or equal to 32. The most common choice for SPARC implementations 290 appears to be 8 register windows. This results in the cwp ranging in value 291 from 0 to 7 on most implementations. 292 293 The second complicating factor is the sharing of registers between adjacent 294 register windows. While each register window has its own set of local 295 registers, the input and output registers are shared between adjacent windows. 296 The output registers for register window N are the same as the input registers 297 for register window ((N + 1) modulo RW) where RW is the number of register 298 windows. An alternative way to think of this is to remember how parameters are 299 passed to a subroutine on the SPARC. The caller loads values into what are its 300 output registers. Then after the callee executes a save instruction, those 301 parameters are available in its input registers. This is a very efficient way 302 to pass parameters as no data is actually moved by the save or restore 303 instructions. 336 304 337 305 Call and Return Mechanism 338 306 ------------------------- 339 307 340 The SPARC architecture supports a simple yet 341 effective call and return mechanism. A subroutine is invoked 342 via the call (call) instruction. This instruction places the 343 return address in the caller's output register 7 (o7). After 344 the callee executes a save instruction, this value is available 345 in input register 7 (i7) until the corresponding restore 346 instruction is executed. 347 348 The callee returns to the caller via a jmp to the 349 return address. There is a delay slot following this 350 instruction which is commonly used to execute a restore 351 instruction - if a register window was allocated by this 352 subroutine. 353 354 It is important to note that the SPARC subroutine 355 call and return mechanism does not automatically save and 356 restore any registers. This is accomplished via the save and 357 restore instructions which manage the set of registers windows. 358 This allows for the compiler to generate leaf-optimized functions 308 The SPARC architecture supports a simple yet effective call and return 309 mechanism. A subroutine is invoked via the call (call) instruction. This 310 instruction places the return address in the caller's output register 7 (o7). 311 After the callee executes a save instruction, this value is available in input 312 register 7 (i7) until the corresponding restore instruction is executed. 313 314 The callee returns to the caller via a jmp to the return address. There is a 315 delay slot following this instruction which is commonly used to execute a 316 restore instruction - if a register window was allocated by this subroutine. 317 318 It is important to note that the SPARC subroutine call and return mechanism 319 does not automatically save and restore any registers. This is accomplished 320 via the save and restore instructions which manage the set of registers 321 windows. This allows for the compiler to generate leaf-optimized functions 359 322 that utilize the caller's output registers without using save and restore. 360 323 … … 362 325 ----------------- 363 326 364 All RTEMS directives are invoked using the regular 365 SPARC calling convention viathe call instruction.327 All RTEMS directives are invoked using the regular SPARC calling convention via 328 the call instruction. 366 329 367 330 Register Usage 368 331 -------------- 369 332 370 As discussed above, the call instruction does not 371 automatically save any registers. The save and restore 372 instructions are used to allocate and deallocate register 373 windows. When a register window is allocated, the new set of 374 local registers are available for the exclusive use of the 375 subroutine which allocated this register set. 333 As discussed above, the call instruction does not automatically save any 334 registers. The save and restore instructions are used to allocate and 335 deallocate register windows. When a register window is allocated, the new set 336 of local registers are available for the exclusive use of the subroutine which 337 allocated this register set. 376 338 377 339 Parameter Passing 378 340 ----------------- 379 341 380 RTEMS assumes that arguments are placed in the 381 caller's output registers with the first argument in output 382 register 0 (o0), the second argument in output register 1 (o1), 383 and so forth. Until the callee executes a save instruction, the 384 parameters are still visible in the output registers. After the 385 callee executes a save instruction, the parameters are visible 386 in the corresponding input registers. The following pseudo-code 387 illustrates the typical sequence used to call a RTEMS directive 388 with three (3) arguments: 389 .. code:: c 342 RTEMS assumes that arguments are placed in the caller's output registers with 343 the first argument in output register 0 (o0), the second argument in output 344 register 1 (o1), and so forth. Until the callee executes a save instruction, 345 the parameters are still visible in the output registers. After the callee 346 executes a save instruction, the parameters are visible in the corresponding 347 input registers. The following pseudo-code illustrates the typical sequence 348 used to call a RTEMS directive with three (3) arguments: 349 350 .. code-block:: c 390 351 391 352 load third argument into o2 … … 397 358 ---------------------- 398 359 399 All user-provided routines invoked by RTEMS, such as 400 user extensions, device drivers, and MPCI routines, must also 401 adhere to these calling conventions. 402 403 .. COMMENT: COPYRIGHT (c) 1988-2002. 404 405 .. COMMENT: On-Line Applications Research Corporation (OAR). 406 407 .. COMMENT: All rights reserved. 360 All user-provided routines invoked by RTEMS, such as user extensions, device 361 drivers, and MPCI routines, must also adhere to these calling conventions. 408 362 409 363 Memory Model 410 364 ============ 411 365 412 A processor may support any combination of memory 413 models ranging from pure physical addressing to complex demand 414 paged virtual memory systems. RTEMS supports a flat memory 415 model which ranges contiguously over the processor's allowable 416 address space. RTEMS does not support segmentation or virtual 417 memory of any kind. The appropriate memory model for RTEMS 418 provided by the targeted processor and related characteristics 419 of that model are described in this chapter. 366 A processor may support any combination of memory models ranging from pure 367 physical addressing to complex demand paged virtual memory systems. RTEMS 368 supports a flat memory model which ranges contiguously over the processor's 369 allowable address space. RTEMS does not support segmentation or virtual memory 370 of any kind. The appropriate memory model for RTEMS provided by the targeted 371 processor and related characteristics of that model are described in this 372 chapter. 420 373 421 374 Flat Memory Model 422 375 ----------------- 423 376 424 The SPARC-64 architecture supports a flat 64-bit address space with 425 addresses ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. 426 Each address is represented by a 64-bit value (and an 8-bit address 427 space identifider or ASI) and is byte addressable. The address 428 may be used to reference a single byte, half-word (2-bytes), 429 word (4 bytes), doubleword (8 bytes), or quad-word (16 bytes). 430 Memory accesses within this address space are performed 431 in big endian fashion by the SPARC. Memory accesses which are not 432 properly aligned generate a "memory address not aligned" trap 433 (type number 0x34). The following table lists the alignment 434 requirements for a variety of data accesses: 435 436 .. code:: c 377 The SPARC-64 architecture supports a flat 64-bit address space with addresses 378 ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. Each address is 379 represented by a 64-bit value (and an 8-bit address space identifider or ASI) 380 and is byte addressable. The address may be used to reference a single byte, 381 half-word (2-bytes), word (4 bytes), doubleword (8 bytes), or quad-word (16 382 bytes). Memory accesses within this address space are performed in big endian 383 fashion by the SPARC. Memory accesses which are not properly aligned generate a 384 "memory address not aligned" trap (type number 0x34). The following table lists 385 the alignment requirements for a variety of data accesses: 386 387 .. table:: 437 388 438 389 +--------------+-----------------------+ … … 446 397 +--------------+-----------------------+ 447 398 448 RTEMS currently does not support any SPARC Memory Management 449 Units, therefore, virtual memory or segmentation systems 450 involving the SPARC are not supported. 451 452 .. COMMENT: COPYRIGHT (c) 1988-2002. 453 454 .. COMMENT: On-Line Applications Research Corporation (OAR). 455 456 .. COMMENT: All rights reserved. 399 RTEMS currently does not support any SPARC Memory Management Units, therefore, 400 virtual memory or segmentation systems involving the SPARC are not supported. 457 401 458 402 Interrupt Processing 459 403 ==================== 460 404 461 RTEMS and associated documentation uses the terms 462 interrupt and vector. In the SPARC architecture, these terms 463 correspond to traps and trap type, respectively. The terms will 464 be used interchangeably in this manual. Note that in the SPARC manuals, 465 interrupts are a subset of the traps that are delivered to software 466 interrupt handlers. 405 RTEMS and associated documentation uses the terms interrupt and vector. In the 406 SPARC architecture, these terms correspond to traps and trap type, 407 respectively. The terms will be used interchangeably in this manual. Note that 408 in the SPARC manuals, interrupts are a subset of the traps that are delivered 409 to software interrupt handlers. 467 410 468 411 Synchronous Versus Asynchronous Traps 469 412 ------------------------------------- 470 413 471 The SPARC architecture includes two classes of traps: 472 synchronous (precise) and asynchronous (deferred). 473 Asynchronous traps occur when an 474 external event interrupts the processor. These traps are not 475 associated with any instruction executed by the processor and 476 logically occur between instructions. The instruction currently 477 in the execute stage of the processor is allowed to complete 478 although subsequent instructions are annulled. The return 479 address reported by the processor for asynchronous traps is the 480 pair of instructions following the current instruction. 481 482 Synchronous traps are caused by the actions of an 483 instruction. The trap stimulus in this case either occurs 484 internally to the processor or is from an external signal that 485 was provoked by the instruction. These traps are taken 486 immediately and the instruction that caused the trap is aborted 487 before any state changes occur in the processor itself. The 488 return address reported by the processor for synchronous traps 489 is the instruction which caused the trap and the following 490 instruction. 414 The SPARC architecture includes two classes of traps: synchronous (precise) and 415 asynchronous (deferred). Asynchronous traps occur when an external event 416 interrupts the processor. These traps are not associated with any instruction 417 executed by the processor and logically occur between instructions. The 418 instruction currently in the execute stage of the processor is allowed to 419 complete although subsequent instructions are annulled. The return address 420 reported by the processor for asynchronous traps is the pair of instructions 421 following the current instruction. 422 423 Synchronous traps are caused by the actions of an instruction. The trap 424 stimulus in this case either occurs internally to the processor or is from an 425 external signal that was provoked by the instruction. These traps are taken 426 immediately and the instruction that caused the trap is aborted before any 427 state changes occur in the processor itself. The return address reported by 428 the processor for synchronous traps is the instruction which caused the trap 429 and the following instruction. 491 430 492 431 Vectoring of Interrupt Handler 493 432 ------------------------------ 494 433 495 Upon receipt of an interrupt the SPARC automatically 496 performs the following actions: 497 498 - The trap level is set. This provides access to a fresh set of 499 privileged trap-state registers used to save the current state, 500 in effect, pushing a frame on the trap stack. 501 TL <- TL + 1 434 Upon receipt of an interrupt the SPARC automatically performs the following 435 actions: 436 437 - The trap level is set. This provides access to a fresh set of privileged 438 trap-state registers used to save the current state, in effect, pushing a 439 frame on the trap stack. TL <- TL + 1 502 440 503 441 - Existing state is preserved … … 537 475 538 476 In order to safely invoke a subroutine during trap handling, traps must be 539 enabled to allow for the possibility of register window overflow and 540 underflow traps. 541 542 If the interrupt handler was installed as an RTEMS 543 interrupt handler, then upon receipt of the interrupt, the 544 processor passes control to the RTEMS interrupt handler which 545 performs the following actions: 477 enabled to allow for the possibility of register window overflow and underflow 478 traps. 479 480 If the interrupt handler was installed as an RTEMS interrupt handler, then upon 481 receipt of the interrupt, the processor passes control to the RTEMS interrupt 482 handler which performs the following actions: 546 483 547 484 - saves the state of the interrupted task on it's stack, … … 549 486 - switches the processor to trap level 0, 550 487 551 - if this is the outermost (i.e. non-nested) interrupt, 552 then the RTEMS interrupt handler switches from the current stack 553 to the interrupt stack, 488 - if this is the outermost (i.e. non-nested) interrupt, then the RTEMS 489 interrupt handler switches from the current stack to the interrupt stack, 554 490 555 491 - enables traps, … … 557 493 - invokes the vectors to a user interrupt service routine (ISR). 558 494 559 Asynchronous interrupts are ignored while traps are 560 disabled. Synchronous traps which occur while traps are 561 disabled may result in the CPU being forced into an error mode. 562 563 A nested interrupt is processed similarly with the 564 exception that the current stack need not be switched to the 565 interrupt stack. 495 Asynchronous interrupts are ignored while traps are disabled. Synchronous 496 traps which occur while traps are disabled may result in the CPU being forced 497 into an error mode. 498 499 A nested interrupt is processed similarly with the exception that the current 500 stack need not be switched to the interrupt stack. 566 501 567 502 Traps and Register Windows … … 573 508 ---------------- 574 509 575 Sixteen levels (0-15) of interrupt priorities are 576 supported by the SPARC architecture with level fifteen (15) 577 being the highest priority. Level zero (0) indicates that 578 interrupts are fully enabled. Interrupt requests for interrupts 579 with priorities less than or equal to the current interrupt mask 510 Sixteen levels (0-15) of interrupt priorities are supported by the SPARC 511 architecture with level fifteen (15) being the highest priority. Level 512 zero (0) indicates that interrupts are fully enabled. Interrupt requests for 513 interrupts with priorities less than or equal to the current interrupt mask 580 514 level are ignored. 581 515 582 Although RTEMS supports 256 interrupt levels, the 583 SPARC only supports sixteen. RTEMS interrupt levels 0 through 584 15 directly correspond to SPARC processor interrupt levels. All 585 other RTEMS interrupt levels are undefined and their behavior is 586 unpredictable. 516 Although RTEMS supports 256 interrupt levels, the SPARC only supports sixteen. 517 RTEMS interrupt levels 0 through 15 directly correspond to SPARC processor 518 interrupt levels. All other RTEMS interrupt levels are undefined and their 519 behavior is unpredictable. 587 520 588 521 Disabling of Interrupts by RTEMS … … 594 527 --------------- 595 528 596 The SPARC architecture does not provide for a 597 dedicated interrupt stack. Thus by default, trap handlers would 598 execute on the stack of the RTEMS task which they interrupted. 599 This artificially inflates the stack requirements for each task 600 since EVERY task stack would have to include enough space to 601 account for the worst case interrupt stack requirements in 602 addition to it's own worst case usage. RTEMS addresses this 603 problem on the SPARC by providing a dedicated interrupt stack 604 managed by software. 605 606 During system initialization, RTEMS allocates the 607 interrupt stack from the Workspace Area. The amount of memory 608 allocated for the interrupt stack is determined by the 609 interrupt_stack_size field in the CPU Configuration Table. As 610 part of processing a non-nested interrupt, RTEMS will switch to 611 the interrupt stack before invoking the installed handler. 612 613 .. COMMENT: COPYRIGHT (c) 1988-2002. 614 615 .. COMMENT: On-Line Applications Research Corporation (OAR). 616 617 .. COMMENT: All rights reserved. 529 The SPARC architecture does not provide for a dedicated interrupt stack. Thus 530 by default, trap handlers would execute on the stack of the RTEMS task which 531 they interrupted. This artificially inflates the stack requirements for each 532 task since EVERY task stack would have to include enough space to account for 533 the worst case interrupt stack requirements in addition to it's own worst case 534 usage. RTEMS addresses this problem on the SPARC by providing a dedicated 535 interrupt stack managed by software. 536 537 During system initialization, RTEMS allocates the interrupt stack from the 538 Workspace Area. The amount of memory allocated for the interrupt stack is 539 determined by the interrupt_stack_size field in the CPU Configuration Table. 540 As part of processing a non-nested interrupt, RTEMS will switch to the 541 interrupt stack before invoking the installed handler. 618 542 619 543 Default Fatal Error Processing 620 544 ============================== 621 545 622 Upon detection of a fatal error by either the 623 application or RTEMS the fatal error manager is invoked. The