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

2003-09-26 Joel Sherrill <joel@OARcorp.com>

Browse Source 
* hppa1_1/.cvsignore, hppa1_1/ChangeLog, hppa1_1/Makefile.am,
	hppa1_1/SIMHPPA_TIMES, hppa1_1/bsp.t, hppa1_1/callconv.t,
	hppa1_1/cpumodel.t, hppa1_1/cputable.t, hppa1_1/fatalerr.t,
	hppa1_1/hppa1_1.texi, hppa1_1/intr_NOTIMES.t, hppa1_1/memmodel.t,
	hppa1_1/preface.texi, hppa1_1/timeSIMHPPA.t: Removed.
This commit is contained in:
Joel Sherrill
2003-09-26 21:44:42 +00:00
parent 5e8552a407
commit f29151e1df
15 changed files with 8 additions and 1336 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/supplements/ChangeLog
View File

@@ -1,3 +1,11 @@
2003-09-26 Joel Sherrill <joel@OARcorp.com>
* hppa1_1/.cvsignore, hppa1_1/ChangeLog, hppa1_1/Makefile.am,
hppa1_1/SIMHPPA_TIMES, hppa1_1/bsp.t, hppa1_1/callconv.t,
hppa1_1/cpumodel.t, hppa1_1/cputable.t, hppa1_1/fatalerr.t,
hppa1_1/hppa1_1.texi, hppa1_1/intr_NOTIMES.t, hppa1_1/memmodel.t,
hppa1_1/preface.texi, hppa1_1/timeSIMHPPA.t: Removed.
2003-09-20 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
* supplement.am: Add -I $(top_builddir) TEXI2WWW_ARGS.

37
doc/supplements/hppa1_1/.cvsignore
View File

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

55
doc/supplements/hppa1_1/ChangeLog
View File

@@ -1,55 +0,0 @@
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>
* hppa1_1.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>
* hppa1_1.texi: Set @setfilename hppa1_1.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.

102
doc/supplements/hppa1_1/Makefile.am
View File

@@ -1,102 +0,0 @@
#
# COPYRIGHT (c) 1988-2002.
# On-Line Applications Research Corporation (OAR).
# All rights reserved.
#
# $Id$
#
PROJECT = hppa1_1
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 wksheets.texi timing.texi \
timeSIMHPPA.texi
COMMON_FILES += $(top_srcdir)/common/cpright.texi
FILES = preface.texi
info_TEXINFOS = hppa1_1.texi
hppa1_1_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 Name" \
-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 SIMHPPA_TIMES
${REPLACE2} -p $(srcdir)/SIMHPPA_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 Disabling of Interrupts by RTEMS" \
-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 SIMHPPA_TIMES
${REPLACE2} -p $(srcdir)/SIMHPPA_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 "HP-7100 Timing Data" < $< > $@
# Timing Data for BSP Chapter:
# 1. Copy the Shared File
# 2. Replace Times and Sizes
# 3. Build Node Structure
timeSIMHPPA.texi: timeSIMHPPA.t
$(BMENU2) -p "Timing Specification Terminology" \
-u "Top" \
-n "Command and Variable Index" < $< > $@
EXTRA_DIST = SIMHPPA_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
intr_NOTIMES.t memmodel.t timeSIMHPPA.t

247
doc/supplements/hppa1_1/SIMHPPA_TIMES
View File

@@ -1,247 +0,0 @@
#
# PA-RISC Timing and Size Information
#
# $Id$
#
#
# CPU Model Information
#
RTEMS_BSP simhppa
RTEMS_CPU_MODEL HP-7100
#
# 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 TBD
RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD TBD
#
# 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

53
doc/supplements/hppa1_1/bsp.t
View File

