cpu.h

RTEMS (Real-Time Executive for Multiprocessor Systems) is a free open source real-time operating sys

 *  is not really defined by the CPU.  In this case, there is no need
 *  to figure out the exact format -- only the size.  Of course, although
 *  this is enough information for RTEMS, it is probably not enough for
 *  a debugger such as gdb.  But that is another problem.
 *
 *  C4x Specific Information:
 *
 *  From email with Michael Hayes:
 *  > > But what are the rules for what is passed in what registers?
 *  
 *  Args are passed in the following registers (in order):
 *  
 *  AR2, R2, R3, RC, RS, RE
 *  
 *  However, the first and second floating point values are always in R2
 *  and R3 (and all other floats are on the stack).  Structs are always
 *  passed on the stack.  If the last argument is an ellipsis, the
 *  previous argument is passed on the stack so that its address can be
 *  taken for the stdargs macros.
 *  
 *   > > What is assumed to be preserved across calls?
 *  
 *  AR3, AR4, AR5, AR6, AR7   
 *  R4, R5, R8              (using STI/LDI)
 *  R6, R7                  (using STF/LDF)
 *  
 *   > > What is assumed to be scratch registers?
 *  
 *  R0, R1, R2, R3, AR0, AR1, AR2, IR0, IR1, BK, RS, RE, RC, R9, R10, R11
 *  
 *  Based on this information, the task specific context is quite small
 *  but the interrupt context is much larger.  In fact, it could
 *  easily be argued that there is no point in distinguishing between
 *  integer and floating point contexts on the Cxx since there is
 *  so little context involved.  So that is the decision made.
 *
 *  Not Mentioned in list: DP
 *
 *  Assumed to be global resources:
 *
 *  C3X: IE, IF, and IOF
 *  C4X: DIE, IIF, and IIF
 */


typedef struct {
  unsigned int st;
  unsigned int ar3;
  unsigned int ar4;
  unsigned int ar5;
  unsigned int ar6;
  unsigned int ar7;
  unsigned int r4_sti;  /* other part of register is in interrupt context */
  unsigned int r5_sti;  /* other part of register is in interrupt context */
  unsigned int r6_stf;  /* other part of register is in interrupt context */
  unsigned int r7_stf;  /* other part of register is in interrupt context */
#ifdef _TMS320C40
  unsigned int r8_sti;  /* other part of register is in interrupt context */
#endif
  unsigned int sp;
} Context_Control;

typedef struct {
} Context_Control_fp;

/*
 *  This is the order the interrupt entry code pushes the registers.
 */

typedef struct {
  void        *interrupted;
  unsigned int st;
  unsigned int ar2;   /* because the vector numbers goes here */
  unsigned int ar0;
  unsigned int ar1;
  unsigned int dp;
  unsigned int ir0;
  unsigned int ir1;
  unsigned int rs;
  unsigned int re;
  unsigned int rc;
  unsigned int bk;
  unsigned int r0_sti;
  unsigned int r0_stf;
  unsigned int r1_sti;
  unsigned int r1_stf;
  unsigned int r2_sti;
  unsigned int r2_stf;
  unsigned int r3_sti;
  unsigned int r3_stf;
  unsigned int r4_stf;  /* other part of register is in basic context */
  unsigned int r5_stf;  /* other part of register is in basic context */
  unsigned int r6_sti;  /* other part of register is in basic context */
  unsigned int r7_sti;  /* other part of register is in basic context */

#ifdef _TMS320C40
  unsigned int r8_sti;  /* other part of register is in basic context */
  unsigned int r9_sti;
  unsigned int r9_stf;
  unsigned int r10_sti;
  unsigned int r10_stf;
  unsigned int r11_sti;
  unsigned int r11_stf;
#endif

} CPU_Interrupt_frame;

/*
 *  The following table contains the information required to configure
 *  the C4x processor specific parameters.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 */

typedef struct {
  void       (*pretasking_hook)( void );
  void       (*predriver_hook)( void );
  void       (*postdriver_hook)( void );
  void       (*idle_task)( void );
  boolean      do_zero_of_workspace;
  unsigned32   idle_task_stack_size;
  unsigned32   interrupt_stack_size;
  unsigned32   extra_mpci_receive_server_stack;
  void *     (*stack_allocate_hook)( unsigned32 );
  void       (*stack_free_hook)( void* );
  /* end of fields required on all CPUs */

}   rtems_cpu_table;

/*
 *  Macros to access required entires in the CPU Table are in 
 *  the file rtems/system.h.
 */

/*
 *  Macros to access C4X specific additions to the CPU Table
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 */

