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

New files -- PowerPC supplement is based on the SPARC supplement.

Browse Source 
This version has had some initial work done to convert it to
be PowerPC specific.
This commit is contained in:
Joel Sherrill
1997-07-01 18:39:44 +00:00
parent 85ecda876c
commit 563f7e0f1c
20 changed files with 3307 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
doc/supplements/powerpc/Makefile Normal file
View File

@@ -0,0 +1,92 @@
#
# COPYRIGHT (c) 1996.
# On-Line Applications Research Corporation (OAR).
# All rights reserved.
#
# $Id$
#
include ../Make.config
PROJECT=powerpc
REPLACE=../tools/word-replace
all:
COMMON_FILES=../common/cpright.texi ../common/setup.texi \
../common/timing.texi
FILES= $(PROJECT).texi \
bsp.texi callconv.texi cpumodel.texi cputable.texi fatalerr.texi \
intr.texi memmodel.texi preface.texi timetbl.texi timedata.texi wksheets.texi
all:
INFOFILES=$(wildcard $(PROJECT) $(PROJECT)-*)
info: c_$(PROJECT)
cp c_$(PROJECT) c_$(PROJECT)-* $(INFO_INSTALL)
c_$(PROJECT): $(FILES)
$(MAKEINFO) $(PROJECT).texi
vinfo: info
$(INFO) -f c_$(PROJECT)
dvi: $(PROJECT).dvi
ps: $(PROJECT).ps
$(PROJECT).ps: $(PROJECT).dvi
dvips -o $(PROJECT).ps $(PROJECT).dvi
cp $(PROJECT).ps $(PS_INSTALL)
dv: dvi
$(XDVI) $(PROJECT).dvi
view: ps
$(GHOSTVIEW) $(PROJECT).ps
$(PROJECT).dvi: $(FILES)
$(TEXI2DVI) $(PROJECT).texi
replace: timedata.texi
intr.texi: intr.t PSIM_TIMES
${REPLACE} -p PSIM_TIMES intr.t
mv intr.t.fixed intr.texi
timetbl.t: ../common/timetbl.t
sed -e 's/TIMETABLE_NEXT_LINK/Command and Variable Index/' \
<../common/timetbl.t >timetbl.t
timetbl.texi: timetbl.t PSIM_TIMES
${REPLACE} -p PSIM_TIMES timetbl.t
mv timetbl.t.fixed timetbl.texi
timedata.texi: timedata.t PSIM_TIMES
${REPLACE} -p PSIM_TIMES timedata.t
mv timedata.t.fixed timedata.texi
wksheets.t: ../common/wksheets.t
sed -e 's/WORKSHEETS_PREVIOUS_LINK/Processor Dependent Information Table CPU Dependent Information Table/' \
-e 's/WORKSHEETS_NEXT_LINK/PSIM Timing Data/' \
<../common/wksheets.t >wksheets.t
wksheets.texi: wksheets.t PSIM_TIMES
${REPLACE} -p PSIM_TIMES wksheets.t
mv wksheets.t.fixed wksheets.texi
html: $(FILES)
-mkdir $(WWW_INSTALL)/c_$(PROJECT)
$(TEXI2WWW) $(TEXI2WWW_ARGS) -dir $(WWW_INSTALL)/c_$(PROJECT) \
$(PROJECT).texi
clean:
rm -f *.o $(PROG) *.txt core
rm -f *.dvi *.ps *.log *.aux *.cp *.fn *.ky *.pg *.toc *.tp *.vr $(BASE)
rm -f $(PROJECT) $(PROJECT)-*
rm -f c_$(PROJECT) c_$(PROJECT)-*
rm -f timedata.texi timetbl.texi intr.texi wksheets.texi
rm -f timetbl.t wksheets.t
rm -f *.fixed _*

246
doc/supplements/powerpc/PSIM_TIMES Normal file
View File

@@ -0,0 +1,246 @@
#
# PowerPC/603e/PSIM Timing and Size Information
#
# $Id$
#
#
# CPU Model Information
#
RTEMS_CPU_MODEL PPC603e
#
# 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

