From 6959e663e46b8a0062a7fa131b0cc136922c6a54 Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Wed, 7 Oct 2015 09:13:23 +0200 Subject: epiphany: Delete CPU_UNROLL_ENQUEUE_PRIORITY --- cpukit/score/cpu/epiphany/rtems/score/cpu.h | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/cpukit/score/cpu/epiphany/rtems/score/cpu.h b/cpukit/score/cpu/epiphany/rtems/score/cpu.h index fb5e6b2966..e0c5682db4 100644 --- a/cpukit/score/cpu/epiphany/rtems/score/cpu.h +++ b/cpukit/score/cpu/epiphany/rtems/score/cpu.h @@ -69,27 +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 TRUE - /* * Does RTEMS manage a dedicated interrupt stack in software? * -- cgit v1.2.3