RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

2004-09-29 Joel Sherrill <joel@OARcorp.com>

Browse Source 
* supplements/Makefile.am: i960 obsoleted.
	* supplements/i960/.cvsignore, supplements/i960/CVME961_TIMES,
	supplements/i960/ChangeLog, supplements/i960/Makefile.am,
	supplements/i960/bsp.t, supplements/i960/callconv.t,
	supplements/i960/cpumodel.t, supplements/i960/cputable.t,
	supplements/i960/fatalerr.t, supplements/i960/i960.texi,
	supplements/i960/intr_NOTIMES.t, supplements/i960/memmodel.t,
	supplements/i960/preface.texi, supplements/i960/timeCVME961.t: Removed.
This commit is contained in:
Joel Sherrill
2004-09-29 17:30:27 +00:00
parent e4e9d60233
commit a93c17494c
16 changed files with 11 additions and 1309 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
doc/ChangeLog
View File

@@ -1,3 +1,14 @@
2004-09-29 Joel Sherrill <joel@OARcorp.com>
* supplements/Makefile.am: i960 obsoleted.
* supplements/i960/.cvsignore, supplements/i960/CVME961_TIMES,
supplements/i960/ChangeLog, supplements/i960/Makefile.am,
supplements/i960/bsp.t, supplements/i960/callconv.t,
supplements/i960/cpumodel.t, supplements/i960/cputable.t,
supplements/i960/fatalerr.t, supplements/i960/i960.texi,
supplements/i960/intr_NOTIMES.t, supplements/i960/memmodel.t,
supplements/i960/preface.texi, supplements/i960/timeCVME961.t: Removed.
2004-09-27 Joel Sherrill <joel@OARcorp.com>
PR 682/doc

1
doc/supplements/Makefile.am
View File

@@ -3,7 +3,6 @@
SUBDIRS = arm
SUBDIRS += c4x
SUBDIRS += i386
SUBDIRS += i960
SUBDIRS += m68k
SUBDIRS += mips
SUBDIRS += powerpc

36
doc/supplements/i960/.cvsignore
View File

@@ -1,36 +0,0 @@
bsp.texi
callconv.texi
cpumodel.texi
cputable.texi
fatalerr.texi
i960
i960.aux
i960.cp
i960.dvi
i960.fn
i960*.html
i960.ky
i960.log
i960.pdf
i960.pg
i960.ps
i960.toc
i960.tp
i960.vr
index.html
intr.t
intr.texi
Makefile
Makefile.in
mdate-sh
memmodel.texi
rtems_footer.html
rtems_header.html
stamp-vti
timeCVME961_.t
timeCVME961.texi
timing.t
timing.texi
version.texi
wksheets.t
wksheets.texi

247
doc/supplements/i960/CVME961_TIMES
View File