106
doc/supplements/powerpc/bsp.t Normal file
View File

@@ -0,0 +1,106 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Board Support Packages, Board Support Packages Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Top
@end ifinfo
@chapter Board Support Packages
@ifinfo
@menu
* Board Support Packages Introduction::
* Board Support Packages System Reset::
* Board Support Packages Processor Initialization::
@end menu
@end ifinfo
@ifinfo
@node Board Support Packages Introduction, Board Support Packages System Reset, Board Support Packages, Board Support Packages
@end ifinfo
@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.
@ifinfo
@node Board Support Packages System Reset, Board Support Packages Processor Initialization, Board Support Packages Introduction, Board Support Packages
@end ifinfo
@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.
@ifinfo
@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
@end ifinfo
@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 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{RTEMS-LANGUAGE}
Applications User's Manual for the reset code
which is executed before the call to
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
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

106
doc/supplements/powerpc/bsp.texi Normal file
View File

@@ -0,0 +1,106 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Board Support Packages, Board Support Packages Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Top
@end ifinfo
@chapter Board Support Packages
@ifinfo
@menu
* Board Support Packages Introduction::
* Board Support Packages System Reset::
* Board Support Packages Processor Initialization::
@end menu
@end ifinfo
@ifinfo
@node Board Support Packages Introduction, Board Support Packages System Reset, Board Support Packages, Board Support Packages
@end ifinfo
@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.
@ifinfo
@node Board Support Packages System Reset, Board Support Packages Processor Initialization, Board Support Packages Introduction, Board Support Packages
@end ifinfo
@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.
@ifinfo
@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
@end ifinfo
@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 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{RTEMS-LANGUAGE}
Applications User's Manual for the reset code
which is executed before the call to
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
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

447
doc/supplements/powerpc/callconv.t Normal file
View File

@@ -0,0 +1,447 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top
@end ifinfo
@chapter Calling Conventions
@ifinfo
@menu
* Calling Conventions Introduction::
* Calling Conventions Programming Model::
* Calling Conventions Register Windows::
* Calling Conventions Call and Return Mechanism::
* Calling Conventions Calling Mechanism::
* Calling Conventions Register Usage::
* Calling Conventions Parameter Passing::
* Calling Conventions User-Provided Routines::
@end menu
@end ifinfo
@ifinfo
@node Calling Conventions Introduction, Calling Conventions Programming Model, Calling Conventions, Calling Conventions
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
@end ifinfo
@section Programming Model
@ifinfo
@menu
* Non-Floating Point Registers::
* Floating Point Registers::
* Special Registers::
@end menu
@end ifinfo
This section discusses the programming model for the
SPARC architecture.
@ifinfo
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
@end ifinfo
@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
@ifinfo
@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model
@end ifinfo
@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.
@ifinfo
@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions
@end ifinfo
@section Calling Mechanism
All RTEMS directives are invoked using the regular
SPARC calling convention via the call instruction.
@ifinfo
@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
@end ifinfo
@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
@ifinfo
@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions
@end ifinfo
@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.

447
doc/supplements/powerpc/callconv.texi Normal file
View File

@@ -0,0 +1,447 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top
@end ifinfo
@chapter Calling Conventions
@ifinfo
@menu
* Calling Conventions Introduction::
* Calling Conventions Programming Model::
* Calling Conventions Register Windows::
* Calling Conventions Call and Return Mechanism::
* Calling Conventions Calling Mechanism::
* Calling Conventions Register Usage::
* Calling Conventions Parameter Passing::
* Calling Conventions User-Provided Routines::
@end menu
@end ifinfo
@ifinfo
@node Calling Conventions Introduction, Calling Conventions Programming Model, Calling Conventions, Calling Conventions
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
@end ifinfo
@section Programming Model
@ifinfo
@menu
* Non-Floating Point Registers::
* Floating Point Registers::
* Special Registers::
@end menu
@end ifinfo
This section discusses the programming model for the
SPARC architecture.
@ifinfo
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
@end ifinfo
@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
@ifinfo
@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model
@end ifinfo
@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.
@ifinfo
@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions
@end ifinfo
@section Calling Mechanism
All RTEMS directives are invoked using the regular
SPARC calling convention via the call instruction.
@ifinfo
@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
@end ifinfo
@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.
@ifinfo
@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
@end ifinfo
@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
@ifinfo
@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions
@end ifinfo
@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.