/* There are no CPU specific additions to the CPU Table for this port. */

#if 0
/*
 *  This variable is optional.  It is used on CPUs on which it is difficult
 *  to generate an "uninitialized" FP context.  It is filled in by
 *  _CPU_Initialize and copied into the task's FP context area during
 *  _CPU_Context_Initialize.
 *
 *  C4x Specific Information:
 *
 *  Unused
 */

SCORE_EXTERN Context_Control_fp  _CPU_Null_fp_context;
#endif

/*
 *  On some CPUs, RTEMS supports a software managed interrupt stack.
 *  This stack is allocated by the Interrupt Manager and the switch
 *  is performed in _ISR_Handler.  These variables contain pointers
 *  to the lowest and highest addresses in the chunk of memory allocated
 *  for the interrupt stack.  Since it is unknown whether the stack
 *  grows up or down (in general), this give the CPU dependent
 *  code the option of picking the version it wants to use.
 *
 *  NOTE: These two variables are required if the macro
 *        CPU_HAS_SOFTWARE_INTERRUPT_STACK is defined as TRUE.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 */

SCORE_EXTERN void               *_CPU_Interrupt_stack_low;
SCORE_EXTERN void               *_CPU_Interrupt_stack_high;

/*
 *  With some compilation systems, it is difficult if not impossible to
 *  call a high-level language routine from assembly language.  This
 *  is especially true of commercial Ada compilers and name mangling
 *  C++ ones.  This variable can be optionally defined by the CPU porter
 *  and contains the address of the routine _Thread_Dispatch.  This
 *  can make it easier to invoke that routine at the end of the interrupt
 *  sequence (if a dispatch is necessary).
 *
 *  C4x Specific Information:
 *
 *  This port should not require this.
 */

#if 0
SCORE_EXTERN void           (*_CPU_Thread_dispatch_pointer)();
#endif

/*
 *  Nothing prevents the porter from declaring more CPU specific variables.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 */

/* XXX: if needed, put more variables here */

/*
 *  The size of the floating point context area.  On some CPUs this
 *  will not be a "sizeof" because the format of the floating point
 *  area is not defined -- only the size is.  This is usually on
 *  CPUs with a "floating point save context" instruction.
 *
 *  C4x Specific Information:
 *
 *  If we decide to have a separate floating point context, then
 *  the answer is the size of the data structure.  Otherwise, we
 *  need to define it as 0 to let upper level configuration work.
 */

#if ( C4X_HAS_FPU == 1 )
#define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp )
#else
#define CPU_CONTEXT_FP_SIZE 0
#endif

/*
 *  Amount of extra stack (above minimum stack size) required by
 *  MPCI receive server thread.  Remember that in a multiprocessor
 *  system this thread must exist and be able to process all directives.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 */

#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0

/*
 *  This defines the number of entries in the ISR_Vector_table managed
 *  by RTEMS.
 *
 *  C4x Specific Information:
 *
 *  Based on the information provided in section 7.6.1 (p. 7-26) 
 *  titled "TMS320C30 and TMS320C31 Interrupt Vector Table" and section
 *  7.6.2 "TMS320C32 Interrupt Vector Table" of the TMS32C3x User's
 *  Guide (rev L, July 1997), vectors are numbered 0x00 - 0x3F.  Thus
 *  there are 0x40 or 64 vectors.
 */

#define CPU_INTERRUPT_NUMBER_OF_VECTORS      0x40
#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER  (CPU_INTERRUPT_NUMBER_OF_VECTORS - 1)

/*
 *  This is defined if the port has a special way to report the ISR nesting
 *  level.  Most ports maintain the variable _ISR_Nest_level.
 */

#define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE

/*
 *  Should be large enough to run all RTEMS tests.  This insures
 *  that a "reasonable" small application should not have any problems.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 */

#define CPU_STACK_MINIMUM_SIZE          (1024)

/*
 *  CPU's worst alignment requirement for data types on a byte boundary.  This
 *  alignment does not take into account the requirements for the stack.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 *  As best I can tell, there are no restrictions since this is a word
 *  -- not byte -- oriented archtiecture.
 */

#define CPU_ALIGNMENT              0