@@ -1,247 +0,0 @@
#
# Intel i960/Cyclone CVME961 (i960CA) Timing and Size Information
#
# $Id$
#
#
# CPU Model Information
#
RTEMS_BSP CVME961
RTEMS_CPU_MODEL i960CA
#
# 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 2.5
RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 33
RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.2.1
#
# Context Switch Times
#
RTEMS_NO_FP_CONTEXTS 1
RTEMS_RESTORE_1ST_FP_TASK 2
RTEMS_SAVE_INIT_RESTORE_INIT 3
RTEMS_SAVE_IDLE_RESTORE_INIT 4
RTEMS_SAVE_IDLE_RESTORE_IDLE 5
#
# Task Manager Times
#
RTEMS_TASK_CREATE_ONLY 6
RTEMS_TASK_IDENT_ONLY 7
RTEMS_TASK_START_ONLY 8
RTEMS_TASK_RESTART_CALLING_TASK 9
RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 9
RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 10
RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 11
RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 12
RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 13
RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 14
RTEMS_TASK_DELETE_CALLING_TASK 15
RTEMS_TASK_DELETE_SUSPENDED_TASK 16
RTEMS_TASK_DELETE_BLOCKED_TASK 17
RTEMS_TASK_DELETE_READY_TASK 18
RTEMS_TASK_SUSPEND_CALLING_TASK 19
RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 20
RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 21
RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 22
RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 23
RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 24
RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 25
RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 26
RTEMS_TASK_MODE_NO_RESCHEDULE 27
RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 28
RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 29
RTEMS_TASK_GET_NOTE_ONLY 30
RTEMS_TASK_SET_NOTE_ONLY 31
RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 32
RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 33
RTEMS_TASK_WAKE_WHEN_ONLY 34
#
# Interrupt Manager
#
RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 35
RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 36
RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 37
RTEMS_INTR_EXIT_RETURNS_TO_NESTED 38
RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 39
RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 40
#
# Clock Manager
#
RTEMS_CLOCK_SET_ONLY 41
RTEMS_CLOCK_GET_ONLY 42
RTEMS_CLOCK_TICK_ONLY 43
#
# Timer Manager
#
RTEMS_TIMER_CREATE_ONLY 44
RTEMS_TIMER_IDENT_ONLY 45
RTEMS_TIMER_DELETE_INACTIVE 46
RTEMS_TIMER_DELETE_ACTIVE 47
RTEMS_TIMER_FIRE_AFTER_INACTIVE 48
RTEMS_TIMER_FIRE_AFTER_ACTIVE 49
RTEMS_TIMER_FIRE_WHEN_INACTIVE 50
RTEMS_TIMER_FIRE_WHEN_ACTIVE 51
RTEMS_TIMER_RESET_INACTIVE 52
RTEMS_TIMER_RESET_ACTIVE 53
RTEMS_TIMER_CANCEL_INACTIVE 54
RTEMS_TIMER_CANCEL_ACTIVE 55
#
# Semaphore Manager
#
RTEMS_SEMAPHORE_CREATE_ONLY 56
RTEMS_SEMAPHORE_IDENT_ONLY 57
RTEMS_SEMAPHORE_DELETE_ONLY 58
RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 59
RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 60
RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 61
RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 62
RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 63
RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 64
#
# Message Manager
#
RTEMS_MESSAGE_QUEUE_CREATE_ONLY 65
RTEMS_MESSAGE_QUEUE_IDENT_ONLY 66
RTEMS_MESSAGE_QUEUE_DELETE_ONLY 67
RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 68
RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 69
RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 70
RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 71
RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 72
RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 73
RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 74
RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 75
RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 76
RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 77
RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 78
RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 79
RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 80
RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 81
#
# Event Manager
#
RTEMS_EVENT_SEND_NO_TASK_READIED 82
RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 83
RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84
RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 85
RTEMS_EVENT_RECEIVE_AVAILABLE 86
RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 87
RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 88
#
# Signal Manager
#
RTEMS_SIGNAL_CATCH_ONLY 89
RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 90
RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 91
RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 92
RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 93
#
# Partition Manager
#
RTEMS_PARTITION_CREATE_ONLY 94
RTEMS_PARTITION_IDENT_ONLY 95
RTEMS_PARTITION_DELETE_ONLY 96
RTEMS_PARTITION_GET_BUFFER_AVAILABLE 97
RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 98
RTEMS_PARTITION_RETURN_BUFFER_ONLY 99
#
# Region Manager
#
RTEMS_REGION_CREATE_ONLY 100
RTEMS_REGION_IDENT_ONLY 101
RTEMS_REGION_DELETE_ONLY 102
RTEMS_REGION_GET_SEGMENT_AVAILABLE 103
RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 104
RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 105
RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 106
RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 107
RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 108
#
# Dual-Ported Memory Manager
#
RTEMS_PORT_CREATE_ONLY 109
RTEMS_PORT_IDENT_ONLY 110
RTEMS_PORT_DELETE_ONLY 111
RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 112
RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 113
#
# IO Manager
#
RTEMS_IO_INITIALIZE_ONLY 114
RTEMS_IO_OPEN_ONLY 115
RTEMS_IO_CLOSE_ONLY 116
RTEMS_IO_READ_ONLY 117
RTEMS_IO_WRITE_ONLY 118
RTEMS_IO_CONTROL_ONLY 119
#
# Rate Monotonic Manager
#
RTEMS_RATE_MONOTONIC_CREATE_ONLY 120
RTEMS_RATE_MONOTONIC_IDENT_ONLY 121
RTEMS_RATE_MONOTONIC_CANCEL_ONLY 122
RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 123
RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 124
RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 125
RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 126
RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 127
#
# Size Information
#
#
# xxx alloted for numbers
#
RTEMS_DATA_SPACE 128
RTEMS_MINIMUM_CONFIGURATION xx,129
RTEMS_MAXIMUM_CONFIGURATION xx,130
# x,xxx alloted for numbers
RTEMS_CORE_CODE_SIZE x,131
RTEMS_INITIALIZATION_CODE_SIZE x,132
RTEMS_TASK_CODE_SIZE x,133
RTEMS_INTERRUPT_CODE_SIZE x,134
RTEMS_CLOCK_CODE_SIZE x,135
RTEMS_TIMER_CODE_SIZE x,136
RTEMS_SEMAPHORE_CODE_SIZE x,137
RTEMS_MESSAGE_CODE_SIZE x,138
RTEMS_EVENT_CODE_SIZE x,139
RTEMS_SIGNAL_CODE_SIZE x,140
RTEMS_PARTITION_CODE_SIZE x,141
RTEMS_REGION_CODE_SIZE x,142
RTEMS_DPMEM_CODE_SIZE x,143
RTEMS_IO_CODE_SIZE x,144
RTEMS_FATAL_ERROR_CODE_SIZE x,145
RTEMS_RATE_MONOTONIC_CODE_SIZE x,146
RTEMS_MULTIPROCESSING_CODE_SIZE x,147
# xxx alloted for numbers
RTEMS_TIMER_CODE_OPTSIZE 148
RTEMS_SEMAPHORE_CODE_OPTSIZE 149
RTEMS_MESSAGE_CODE_OPTSIZE 150
RTEMS_EVENT_CODE_OPTSIZE 151
RTEMS_SIGNAL_CODE_OPTSIZE 152
RTEMS_PARTITION_CODE_OPTSIZE 153
RTEMS_REGION_CODE_OPTSIZE 154
RTEMS_DPMEM_CODE_OPTSIZE 155
RTEMS_IO_CODE_OPTSIZE 156
RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 157
RTEMS_MULTIPROCESSING_CODE_OPTSIZE 158
# xxx alloted for numbers
RTEMS_BYTES_PER_TASK 159
RTEMS_BYTES_PER_TIMER 160
RTEMS_BYTES_PER_SEMAPHORE 161
RTEMS_BYTES_PER_MESSAGE_QUEUE 162
RTEMS_BYTES_PER_REGION 163
RTEMS_BYTES_PER_PARTITION 164
RTEMS_BYTES_PER_PORT 165
RTEMS_BYTES_PER_PERIOD 166
RTEMS_BYTES_PER_EXTENSION 167
RTEMS_BYTES_PER_FP_TASK 168
RTEMS_BYTES_PER_NODE 169
RTEMS_BYTES_PER_GLOBAL_OBJECT 170
RTEMS_BYTES_PER_PROXY 171
# x,xxx alloted for numbers
RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS x,172