193
doc/supplements/powerpc/cpumodel.t Normal file
View File

@@ -0,0 +1,193 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node CPU Model Dependent Features, CPU Model Dependent Features Introduction, Preface, Top
@end ifinfo
@chapter CPU Model Dependent Features
@ifinfo
@menu
* CPU Model Dependent Features Introduction::
* CPU Model Dependent Features CPU Model Feature Flags::
* CPU Model Dependent Features CPU Model Implementation Notes::
@end menu
@end ifinfo
@ifinfo
@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features, CPU Model Dependent Features
@end ifinfo
@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
PowerPC, SPARC, and 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.
@ifinfo
@node CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Introduction, CPU Model Dependent Features
@end ifinfo
@section CPU Model Feature Flags
@ifinfo
@menu
* CPU Model Dependent Features CPU Model Name::
* CPU Model Dependent Features Floating Point Unit::
* CPU Model Dependent Features Alignment::
* CPU Model Dependent Features Cache Alignment::
* CPU Model Dependent Features Maximum Interrupts::
* CPU Model Dependent Features Has Double Precision Floating Point::
* CPU Model Dependent Features Critical Interrupts::
* CPU Model Dependent Features MSR Values::
* CPU Model Dependent Features FPU Status Control Register Values::
* CPU Model Dependent Features Use Multiword Load/Store Instructions::
* CPU Model Dependent Features Instruction Cache Size::
* CPU Model Dependent Features Data Cache Size::
@end menu
@end ifinfo
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 PowerPC implementations and are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
c/src/exec/score/cpu/ppc/ppc.h based upon the particular CPU
model defined on the compilation command line.
@ifinfo
@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the PowerPC 603e
model, this macro is set to the string "PowerPC 603e".
@ifinfo
@node CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features Alignment, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Floating Point Unit
The macro PPC_HAS_FPU is set to 1 to indicate that
this CPU model has a hardware floating point unit and 0
otherwise.
@ifinfo
@node CPU Model Dependent Features Alignment, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Alignment
The macro PPC_ALIGNMENT is set to
@ifinfo
@node CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Alignment, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Cache Alignment
The macro PPC_CACHE_ALIGNMENT is set to
Similarly, the macro PPC_CACHE_ALIGN_POWER is set to the
@ifinfo
@node CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Maximum Interrupts
The macro PPC_INTERRUPT_MAX is set to
@ifinfo
@node CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Has Double Precision Floating Point
The macro PPC_HAS_DOUBLE is set to
@ifinfo
@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features MSR Values, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Critical Interrupts
The macro PPC_HAS_RFCI is set to
@ifinfo
@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection MSR Values
The macro PPC_MSR_DISABLE_MASK is set to
The macro PPC_MSR_INITIAL is set to
The macro PPC_MSR_0 is set to
The macro PPC_MSR_1 is set to
The macro PPC_MSR_2 is set to
The macro PPC_MSR_3 is set to
@ifinfo
@node CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection FPU Status Control Register Values
The macro PPC_INIT_FPSCR is set to
@ifinfo
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Use Multiword Load/Store Instructions
The macro PPC_USE_MULTIPLE is set to
@ifinfo
@node CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Instruction Cache Size
The macro PPC_I_CACHE is set to
@ifinfo
@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Data Cache Size
The macro PPC_D_CACHE is set to
@ifinfo
@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features
@end ifinfo
@section CPU Model Implementation Notes
TBD

193
doc/supplements/powerpc/cpumodel.texi Normal file
View File

