From 8ecc042a2a8abaf14c22198d1007823940d9f534 Mon Sep 17 00:00:00 2001 From: Ralf Corsepius Date: Wed, 6 Nov 2002 11:16:48 +0000 Subject: 2002-11-06 Ralf Corsepius * 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. --- cpukit/score/cpu/powerpc/ChangeLog | 14 ++++++++ .../score/cpu/powerpc/rtems/new-exceptions/cpu.h | 39 -------------------- .../score/cpu/powerpc/rtems/old-exceptions/cpu.h | 39 -------------------- cpukit/score/cpu/powerpc/rtems/score/cpu.h | 41 ++++++++++++++++++++++ 4 files changed, 55 insertions(+), 78 deletions(-) diff --git a/cpukit/score/cpu/powerpc/ChangeLog b/cpukit/score/cpu/powerpc/ChangeLog index c4ff528e15..4f10be962a 100644 --- a/cpukit/score/cpu/powerpc/ChangeLog +++ b/cpukit/score/cpu/powerpc/ChangeLog @@ -1,3 +1,17 @@ +2002-11-06 Ralf Corsepius + + * 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 + + * rtems/new-exceptions/cpu.h: Removed warnings. + + 2002-10-31 Joel Sherrill * rtems/new-exceptions/cpu.h: Removed warnings. diff --git a/cpukit/score/cpu/powerpc/rtems/new-exceptions/cpu.h b/cpukit/score/cpu/powerpc/rtems/new-exceptions/cpu.h index c0a7f8809b..bdb7ec8101 100644 --- a/cpukit/score/cpu/powerpc/rtems/new-exceptions/cpu.h +++ b/cpukit/score/cpu/powerpc/rtems/new-exceptions/cpu.h @@ -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? * diff --git a/cpukit/score/cpu/powerpc/rtems/old-exceptions/cpu.h b/cpukit/score/cpu/powerpc/rtems/old-exceptions/cpu.h index 4ab28fc368..21f5769451 100644 --- a/cpukit/score/cpu/powerpc/rtems/old-exceptions/cpu.h +++ b/cpukit/score/cpu/powerpc/rtems/old-exceptions/cpu.h @@ -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? * diff --git a/cpukit/score/cpu/powerpc/rtems/score/cpu.h b/cpukit/score/cpu/powerpc/rtems/score/cpu.h index 7e181da7f8..a380942c87 100644 --- a/cpukit/score/cpu/powerpc/rtems/score/cpu.h +++ b/cpukit/score/cpu/powerpc/rtems/score/cpu.h @@ -10,6 +10,47 @@ #include #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 #else -- cgit v1.2.3