76
doc/supplements/i960/ChangeLog
View File

@@ -1,76 +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>
* i960.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>
* i960.texi: Set @setfilename i960.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-07-30 Joel Sherrill <joel@OARcorp.com>
* callconf.t: Added some markups for fonts and clarified
some places.
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.

110
doc/supplements/i960/Makefile.am
View File

@@ -1,110 +0,0 @@
#
# COPYRIGHT (c) 1988-2002.
# On-Line Applications Research Corporation (OAR).
# All rights reserved.
#
# $Id$
#
PROJECT = i960
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 \
timeCVME961.texi
COMMON_FILES += $(top_srcdir)/common/cpright.texi \
$(top_srcdir)/common/timemac.texi
FILES = preface.texi
info_TEXINFOS = i960.texi
i960_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 Floating Point Unit" \
-u "Top" \
-n "Memory Model" < $< > $@
memmodel.texi: memmodel.t
$(BMENU2) -p "Calling Conventions Leaf Procedures" \
-u "Top" \
-n "Interrupt Processing" < $< > $@
# Interrupt Chapter:
# 1. Replace Times and Sizes
# 2. Build Node Structure
intr.texi: intr_NOTIMES.t CVME961_TIMES
${REPLACE2} -p $(srcdir)/CVME961_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 CVME961_TIMES
${REPLACE2} -p $(srcdir)/CVME961_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 "CVME961 Timing Data" < $< > $@
# Timing Data for BSP Chapter:
# 1. Copy the Shared File
# 2. Replace Times and Sizes
# 3. Build Node Structure
timeCVME961.texi: $(top_srcdir)/common/timetbl.t timeCVME961.t
cat $(srcdir)/timeCVME961.t $(top_srcdir)/common/timetbl.t >timeCVME961_.t
@echo >>timeCVME961_.t
@echo "@tex" >>timeCVME961_.t
@echo "\\global\\advance \\smallskipamount by 4pt" >>timeCVME961_.t
@echo "@end tex" >>timeCVME961_.t
${REPLACE2} -p $(srcdir)/CVME961_TIMES timeCVME961_.t | \
$(BMENU2) -p "Timing Specification Terminology" \
-u "Top" \
-n "Command and Variable Index" > $@
CLEANFILES += timeCVME961_.t
EXTRA_DIST = CVME961_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
intr_NOTIMES.t memmodel.t timeCVME961.t
CLEANFILES += i960.info i960.info-?