@@ -1,53 +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 PA-RISC 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 PA-RISC processor is reset. The behavior
of a PA-RISC upon reset is implementation defined and thus is
beyond the scope of this manual.
@section Processor Initialization
The precise requirements for initialization of a
particular implementation of the PA-RISC architecture are
implementation defined. Thus it is impossible to provide exact
details of this procedure in this manual. However, the
requirements of RTEMS which must be satisfied by this
initialization code can be discussed.
RTEMS assumes that interrupts are disabled when the
initialize_executive directive is invoked. Interrupts are
enabled automatically by RTEMS as part of the initialize
executive directive and device driver initialization occurs
after interrupts are enabled. Thus all interrupt sources should
be quiescent until the system's device drivers have been
initialized and installed their interrupt handlers.
If the processor requires initialization of the
cache, then it should be be done during the reset application
initialization code.
Finally, the requirements in the Board Support
Packages chapter of the Applications User's Manual for the
reset code which is executed before the call to initialize
executive must be satisfied.

143
doc/supplements/hppa1_1/callconv.t
View File

@@ -1,143 +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.
This chapter describes the calling conventions used
by the GNU C and standard HP-UX compilers for the PA-RISC
architecture.
@section Processor Background
The PA-RISC architecture supports a simple yet
effective call and return mechanism for subroutine calls where
the caller and callee are both in the same address space. The
compiler will not automatically generate subroutine calls which
cross address spaces. A subroutine is invoked via the branch
and link (bl) or the branch and link register (blr). These
instructions save the return address in a caller specified
register. By convention, the return address is saved in r2.
The callee is responsible for maintaining the return address so
it can return to the correct address. The branch vectored (bv)
instruction is used to branch to the return address and thus
return from the subroutine to the caller. It is is important to
note that the PA-RISC subroutine call and return mechanism does
not automatically save or restore any registers. It is the
responsibility of the high-level language compiler to define the
register preservation and usage convention.
@section Calling Mechanism
All RTEMS directives are invoked as standard
subroutines via a bl or a blr instruction with the return address
assumed to be in r2 and return to the user application via the
bv instruction.
@section Register Usage
As discussed above, the bl and blr instructions do
not automatically save any registers. RTEMS uses the registers
r1, r19 - r26, and r31 as scratch registers. The PA-RISC
calling convention specifies that the first four (4) arguments
to subroutines are passed in registers r23 - r26. After the
arguments have been used, the contents of these registers may be
altered. Register r31 is the millicode scratch register.
Millicode is the set of routines which support high-level
languages on the PA-RISC by providing routines which are either
too complex or too long for the compiler to generate inline code
when these operations are needed. For example, indirect calls
utilize a millicode routine. The scratch registers are not
preserved by RTEMS directives therefore, the contents of these
registers should not be assumed upon return from any RTEMS
directive.
Surprisingly, when using the GNU C compiler at least
integer multiplies are performed using the floating point
registers. This is an important optimization because the
PA-RISC does not have otherwise have hardware for multiplies.
This has important ramifications in regards to the PA-RISC port
of RTEMS. On most processors, the floating point unit is
ignored if the code only performs integer operations. This
makes it easy for the application developer to predict whether
or not any particular task will require floating point
operations. This property is taken advantage of by RTEMS on
other architectures to minimize the number of times the floating
point context is saved and restored. However, on the PA-RISC
architecture, every task is implicitly a floating point task.
Additionally the state of the floating point unit must be saved
and restored as part of the interrupt processing because for all
practical purposes it is impossible to avoid the use of the
floating point registers. It is unknown if the HP-UX C compiler
shares this property.
@itemize @code{ }
@item @b{NOTE}: Later versions of the GNU C has a PA-RISC specific
option to disable use of the floating point registers. RTEMS
currently assumes that this option is not turned on. If the use
of this option sets a built-in define, then it should be
possible to modify the PA-RISC specific code such that all tasks
are considered floating point only when this option is not used.
@end itemize
@section Parameter Passing
RTEMS assumes that the first four (4) arguments are
placed in the appropriate registers (r26, r25, r24, and r23)
and, if needed, additional are placed on the current stack
before the directive is invoked via the bl or blr instruction.
The first argument is placed in r26, the second is placed in
r25, and so forth. The following pseudo-code illustrates the
typical sequence used to call a RTEMS directive with three (3)
arguments:
@example
set r24 to the third argument
set r25 to the second argument
set r26 to the first argument
invoke directive
@end example
The stack on the PA-RISC grows upward -- i.e.
"pushing" onto the stack results in the address in the stack
pointer becoming numerically larger. By convention, r27 is used
as the stack pointer. The standard stack frame consists of a
minimum of sixty-four (64) bytes and is the responsibility of
the callee to maintain.
@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.

