[PATCH] score: Delete unused CPU_UNROLL_ENQUEUE_PRIORITY
Sebastian Huber
sebastian.huber at embedded-brains.de
Wed Mar 4 15:14:10 UTC 2015
---
cpukit/score/cpu/arm/rtems/score/cpu.h | 2 --
cpukit/score/cpu/avr/rtems/score/cpu.h | 24 ------------------------
cpukit/score/cpu/bfin/rtems/score/cpu.h | 23 -----------------------
cpukit/score/cpu/h8300/rtems/score/cpu.h | 24 ------------------------
cpukit/score/cpu/i386/rtems/score/cpu.h | 1 -
cpukit/score/cpu/lm32/rtems/score/cpu.h | 23 -----------------------
cpukit/score/cpu/m32c/rtems/score/cpu.h | 23 -----------------------
cpukit/score/cpu/m32r/rtems/score/cpu.h | 23 -----------------------
cpukit/score/cpu/m68k/rtems/score/cpu.h | 1 -
cpukit/score/cpu/mips/rtems/score/cpu.h | 20 --------------------
cpukit/score/cpu/moxie/rtems/score/cpu.h | 23 -----------------------
cpukit/score/cpu/nios2/rtems/score/cpu.h | 5 -----
cpukit/score/cpu/no_cpu/rtems/score/cpu.h | 23 -----------------------
cpukit/score/cpu/or1k/rtems/score/cpu.h | 21 ---------------------
cpukit/score/cpu/powerpc/rtems/score/cpu.h | 20 --------------------
cpukit/score/cpu/sh/rtems/score/cpu.h | 20 --------------------
cpukit/score/cpu/sparc/rtems/score/cpu.h | 16 ----------------
cpukit/score/cpu/sparc64/rtems/score/cpu.h | 17 -----------------
cpukit/score/cpu/v850/rtems/score/cpu.h | 24 ------------------------
19 files changed, 333 deletions(-)
diff --git a/cpukit/score/cpu/arm/rtems/score/cpu.h b/cpukit/score/cpu/arm/rtems/score/cpu.h
index f0573c2..ca8a09f 100644
--- a/cpukit/score/cpu/arm/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/rtems/score/cpu.h
@@ -113,8 +113,6 @@
#error "unknown endianness"
#endif
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
/*
* The ARM uses the PIC interrupt model.
*/
diff --git a/cpukit/score/cpu/avr/rtems/score/cpu.h b/cpukit/score/cpu/avr/rtems/score/cpu.h
index 7a6e9d9..fc5cc59 100644
--- a/cpukit/score/cpu/avr/rtems/score/cpu.h
+++ b/cpukit/score/cpu/avr/rtems/score/cpu.h
@@ -57,30 +57,6 @@ extern "C" {
#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.
- *
- * AVR Specific Information:
- *
- * XXX document implementation including references if appropriate
- */
-
-#define CPU_UNROLL_ENQUEUE_PRIORITY FALSE
-
-/*
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/bfin/rtems/score/cpu.h b/cpukit/score/cpu/bfin/rtems/score/cpu.h
index 0b728e7..52fb3f8 100644
--- a/cpukit/score/cpu/bfin/rtems/score/cpu.h
+++ b/cpukit/score/cpu/bfin/rtems/score/cpu.h
@@ -54,29 +54,6 @@ extern "C" {
#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.
- *
- * Port Specific Information:
- *
- * XXX document implementation including references if appropriate
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/**
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/h8300/rtems/score/cpu.h b/cpukit/score/cpu/h8300/rtems/score/cpu.h
index 334cfbd..56b3fdb 100644
--- a/cpukit/score/cpu/h8300/rtems/score/cpu.h
+++ b/cpukit/score/cpu/h8300/rtems/score/cpu.h
@@ -55,30 +55,6 @@ extern "C" {
#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.
- *
- * H8300 Specific Information:
- *
- * XXX
- */
-
-#define CPU_UNROLL_ENQUEUE_PRIORITY FALSE
-
-/*
* Should this target use 16 or 32 bit object Ids?
*
*/
diff --git a/cpukit/score/cpu/i386/rtems/score/cpu.h b/cpukit/score/cpu/i386/rtems/score/cpu.h
index 5639fdf..96cea5a 100644
--- a/cpukit/score/cpu/i386/rtems/score/cpu.h
+++ b/cpukit/score/cpu/i386/rtems/score/cpu.h
@@ -38,7 +38,6 @@ extern "C" {
/* conditional compilation parameters */
#define CPU_INLINE_ENABLE_DISPATCH TRUE
-#define CPU_UNROLL_ENQUEUE_PRIORITY FALSE
/*
* Does the CPU follow the simple vectored interrupt model?
diff --git a/cpukit/score/cpu/lm32/rtems/score/cpu.h b/cpukit/score/cpu/lm32/rtems/score/cpu.h
index 67d7ebe..4cd07ba 100644
--- a/cpukit/score/cpu/lm32/rtems/score/cpu.h
+++ b/cpukit/score/cpu/lm32/rtems/score/cpu.h
@@ -52,29 +52,6 @@ extern "C" {
#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.
- *
- * Port Specific Information:
- *
- * XXX document implementation including references if appropriate
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/**
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/m32c/rtems/score/cpu.h b/cpukit/score/cpu/m32c/rtems/score/cpu.h
index 55e9853..6ca7972 100644
--- a/cpukit/score/cpu/m32c/rtems/score/cpu.h
+++ b/cpukit/score/cpu/m32c/rtems/score/cpu.h
@@ -68,29 +68,6 @@ extern "C" {
#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.
- *
- * Port Specific Information:
- *
- * XXX document implementation including references if appropriate
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/**
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/m32r/rtems/score/cpu.h b/cpukit/score/cpu/m32r/rtems/score/cpu.h
index 9408045..311578db 100644
--- a/cpukit/score/cpu/m32r/rtems/score/cpu.h
+++ b/cpukit/score/cpu/m32r/rtems/score/cpu.h
@@ -64,29 +64,6 @@ extern "C" {
#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.
- *
- * Port Specific Information:
- *
- * XXX document implementation including references if appropriate
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/**
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/m68k/rtems/score/cpu.h b/cpukit/score/cpu/m68k/rtems/score/cpu.h
index c36b2f1..913bb78 100644
--- a/cpukit/score/cpu/m68k/rtems/score/cpu.h
+++ b/cpukit/score/cpu/m68k/rtems/score/cpu.h
@@ -29,7 +29,6 @@ extern "C" {
/* conditional compilation parameters */
#define CPU_INLINE_ENABLE_DISPATCH TRUE
-#define CPU_UNROLL_ENQUEUE_PRIORITY FALSE
/*
* Does the CPU follow the simple vectored interrupt model?
diff --git a/cpukit/score/cpu/mips/rtems/score/cpu.h b/cpukit/score/cpu/mips/rtems/score/cpu.h
index c1bdc31..4e426f8 100644
--- a/cpukit/score/cpu/mips/rtems/score/cpu.h
+++ b/cpukit/score/cpu/mips/rtems/score/cpu.h
@@ -81,26 +81,6 @@ extern "C" {
#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 _Interrupt_Manager_initialization.
diff --git a/cpukit/score/cpu/moxie/rtems/score/cpu.h b/cpukit/score/cpu/moxie/rtems/score/cpu.h
index 4b204cb..3422d02 100644
--- a/cpukit/score/cpu/moxie/rtems/score/cpu.h
+++ b/cpukit/score/cpu/moxie/rtems/score/cpu.h
@@ -54,29 +54,6 @@ extern "C" {
#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.
- *
- * MOXIE Specific Information:
- *
- * XXX
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY FALSE
-
-/*
* Should this target use 16 or 32 bit object Ids?
*
*/
diff --git a/cpukit/score/cpu/nios2/rtems/score/cpu.h b/cpukit/score/cpu/nios2/rtems/score/cpu.h
index a14392c..d9a7bbd 100644
--- a/cpukit/score/cpu/nios2/rtems/score/cpu.h
+++ b/cpukit/score/cpu/nios2/rtems/score/cpu.h
@@ -32,11 +32,6 @@ extern "C" {
*/
#define CPU_INLINE_ENABLE_DISPATCH FALSE
-/*
- * TODO: Run the timing tests and figure out what is better.
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
#define CPU_HAS_SOFTWARE_INTERRUPT_STACK TRUE
#define CPU_SIMPLE_VECTORED_INTERRUPTS TRUE
diff --git a/cpukit/score/cpu/no_cpu/rtems/score/cpu.h b/cpukit/score/cpu/no_cpu/rtems/score/cpu.h
index c4e838b..f556087 100644
--- a/cpukit/score/cpu/no_cpu/rtems/score/cpu.h
+++ b/cpukit/score/cpu/no_cpu/rtems/score/cpu.h
@@ -69,29 +69,6 @@ extern "C" {
#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.
- *
- * Port Specific Information:
- *
- * XXX document implementation including references if appropriate
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/**
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/or1k/rtems/score/cpu.h b/cpukit/score/cpu/or1k/rtems/score/cpu.h
index 0be9bca..7c6dfda 100644
--- a/cpukit/score/cpu/or1k/rtems/score/cpu.h
+++ b/cpukit/score/cpu/or1k/rtems/score/cpu.h
@@ -60,27 +60,6 @@ extern "C" {
#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.
diff --git a/cpukit/score/cpu/powerpc/rtems/score/cpu.h b/cpukit/score/cpu/powerpc/rtems/score/cpu.h
index 6250c56..06cab2c 100644
--- a/cpukit/score/cpu/powerpc/rtems/score/cpu.h
+++ b/cpukit/score/cpu/powerpc/rtems/score/cpu.h
@@ -69,26 +69,6 @@ extern "C" {
#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 this port provide a CPU dependent IDLE task implementation?
*
* If TRUE, then the routine _CPU_Thread_Idle_body
diff --git a/cpukit/score/cpu/sh/rtems/score/cpu.h b/cpukit/score/cpu/sh/rtems/score/cpu.h
index 217eb7d..76220f7 100644
--- a/cpukit/score/cpu/sh/rtems/score/cpu.h
+++ b/cpukit/score/cpu/sh/rtems/score/cpu.h
@@ -56,26 +56,6 @@ extern "C" {
#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 the CPU follow the simple vectored interrupt model?
*
* If TRUE, then RTEMS allocates the vector table it internally manages.
diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h b/cpukit/score/cpu/sparc/rtems/score/cpu.h
index c3348f0..235b365 100644
--- a/cpukit/score/cpu/sparc/rtems/score/cpu.h
+++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h
@@ -39,22 +39,6 @@ extern "C" {
#define CPU_INLINE_ENABLE_DISPATCH TRUE
/**
- * 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.
- *
- * This parameter could go either way on the SPARC. The interrupt flash
- * code is relatively lengthy given the requirements for nops following
- * writes to the psr. But if the clock speed were high enough, this would
- * not represent a great deal of time.
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/**
* Does the executive manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/sparc64/rtems/score/cpu.h b/cpukit/score/cpu/sparc64/rtems/score/cpu.h
index ff58fc9..a222c0b 100644
--- a/cpukit/score/cpu/sparc64/rtems/score/cpu.h
+++ b/cpukit/score/cpu/sparc64/rtems/score/cpu.h
@@ -43,23 +43,6 @@ extern "C" {
#define CPU_INLINE_ENABLE_DISPATCH TRUE
/*
- * 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.
- *
- * This parameter could go either way on the SPARC. The interrupt flash
- * code is relatively lengthy given the requirements for nops following
- * writes to the psr. But if the clock speed were high enough, this would
- * not represent a great deal of time.
- */
-
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/*
* Does the executive manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in _ISR_Handler_initialization.
diff --git a/cpukit/score/cpu/v850/rtems/score/cpu.h b/cpukit/score/cpu/v850/rtems/score/cpu.h
index e76a2a2..9725900 100644
--- a/cpukit/score/cpu/v850/rtems/score/cpu.h
+++ b/cpukit/score/cpu/v850/rtems/score/cpu.h
@@ -53,30 +53,6 @@ extern "C" {
#define CPU_INLINE_ENABLE_DISPATCH TRUE
/**
- * 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.
- *
- * Port Specific Information:
- *
- * The v850 is a RISC CPU which typically has enough memory to justify
- * the unrolling of this method.
- */
-#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
-
-/**
* Does RTEMS manage a dedicated interrupt stack in software?
*
* If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
--
1.8.4.5
More information about the devel
mailing list