54
doc/supplements/i960/bsp.t
View File

@@ -1,54 +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 i960CA 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 when the
i960CA processor is reset. When the i960CA is reset, the
processor reads an Initial Memory Image (IMI) to establish its
state. The IMI consists of the Initialization Boot Record (IBR)
and the Process Control Block (PRCB) from an Initial Memory
Image (IMI) at location 0xFFFFFF00. The IBR contains the
initial bus configuration data, the address of the first
instruction to execute after reset, the address of the PRCB, and
the checksum used by the processor's self-test.
@section Processor Initialization
The PRCB contains the base addresses for system data
structures, and initial configuration information for the core
and integrated peripherals. In particular, the PRCB contains
the initial contents of the Arithmetic Control (AC) Register as
well as the base addresses of the Interrupt Vector Table, System
Procedure Entry Table, Fault Entry Table, and the Control Table.
In addition, the PRCB is used to configure the depth of the
instruction and register caches and the actions when certain
types of faults are encountered.
The Process Controls (PC) Register is initialized to
0xC01F2002 which sets the i960CA's interrupt level to 0x1F (31
decimal). In addition, the Interrupt Mask (IMSK) Register
(alternately referred to as Special Function Register 1 or sf1)
is set to 0x00000000 to mask all external and DMA interrupt
sources. Thus, all interrupts are disabled when the first
instruction is executed.
For more information regarding the i960CA's data
structures and their contents, refer to Intel's i960CA User's
Manual.

97
doc/supplements/i960/callconv.t
View File