56
doc/supplements/hppa1_1/cpumodel.t
View File

@@ -1,56 +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 PA-RISC 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 PA-RISC implementations and are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
cpukit/score/cpu/hppa1_1/hppa.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 Hewlett Packard
PA-7100 CPU model, this macro is set to the string "hppa 7100".

116
doc/supplements/hppa1_1/cputable.t
View File

@@ -1,116 +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 PA-RISC version of the RTEMS CPU Dependent
Information Table contains the information required to interface
a Board Support Package and RTEMS on the PA-RISC. This
information is provided to allow RTEMS to interoperate
effectively with the BSP. The C structure definition is given
here:
@example
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 */
hppa_rtems_isr_entry spurious_handler;
/* itimer_clicks_per_microsecond is for the Clock driver */
unsigned32 itimer_clicks_per_microsecond;
@} rtems_cpu_table;
@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.
@item spurious_handler
is the address of the optional user provided routine which is invoked
when a spurious external interrupt occurs. A spurious interrupt is one
for which no handler is installed.
@item itimer_clicks_per_microsecond
is the number of countdowns in the on-CPU timer which corresponds
to a microsecond. This is a function of the clock speed of the CPU
being used.
@end table

32
doc/supplements/hppa1_1/fatalerr.t
View File

@@ -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 a user-supplied fatal error
handler. If no user-supplied handler is configured, the RTEMS
provided default fatal error handler is invoked. If the
user-supplied fatal error handler returns 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 (i.e.
sets the I bit in the PSW register to 0), places the error code
in r1, and executes a break instruction to simulate a halt
processor instruction.

115
doc/supplements/hppa1_1/hppa1_1.texi
View File

@@ -1,115 +0,0 @@
\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename hppa1_1.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 Hewlett Packard PA-RISC Applications Supplement
@c
@include version.texi
@include common/setup.texi
@include common/rtems.texi
@ifset use-ascii
@dircategory RTEMS Target Supplements
@direntry
* RTEMS Hewlett Packard PA-RISC Applications Supplement: (hppa1_1).
@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 Hewlett Packard PA-RISC Applications Supplement
@setchapternewpage odd
@settitle RTEMS Hewlett Packard PA-RISC Applications Supplement
@titlepage
@finalout
@title RTEMS Hewlett Packard PA-RISC 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 timeSIMHPPA.texi
@ifinfo
@node Top, Preface, (dir), (dir)
@top hppa1_1
This is the online version of the RTEMS Hewlett Packard PA-RISC
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::
* HP-7100 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, HP-7100 Timing Data Directive Times, 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

191
doc/supplements/hppa1_1/intr_NOTIMES.t
View File

