[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