@@ -0,0 +1,193 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node CPU Model Dependent Features, CPU Model Dependent Features Introduction, Preface, Top
@end ifinfo
@chapter CPU Model Dependent Features
@ifinfo
@menu
* CPU Model Dependent Features Introduction::
* CPU Model Dependent Features CPU Model Feature Flags::
* CPU Model Dependent Features CPU Model Implementation Notes::
@end menu
@end ifinfo
@ifinfo
@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features, CPU Model Dependent Features
@end ifinfo
@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
PowerPC, SPARC, and 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.
@ifinfo
@node CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Introduction, CPU Model Dependent Features
@end ifinfo
@section CPU Model Feature Flags
@ifinfo
@menu
* CPU Model Dependent Features CPU Model Name::
* CPU Model Dependent Features Floating Point Unit::
* CPU Model Dependent Features Alignment::
* CPU Model Dependent Features Cache Alignment::
* CPU Model Dependent Features Maximum Interrupts::
* CPU Model Dependent Features Has Double Precision Floating Point::
* CPU Model Dependent Features Critical Interrupts::
* CPU Model Dependent Features MSR Values::
* CPU Model Dependent Features FPU Status Control Register Values::
* CPU Model Dependent Features Use Multiword Load/Store Instructions::
* CPU Model Dependent Features Instruction Cache Size::
* CPU Model Dependent Features Data Cache Size::
@end menu
@end ifinfo
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 PowerPC implementations and are of importance to RTEMS.
The set of CPU model feature macros are defined in the file
c/src/exec/score/cpu/ppc/ppc.h based upon the particular CPU
model defined on the compilation command line.
@ifinfo
@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the PowerPC 603e
model, this macro is set to the string "PowerPC 603e".
@ifinfo
@node CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features Alignment, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Floating Point Unit
The macro PPC_HAS_FPU is set to 1 to indicate that
this CPU model has a hardware floating point unit and 0
otherwise.
@ifinfo
@node CPU Model Dependent Features Alignment, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Alignment
The macro PPC_ALIGNMENT is set to
@ifinfo
@node CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Alignment, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Cache Alignment
The macro PPC_CACHE_ALIGNMENT is set to
Similarly, the macro PPC_CACHE_ALIGN_POWER is set to the
@ifinfo
@node CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Maximum Interrupts
The macro PPC_INTERRUPT_MAX is set to
@ifinfo
@node CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Has Double Precision Floating Point
The macro PPC_HAS_DOUBLE is set to
@ifinfo
@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features MSR Values, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Critical Interrupts
The macro PPC_HAS_RFCI is set to
@ifinfo
@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection MSR Values
The macro PPC_MSR_DISABLE_MASK is set to
The macro PPC_MSR_INITIAL is set to
The macro PPC_MSR_0 is set to
The macro PPC_MSR_1 is set to
The macro PPC_MSR_2 is set to
The macro PPC_MSR_3 is set to
@ifinfo
@node CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection FPU Status Control Register Values
The macro PPC_INIT_FPSCR is set to
@ifinfo
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Use Multiword Load/Store Instructions
The macro PPC_USE_MULTIPLE is set to
@ifinfo
@node CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Instruction Cache Size
The macro PPC_I_CACHE is set to
@ifinfo
@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
@end ifinfo
@subsection Data Cache Size
The macro PPC_D_CACHE is set to
@ifinfo
@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features
@end ifinfo
@section CPU Model Implementation Notes
TBD

111
doc/supplements/powerpc/cputable.t Normal file
View File