@@ -1,191 +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
occurence of an interrupt in their 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 PA-RISC's
interrupt response and control mechanisms as they pertain to
RTEMS.
@section Vectoring of Interrupt Handler
Upon receipt of an interrupt the PA-RISC
automatically performs the following actions:
@itemize @bullet
@item The PSW (Program Status Word) is saved in the IPSW
(Interrupt Program Status Word).
@item The current privilege level is set to 0.
@item The following defined bits in the PSW are set:
@item E bit is set to the default endian bit
@item M bit is set to 1 if the interrupt is a high-priority
machine check and 0 otherwise
@item Q bit is set to zero thuse freezing the IIA
(Instruction Address) queues
@item C and D bits are set to zero thus disabling all
protection and translation.
@item I bit is set to zero this disabling all external,
powerfail, and low-priority machine check interrupts.
@item All others bits are set to zero.
@item General purpose registers r1, r8, r9, r16, r17, r24, and
r25 are copied to the shadow registers.
@item Execution begins at the address given by the formula:
Interruption Vector Address + (32 * interrupt vector number).
@end itemize
Once the processor has completed the actions it is is
required to perform for each interrupt, the RTEMS interrupt
management code (the beginning of which is stored in the
Interruption Vector Table) gains control and performs the
following actions upon each interrupt:
@itemize @bullet
@item returns the processor to "virtual mode" thus reenabling
all code and data address translation.
@item saves all necessary interrupt state information
@item saves all floating point registers
@item saves all integer registers
@item switches the current stack to the interrupt stack
@item dispatches to the appropriate user provided interrupt
service routine (ISR). If the ISR was installed with the
interrupt_catch directive, then it will be executed at this.
Because, the RTEMS interrupt handler saves all registers which
are not preserved according to the calling conventions and
invokes the application's ISR, the ISR can easily be written in
a high-level language.
@end itemize
RTEMS refers to the combination of the interrupt
state information and registers saved when vectoring an
interrupt as the Interrupt Stack Frame (ISF). A nested
interrupt is processed similarly by the PA-RISC and RTEMS with
the exception that the nested interrupt occurred while executing
on the interrupt stack and, thus, the current stack need not be
switched.
@section Interrupt Stack Frame
The PA-RISC architecture does not alter the stack
while processing interrupts. However, RTEMS does save
information on the stack as part of processing an interrupt.
This following shows the format of the Interrupt Stack Frame for
the PA-RISC as defined by RTEMS:
@example
@group
+------------------------+
| Interrupt Context | 0xXXX
+------------------------+
| Integer Context | 0xXXX
+------------------------+
| Floating Point Context | 0xXXX
+------------------------+
@end group
@end example
@section External Interrupts and Traps
In addition to the thirty-two unique interrupt
sources supported by the PA-RISC architecture, RTEMS also
supports the installation of handlers for each of the thirty-two
external interrupts supported by the PA-RISC architecture.
Except for interrupt vector 4, each of the interrupt vectors 0
through 31 may be associated with a user-provided interrupt
handler. Interrupt vector 4 is used for external interrupts.
When an external interrupt occurs, the RTEMS external interrupt
handler is invoked and the actual interrupt source is indicated
by status bits in the EIR (External Interrupt Request) register.
The RTEMS external interrupt handler (or interrupt vector four)
examines the EIR to determine which interrupt source requires
servicing.
RTEMS supports sixty-four interrupt vectors for the
PA-RISC. Vectors 0 through 31 map to the normal interrupt
sources while RTEMS interrupt vectors 32 through 63 are directly
associated with the external interrupt sources indicated by bits
0 through 31 in the EIR.
The exact set of interrupt sources which are checked
for by the RTEMS external interrupt handler and the order in
which they are checked are configured by the user in the CPU
Configuration Table. If an external interrupt occurs which does
not have a handler configured, then the spurious interrupt
handler will be invoked. The spurious interrupt handler may
also be specifiec by the user in the CPU Configuration Table.
@section Interrupt Levels
Two levels (enabled and disabled) of interrupt
priorities are supported by the PA-RISC architecture. Level
zero (0) indicates that interrupts are fully enabled (i.e. the I
bit of the PSW is 1). Level one (1) indicates that interrupts
are disabled (i.e. the I bit of the PSW is 0). Thirty-two
independent sources of external interrupts are supported by the
PA-RISC architecture. Each of these interrupts sources may be
individually enabled or disabled. When processor interrupts are
disabled, all sources of external interrupts are ignored. When
processor interrupts are enabled, the EIR (External Interrupt
Request) register is used to determine which sources are
currently allowed to generate interrupts.
Although RTEMS supports 256 interrupt levels, the
PA-RISC architecture only supports two. RTEMS interrupt level 0
indicates that interrupts are enabled and level 1 indicates that
interrupts are disabled. 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 external interrupts by setting the I
bit in the PSW to 0 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 XXX instructions when compiled with GNU
CC at optimization level 4. The exact execution time will vary
based on the based on the processor implementation, amount of
cache, the number of wait states for primary memory, and
processor speed present on the target board.
Non-maskable interrupts (NMI) such as high-priority
machine checks 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.

