forked from Imagelibrary/rtems
Removed.
This commit is contained in:
Joel Sherrill
@@ -1,174 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-1998.
|
||||
@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 Name, Top
|
||||
@end ifinfo
|
||||
@chapter Calling Conventions
|
||||
@ifinfo
|
||||
@menu
|
||||
* Calling Conventions Introduction::
|
||||
* Calling Conventions Processor Background::
|
||||
* 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 Processor Background, 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.
|
||||
|
||||
This chapter describes the calling conventions used
|
||||
by the GNU C and standard HP-UX compilers for the PA-RISC
|
||||
architecture.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions
|
||||
@end ifinfo
|
||||
@section Processor Background
|
||||
|
||||
The PA-RISC architecture supports a simple yet
|
||||
effective call and return mechanism for subroutine calls where
|
||||
the caller and callee are both in the same address space. The
|
||||
compiler will not automatically generate subroutine calls which
|
||||
cross address spaces. A subroutine is invoked via the branch
|
||||
and link (bl) or the branch and link register (blr). These
|
||||
instructions save the return address in a caller specified
|
||||
register. By convention, the return address is saved in r2.
|
||||
The callee is responsible for maintaining the return address so
|
||||
it can return to the correct address. The branch vectored (bv)
|
||||
instruction is used to branch to the return address and thus
|
||||
return from the subroutine to the caller. It is is important to
|
||||
note that the PA-RISC subroutine call and return mechanism does
|
||||
not automatically save or restore any registers. It is the
|
||||
responsibility of the high-level language compiler to define the
|
||||
register preservation and usage convention.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions
|
||||
@end ifinfo
|
||||
@section Calling Mechanism
|
||||
|
||||
All RTEMS directives are invoked as standard
|
||||
subroutines via a bl or a blr instruction with the return address
|
||||
assumed to be in r2 and return to the user application via the
|
||||
bv instruction.
|
||||
|
||||
@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 bl and blr instructions do
|
||||
not automatically save any registers. RTEMS uses the registers
|
||||
r1, r19 - r26, and r31 as scratch registers. The PA-RISC
|
||||
calling convention specifies that the first four (4) arguments
|
||||
to subroutines are passed in registers r23 - r26. After the
|
||||
arguments have been used, the contents of these registers may be
|
||||
altered. Register r31 is the millicode scratch register.
|
||||
Millicode is the set of routines which support high-level
|
||||
languages on the PA-RISC by providing routines which are either
|
||||
too complex or too long for the compiler to generate inline code
|
||||
when these operations are needed. For example, indirect calls
|
||||
utilize a millicode routine. The scratch registers are not
|
||||
preserved by RTEMS directives therefore, the contents of these
|
||||
registers should not be assumed upon return from any RTEMS
|
||||
directive.
|
||||
|
||||
Surprisingly, when using the GNU C compiler at least
|
||||
integer multiplies are performed using the floating point
|
||||
registers. This is an important optimization because the
|
||||
PA-RISC does not have otherwise have hardware for multiplies.
|
||||
This has important ramifications in regards to the PA-RISC port
|
||||
of RTEMS. On most processors, the floating point unit is
|
||||
ignored if the code only performs integer operations. This
|
||||
makes it easy for the application developer to predict whether
|
||||
or not any particular task will require floating point
|
||||
operations. This property is taken advantage of by RTEMS on
|
||||
other architectures to minimize the number of times the floating
|
||||
point context is saved and restored. However, on the PA-RISC
|
||||
architecture, every task is implicitly a floating point task.
|
||||
Additionally the state of the floating point unit must be saved
|
||||
and restored as part of the interrupt processing because for all
|
||||
practical purposes it is impossible to avoid the use of the
|
||||
floating point registers. It is unknown if the HP-UX C compiler
|
||||
shares this property.
|
||||
|
||||
@itemize @code{ }
|
||||
@item @b{NOTE}: Later versions of the GNU C has a PA-RISC specific
|
||||
option to disable use of the floating point registers. RTEMS
|
||||
currently assumes that this option is not turned on. If the use
|
||||
of this option sets a built-in define, then it should be
|
||||
possible to modify the PA-RISC specific code such that all tasks
|
||||
are considered floating point only when this option is not used.
|
||||
@end itemize
|
||||
|
||||
@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 the first four (4) arguments are
|
||||
placed in the appropriate registers (r26, r25, r24, and r23)
|
||||
and, if needed, additional are placed on the current stack
|
||||
before the directive is invoked via the bl or blr instruction.
|
||||
The first argument is placed in r26, the second is placed in
|
||||
r25, and so forth. The following pseudo-code illustrates the
|
||||
typical sequence used to call a RTEMS directive with three (3)
|
||||
arguments:
|
||||
|
||||
|
||||
@example
|
||||
set r24 to the third argument
|
||||
set r25 to the second argument
|
||||
set r26 to the first argument
|
||||
invoke directive
|
||||
@end example
|
||||
|
||||
The stack on the PA-RISC grows upward -- i.e.
|
||||
"pushing" onto the stack results in the address in the stack
|
||||
pointer becoming numerically larger. By convention, r27 is used
|
||||
as the stack pointer. The standard stack frame consists of a
|
||||
minimum of sixty-four (64) bytes and is the responsibility of
|
||||
the callee to maintain.
|
||||
|
||||
@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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,67 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-1998.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Memory Model
|
||||
|
||||
@section Introduction
|
||||
|
||||
A processor may support any combination of memory
|
||||
models ranging from pure physical addressing to complex demand
|
||||
paged virtual memory systems. RTEMS supports a flat memory
|
||||
model which ranges contiguously over the processor's allowable
|
||||
address space. RTEMS does not support segmentation or virtual
|
||||
memory of any kind. The appropriate memory model for RTEMS
|
||||
provided by the targeted processor and related characteristics
|
||||
of that model are described in this chapter.
|
||||
|
||||
@section Flat Memory Model
|
||||
|
||||
RTEMS supports applications in which the application
|
||||
and the executive execute within a single thirty-two bit address
|
||||
space. Thus RTEMS and the application share a common four
|
||||
gigabyte address space within a single space. The PA-RISC
|
||||
automatically converts every address from a logical to a
|
||||
physical address each time it is used. The PA-RISC uses
|
||||
information provided in the page table to perform this
|
||||
translation. The following protection levels are assumed:
|
||||
|
||||
@itemize @bullet
|
||||
@item a single code segment at protection level (0) which
|
||||
contains all application and executive code.
|
||||
|
||||
@item a single data segment at protection level zero (0) which
|
||||
contains all application and executive data.
|
||||
@end itemize
|
||||
|
||||
The PA-RISC space registers and associated stack --
|
||||
including the stack pointer r27 -- must be initialized when the
|
||||
initialize_executive directive is invoked. RTEMS treats the
|
||||
space registers as system resources shared by all tasks and does
|
||||
not modify or context switch them.
|
||||
|
||||
This memory model supports a flat 32-bit address
|
||||
space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
|
||||
gigabytes). Each address is represented by a 32-bit value and
|
||||
memory is addressable. The address may be used to reference a
|
||||
single byte, half-word (2-bytes), or word (4 bytes).
|
||||
|
||||
RTEMS does not require that logical addresses map
|
||||
directly to physical addresses, although it is desirable in many
|
||||
applications to do so. RTEMS does not need any additional
|
||||
information when physical addresses do not map directly to
|
||||
physical addresses. By not requiring that logical addresses map
|
||||
directly to physical addresses, the memory space of an RTEMS
|
||||
space can be separated from that of a ROM monitor. For example,
|
||||
a ROM monitor may load application programs into a separate
|
||||
logical address space from itself.
|
||||
|
||||
RTEMS assumes that the space registers contain the
|
||||
selector for the single data segment when a directive is
|
||||
invoked. This assumption is especially important when
|
||||
developing interrupt service routines.
|
||||
|
||||
Reference in New Issue
Block a user