@@ -0,0 +1,111 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Processor Dependent Information Table, Processor Dependent Information Table Introduction, Board Support Packages Processor Initialization, Top
@end ifinfo
@chapter Processor Dependent Information Table
@ifinfo
@menu
* Processor Dependent Information Table Introduction::
* Processor Dependent Information Table CPU Dependent Information Table::
@end menu
@end ifinfo
@ifinfo
@node Processor Dependent Information Table Introduction, Processor Dependent Information Table CPU Dependent Information Table, Processor Dependent Information Table, Processor Dependent Information Table
@end ifinfo
@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.
@ifinfo
@node Processor Dependent Information Table CPU Dependent Information Table, Memory Requirements, Processor Dependent Information Table Introduction, Processor Dependent Information Table
@end ifinfo
@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
struct cpu_configuration_table @{
void (*pretasking_hook)( void );
void (*predriver_hook)( void );
void (*postdriver_hook)( void );
void (*idle_task)( void );
boolean do_zero_of_workspace;
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 */
@};
@end example
@table @code
@item pretasking_hook
is the address of the
user provided routine which is invoked once RTEMS initialization
is complete but before interrupts and tasking are enabled. This
field may be NULL to indicate that the hook is not utilized.
@item predriver_hook
is the address of the user provided
routine which is invoked with tasking enabled immediately before
the MPCI and device drivers are initialized. RTEMS
initialization is complete, interrupts and tasking are enabled,
but no device drivers are initialized. This field may be NULL to
indicate that the hook is not utilized.
@item postdriver_hook
is the address of the user provided
routine which is invoked with tasking enabled immediately after
the MPCI and device drivers are initialized. RTEMS
initialization is complete, interrupts and tasking are enabled,
and the device drivers are initialized. 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 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

111
doc/supplements/powerpc/cputable.texi Normal file
View File

@@ -0,0 +1,111 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Processor Dependent Information Table, Processor Dependent Information Table Introduction, Board Support Packages Processor Initialization, Top
@end ifinfo
@chapter Processor Dependent Information Table
@ifinfo
@menu
* Processor Dependent Information Table Introduction::
* Processor Dependent Information Table CPU Dependent Information Table::
@end menu
@end ifinfo
@ifinfo
@node Processor Dependent Information Table Introduction, Processor Dependent Information Table CPU Dependent Information Table, Processor Dependent Information Table, Processor Dependent Information Table
@end ifinfo
@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.
@ifinfo
@node Processor Dependent Information Table CPU Dependent Information Table, Memory Requirements, Processor Dependent Information Table Introduction, Processor Dependent Information Table
@end ifinfo
@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
struct cpu_configuration_table @{
void (*pretasking_hook)( void );
void (*predriver_hook)( void );
void (*postdriver_hook)( void );
void (*idle_task)( void );
boolean do_zero_of_workspace;
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 */
@};
@end example
@table @code
@item pretasking_hook
is the address of the
user provided routine which is invoked once RTEMS initialization
is complete but before interrupts and tasking are enabled. This
field may be NULL to indicate that the hook is not utilized.
@item predriver_hook
is the address of the user provided
routine which is invoked with tasking enabled immediately before
the MPCI and device drivers are initialized. RTEMS
initialization is complete, interrupts and tasking are enabled,
but no device drivers are initialized. This field may be NULL to
indicate that the hook is not utilized.
@item postdriver_hook
is the address of the user provided
routine which is invoked with tasking enabled immediately after
the MPCI and device drivers are initialized. RTEMS
initialization is complete, interrupts and tasking are enabled,
and the device drivers are initialized. 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 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

47
doc/supplements/powerpc/fatalerr.t Normal file
View File

@@ -0,0 +1,47 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Default Fatal Error Processing, Default Fatal Error Processing Introduction, Interrupt Processing Interrupt Stack, Top
@end ifinfo
@chapter Default Fatal Error Processing
@ifinfo
@menu
* Default Fatal Error Processing Introduction::
* Default Fatal Error Processing Default Fatal Error Handler Operations::
@end menu
@end ifinfo
@ifinfo
@node Default Fatal Error Processing Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Default Fatal Error Processing, Default Fatal Error Processing
@end ifinfo
@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.
@ifinfo
@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing
@end ifinfo
@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.

47
doc/supplements/powerpc/fatalerr.texi Normal file
View File

@@ -0,0 +1,47 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Default Fatal Error Processing, Default Fatal Error Processing Introduction, Interrupt Processing Interrupt Stack, Top
@end ifinfo
@chapter Default Fatal Error Processing
@ifinfo
@menu
* Default Fatal Error Processing Introduction::
* Default Fatal Error Processing Default Fatal Error Handler Operations::
@end menu
@end ifinfo
@ifinfo
@node Default Fatal Error Processing Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Default Fatal Error Processing, Default Fatal Error Processing
@end ifinfo
@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.
@ifinfo
@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing
@end ifinfo
@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.