/*
 *  This number corresponds to the byte alignment requirement for the
 *  heap handler.  This alignment requirement may be stricter than that
 *  for the data types alignment specified by CPU_ALIGNMENT.  It is
 *  common for the heap to follow the same alignment requirement as
 *  CPU_ALIGNMENT.  If the CPU_ALIGNMENT is strict enough for the heap,
 *  then this should be set to CPU_ALIGNMENT.
 *
 *  NOTE:  This does not have to be a power of 2.  It does have to
 *         be greater or equal to than CPU_ALIGNMENT.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 *
 *  A CPU_HEAP_ALIGNMENT of 2 comes close to disabling all the rounding
 *  while still ensuring that the least significant bit of the front
 *  and back flags can be used as the used bit -- not part of the size.
 */

#define CPU_HEAP_ALIGNMENT         2

/*
 *  This number corresponds to the byte alignment requirement for memory
 *  buffers allocated by the partition manager.  This alignment requirement
 *  may be stricter than that for the data types alignment specified by
 *  CPU_ALIGNMENT.  It is common for the partition to follow the same
 *  alignment requirement as CPU_ALIGNMENT.  If the CPU_ALIGNMENT is strict
 *  enough for the partition, then this should be set to CPU_ALIGNMENT.
 *
 *  NOTE:  This does not have to be a power of 2.  It does have to
 *         be greater or equal to than CPU_ALIGNMENT.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 *  I think a CPU_PARTITION_ALIGNMENT of 1 will effectively disable all
 *  the rounding.
 */

#define CPU_PARTITION_ALIGNMENT    1

/*
 *  This number corresponds to the byte alignment requirement for the
 *  stack.  This alignment requirement may be stricter than that for the
 *  data types alignment specified by CPU_ALIGNMENT.  If the CPU_ALIGNMENT
 *  is strict enough for the stack, then this should be set to 0.
 *
 *  NOTE:  This must be a power of 2 either 0 or greater than CPU_ALIGNMENT.
 *
 *  C4x Specific Information:
 *
 *  XXXanswer
 */

#define CPU_STACK_ALIGNMENT        0

/*
 *  ISR handler macros
 *
 *  C4x Specific Information:
 *
 *  These macros disable interrupts using the GIE (global interrupts enable)
 *  bit in the status word.
 */

/*
 *  Support routine to initialize the RTEMS vector table after it is allocated.
 */

#define _CPU_Initialize_vectors()

/*
 *  Disable all interrupts for an RTEMS critical section.  The previous
 *  level is returned in _isr_cookie.
 */

#define _CPU_ISR_Disable( _isr_cookie ) \
  do { \
    (_isr_cookie) = c4x_global_interrupts_get(); \
    c4x_global_interrupts_disable(); \
  } while (0)

/*
 *  Enable interrupts to the previous level (returned by _CPU_ISR_Disable).
 *  This indicates the end of an RTEMS critical section.  The parameter
 *  _isr_cookie is not modified.
 */

#define _CPU_ISR_Enable( _isr_cookie )  \
  c4x_global_interrupts_restore( _isr_cookie )

/*
 *  This temporarily restores the interrupt to _isr_cookie before immediately
 *  disabling them again.  This is used to divide long RTEMS critical
 *  sections into two or more parts.  The parameter _isr_cookie is not
 *  modified.
 */

#define _CPU_ISR_Flash( _isr_cookie ) \
  c4x_global_interrupts_flash( _isr_cookie )

/*
 *  Map interrupt level in task mode onto the hardware that the CPU
 *  actually provides.  Currently, interrupt levels which do not
 *  map onto the CPU in a generic fashion are undefined.  Someday,
 *  it would be nice if these were "mapped" by the application
 *  via a callout.  For example, m68k has 8 levels 0 - 7, levels
 *  8 - 255 would be available for bsp/application specific meaning.
 *  This could be used to manage a programmable interrupt controller
 *  via the rtems_task_mode directive.
 *
 *  The get routine usually must be implemented as a subroutine.
 *
 *  C4x Specific Information:
 *
 *  The C4x port probably needs to allow the BSP to define
 *  a mask table for all values 0-255.  For now, 0 is global
 *  interrupts enabled and and non-zero is global interrupts
 *  disabled.  In the future, values 1-254 could be defined as
 *  specific combinations of the global interrupt enabled and the IE mask.
 *
 *  The logic for setting the mask field is something like this:
 *    _ie_value = c4x_get_ie();
 *    _ie_value &= C4X_IE_INTERRUPT_MASK_BITS;
 *    _ie_value |= _ie_mask;
 *    c4x_set_ie(_ie_value);
 *
 *  NOTE:  If this is implemented, then the context of each task
 *         must be extended to include the IE register.
 */

#define _CPU_ISR_Set_level( _new_level ) \
  do { \
    if ( _new_level == 0 ) c4x_global_interrupts_enable(); \
    else                   c4x_global_interrupts_disable(); \