score: Delete unused CPU_UNROLL_ENQUEUE_PRIORITY

19 files changed, 0 insertions, 333 deletions

diff --git a/cpukit/score/cpu/arm/rtems/score/cpu.h b/cpukit/score/cpu/arm/rtems/score/cpu.h
index f0573c2372..ca8a09fbf9 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 7a6e9d91dc..fc5cc595ba 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 0b728e7a1c..52fb3f8a5e 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 334cfbd778..56b3fdbf29 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 5639fdf1dd..96cea5a207 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 67d7ebebac..4cd07ba7bb 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 55e9853aad..6ca79729c6 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 940804596c..311578db7c 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 c36b2f1739..913bb78a71 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 c1bdc318c4..4e426f8bcc 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 4b204cbb43..3422d0205e 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 a14392c821..d9a7bbdf53 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 c4e838b51a..f556087f25 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 0be9bcae31..7c6dfdac83 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 6250c5639f..06cab2c156 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 217eb7da96..76220f7215 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 c3348f0652..235b3652ac 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 ff58fc97d7..a222c0b10a 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 e76a2a2728..97259009d1 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.