67
doc/supplements/hppa1_1/memmodel.t
View File

@@ -1,67 +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
RTEMS supports applications in which the application
and the executive execute within a single thirty-two bit address
space. Thus RTEMS and the application share a common four
gigabyte address space within a single space. The PA-RISC
automatically converts every address from a logical to a
physical address each time it is used. The PA-RISC uses
information provided in the page table to perform this
translation. The following protection levels are assumed:
@itemize @bullet
@item a single code segment at protection level (0) which
contains all application and executive code.
@item a single data segment at protection level zero (0) which
contains all application and executive data.
@end itemize
The PA-RISC space registers and associated stack --
including the stack pointer r27 -- must be initialized when the
initialize_executive directive is invoked. RTEMS treats the
space registers as system resources shared by all tasks and does
not modify or context switch them.
This memory model 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
memory is addressable. The address may be used to reference a
single byte, half-word (2-bytes), or word (4 bytes).
RTEMS does not require that logical addresses map
directly to physical addresses, although it is desirable in many
applications to do so. RTEMS does not need any additional
information when physical addresses do not map directly to
physical addresses. By not requiring that logical addresses map
directly to physical addresses, the memory space of an RTEMS
space can be separated from that of a ROM monitor. For example,
a ROM monitor may load application programs into a separate
logical address space from itself.
RTEMS assumes that the space registers contain the
selector for the single data segment when a directive is
invoked. This assumption is especially important when
developing interrupt service routines.

36
doc/supplements/hppa1_1/preface.texi
View File

@@ -1,36 +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 PA-RISC V1.1 architecture in
general, refer to the following documents:
@itemize @bullet
@item @cite{PA-RISC 1.1 Architecture and Instruction Set Reference
Manual, Third Edition. HP Part Number 09740-90039}.
@end itemize
It is highly recommended that the PA-RISC RTEMS
application developer also obtain and become familiar with the
Technical Reference Manual for the particular implementation of
the PA-RISC being used.

86
doc/supplements/hppa1_1/timeSIMHPPA.t
View File

@@ -1,86 +0,0 @@
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@chapter HP-7100 Timing Data
@section Introduction
The timing data for the PA-RISC 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 PA-RISC version of RTEMS.
@section Hardware Platform
No directive execution times are reported for the
HP-7100 because the target platform was proprietary and
executions times could not be released.
@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
HP-7100 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 15 Mhz.
[NOTE: The maximum period with interrupts disabled was last
determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
It should be noted again that the maximum period with
interrupts disabled within RTEMS for the HP-7100 is hand calculated.
@section Context Switch
The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
microsections for the HP-7100 when no floating point context
switch is saved or restored. Saving and restoring the floating
point context adds additional time to the context
switch procedure. 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. On many
processors, 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. As discussed in the Register
Usage section, on the HP-7100 the every task is considered to be
floating point registers and , as a rsule, every context switch
involves saving and restoring the state of the floating point
unit.
The following table summarizes the context switch
times for the HP-7100 processor:
@example
no times are available for the HP-7100
@end example
@section Directive Times
No execution times are available for the HP-7100
because the target platform was proprietary and no timing
information could be released.