@@ -1,97 +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 Processor Background
All members of the i960 architecture family support
two methods for performing procedure calls: a RISC-style
branch-and-link and an integrated call and return mechanism.
On a branch-and-link, the processor branches to the
invoked procedure and saves the return address in a register,
@code{G14}. Typically, the invoked procedure will not invoke another
procedure and is referred to as a leaf procedure. Many
high-level language compilers for the i960 family recognize leaf
procedures and automatically optimize them to utilize the
branch-and-link mechanism. Branch-and-link procedures are
invoked using the @code{bal} and @code{balx} instructions and return control
via the @code{bx} instruction. By convention, @code{G14} is zero when not in
a leaf procedure. It is the responsibility of the leaf
procedure to clear @code{G14} before returning.
The integrated call and return mechanism also
branches to the invoked procedure and saves the return address
as did the branch and link mechanism. However, the important
difference is that the @code{call}, @code{callx}, and @code{calls} instructions save
the local register set (@code{R0} through @code{R15}) before transferring
control to the invoked procedure. The @code{ret} instruction
automatically restores the previous local register set. The
i960CA provides a register cache which can be configured to
retain the last five to sixteen recent register caches. When
the register cache is full, the oldest cached register set is
written to the stack.
@section Calling Mechanism
All RTEMS directives are invoked using either a @code{call}
or @code{callx} instruction and return to the user via the @code{ret}
instruction.
@section Register Usage
As discussed above, the @code{call} and @code{callx} instructions
automatically save the current contents of the local register
set (@code{R0} through @code{R15}). The contents of the local registers will
be restored as part of returning to the application. The
contents of global registers @code{G0} through @code{G7} are not preserved by
RTEMS directives.
@section Parameter Passing
RTEMS uses the standard i960 family C parameter
passing mechanism in which @code{G0} contains the first parameter, @code{G1}
the second, and so on for the remaining parameters. No RTEMS
directive requires more than six parameters.
@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.
@section Leaf Procedures
RTEMS utilizes leaf procedures internally to improve
performance. This improves execution speed as well as reducing
stack usage and the number of register sets which must be cached.

62
doc/supplements/i960/cpumodel.t
View File

@@ -1,62 +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. 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 chapter presents the set of features which vary
across i960 implementations and are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
cpukit/score/cpu/i960/i960.h based upon the particular CPU
model defined on the compilation command line.
@section CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the Intel i960CA,
this macro is set to the string "i960ca".
@section Floating Point Unit
The macro I960_HAS_FPU is set to 1 to indicate that
this CPU model has a hardware floating point unit and 0
otherwise.

121
doc/supplements/i960/cputable.t
View File

@@ -1,121 +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 i960CA version of the RTEMS CPU Dependent
Information Table contains the information required to interface
a Board Support Package and RTEMS on the i960CA. This
information is provided to allow RTEMS to interoperate
effectively with the BSP. The C structure definition is given
here:
@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_free_hook)( void* );
/* end of fields required on all CPUs */
i960_PRCB *Prcb;
@} rtems_cpu_table;
@end group
@end example
The contents of the i960 Processor Control Block
are discussed in the User's Manual for the particular
i960 model being used. Structure definitions for the
i960CA and i960HA PRCB and Control Table are provided
by including the file @code{rtems.h}.
@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.
@item Prcb
is the base address of the Processor Control Block. It
is primarily used by RTEMS to install interrupt handlers.
@end table

30
doc/supplements/i960/fatalerr.t
View File

@@ -1,30 +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 is 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 31, places the error code in G0, and executes a branch to
self instruction to simulate a halt processor instruction.

114
doc/supplements/i960/i960.texi
View File

@@ -1,114 +0,0 @@
\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename i960.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 Intel i960 Applications Supplement
@c
@include version.texi
@include common/setup.texi
@include common/rtems.texi
@ifset use-ascii
@dircategory RTEMS Target Supplements
@direntry
* RTEMS Intel i960 Applications Supplement: (i960).
@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 Intel i960 Applications Supplement
@setchapternewpage odd
@settitle RTEMS Intel i960 Applications Supplement
@titlepage
@finalout
@title RTEMS Intel i960 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 timeCVME961.texi
@ifinfo
@node Top, Preface, (dir), (dir)
@top i960
This is the online version of the RTEMS Intel i960
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::
* CVME961 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, CVME961 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

193
doc/supplements/i960/intr_NOTIMES.t
View File