234
doc/supplements/powerpc/intr.t Normal file
View File

@@ -0,0 +1,234 @@
@c
@c COPYRIGHT (c) 1988-1997.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
@end ifinfo
@chapter Interrupt Processing
@ifinfo
@menu
* Interrupt Processing Introduction::
* Interrupt Processing Synchronous Versus Asynchronous Traps::
* Interrupt Processing Vectoring of Interrupt Handler::
* Interrupt Processing Traps and Register Windows::
* Interrupt Processing Interrupt Levels::
* Interrupt Processing Disabling of Interrupts by RTEMS::
* Interrupt Processing Interrupt Stack::
@end menu
@end ifinfo
@ifinfo
@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
@end ifinfo
@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 PowerPC 603e 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.
@ifinfo
@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
@end ifinfo
@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.

234
doc/supplements/powerpc/intr_NOTIMES.t Normal file
View File

@@ -0,0 +1,234 @@
@c
@c COPYRIGHT (c) 1988-1997.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
@end ifinfo
@chapter Interrupt Processing
@ifinfo
@menu
* Interrupt Processing Introduction::
* Interrupt Processing Synchronous Versus Asynchronous Traps::
* Interrupt Processing Vectoring of Interrupt Handler::
* Interrupt Processing Traps and Register Windows::
* Interrupt Processing Interrupt Levels::
* Interrupt Processing Disabling of Interrupts by RTEMS::
* Interrupt Processing Interrupt Stack::
@end menu
@end ifinfo
@ifinfo
@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing
@end ifinfo
@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.
@ifinfo
@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
@end ifinfo
@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 PowerPC 603e 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.
@ifinfo
@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
@end ifinfo
@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.

119
doc/supplements/powerpc/memmodel.t Normal file
View File

@@ -0,0 +1,119 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top
@end ifinfo
@chapter Memory Model
@ifinfo
@menu
* Memory Model Introduction::
* Memory Model Flat Memory Model::
@end menu
@end ifinfo
@ifinfo
@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model
@end ifinfo
@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.
@ifinfo
@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model
@end ifinfo
@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.

119
doc/supplements/powerpc/memmodel.texi Normal file
View File

@@ -0,0 +1,119 @@
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top
@end ifinfo
@chapter Memory Model
@ifinfo
@menu
* Memory Model Introduction::
* Memory Model Flat Memory Model::
@end menu
@end ifinfo
@ifinfo
@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model
@end ifinfo
@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.
@ifinfo
@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model
@end ifinfo
@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.

118
doc/supplements/powerpc/powerpc.texi Normal file
View File

@@ -0,0 +1,118 @@
\input ../texinfo/texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename c_powerpc
@syncodeindex vr fn
@synindex ky cp
@paragraphindent 0
@c @smallbook
@c %**end of header
@c
@c COPYRIGHT (c) 1988-1996.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@c
@c Master file for the PowerPC Applications Supplement
@c
@include ../common/setup.texi
@ignore
@ifinfo
@format
START-INFO-DIR-ENTRY
* RTEMS PowerPC Applications Supplement (powerpc):
END-INFO-DIR-ENTRY
@end format
@end ifinfo
@end ignore
@c
@c Title Page Stuff
@c
@set edition 4.2.0-beta1
@set update-date 1 June 1997
@set update-month June 1997
@c
@c I don't really like having a short title page. --joel
@c
@c @shorttitlepage RTEMS PowerPC Applications Supplement
@setchapternewpage odd
@settitle RTEMS PowerPC Applications Supplement
@titlepage
@finalout
@title RTEMS PowerPC Applications Supplement
@subtitle Edition @value{edition}, for RTEMS 4.2.0-prerelease
@sp 1
@subtitle @value{update-month}
@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 ../common/timing.texi
@include timedata.texi
@ifinfo
@node Top, Preface, (dir), (dir)
@top c_powerpc
This is the online version of the RTEMS PowerPC 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::
* PPC603e 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, PPC603e 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
@c @contents
@bye

