forked from Imagelibrary/rtems
2002-11-06 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
* rtems/new-exceptions/cpu.h: Remove sections on CPU_INLINE_ENABLE_DISPATCH and CPU_UNROLL_ENQUEUE_PRIORITY. * rtems/old-exceptions/cpu.h: Remove sections on CPU_INLINE_ENABLE_DISPATCH and CPU_UNROLL_ENQUEUE_PRIORITY. * rtems/score/cpu.h: Insert sections on CPU_INLINE_ENABLE_DISPATCH and CPU_UNROLL_ENQUEUE_PRIORITY.
This commit is contained in:
@@ -1,3 +1,17 @@
|
||||
2002-11-06 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
|
||||
|
||||
* rtems/new-exceptions/cpu.h: Remove sections on
|
||||
CPU_INLINE_ENABLE_DISPATCH and CPU_UNROLL_ENQUEUE_PRIORITY.
|
||||
* rtems/old-exceptions/cpu.h: Remove sections on
|
||||
CPU_INLINE_ENABLE_DISPATCH and CPU_UNROLL_ENQUEUE_PRIORITY.
|
||||
* rtems/score/cpu.h: Insert sections on
|
||||
CPU_INLINE_ENABLE_DISPATCH and CPU_UNROLL_ENQUEUE_PRIORITY.
|
||||
|
||||
2002-10-31 Joel Sherrill <joel@OARcorp.com>
|
||||
|
||||
* rtems/new-exceptions/cpu.h: Removed warnings.
|
||||
|
||||
|
||||
2002-10-31 Joel Sherrill <joel@OARcorp.com>
|
||||
|
||||
* rtems/new-exceptions/cpu.h: Removed warnings.
|
||||
|
||||
@@ -48,45 +48,6 @@ extern "C" {
|
||||
|
||||
/* 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 FALSE
|
||||
|
||||
/*
|
||||
* Does RTEMS manage a dedicated interrupt stack in software?
|
||||
*
|
||||
|
||||
@@ -48,45 +48,6 @@ typedef void ( *ppc_isr_entry )( int, struct CPU_Interrupt_frame * );
|
||||
|
||||
/* 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 FALSE
|
||||
|
||||
/*
|
||||
* Does RTEMS manage a dedicated interrupt stack in software?
|
||||
*
|
||||
|
||||
@@ -10,6 +10,47 @@
|
||||
#include <rtems/score/types.h>
|
||||
#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 FALSE
|
||||
|
||||
#ifdef _OLD_EXCEPTIONS
|
||||
#include <rtems/old-exceptions/cpu.h>
|
||||
#else
|
||||
|
||||
Reference in New Issue
Block a user