@@ -1,193 +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 the proper handling of an interrupt. The processor
dependent response to the interrupt which modifies the execution
state and results in the modification of the execution stream.
This modification usually requires that an interrupt handler
utilize the provided 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 the processor's response and control mechanisms as they
pertain to RTEMS.
@section Vectoring of Interrupt Handler
Upon receipt of an interrupt the i960CA
automatically performs the following actions:
@itemize @bullet
@item saves the local register set,
@item sets the Frame Pointer (FP) to point to the interrupt
stack,
@item increments the FP by sixteen (16) to make room for the
Interrupt Record,
@item saves the current values of the arithmetic-controls (AC)
register, the process-controls (PC) register, and the interrupt
vector number are saved in the Interrupt Record,
@item the CPU sets the Instruction Pointer (IP) to the address
of the first instruction in the interrupt handler,
@item the return-status field of the Previous Frame Pointer
(PFP or R0) register is set to interrupt return,
@item sets the PC state bit to interrupted,
@item sets the current interrupt disable level in the PC to
the level of the current interrupt, and
@item disables tracing.
@end itemize
A nested interrupt is processed similarly by the
i960CA with the exception that the Frame Pointer (FP) already
points to the interrupt stack. This means that the FP is NOT
overwritten before space for the Interrupt Record is allocated.
The state flag bit of the saved PC register in the
Interrupt Record is examined by RTEMS to determine when an outer
most interrupt is being exited. Therefore, the user application
code MUST NOT modify this bit.
@section Interrupt Record
The structure of the Interrupt Record for the i960CA
which is placed on the interrupt stack by the processor in
response to an interrupt is as follows:
@ifset use-ascii
@example
@group
+---------------------------+
| Saved Process Controls | NFP-16
+---------------------------+
| Saved Arithmetic Controls | NFP-12
+---------------------------+
| UNUSED | NFP-8
+---------------------------+
| UNUSED | NFP-4
+---------------------------+
@end group
@end example
@end ifset
@ifset use-tex
@sp 1
@tex
\centerline{\vbox{\offinterlineskip\halign{
\strut\vrule#&
\hbox to 2.00in{\enskip\hfil#\hfil}&
\vrule#&
\hbox to 1.00in{\enskip\hfil#\hfil}
\cr
\multispan{3}\hrulefill\cr
& Saved Process Controls && NFP-16\cr
\multispan{3}\hrulefill\cr
& Saved Arithmetic Controls && NFP-12\cr
\multispan{3}\hrulefill\cr
& UNUSED && NFP-8\cr
\multispan{3}\hrulefill\cr
& UNUSED && NFP-4\cr
\multispan{3}\hrulefill\cr
}}\hfil}
@end tex
@end ifset
@ifset use-html
@html
<CENTER>
<TABLE COLS=2 WIDTH="40%" BORDER=2>
<TR><TD ALIGN=center><STRONG>Saved Process Controls</STRONG></TD>
<TD ALIGN=center>NFP-16</TD></TR>
<TR><TD ALIGN=center><STRONG>Saved Arithmetic Controls</STRONG></TD>
<TD ALIGN=center>NFP-12</TD></TR>
<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD>
<TD ALIGN=center>NFP-8</TD></TR>
<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD>
<TD ALIGN=center>NFP-4</TD></TR>
</TABLE>
</CENTER>
@end html
@end ifset
@section Interrupt Levels
Thirty-two levels (0-31) of interrupt priorities are
supported by the i960CA microprocessor with level thirty-one
(31) 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
i960CA only supports thirty-two. RTEMS interrupt levels 0
through 31 directly correspond to i960CA 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 thirty-one (31)
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 i960CA with zero wait states.
These numbers will vary based the number of wait states and
processor speed present on the target board. [NOTE: This
calculation was most recently performed for Release
RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
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 Register Cache Flushing
The i960CA version of the RTEMS interrupt manager is
optimized to insure that the flushreg instruction is only
executed when a context switch is necessary. The flushreg
instruction flushes the i960CA register set cache and takes (14
+ 23 * number of sets flushed) cycles to execute. As the i960CA
supports caching of from five to sixteen register sets, this
instruction takes from 129 to 382 cycles (3.90 to 11.57
microseconds at 33 Mhz) to execute given no wait state memory.
RTEMS flushes the register set cache only at the conclusion of
the outermost ISR when a context switch is necessary. The
register set cache will not be flushed as part of processing a
nested interrupt or when a context switch is not necessary.
This optimization is essential to providing high-performance
interrupt management on the i960CA.
@section Interrupt Stack
On the i960CA, 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. During the initialization
process, RTEMS will install its interrupt stack.

40
doc/supplements/i960/memmodel.t
View File

@@ -1,40 +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 i960CA supports a flat 32-bit address space with
addresses ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes).
Although the i960CA reserves portions of this address space,
application code and data may be placed in any non-reserved
areas. 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), double-word (8
bytes), triple-word (12 bytes) or quad-word (16 bytes). The
i960CA does not support virtual memory or segmentation.
The i960CA allows the memory space to be partitioned
into sixteen regions which may be configured individually as big
or little endian. RTEMS assumes that the memory regions in
which its code, data, and the RTEMS Workspace reside are
configured as little endian.

40
doc/supplements/i960/preface.texi
View File

@@ -1,40 +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.
For information on the i960CA and the i960 processor
family in general, refer to the following documents:
@itemize @bullet
@item @cite{80960CA User's Manual, Intel, Order No. 270710}.
@item @cite{32-Bit Embedded Controller Handbook, Intel, Order No. 270647}.
@item @cite{Glenford J. Meyers and David L. Budde. The 80960
Microprocessor Architecture. Wiley. New York. 1988}.
@end itemize
It is highly recommended that the i960CA RTEMS
application developer obtain and become familiar with Intel's
i960CA User's Manual.

88
doc/supplements/i960/timeCVME961.t
View File

@@ -1,88 +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 CVME961 Timing Data
NOTE: The CVME961 board used by the RTEMS Project to
obtain i960CA times is currently broken. The information in
this chapter was obtained using Release 3.2.1.
@section Introduction
The timing data for the i960CA version of RTEMS 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 i960CA version of RTEMS.
@section Hardware Platform
All times reported except for the maximum period
interrupts are disabled by RTEMS were measured using a Cyclone
Microsystems CVME961 board. The CVME961 is a 33 Mhz board with
dynamic RAM which has two wait state dynamic memory (four CPU
cycles) for read accesses and one wait state (two CPU cycles)
for write accesses. The Z8536 on a SQUALL SQSIO4 mezzanine
board was used to measure elapsed time with one-half microsecond
resolution. All sources of hardware interrupts are disabled,
although the interrupt level of the i960CA allows all interrupts.
The maximum interrupt disable period was measured by
summing the number of CPU cycles required by each assembly
language instruction executed while interrupts were disabled.
Zero wait state memory was assumed. The total CPU cycles
executed with interrupts disabled, including the instructions to
disable and enable interrupts, was divided by 33 to simulate a
i960CA executing at 33 Mhz with zero wait states.
@section Interrupt Latency
The maximum period with interrupts disabled within
RTEMS is less than
RTEMS_MAXIMUM_DISABLE_PERIOD microseconds including the instructions
which disable and re-enable interrupts. The time required for
the i960CA to generate an interrupt using the sysctl
instruction, vectoring to an interrupt handler, and for the
RTEMS entry overhead before invoking the user's interrupt
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. [NOTE: The maximum period with interrupts
disabled within RTEMS was last calculated for Release
RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
It should be noted again that the maximum period with
interrupts disabled within RTEMS is hand-timed. The interrupt
vector and entry overhead time was generated on the Cyclone
CVME961 benchmark platform using the sysctl instruction as the
interrupt source.
@section Context Switch
The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
microseconds on the Cyclone CVME961 benchmark platform. This
time represents the raw context switch time with no user
extensions configured. Additional execution time is required
when a TSWITCH user extension is configured. The use of the
TSWITCH extension is application dependent. Thus, its execution
time is not considered part of the base context switch time.
The CVME961 has no hardware floating point capability
and floating point tasks are not supported.
The following table summarizes the context switch
times for the CVME961 benchmark platform: