⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 cpu.h

📁 RTEMS (Real-Time Executive for Multiprocessor Systems) is a free open source real-time operating sys
💻 H
📖 第 1 页 / 共 3 页
字号:
/*  cpu.h * *  This include file contains information pertaining to the HP *  PA-RISC processor (Level 1.1). * *  COPYRIGHT (c) 1994 by Division Incorporated * *  The license and distribution terms for this file may be *  found in the file LICENSE in this distribution or at *  http://www.rtems.com/license/LICENSE. * *  $Id: cpu.h,v 1.14.2.1 2003/09/04 18:47:42 joel Exp $ */#ifndef __CPU_h#define __CPU_h#ifdef __cplusplusextern "C" {#endif#include <rtems/score/unix.h>              /* pick up machine definitions */#ifndef ASM#include <rtems/score/types.h>#endif#include <rtems/score/unixsize.h>#if defined(solaris2)#undef  _POSIX_C_SOURCE#define _POSIX_C_SOURCE 3#endif#if defined(linux)#define MALLOC_0_RETURNS_NULL#endif/* conditional compilation parameters *//* *  Should the calls to _Thread_Enable_dispatch be inlined? * *  If TRUE, then they are inlined. *  If FALSE, then a subroutine call is made. * *  Basically this is an example of the classic trade-off of size *  versus speed.  Inlining the call (TRUE) typically increases the *  size of RTEMS while speeding up the enabling of dispatching. *  [NOTE: In general, the _Thread_Dispatch_disable_level will *  only be 0 or 1 unless you are in an interrupt handler and that *  interrupt handler invokes the executive.]  When not inlined *  something calls _Thread_Enable_dispatch which in turns calls *  _Thread_Dispatch.  If the enable dispatch is inlined, then *  one subroutine call is avoided entirely.] */#define CPU_INLINE_ENABLE_DISPATCH       FALSE/* *  Should the body of the search loops in _Thread_queue_Enqueue_priority *  be unrolled one time?  In unrolled each iteration of the loop examines *  two "nodes" on the chain being searched.  Otherwise, only one node *  is examined per iteration. * *  If TRUE, then the loops are unrolled. *  If FALSE, then the loops are not unrolled. * *  The primary factor in making this decision is the cost of disabling *  and enabling interrupts (_ISR_Flash) versus the cost of rest of the *  body of the loop.  On some CPUs, the flash is more expensive than *  one iteration of the loop body.  In this case, it might be desirable *  to unroll the loop.  It is important to note that on some CPUs, this *  code is the longest interrupt disable period in RTEMS.  So it is *  necessary to strike a balance when setting this parameter. */#define CPU_UNROLL_ENQUEUE_PRIORITY      TRUE/* *  Does RTEMS manage a dedicated interrupt stack in software? * *  If TRUE, then a stack is allocated in _ISR_Handler_initialization. *  If FALSE, nothing is done. * *  If the CPU supports a dedicated interrupt stack in hardware, *  then it is generally the responsibility of the BSP to allocate it *  and set it up. * *  If the CPU does not support a dedicated interrupt stack, then *  the porter has two options: (1) execute interrupts on the *  stack of the interrupted task, and (2) have RTEMS manage a dedicated *  interrupt stack. * *  If this is TRUE, CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE. * *  Only one of CPU_HAS_SOFTWARE_INTERRUPT_STACK and *  CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is *  possible that both are FALSE for a particular CPU.  Although it *  is unclear what that would imply about the interrupt processing *  procedure on that CPU. */#define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE/* *  Does this CPU have hardware support for a dedicated interrupt stack? * *  If TRUE, then it must be installed during initialization. *  If FALSE, then no installation is performed. * *  If this is TRUE, CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE. * *  Only one of CPU_HAS_SOFTWARE_INTERRUPT_STACK and *  CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is *  possible that both are FALSE for a particular CPU.  Although it *  is unclear what that would imply about the interrupt processing *  procedure on that CPU. */#define CPU_HAS_HARDWARE_INTERRUPT_STACK TRUE/* *  Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager? * *  If TRUE, then the memory is allocated during initialization. *  If FALSE, then the memory is allocated during initialization. * *  This should be TRUE if CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE *  or CPU_INSTALL_HARDWARE_INTERRUPT_STACK is TRUE. */#define CPU_ALLOCATE_INTERRUPT_STACK FALSE/* *  Does the RTEMS invoke the user's ISR with the vector number and *  a pointer to the saved interrupt frame (1) or just the vector  *  number (0)? */#define CPU_ISR_PASSES_FRAME_POINTER 0/* *  Does the CPU have hardware floating point? * *  If TRUE, then the RTEMS_FLOATING_POINT task attribute is supported. *  If FALSE, then the RTEMS_FLOATING_POINT task attribute is ignored. * *  If there is a FP coprocessor such as the i387 or mc68881, then *  the answer is TRUE. * *  The macro name "NO_CPU_HAS_FPU" should be made CPU specific. *  It indicates whether or not this CPU model has FP support.  For *  example, it would be possible to have an i386_nofp CPU model *  which set this to false to indicate that you have an i386 without *  an i387 and wish to leave floating point support out of RTEMS. */#define CPU_HARDWARE_FP     TRUE#define CPU_SOFTWARE_FP     FALSE/* *  Are all tasks RTEMS_FLOATING_POINT tasks implicitly? * *  If TRUE, then the RTEMS_FLOATING_POINT task attribute is assumed. *  If FALSE, then the RTEMS_FLOATING_POINT task attribute is followed. * *  So far, the only CPU in which this option has been used is the *  HP PA-RISC.  The HP C compiler and gcc both implicitly use the *  floating point registers to perform integer multiplies.  If *  a function which you would not think utilize the FP unit DOES, *  then one can not easily predict which tasks will use the FP hardware. *  In this case, this option should be TRUE. * *  If CPU_HARDWARE_FP is FALSE, then this should be FALSE as well. */#define CPU_ALL_TASKS_ARE_FP     FALSE/* *  Should the IDLE task have a floating point context? * *  If TRUE, then the IDLE task is created as a RTEMS_FLOATING_POINT task *  and it has a floating point context which is switched in and out. *  If FALSE, then the IDLE task does not have a floating point context. * *  Setting this to TRUE negatively impacts the time required to preempt *  the IDLE task from an interrupt because the floating point context *  must be saved as part of the preemption. */#define CPU_IDLE_TASK_IS_FP      FALSE/* *  Should the saving of the floating point registers be deferred *  until a context switch is made to another different floating point *  task? * *  If TRUE, then the floating point context will not be stored until *  necessary.  It will remain in the floating point registers and not *  disturned until another floating point task is switched to. * *  If FALSE, then the floating point context is saved when a floating *  point task is switched out and restored when the next floating point *  task is restored.  The state of the floating point registers between *  those two operations is not specified. * *  If the floating point context does NOT have to be saved as part of *  interrupt dispatching, then it should be safe to set this to TRUE. * *  Setting this flag to TRUE results in using a different algorithm *  for deciding when to save and restore the floating point context. *  The deferred FP switch algorithm minimizes the number of times *  the FP context is saved and restored.  The FP context is not saved *  until a context switch is made to another, different FP task. *  Thus in a system with only one FP task, the FP context will never *  be saved or restored. */#define CPU_USE_DEFERRED_FP_SWITCH       TRUE/* *  Does this port provide a CPU dependent IDLE task implementation? * *  If TRUE, then the routine _CPU_Thread_Idle_body *  must be provided and is the default IDLE thread body instead of *  _CPU_Thread_Idle_body. * *  If FALSE, then use the generic IDLE thread body if the BSP does *  not provide one. * *  This is intended to allow for supporting processors which have *  a low power or idle mode.  When the IDLE thread is executed, then *  the CPU can be powered down. * *  The order of precedence for selecting the IDLE thread body is: * *    1.  BSP provided *    2.  CPU dependent (if provided) *    3.  generic (if no BSP and no CPU dependent) */#define CPU_PROVIDES_IDLE_THREAD_BODY    TRUE/* *  Does the stack grow up (toward higher addresses) or down *  (toward lower addresses)? * *  If TRUE, then the grows upward. *  If FALSE, then the grows toward smaller addresses. */#if defined(__hppa__)#define CPU_STACK_GROWS_UP               TRUE#elif defined(__sparc__) || defined(__i386__)#define CPU_STACK_GROWS_UP               FALSE#else#error "unknown CPU!!"#endif/* *  The following is the variable attribute used to force alignment *  of critical RTEMS structures.  On some processors it may make *  sense to have these aligned on tighter boundaries than *  the minimum requirements of the compiler in order to have as *  much of the critical data area as possible in a cache line. * *  The placement of this macro in the declaration of the variables *  is based on the syntactically requirements of the GNU C *  "__attribute__" extension.  For example with GNU C, use *  the following to force a structures to a 32 byte boundary. * *      __attribute__ ((aligned (32))) * *  NOTE:  Currently only the Priority Bit Map table uses this feature. *         To benefit from using this, the data must be heavily *         used so it will stay in the cache and used frequently enough *         in the executive to justify turning this on. * *  This is really not critical on the POSIX simulator ports as  *  performance is not the goal here. */#define CPU_STRUCTURE_ALIGNMENT/* *  Define what is required to specify how the network to host conversion *  routines are handled. */#if defined(__hppa__) || defined(__sparc__)#define CPU_HAS_OWN_HOST_TO_NETWORK_ROUTINES     FALSE#define CPU_BIG_ENDIAN                           TRUE#define CPU_LITTLE_ENDIAN                        FALSE#elif defined(__i386__)#define CPU_HAS_OWN_HOST_TO_NETWORK_ROUTINES     FALSE#define CPU_BIG_ENDIAN                           FALSE#define CPU_LITTLE_ENDIAN                        TRUE#else#error "Unknown CPU!!!"#endif/* *  The following defines the number of bits actually used in the *  interrupt field of the task mode.  How those bits map to the *  CPU interrupt levels is defined by the routine _CPU_ISR_Set_level(). */#define CPU_MODES_INTERRUPT_MASK   0x00000001#define CPU_NAME "UNIX"/* *  Processor defined structures * *  Examples structures include the descriptor tables from the i386 *  and the processor control structure on the i960ca. *//* may need to put some structures here.  */#if defined(__hppa__)/* * Word indices within a jmp_buf structure */#ifdef RTEMS_NEWLIB_SETJMP#define RP_OFF       6#define SP_OFF       2#define R3_OFF      10#define R4_OFF      11#define R5_OFF      12#define R6_OFF      13#define R7_OFF      14#define R8_OFF      15#define R9_OFF      16#define R10_OFF     17#define R11_OFF     18#define R12_OFF     19#define R13_OFF     20#define R14_OFF     21#define R15_OFF     22#define R16_OFF     23#define R17_OFF     24#define R18_OFF     25#define DP_OFF      26#endif#ifdef RTEMS_UNIXLIB_SETJMP#define RP_OFF       0#define SP_OFF       1#define R3_OFF       4#define R4_OFF       5#define R5_OFF       6#define R6_OFF       7#define R7_OFF       8#define R8_OFF       9#define R9_OFF      10#define R10_OFF     11#define R11_OFF     12#define R12_OFF     13#define R13_OFF     14#define R14_OFF     15#define R15_OFF     16#define R16_OFF     17#define R17_OFF     18#define R18_OFF     19#define DP_OFF      20#endif#endif#if defined(__i386__) #ifdef RTEMS_NEWLIB

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -