From 8ac3549db324367d331b779676212c0a0e3cea7b Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Wed, 4 Mar 2015 16:13:49 +0100 Subject: score: Delete unused CPU_UNROLL_ENQUEUE_PRIORITY --- 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 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 @@ -56,30 +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. - * - * 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? * 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 @@ -53,29 +53,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? * 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 @@ -54,30 +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. - * - * 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 @@ -51,29 +51,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? * 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 @@ -67,29 +67,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? * 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 @@ -63,29 +63,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? * 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 @@ -80,26 +80,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? * 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 @@ -53,29 +53,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 @@ -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? * 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 @@ -59,27 +59,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? * 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 @@ -68,26 +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. - */ - -#define CPU_UNROLL_ENQUEUE_PRIORITY FALSE - /* * Does this port provide a CPU dependent IDLE task implementation? * 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 @@ -55,26 +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. - */ - -#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE - /* * Does the CPU follow the simple vectored interrupt model? * 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 @@ -38,22 +38,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? * 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 @@ -42,23 +42,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? * 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 @@ -52,30 +52,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? * -- cgit v1.2.3