59
doc/supplements/powerpc/preface.texi Normal file
View File

@@ -0,0 +1,59 @@
@c
@c COPYRIGHT (c) 1988-1996.
@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 PowerPC architecture
dependencies in this port of RTEMS.
It is highly recommended that the PowerPC 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 PowerPC architecture which
corresponds to that processor.
@subheading PowerPC Architecture Documents
For information on the PowerPC architecture, refer to
the following documents available from Motorola
(http://www.moto.com):
@itemize @bullet
@item some PowerPC document shere
@end itemize
@subheading PowerPC Processor Simulator Information
PSIM is a program which emulates the Instruction Set Architecture
of the PowerPC microprocessor family. It is reely available in source
code form under the terms of the GNU General Public License (version
2 or later). PSIM can be integrated with the GNU Debugger (gdb) to
execute and debug PowerPC executables on non-PowerPC hosts. PSIM
supports the addition of user provided device models which can be
used to allow one to develop and debug embedded applications using
the simulator.
The latest version of PSIM is made available to the public via
anonymous ftp at ftp://ftp.ci.com.au/pub/psim or
ftp://cambridge.cygnus.com/pub/psim. There is also a mailing list
at powerpc-psim@@ci.com.au.

139
doc/supplements/powerpc/timePSIM.t Normal file
View File

@@ -0,0 +1,139 @@
@c
@c COPYRIGHT (c) 1988-1997.
@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
@ifinfo
@node PPC603e Timing Data, PPC603e Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
@end ifinfo
@chapter PPC603e Timing Data
@ifinfo
@menu
* PPC603e Timing Data Introduction::
* PPC603e Timing Data Hardware Platform::
* PPC603e Timing Data Interrupt Latency::
* PPC603e Timing Data Context Switch::
* PPC603e Timing Data Directive Times::
* PPC603e Timing Data Task Manager::
* PPC603e Timing Data Interrupt Manager::
* PPC603e Timing Data Clock Manager::
* PPC603e Timing Data Timer Manager::
* PPC603e Timing Data Semaphore Manager::
* PPC603e Timing Data Message Manager::
* PPC603e Timing Data Event Manager::
* PPC603e Timing Data Signal Manager::
* PPC603e Timing Data Partition Manager::
* PPC603e Timing Data Region Manager::
* PPC603e Timing Data Dual-Ported Memory Manager::
* PPC603e Timing Data I/O Manager::
* PPC603e Timing Data Rate Monotonic Manager::
@end menu
@end ifinfo
@ifinfo
@node PPC603e Timing Data Introduction, PPC603e Timing Data Hardware Platform, PPC603e Timing Data, PPC603e Timing Data
@end ifinfo
@section Introduction
The timing data for RTEMS on the 603e implementation
of the PowerPC 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
PowerPC version of RTEMS.
@ifinfo
@node PPC603e Timing Data Hardware Platform, PPC603e Timing Data Interrupt Latency, PPC603e Timing Data Introduction, PPC603e Timing Data
@end ifinfo
@section Hardware Platform
All times reported in this chapter were measured using the PowerPC
Instruction Simulator (PSIM). PSIM simulates a variety of PowerPC
6xx models with the PPC603e being used as the basis for the measurements
reported in this chapter.
The PowerPC decrementer register was was used to gather
all timing information. In real hardware implementations
of the PowerPC architecture, this register would typically
count something like CPU cycles or be a function of the clock
speed. However, wth PSIM each count of the decrementer register
represents an instruction. Thus all measurements in this
chapter are reported as the actual number of instructions
executed. All sources of hardware interrupts were disabled,
although traps were enabled and the interrupt level of the
PowerPC allows all interrupts.
@ifinfo
@node PPC603e Timing Data Interrupt Latency, PPC603e Timing Data Context Switch, PPC603e Timing Data Hardware Platform, PPC603e Timing Data
@end ifinfo
@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
PowerPC 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 PSIM. The maximum
period with interrupts disabled with RTEMS occurs .... XXX
The interrupt vector and entry overhead time was
generated on the PSIM benchmark platform using the PowerPC's
decrementer register. This register was programmed to generate
an interrupt after one countdown.
@ifinfo
@node PPC603e Timing Data Context Switch, PPC603e Timing Data Directive Times, PPC603e Timing Data Interrupt Latency, PPC603e Timing Data
@end ifinfo
@section Context Switch
The RTEMS processor context switch time is XXX
microseconds on the PSIM 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 PSIM benchmark platform:
@include timetbl.texi
@tex
\global\advance \smallskipamount by 4pt
@end tex

139
doc/supplements/powerpc/timedata.t Normal file
View File

@@ -0,0 +1,139 @@
@c
@c COPYRIGHT (c) 1988-1997.
@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
@ifinfo
@node PPC603e Timing Data, PPC603e Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
@end ifinfo
@chapter PPC603e Timing Data
@ifinfo
@menu
* PPC603e Timing Data Introduction::
* PPC603e Timing Data Hardware Platform::
* PPC603e Timing Data Interrupt Latency::
* PPC603e Timing Data Context Switch::
* PPC603e Timing Data Directive Times::
* PPC603e Timing Data Task Manager::
* PPC603e Timing Data Interrupt Manager::
* PPC603e Timing Data Clock Manager::
* PPC603e Timing Data Timer Manager::
* PPC603e Timing Data Semaphore Manager::
* PPC603e Timing Data Message Manager::
* PPC603e Timing Data Event Manager::
* PPC603e Timing Data Signal Manager::
* PPC603e Timing Data Partition Manager::
* PPC603e Timing Data Region Manager::
* PPC603e Timing Data Dual-Ported Memory Manager::
* PPC603e Timing Data I/O Manager::
* PPC603e Timing Data Rate Monotonic Manager::
@end menu
@end ifinfo
@ifinfo
@node PPC603e Timing Data Introduction, PPC603e Timing Data Hardware Platform, PPC603e Timing Data, PPC603e Timing Data
@end ifinfo
@section Introduction
The timing data for RTEMS on the 603e implementation
of the PowerPC 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
PowerPC version of RTEMS.
@ifinfo
@node PPC603e Timing Data Hardware Platform, PPC603e Timing Data Interrupt Latency, PPC603e Timing Data Introduction, PPC603e Timing Data
@end ifinfo
@section Hardware Platform
All times reported in this chapter were measured using the PowerPC
Instruction Simulator (PSIM). PSIM simulates a variety of PowerPC
6xx models with the PPC603e being used as the basis for the measurements
reported in this chapter.
The PowerPC decrementer register was was used to gather
all timing information. In real hardware implementations
of the PowerPC architecture, this register would typically
count something like CPU cycles or be a function of the clock
speed. However, wth PSIM each count of the decrementer register
represents an instruction. Thus all measurements in this
chapter are reported as the actual number of instructions
executed. All sources of hardware interrupts were disabled,
although traps were enabled and the interrupt level of the
PowerPC allows all interrupts.
@ifinfo
@node PPC603e Timing Data Interrupt Latency, PPC603e Timing Data Context Switch, PPC603e Timing Data Hardware Platform, PPC603e Timing Data
@end ifinfo
@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
PowerPC 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 PSIM. The maximum
period with interrupts disabled with RTEMS occurs .... XXX
The interrupt vector and entry overhead time was
generated on the PSIM benchmark platform using the PowerPC's
decrementer register. This register was programmed to generate
an interrupt after one countdown.
@ifinfo
@node PPC603e Timing Data Context Switch, PPC603e Timing Data Directive Times, PPC603e Timing Data Interrupt Latency, PPC603e Timing Data
@end ifinfo
@section Context Switch
The RTEMS processor context switch time is XXX
microseconds on the PSIM 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 PSIM benchmark platform:
@include timetbl.texi
@tex
\global\advance \smallskipamount by 4pt
@end tex