diff options
author | Joel Sherrill <joel.sherrill@OARcorp.com> | 2006-08-23 19:11:14 +0000 |
---|---|---|
committer | Joel Sherrill <joel.sherrill@OARcorp.com> | 2006-08-23 19:11:14 +0000 |
commit | 83fb86f32b73942be758c22423c0bfe506fd4ff6 (patch) | |
tree | d51a136781eaccf67bfb2addfbe5330d9aed4791 /doc/supplements/sparc | |
parent | 2006-08-23 Joel Sherrill <joel@OARcorp.com> (diff) | |
download | rtems-83fb86f32b73942be758c22423c0bfe506fd4ff6.tar.bz2 |
2006-08-23 Joel Sherrill <joel@OARcorp.com>
* Makefile.am, configure.ac, FAQ/stamp-vti, FAQ/version.texi,
common/cpright.texi: Merging CPU Supplements into a single document.
As part of this removed the obsolete and impossible to maintain size
and timing information.
* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
cpu_supplement/arm.t, cpu_supplement/i386.t, cpu_supplement/m68k.t,
cpu_supplement/mips.t, cpu_supplement/powerpc.t,
cpu_supplement/preface.texi, cpu_supplement/sh.t,
cpu_supplement/sparc.t, cpu_supplement/tic4x.t: New files.
* supplements/.cvsignore, supplements/Makefile.am,
supplements/supplement.am, supplements/arm/.cvsignore,
supplements/arm/BSP_TIMES, supplements/arm/ChangeLog,
supplements/arm/Makefile.am, supplements/arm/arm.texi,
supplements/arm/bsp.t, supplements/arm/callconv.t,
supplements/arm/cpumodel.t, supplements/arm/cputable.t,
supplements/arm/fatalerr.t, supplements/arm/intr_NOTIMES.t,
supplements/arm/memmodel.t, supplements/arm/preface.texi,
supplements/arm/timeBSP.t, supplements/c4x/.cvsignore,
supplements/c4x/BSP_TIMES, supplements/c4x/ChangeLog,
supplements/c4x/Makefile.am, supplements/c4x/bsp.t,
supplements/c4x/c4x.texi, supplements/c4x/callconv.t,
supplements/c4x/cpumodel.t, supplements/c4x/cputable.t,
supplements/c4x/fatalerr.t, supplements/c4x/intr_NOTIMES.t,
supplements/c4x/memmodel.t, supplements/c4x/preface.texi,
supplements/c4x/timeBSP.t, supplements/i386/.cvsignore,
supplements/i386/ChangeLog, supplements/i386/FORCE386_TIMES,
supplements/i386/Makefile.am, supplements/i386/bsp.t,
supplements/i386/callconv.t, supplements/i386/cpumodel.t,
supplements/i386/cputable.t, supplements/i386/fatalerr.t,
supplements/i386/i386.texi, supplements/i386/intr_NOTIMES.t,
supplements/i386/memmodel.t, supplements/i386/preface.texi,
supplements/i386/timeFORCE386.t, supplements/m68k/.cvsignore,
supplements/m68k/ChangeLog, supplements/m68k/MVME136_TIMES,
supplements/m68k/Makefile.am, supplements/m68k/bsp.t,
supplements/m68k/callconv.t, supplements/m68k/cpumodel.t,
supplements/m68k/cputable.t, supplements/m68k/fatalerr.t,
supplements/m68k/intr_NOTIMES.t, supplements/m68k/m68k.texi,
supplements/m68k/memmodel.t, supplements/m68k/preface.texi,
supplements/m68k/timeMVME136.t, supplements/m68k/timedata.t,
supplements/mips/.cvsignore, supplements/mips/BSP_TIMES,
supplements/mips/ChangeLog, supplements/mips/Makefile.am,
supplements/mips/bsp.t, supplements/mips/callconv.t,
supplements/mips/cpumodel.t, supplements/mips/cputable.t,
supplements/mips/fatalerr.t, supplements/mips/intr_NOTIMES.t,
supplements/mips/memmodel.t, supplements/mips/mips.texi,
supplements/mips/preface.texi, supplements/mips/timeBSP.t,
supplements/powerpc/.cvsignore, supplements/powerpc/ChangeLog,
supplements/powerpc/DMV177_TIMES, supplements/powerpc/Makefile.am,
supplements/powerpc/PSIM_TIMES, supplements/powerpc/bsp.t,
supplements/powerpc/callconv.t, supplements/powerpc/cpumodel.t,
supplements/powerpc/cputable.t, supplements/powerpc/fatalerr.t,
supplements/powerpc/intr_NOTIMES.t, supplements/powerpc/memmodel.t,
supplements/powerpc/powerpc.texi, supplements/powerpc/preface.texi,
supplements/powerpc/timeDMV177.t, supplements/powerpc/timePSIM.t,
supplements/sh/.cvsignore, supplements/sh/BSP_TIMES,
supplements/sh/ChangeLog, supplements/sh/Makefile.am,
supplements/sh/bsp.t, supplements/sh/callconv.t,
supplements/sh/cpumodel.t, supplements/sh/cputable.t,
supplements/sh/fatalerr.t, supplements/sh/intr_NOTIMES.t,
supplements/sh/memmodel.t, supplements/sh/preface.texi,
supplements/sh/sh.texi, supplements/sh/timeBSP.t,
supplements/sparc/.cvsignore, supplements/sparc/ChangeLog,
supplements/sparc/ERC32_TIMES, supplements/sparc/Makefile.am,
supplements/sparc/bsp.t, supplements/sparc/callconv.t,
supplements/sparc/cpumodel.t, supplements/sparc/cputable.t,
supplements/sparc/fatalerr.t, supplements/sparc/intr_NOTIMES.t,
supplements/sparc/memmodel.t, supplements/sparc/preface.texi,
supplements/sparc/sparc.texi, supplements/sparc/timeERC32.t,
supplements/template/.cvsignore, supplements/template/BSP_TIMES,
supplements/template/ChangeLog, supplements/template/Makefile.am,
supplements/template/bsp.t, supplements/template/callconv.t,
supplements/template/cpumodel.t, supplements/template/cputable.t,
supplements/template/fatalerr.t, supplements/template/intr_NOTIMES.t,
supplements/template/memmodel.t, supplements/template/preface.texi,
supplements/template/template.texi, supplements/template/timeBSP.t: Removed.
Diffstat (limited to 'doc/supplements/sparc')
-rw-r--r-- | doc/supplements/sparc/.cvsignore | 31 | ||||
-rw-r--r-- | doc/supplements/sparc/ChangeLog | 72 | ||||
-rw-r--r-- | doc/supplements/sparc/ERC32_TIMES | 247 | ||||
-rw-r--r-- | doc/supplements/sparc/Makefile.am | 108 | ||||
-rw-r--r-- | doc/supplements/sparc/bsp.t | 87 | ||||
-rw-r--r-- | doc/supplements/sparc/callconv.t | 392 | ||||
-rw-r--r-- | doc/supplements/sparc/cpumodel.t | 128 | ||||
-rw-r--r-- | doc/supplements/sparc/cputable.t | 102 | ||||
-rw-r--r-- | doc/supplements/sparc/fatalerr.t | 32 | ||||
-rw-r--r-- | doc/supplements/sparc/intr_NOTIMES.t | 199 | ||||
-rw-r--r-- | doc/supplements/sparc/memmodel.t | 104 | ||||
-rw-r--r-- | doc/supplements/sparc/preface.texi | 91 | ||||
-rw-r--r-- | doc/supplements/sparc/sparc.texi | 113 | ||||
-rw-r--r-- | doc/supplements/sparc/timeERC32.t | 120 |
14 files changed, 0 insertions, 1826 deletions
diff --git a/doc/supplements/sparc/.cvsignore b/doc/supplements/sparc/.cvsignore deleted file mode 100644 index 9bbd58773d..0000000000 --- a/doc/supplements/sparc/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -rtems_footer.html -rtems_header.html -sparc -sparc-? -sparc-?? -sparc.aux -sparc.cp -sparc.dvi -sparc.fn -sparc*.html -sparc.ky -sparc.log -sparc.pdf -sparc.pg -sparc.ps -sparc.toc -sparc.tp -sparc.vr -stamp-vti -timeERC32_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/sparc/ChangeLog b/doc/supplements/sparc/ChangeLog deleted file mode 100644 index ee5e300ac1..0000000000 --- a/doc/supplements/sparc/ChangeLog +++ /dev/null @@ -1,72 +0,0 @@ -2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill <joel@OARcorp.com> - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill <joel@OARcorp.com> - - * sparc.texi: Merge from branch. - -2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * sparc.texi: Set @setfilename sparc.info. - -2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-21 Joel Sherrill <joel@OARcorp.com> - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill <joel@OARcorp.com> - - * stamp-vti, version.texi: Regenerated. - -2002-10-24 Joel Sherrill <joel@OARcorp.com> - - * stamp-vti, version.texi: Regenerated. - -2002-03-27 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * Makefile.am: Remove AUTOMAKE_OPTIONS. - -2002-01-18 Ralf Corsepius <corsepiu@faw.uni-ulm.de> - - * Makefile.am: Require automake-1.5. - -2001-01-17 Joel Sherrill <joel@OARcorp.com> - - * .cvsignore: Added rtems_header.html and rtems_footer.html. - -2000-08-10 Joel Sherrill <joel@OARcorp.com> - - * ChangeLog: New file. diff --git a/doc/supplements/sparc/ERC32_TIMES b/doc/supplements/sparc/ERC32_TIMES deleted file mode 100644 index 4f9ce4c98b..0000000000 --- a/doc/supplements/sparc/ERC32_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# SPARC/ERC32/SIS Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP ERC32 -RTEMS_CPU_MODEL ERC32 -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 15.0 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.2.0-prerelease -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 21 -RTEMS_RESTORE_1ST_FP_TASK 26 -RTEMS_SAVE_INIT_RESTORE_INIT 24 -RTEMS_SAVE_IDLE_RESTORE_INIT 23 -RTEMS_SAVE_IDLE_RESTORE_IDLE 33 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 59 -RTEMS_TASK_IDENT_ONLY 163 -RTEMS_TASK_START_ONLY 30 -RTEMS_TASK_RESTART_CALLING_TASK 64 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 36 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 47 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 37 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 77 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 84 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 75 -RTEMS_TASK_DELETE_CALLING_TASK 91 -RTEMS_TASK_DELETE_SUSPENDED_TASK 47 -RTEMS_TASK_DELETE_BLOCKED_TASK 50 -RTEMS_TASK_DELETE_READY_TASK 51 -RTEMS_TASK_SUSPEND_CALLING_TASK 56 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 16 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 17 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 52 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 10 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 25 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 67 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 5 -RTEMS_TASK_MODE_NO_RESCHEDULE 6 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 9 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 42 -RTEMS_TASK_GET_NOTE_ONLY 10 -RTEMS_TASK_SET_NOTE_ONLY 10 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 6 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 49 -RTEMS_TASK_WAKE_WHEN_ONLY 75 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 7 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 8 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 8 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED 5 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 7 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 14 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 33 -RTEMS_CLOCK_GET_ONLY 4 -RTEMS_CLOCK_TICK_ONLY 6 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 11 -RTEMS_TIMER_IDENT_ONLY 159 -RTEMS_TIMER_DELETE_INACTIVE 15 -RTEMS_TIMER_DELETE_ACTIVE 17 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 21 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 23 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 34 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 34 -RTEMS_TIMER_RESET_INACTIVE 20 -RTEMS_TIMER_RESET_ACTIVE 22 -RTEMS_TIMER_CANCEL_INACTIVE 10 -RTEMS_TIMER_CANCEL_ACTIVE 13 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 19 -RTEMS_SEMAPHORE_IDENT_ONLY 171 -RTEMS_SEMAPHORE_DELETE_ONLY 19 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 12 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 12 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 67 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 14 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 23 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 57 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 114 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 159 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 25 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 36 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 38 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 76 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 36 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 38 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 76 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 15 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 42 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 83 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 30 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 13 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 67 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 9 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 13 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 9 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 22 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 58 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 -RTEMS_EVENT_RECEIVE_AVAILABLE 10 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 9 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 60 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 6 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 14 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 22 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 27 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 56 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 34 -RTEMS_PARTITION_IDENT_ONLY 159 -RTEMS_PARTITION_DELETE_ONLY 14 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 12 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 16 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 22 -RTEMS_REGION_IDENT_ONLY 162 -RTEMS_REGION_DELETE_ONLY 14 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 19 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 19 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 67 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 17 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 44 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 77 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 14 -RTEMS_PORT_IDENT_ONLY 159 -RTEMS_PORT_DELETE_ONLY 13 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 9 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 9 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 2 -RTEMS_IO_OPEN_ONLY 1 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY 1 -RTEMS_IO_WRITE_ONLY 1 -RTEMS_IO_CONTROL_ONLY 1 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 12 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 159 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 14 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 19 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 16 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 20 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 55 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 9 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 9059 -RTEMS_MINIMUM_CONFIGURATION 28,288 -RTEMS_MAXIMUM_CONFIGURATION 50,432 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 20,336 -RTEMS_INITIALIZATION_CODE_SIZE 1,408 -RTEMS_TASK_CODE_SIZE 4,496 -RTEMS_INTERRUPT_CODE_SIZE 72 -RTEMS_CLOCK_CODE_SIZE 576 -RTEMS_TIMER_CODE_SIZE 1,336 -RTEMS_SEMAPHORE_CODE_SIZE 1,888 -RTEMS_MESSAGE_CODE_SIZE 2,032 -RTEMS_EVENT_CODE_SIZE 1,696 -RTEMS_SIGNAL_CODE_SIZE 664 -RTEMS_PARTITION_CODE_SIZE 1,368 -RTEMS_REGION_CODE_SIZE 1,736 -RTEMS_DPMEM_CODE_SIZE 872 -RTEMS_IO_CODE_SIZE 1,144 -RTEMS_FATAL_ERROR_CODE_SIZE 32 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,656 -RTEMS_MULTIPROCESSING_CODE_SIZE 8,328 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 208 -RTEMS_SEMAPHORE_CODE_OPTSIZE 192 -RTEMS_MESSAGE_CODE_OPTSIZE 320 -RTEMS_EVENT_CODE_OPTSIZE 64 -RTEMS_SIGNAL_CODE_OPTSIZE 64 -RTEMS_PARTITION_CODE_OPTSIZE 152 -RTEMS_REGION_CODE_OPTSIZE 176 -RTEMS_DPMEM_CODE_OPTSIZE 152 -RTEMS_IO_CODE_OPTSIZE 00 -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 208 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 408 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 488 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 124 -RTEMS_BYTES_PER_MESSAGE_QUEUE 148 -RTEMS_BYTES_PER_REGION 144 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 136 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10,072 diff --git a/doc/supplements/sparc/Makefile.am b/doc/supplements/sparc/Makefile.am deleted file mode 100644 index 14ec898a66..0000000000 --- a/doc/supplements/sparc/Makefile.am +++ /dev/null @@ -1,108 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = sparc -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \ - timeERC32.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi - -FILES = preface.texi - -info_TEXINFOS = sparc.texi -sparc_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features CPU Model Implementation Notes" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t ERC32_TIMES - ${REPLACE2} -p $(srcdir)/ERC32_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Obtain the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t ERC32_TIMES - ${REPLACE2} -p $(srcdir)/ERC32_TIMES $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "ERC32 Timing Data" < $< > $@ - -# Timing Data for ERC32 BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeERC32.texi: $(top_srcdir)/common/timetbl.t timeERC32.t - cat $(srcdir)/timeERC32.t $(top_srcdir)/common/timetbl.t >timeERC32_.t - @echo >>timeERC32_.t - @echo "@tex" >>timeERC32_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeERC32_.t - @echo "@end tex" >>timeERC32_.t - ${REPLACE2} -p $(srcdir)/ERC32_TIMES timeERC32_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeERC32_.t - -EXTRA_DIST = ERC32_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ - intr_NOTIMES.t memmodel.t timeERC32.t - -CLEANFILES += sparc.info sparc.info-? diff --git a/doc/supplements/sparc/bsp.t b/doc/supplements/sparc/bsp.t deleted file mode 100644 index 8810614825..0000000000 --- a/doc/supplements/sparc/bsp.t +++ /dev/null @@ -1,87 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of SPARC specific BSP issues. -For more information on developing a BSP, refer to the chapter -titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the SPARC processor is reset. When the SPARC -is reset, the processor performs the following actions: - -@itemize @bullet -@item the enable trap (ET) of the psr is set to 0 to disable -traps, - -@item the supervisor bit (S) of the psr is set to 1 to enter -supervisor mode, and - -@item the PC is set 0 and the nPC is set to 4. -@end itemize - -The processor then begins to execute the code at -location 0. It is important to note that all fields in the psr -are not explicitly set by the above steps and all other -registers retain their value from the previous execution mode. -This is true even of the Trap Base Register (TBR) whose contents -reflect the last trap which occurred before the reset. - -@section Processor Initialization - -It is the responsibility of the application's -initialization code to initialize the TBR and install trap -handlers for at least the register window overflow and register -window underflow conditions. Traps should be enabled before -invoking any subroutines to allow for register window -management. However, interrupts should be disabled by setting -the Processor Interrupt Level (pil) field of the psr to 15. -RTEMS installs it's own Trap Table as part of initialization -which is initialized with the contents of the Trap Table in -place when the @code{rtems_initialize_executive} directive was invoked. -Upon completion of executive initialization, interrupts are -enabled. - -If this SPARC implementation supports on-chip caching -and this is to be utilized, then it should be enabled during the -reset application initialization code. - -In addition to the requirements described in the -Board Support Packages chapter of the @value{LANGUAGE} -Applications User's Manual for the reset code -which is executed before the call to -@code{rtems_initialize_executive}, the SPARC version has the following -specific requirements: - -@itemize @bullet -@item Must leave the S bit of the status register set so that -the SPARC remains in the supervisor state. - -@item Must set stack pointer (sp) such that a minimum stack -size of MINIMUM_STACK_SIZE bytes is provided for the -@code{rtems_initialize_executive} directive. - -@item Must disable all external interrupts (i.e. set the pil -to 15). - -@item Must enable traps so window overflow and underflow -conditions can be properly handled. - -@item Must initialize the SPARC's initial trap table with at -least trap handlers for register window overflow and register -window underflow. -@end itemize - diff --git a/doc/supplements/sparc/callconv.t b/doc/supplements/sparc/callconv.t deleted file mode 100644 index 2b968ebb0b..0000000000 --- a/doc/supplements/sparc/callconv.t +++ /dev/null @@ -1,392 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage - -@item parameter passing - -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -@section Programming Model - -This section discusses the programming model for the -SPARC architecture. - -@subsection Non-Floating Point Registers - -The SPARC architecture defines thirty-two -non-floating point registers directly visible to the programmer. -These are divided into four sets: - -@itemize @bullet -@item input registers - -@item local registers - -@item output registers - -@item global registers -@end itemize - -Each register is referred to by either two or three -names in the SPARC reference manuals. First, the registers are -referred to as r0 through r31 or with the alternate notation -r[0] through r[31]. Second, each register is a member of one of -the four sets listed above. Finally, some registers have an -architecturally defined role in the programming model which -provides an alternate name. The following table describes the -mapping between the 32 registers and the register sets: - -@ifset use-ascii -@example -@group - +-----------------+----------------+------------------+ - | Register Number | Register Names | Description | - +-----------------+----------------+------------------+ - | 0 - 7 | g0 - g7 | Global Registers | - +-----------------+----------------+------------------+ - | 8 - 15 | o0 - o7 | Output Registers | - +-----------------+----------------+------------------+ - | 16 - 23 | l0 - l7 | Local Registers | - +-----------------+----------------+------------------+ - | 24 - 31 | i0 - i7 | Input Registers | - +-----------------+----------------+------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\vrule\strut#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#\cr -\noalign{\hrule} -&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} -&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} -&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} -&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} -&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -<CENTER> - <TABLE COLS=3 WIDTH="80%" BORDER=2> -<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD> - <TD ALIGN=center><STRONG>Register Names</STRONG></TD> - <TD ALIGN=center><STRONG>Description</STRONG></TD> -<TR><TD ALIGN=center>0 - 7</TD> - <TD ALIGN=center>g0 - g7</TD> - <TD ALIGN=center>Global Registers</TD></TR> -<TR><TD ALIGN=center>8 - 15</TD> - <TD ALIGN=center>o0 - o7</TD> - <TD ALIGN=center>Output Registers</TD></TR> -<TR><TD ALIGN=center>16 - 23</TD> - <TD ALIGN=center>l0 - l7</TD> - <TD ALIGN=center>Local Registers</TD></TR> -<TR><TD ALIGN=center>24 - 31</TD> - <TD ALIGN=center>i0 - i7</TD> - <TD ALIGN=center>Input Registers</TD></TR> - </TABLE> -</CENTER> -@end html -@end ifset - -As mentioned above, some of the registers serve -defined roles in the programming model. The following table -describes the role of each of these registers: - -@ifset use-ascii -@example -@group - +---------------+----------------+----------------------+ - | Register Name | Alternate Name | Description | - +---------------+----------------+----------------------+ - | g0 | na | reads return 0 | - | | | writes are ignored | - +---------------+----------------+----------------------+ - | o6 | sp | stack pointer | - +---------------+----------------+----------------------+ - | i6 | fp | frame pointer | - +---------------+----------------+----------------------+ - | i7 | na | return address | - +---------------+----------------+----------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\vrule\strut#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#\cr -\noalign{\hrule} -&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} -&g0&&NA&&reads return 0; &\cr -&&&&&writes are ignored&\cr\noalign{\hrule} -&o6&&sp&&stack pointer&\cr\noalign{\hrule} -&i6&&fp&&frame pointer&\cr\noalign{\hrule} -&i7&&NA&&return address&\cr\noalign{\hrule} -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -<CENTER> - <TABLE COLS=3 WIDTH="80%" BORDER=2> -<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD> - <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD> - <TD ALIGN=center><STRONG>Description</STRONG></TD></TR> -<TR><TD ALIGN=center>g0</TD> - <TD ALIGN=center>NA</TD> - <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR> -<TR><TD ALIGN=center>o6</TD> - <TD ALIGN=center>sp</TD> - <TD ALIGN=center>stack pointer</TD></TR> -<TR><TD ALIGN=center>i6</TD> - <TD ALIGN=center>fp</TD> - <TD ALIGN=center>frame pointer</TD></TR> -<TR><TD ALIGN=center>i7</TD> - <TD ALIGN=center>NA</TD> - <TD ALIGN=center>return address</TD></TR> - </TABLE> -</CENTER> -@end html -@end ifset - - -@subsection Floating Point Registers - -The SPARC V7 architecture includes thirty-two, -thirty-two bit registers. These registers may be viewed as -follows: - -@itemize @bullet -@item 32 single precision floating point or integer registers -(f0, f1, ... f31) - -@item 16 double precision floating point registers (f0, f2, -f4, ... f30) - -@item 8 extended precision floating point registers (f0, f4, -f8, ... f28) -@end itemize - -The floating point status register (fpsr) specifies -the behavior of the floating point unit for rounding, contains -its condition codes, version specification, and trap information. - -A queue of the floating point instructions which have -started execution but not yet completed is maintained. This -queue is needed to support the multiple cycle nature of floating -point operations and to aid floating point exception trap -handlers. Once a floating point exception has been encountered, -the queue is frozen until it is emptied by the trap handler. -The floating point queue is loaded by launching instructions. -It is emptied normally when the floating point completes all -outstanding instructions and by floating point exception -handlers with the store double floating point queue (stdfq) -instruction. - -@subsection Special Registers - -The SPARC architecture includes two special registers -which are critical to the programming model: the Processor State -Register (psr) and the Window Invalid Mask (wim). The psr -contains the condition codes, processor interrupt level, trap -enable bit, supervisor mode and previous supervisor mode bits, -version information, floating point unit and coprocessor enable -bits, and the current window pointer (cwp). The cwp field of -the psr and wim register are used to manage the register windows -in the SPARC architecture. The register windows are discussed -in more detail below. - -@section Register Windows - -The SPARC architecture includes the concept of -register windows. An overly simplistic way to think of these -windows is to imagine them as being an infinite supply of -"fresh" register sets available for each subroutine to use. In -reality, they are much more complicated. - -The save instruction is used to obtain a new register -window. This instruction decrements the current window pointer, -thus providing a new set of registers for use. This register -set includes eight fresh local registers for use exclusively by -this subroutine. When done with a register set, the restore -instruction increments the current window pointer and the -previous register set is once again available. - -The two primary issues complicating the use of -register windows are that (1) the set of register windows is -finite, and (2) some registers are shared between adjacent -registers windows. - -Because the set of register windows is finite, it is -possible to execute enough save instructions without -corresponding restore's to consume all of the register windows. -This is easily accomplished in a high level language because -each subroutine typically performs a save instruction upon -entry. Thus having a subroutine call depth greater than the -number of register windows will result in a window overflow -condition. The window overflow condition generates a trap which -must be handled in software. The window overflow trap handler -is responsible for saving the contents of the oldest register -window on the program stack. - -Similarly, the subroutines will eventually complete -and begin to perform restore's. If the restore results in the -need for a register window which has previously been written to -memory as part of an overflow, then a window underflow condition -results. Just like the window overflow, the window underflow -condition must be handled in software by a trap handler. The -window underflow trap handler is responsible for reloading the -contents of the register window requested by the restore -instruction from the program stack. - -The Window Invalid Mask (wim) and the Current Window -Pointer (cwp) field in the psr are used in conjunction to manage -the finite set of register windows and detect the window -overflow and underflow conditions. The cwp contains the index -of the register window currently in use. The save instruction -decrements the cwp modulo the number of register windows. -Similarly, the restore instruction increments the cwp modulo the -number of register windows. Each bit in the wim represents -represents whether a register window contains valid information. -The value of 0 indicates the register window is valid and 1 -indicates it is invalid. When a save instruction causes the cwp -to point to a register window which is marked as invalid, a -window overflow condition results. Conversely, the restore -instruction may result in a window underflow condition. - -Other than the assumption that a register window is -always available for trap (i.e. interrupt) handlers, the SPARC -architecture places no limits on the number of register windows -simultaneously marked as invalid (i.e. number of bits set in the -wim). However, RTEMS assumes that only one register window is -marked invalid at a time (i.e. only one bit set in the wim). -This makes the maximum possible number of register windows -available to the user while still meeting the requirement that -window overflow and underflow conditions can be detected. - -The window overflow and window underflow trap -handlers are a critical part of the run-time environment for a -SPARC application. The SPARC architectural specification allows -for the number of register windows to be any power of two less -than or equal to 32. The most common choice for SPARC -implementations appears to be 8 register windows. This results -in the cwp ranging in value from 0 to 7 on most implementations. - - -The second complicating factor is the sharing of -registers between adjacent register windows. While each -register window has its own set of local registers, the input -and output registers are shared between adjacent windows. The -output registers for register window N are the same as the input -registers for register window ((N - 1) modulo RW) where RW is -the number of register windows. An alternative way to think of -this is to remember how parameters are passed to a subroutine on -the SPARC. The caller loads values into what are its output -registers. Then after the callee executes a save instruction, -those parameters are available in its input registers. This is -a very efficient way to pass parameters as no data is actually -moved by the save or restore instructions. - -@section Call and Return Mechanism - -The SPARC architecture supports a simple yet -effective call and return mechanism. A subroutine is invoked -via the call (call) instruction. This instruction places the -return address in the caller's output register 7 (o7). After -the callee executes a save instruction, this value is available -in input register 7 (i7) until the corresponding restore -instruction is executed. - -The callee returns to the caller via a jmp to the -return address. There is a delay slot following this -instruction which is commonly used to execute a restore -instruction -- if a register window was allocated by this -subroutine. - -It is important to note that the SPARC subroutine -call and return mechanism does not automatically save and -restore any registers. This is accomplished via the save and -restore instructions which manage the set of registers windows. - -@section Calling Mechanism - -All RTEMS directives are invoked using the regular -SPARC calling convention via the call instruction. - -@section Register Usage - -As discussed above, the call instruction does not -automatically save any registers. The save and restore -instructions are used to allocate and deallocate register -windows. When a register window is allocated, the new set of -local registers are available for the exclusive use of the -subroutine which allocated this register set. - -@section Parameter Passing - -RTEMS assumes that arguments are placed in the -caller's output registers with the first argument in output -register 0 (o0), the second argument in output register 1 (o1), -and so forth. Until the callee executes a save instruction, the -parameters are still visible in the output registers. After the -callee executes a save instruction, the parameters are visible -in the corresponding input registers. The following pseudo-code -illustrates the typical sequence used to call a RTEMS directive -with three (3) arguments: - -@example -load third argument into o2 -load second argument into o1 -load first argument into o0 -invoke directive -@end example - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/sparc/cpumodel.t b/doc/supplements/sparc/cpumodel.t deleted file mode 100644 index d676fcc480..0000000000 --- a/doc/supplements/sparc/cpumodel.t +++ /dev/null @@ -1,128 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. - -@section CPU Model Feature Flags - -Each processor family supported by RTEMS has a -list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This section presents the set of features which vary -across SPARC implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/sparc/sparc.h based upon the particular CPU -model defined on the compilation command line. - -@subsection CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the European Space -Agency's ERC32 SPARC model, this macro is set to the string -"erc32". - -@subsection Floating Point Unit - -The macro SPARC_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. - -@subsection Bitscan Instruction - -The macro SPARC_HAS_BITSCAN is set to 1 to indicate -that this CPU model has the bitscan instruction. For example, -this instruction is supported by the Fujitsu SPARClite family. - -@subsection Number of Register Windows - -The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to -indicate the number of register window sets implemented by this -CPU model. The SPARC architecture allows a for a maximum of -thirty-two register window sets although most implementations -only include eight. - -@subsection Low Power Mode - -The macro SPARC_HAS_LOW_POWER_MODE is set to one to -indicate that this CPU model has a low power mode. If low power -is enabled, then there must be CPU model specific implementation -of the IDLE task in cpukit/score/cpu/sparc/cpu.c. The low -power mode IDLE task should be of the form: - -@example -while ( TRUE ) @{ - enter low power mode -@} -@end example - -The code required to enter low power mode is CPU model specific. - -@section CPU Model Implementation Notes - -The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602 -chipset. This CPU has a number of on-board peripherals and was developed by -the European Space Agency to target space applications. RTEMS currently -provides support for the following peripherals: - -@itemize @bullet -@item UART Channels A and B -@item General Purpose Timer -@item Real Time Clock -@item Watchdog Timer (so it can be disabled) -@item Control Register (so powerdown mode can be enabled) -@item Memory Control Register -@item Interrupt Control -@end itemize - -The General Purpose Timer and Real Time Clock Timer provided with the ERC32 -share the Timer Control Register. Because the Timer Control Register is write -only, we must mirror it in software and insure that writes to one timer do not -alter the current settings and status of the other timer. Routines are -provided in erc32.h which promote the view that the two timers are completely -independent. By exclusively using these routines to access the Timer Control -Register, the application can view the system as having a General Purpose -Timer Control Register and a Real Time Clock Timer Control Register -rather than the single shared value. - -The RTEMS Idle thread take advantage of the low power mode provided by the -ERC32. Low power mode is entered during idle loops and is enabled at -initialization time. diff --git a/doc/supplements/sparc/cputable.t b/doc/supplements/sparc/cputable.t deleted file mode 100644 index 22873590c1..0000000000 --- a/doc/supplements/sparc/cputable.t +++ /dev/null @@ -1,102 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The SPARC version of the RTEMS CPU Dependent -Information Table is given by the C structure definition is -shown below: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS allocated interrupt stack in bytes. -This value must be at least as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@end table - diff --git a/doc/supplements/sparc/fatalerr.t b/doc/supplements/sparc/fatalerr.t deleted file mode 100644 index 6de94ba8f4..0000000000 --- a/doc/supplements/sparc/fatalerr.t +++ /dev/null @@ -1,32 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the fatal_error_occurred directive when there is no user handler -configured or the user handler returns control to RTEMS. The -default fatal error handler disables processor interrupts to -level 15, places the error code in g1, and goes into an infinite -loop to simulate a halt processor instruction. - - diff --git a/doc/supplements/sparc/intr_NOTIMES.t b/doc/supplements/sparc/intr_NOTIMES.t deleted file mode 100644 index a66ccc981d..0000000000 --- a/doc/supplements/sparc/intr_NOTIMES.t +++ /dev/null @@ -1,199 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Interrupt Processing - -@section Introduction - -Different types of processors respond to the -occurrence of an interrupt in its own unique fashion. In -addition, each processor type provides a control mechanism to -allow for the proper handling of an interrupt. The processor -dependent response to the interrupt modifies the current -execution state and results in a change in the execution stream. -Most processors require that an interrupt handler utilize some -special control mechanisms to return to the normal processing -stream. Although RTEMS hides many of the processor dependent -details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor's -unique architecture. Discussed in this chapter are the SPARC's -interrupt response and control mechanisms as they pertain to -RTEMS. - -RTEMS and associated documentation uses the terms -interrupt and vector. In the SPARC architecture, these terms -correspond to traps and trap type, respectively. The terms will -be used interchangeably in this manual. - -@section Synchronous Versus Asynchronous Traps - -The SPARC architecture includes two classes of traps: -synchronous and asynchronous. Asynchronous traps occur when an -external event interrupts the processor. These traps are not -associated with any instruction executed by the processor and -logically occur between instructions. The instruction currently -in the execute stage of the processor is allowed to complete -although subsequent instructions are annulled. The return -address reported by the processor for asynchronous traps is the -pair of instructions following the current instruction. - -Synchronous traps are caused by the actions of an -instruction. The trap stimulus in this case either occurs -internally to the processor or is from an external signal that -was provoked by the instruction. These traps are taken -immediately and the instruction that caused the trap is aborted -before any state changes occur in the processor itself. The -return address reported by the processor for synchronous traps -is the instruction which caused the trap and the following -instruction. - -@section Vectoring of Interrupt Handler - -Upon receipt of an interrupt the SPARC automatically -performs the following actions: - -@itemize @bullet -@item disables traps (sets the ET bit of the psr to 0), - -@item the S bit of the psr is copied into the Previous -Supervisor Mode (PS) bit of the psr, - -@item the cwp is decremented by one (modulo the number of -register windows) to activate a trap window, - -@item the PC and nPC are loaded into local register 1 and 2 -(l0 and l1), - -@item the trap type (tt) field of the Trap Base Register (TBR) -is set to the appropriate value, and - -@item if the trap is not a reset, then the PC is written with -the contents of the TBR and the nPC is written with TBR + 4. If -the trap is a reset, then the PC is set to zero and the nPC is -set to 4. -@end itemize - -Trap processing on the SPARC has two features which -are noticeably different than interrupt processing on other -architectures. First, the value of psr register in effect -immediately before the trap occurred is not explicitly saved. -Instead only reversible alterations are made to it. Second, the -Processor Interrupt Level (pil) is not set to correspond to that -of the interrupt being processed. When a trap occurs, ALL -subsequent traps are disabled. In order to safely invoke a -subroutine during trap handling, traps must be enabled to allow -for the possibility of register window overflow and underflow -traps. - -If the interrupt handler was installed as an RTEMS -interrupt handler, then upon receipt of the interrupt, the -processor passes control to the RTEMS interrupt handler which -performs the following actions: - -@itemize @bullet -@item saves the state of the interrupted task on it's stack, - -@item insures that a register window is available for -subsequent traps, - -@item if this is the outermost (i.e. non-nested) interrupt, -then the RTEMS interrupt handler switches from the current stack -to the interrupt stack, - -@item enables traps, - -@item invokes the vectors to a user interrupt service routine (ISR). -@end itemize - -Asynchronous interrupts are ignored while traps are -disabled. Synchronous traps which occur while traps are -disabled result in the CPU being forced into an error mode. - -A nested interrupt is processed similarly with the -exception that the current stack need not be switched to the -interrupt stack. - -@section Traps and Register Windows - -One of the register windows must be reserved at all -times for trap processing. This is critical to the proper -operation of the trap mechanism in the SPARC architecture. It -is the responsibility of the trap handler to insure that there -is a register window available for a subsequent trap before -re-enabling traps. It is likely that any high level language -routines invoked by the trap handler (such as a user-provided -RTEMS interrupt handler) will allocate a new register window. -The save operation could result in a window overflow trap. This -trap cannot be correctly processed unless (1) traps are enabled -and (2) a register window is reserved for traps. Thus, the -RTEMS interrupt handler insures that a register window is -available for subsequent traps before enabling traps and -invoking the user's interrupt handler. - -@section Interrupt Levels - -Sixteen levels (0-15) of interrupt priorities are -supported by the SPARC architecture with level fifteen (15) -being the highest priority. Level zero (0) indicates that -interrupts are fully enabled. Interrupt requests for interrupts -with priorities less than or equal to the current interrupt mask -level are ignored. - -Although RTEMS supports 256 interrupt levels, the -SPARC only supports sixteen. RTEMS interrupt levels 0 through -15 directly correspond to SPARC processor interrupt levels. All -other RTEMS interrupt levels are undefined and their behavior is -unpredictable. - -@section Disabling of Interrupts by RTEMS - -During the execution of directive calls, critical -sections of code may be executed. When these sections are -encountered, RTEMS disables interrupts to level seven (15) -before the execution of this section and restores them to the -previous level upon completion of the section. RTEMS has been -optimized to insure that interrupts are disabled for less than -RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz ERC32 with zero wait states. -These numbers will vary based the number of wait states and -processor speed present on the target board. -[NOTE: The maximum period with interrupts disabled is hand calculated. This -calculation was last performed for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -[NOTE: It is thought that the length of time at which -the processor interrupt level is elevated to fifteen by RTEMS is -not anywhere near as long as the length of time ALL traps are -disabled as part of the "flush all register windows" operation.] - -Non-maskable interrupts (NMI) cannot be disabled, and -ISRs which execute at this level MUST NEVER issue RTEMS system -calls. If a directive is invoked, unpredictable results may -occur due to the inability of RTEMS to protect its critical -sections. However, ISRs that make no system calls may safely -execute as non-maskable interrupts. - -@section Interrupt Stack - -The SPARC architecture does not provide for a -dedicated interrupt stack. Thus by default, trap handlers would -execute on the stack of the RTEMS task which they interrupted. -This artificially inflates the stack requirements for each task -since EVERY task stack would have to include enough space to -account for the worst case interrupt stack requirements in -addition to it's own worst case usage. RTEMS addresses this -problem on the SPARC by providing a dedicated interrupt stack -managed by software. - -During system initialization, RTEMS allocates the -interrupt stack from the Workspace Area. The amount of memory -allocated for the interrupt stack is determined by the -interrupt_stack_size field in the CPU Configuration Table. As -part of processing a non-nested interrupt, RTEMS will switch to -the interrupt stack before invoking the installed handler. - diff --git a/doc/supplements/sparc/memmodel.t b/doc/supplements/sparc/memmodel.t deleted file mode 100644 index 7bf814ffa8..0000000000 --- a/doc/supplements/sparc/memmodel.t +++ /dev/null @@ -1,104 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -The SPARC architecture supports a flat 32-bit address -space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 -gigabytes). Each address is represented by a 32-bit value and -is byte addressable. The address may be used to reference a -single byte, half-word (2-bytes), word (4 bytes), or doubleword -(8 bytes). Memory accesses within this address space are -performed in big endian fashion by the SPARC. Memory accesses -which are not properly aligned generate a "memory address not -aligned" trap (type number 7). The following table lists the -alignment requirements for a variety of data accesses: - -@ifset use-ascii -@example -@group - +--------------+-----------------------+ - | Data Type | Alignment Requirement | - +--------------+-----------------------+ - | byte | 1 | - | half-word | 2 | - | word | 4 | - | doubleword | 8 | - +--------------+-----------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\vrule\strut#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#\cr -\noalign{\hrule} -&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} -&byte&&1&\cr\noalign{\hrule} -&half-word&&2&\cr\noalign{\hrule} -&word&&4&\cr\noalign{\hrule} -&doubleword&&8&\cr\noalign{\hrule} -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -<CENTER> - <TABLE COLS=2 WIDTH="60%" BORDER=2> -<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD> - <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR> -<TR><TD ALIGN=center>byte</TD> - <TD ALIGN=center>1</TD></TR> -<TR><TD ALIGN=center>half-word</TD> - <TD ALIGN=center>2</TD></TR> -<TR><TD ALIGN=center>word</TD> - <TD ALIGN=center>4</TD></TR> -<TR><TD ALIGN=center>doubleword</TD> - <TD ALIGN=center>8</TD></TR> - </TABLE> -</CENTER> -@end html -@end ifset - -Doubleword load and store operations must use a pair -of registers as their source or destination. This pair of -registers must be an adjacent pair of registers with the first -of the pair being even numbered. For example, a valid -destination for a doubleword load might be input registers 0 and -1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE: -Some assemblers for the SPARC do not generate an error if an odd -numbered register is specified as the beginning register of the -pair. In this case, the assembler assumes that what the -programmer meant was to use the even-odd pair which ends at the -specified register. This may or may not have been a correct -assumption.] - -RTEMS does not support any SPARC Memory Management -Units, therefore, virtual memory or segmentation systems -involving the SPARC are not supported. - diff --git a/doc/supplements/sparc/preface.texi b/doc/supplements/sparc/preface.texi deleted file mode 100644 index c3415236cf..0000000000 --- a/doc/supplements/sparc/preface.texi +++ /dev/null @@ -1,91 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems -(RTEMS) is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the SPARC architecture -dependencies in this port of RTEMS. Currently, only -implementations of SPARC Version 7 are supported by RTEMS. - -It is highly recommended that the SPARC RTEMS -application developer obtain and become familiar with the -documentation for the processor being used as well as the -specification for the revision of the SPARC architecture which -corresponds to that processor. - -@subheading SPARC Architecture Documents - -For information on the SPARC architecture, refer to -the following documents available from SPARC International, Inc. -(http://www.sparc.com): - -@itemize @bullet -@item SPARC Standard Version 7. - -@item SPARC Standard Version 8. - -@item SPARC Standard Version 9. -@end itemize - -@subheading ERC32 Specific Information - -The European Space Agency's ERC32 is a three chip -computing core implementing a SPARC V7 processor and associated -support circuitry for embedded space applications. The integer -and floating-point units (90C601E & 90C602E) are based on the -Cypress 7C601 and 7C602, with additional error-detection and -recovery functions. The memory controller (MEC) implements -system support functions such as address decoding, memory -interface, DMA interface, UARTs, timers, interrupt control, -write-protection, memory reconfiguration and error-detection. -The core is designed to work at 25MHz, but using space qualified -memories limits the system frequency to around 15 MHz, resulting -in a performance of 10 MIPS and 2 MFLOPS. - -Information on the ERC32 and a number of development -support tools, such as the SPARC Instruction Simulator (SIS), -are freely available on the Internet. The following documents -and SIS are available via anonymous ftp or pointing your web -browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. - -@itemize @bullet -@item ERC32 System Design Document - -@item MEC Device Specification -@end itemize - -Additionally, the SPARC RISC User's Guide from Matra -MHS documents the functionality of the integer and floating -point units including the instruction set information. To -obtain this document as well as ERC32 components and VHDL models -contact: - -@example -Matra MHS SA -3 Avenue du Centre, BP 309, -78054 St-Quentin-en-Yvelines, -Cedex, France -VOICE: +31-1-30607087 -FAX: +31-1-30640693 -@end example - -Amar Guennon (amar.guennon@@matramhs.fr) is familiar with the ERC32. - diff --git a/doc/supplements/sparc/sparc.texi b/doc/supplements/sparc/sparc.texi deleted file mode 100644 index 2ed4c3ab1c..0000000000 --- a/doc/supplements/sparc/sparc.texi +++ /dev/null @@ -1,113 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename sparc.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the SPARC Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS SPARC Applications Supplement: (sparc). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS SPARC Applications Supplement - -@setchapternewpage odd -@settitle RTEMS SPARC Applications Supplement -@titlepage -@finalout - -@title RTEMS SPARC Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeERC32.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top sparc - -This is the online version of the RTEMS SPARC Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* ERC32 Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, ERC32 Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/sparc/timeERC32.t b/doc/supplements/sparc/timeERC32.t deleted file mode 100644 index acece2b675..0000000000 --- a/doc/supplements/sparc/timeERC32.t +++ /dev/null @@ -1,120 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter ERC32 Timing Data - -@section Introduction - -The timing data for RTEMS on the ERC32 implementation -of the SPARC architecture is provided along with the target -dependent aspects concerning the gathering of the timing data. -The hardware platform used to gather the times is described to -give the reader a better understanding of each directive time -provided. Also, provided is a description of the interrupt -latency and the context switch times as they pertain to the -SPARC version of RTEMS. - -@section Hardware Platform - -All times reported in this chapter were measured -using the SPARC Instruction Simulator (SIS) developed by the -European Space Agency. SIS simulates the ERC32 -- a custom low -power implementation combining the Cypress 90C601 integer unit, -the Cypress 90C602 floating point unit, and a number of -peripherals such as counter timers, interrupt controller and a -memory controller. - -For the RTEMS tests, SIS is configured with the -following characteristics: - -@itemize @bullet -@item 15 Mhz clock speed - -@item 0 wait states for PROM accesses - -@item 0 wait states for RAM accesses -@end itemize - -The ERC32's General Purpose Timer was used to gather -all timing information. This timer was programmed to operate -with one microsecond accuracy. All sources of hardware -interrupts were disabled, although traps were enabled and the -interrupt level of the SPARC allows all interrupts. - -@section Interrupt Latency - -The maximum period with traps disabled or the -processor interrupt level set to it's highest value inside RTEMS -is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions which -disable and re-enable interrupts. The time required for the -ERC32 to vector an interrupt and for the RTEMS entry overhead -before invoking the user's trap handler are a total of -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case interrupt -latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD + -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz. -[NOTE: The maximum period with interrupts disabled was last -determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -The maximum period with interrupts disabled within -RTEMS is hand-timed with some assistance from SIS. The maximum -period with interrupts disabled with RTEMS occurs during a -context switch when traps are disabled to flush all the register -windows to memory. The length of time spent flushing the -register windows varies based on the number of windows which -must be flushed. Based on the information reported by SIS, it -takes from 4.0 to 18.0 microseconds (37 to 122 instructions) to -flush the register windows. It takes approximately 41 CPU -cycles (2.73 microseconds) to flush each register window set to -memory. The register window flush operation is heavily memory -bound. - -[NOTE: All traps are disabled during the register -window flush thus disabling both software generate traps and -external interrupts. During a normal RTEMS critical section, -the processor interrupt level (pil) is raised to level 15 and -traps are left enabled. The longest path for a normal critical -section within RTEMS is less than 50 instructions.] - -The interrupt vector and entry overhead time was -generated on the SIS benchmark platform using the ERC32's -ability to forcibly generate an arbitrary interrupt as the -source of the "benchmark" interrupt. - -@section Context Switch - -The RTEMS processor context switch time is 10 -microseconds on the SIS benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The following table summarizes the context switch -times for the ERC32 benchmark platform: - |