From 16a1fd9c33fdf99d1c9ac9b636e6e52bb04cf61e Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Mon, 19 Oct 1998 18:30:26 +0000 Subject: Renamed a lot of files. --- doc/supplements/i960/Makefile | 51 +++++++-- doc/supplements/i960/bsp.texi | 73 ------------ doc/supplements/i960/callconv.texi | 132 --------------------- doc/supplements/i960/cpumodel.texi | 81 ------------- doc/supplements/i960/cputable.texi | 140 ----------------------- doc/supplements/i960/fatalerr.texi | 45 -------- doc/supplements/i960/intr.t | 228 ------------------------------------- doc/supplements/i960/memmodel.texi | 55 --------- 8 files changed, 41 insertions(+), 764 deletions(-) delete mode 100644 doc/supplements/i960/bsp.texi delete mode 100644 doc/supplements/i960/callconv.texi delete mode 100644 doc/supplements/i960/cpumodel.texi delete mode 100644 doc/supplements/i960/cputable.texi delete mode 100644 doc/supplements/i960/fatalerr.texi delete mode 100644 doc/supplements/i960/intr.t delete mode 100644 doc/supplements/i960/memmodel.texi (limited to 'doc/supplements') diff --git a/doc/supplements/i960/Makefile b/doc/supplements/i960/Makefile index a2b355ec71..dbf2eb6408 100644 --- a/doc/supplements/i960/Makefile +++ b/doc/supplements/i960/Makefile @@ -20,6 +20,10 @@ dirs: COMMON_FILES=../../common/cpright.texi ../../common/setup.texi +#GENERATED_FILES=\ +# cpumodel.texi callconv.texi memmodel.texi intr.texi fatalerr.texi \ +# bsp.texi cputable.texi timing.texi wksheets.texi timeFORCE386.texi + GENERATED_FILES= \ timing.texi wksheets.texi @@ -50,21 +54,48 @@ replace: timedata.texi # Chapters which get automatic processing # -# CPU Model -# Calling Conventions -# Memory Model +cpumodel.texi: cpumodel.t Makefile + $(BMENU) -p "Preface" \ + -u "Top" \ + -n "Calling Conventions" ${*}.t + +callconv.texi: callconv.t Makefile + $(BMENU) -p "CPU Model Dependent Features Floating Point Unit" \ + -u "Top" \ + -n "Memory Model" ${*}.t + +memmodel.texi: memmodel.t Makefile + $(BMENU) -p "Calling Conventions User-Provided Routines" \ + -u "Top" \ + -n "Interrupt Processing" ${*}.t # Interrupt Chapter: # 1. Replace Times and Sizes # 2. Build Node Structure +intr.t: intr_NOTIMES.t CVME961_TIMES + ${REPLACE} -p CVME961_TIMES intr_NOTIMES.t + mv intr_NOTIMES.t.fixed intr.t -intr.texi: intr.t CVME961_TIMES - ${REPLACE} -p CVME961_TIMES intr.t - mv intr.t.fixed intr.texi +intr.texi: intr.t Makefile + $(BMENU) -p "Memory Model Flat Memory Model" \ + -u "Top" \ + -n "Default Fatal Error Processing" ${*}.t + +fatalerr.texi: fatalerr.t Makefile + $(BMENU) -p "Interrupt Processing Interrupt Stack" \ + -u "Top" \ + -n "Board Support Packages" ${*}.t + +bsp.texi: bsp.t Makefile + $(BMENU) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ + -u "Top" \ + -n "Processor Dependent Information Table" ${*}.t + +cputable.texi: cputable.t Makefile + $(BMENU) -p "Board Support Packages Processor Initialization" \ + -u "Top" \ + -n "Memory Requirements" ${*}.t -# Fatal Error -# BSP -# CPU Table # Worksheets Chapter: # 1. Obtain the Shared File @@ -119,7 +150,7 @@ clean: rm -f *.dvi *.ps *.log *.aux *.cp *.fn *.ky *.pg *.toc *.tp *.vr $(BASE) rm -f $(PROJECT) $(PROJECT)-* rm -f c_i960 c_i960-* - rm -f timedata.texi timetbl.texi timetbl.t intr.texi $(GENERATED_FILES) + rm -f timedata.texi timetbl.texi timetbl.t intr.t $(GENERATED_FILES) rm -f wksheets.t wksheets_NOTIMES.t rm -f *.fixed _* timing.t timing.texi diff --git a/doc/supplements/i960/bsp.texi b/doc/supplements/i960/bsp.texi deleted file mode 100644 index 6e7fb00516..0000000000 --- a/doc/supplements/i960/bsp.texi +++ /dev/null @@ -1,73 +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 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 i960CA specific BSP -issues. For more information on developing a BSP, refer to the -chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - -@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 when the -i960CA processor is reset. When the i960CA is reset, the -processor reads an Initial Memory Image (IMI) to establish its -state. The IMI consists of the Initialization Boot Record (IBR) -and the Process Control Block (PRCB) from an Initial Memory -Image (IMI) at location 0xFFFFFF00. The IBR contains the -initial bus configuration data, the address of the first -instruction to execute after reset, the address of the PRCB, and -the checksum used by the processor's self-test. - -@ifinfo -@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages -@end ifinfo -@section Processor Initialization - -The PRCB contains the base addresses for system data -structures, and initial configuration information for the core -and integrated peripherals. In particular, the PRCB contains -the initial contents of the Arithmetic Control (AC) Register as -well as the base addresses of the Interrupt Vector Table, System -Procedure Entry Table, Fault Entry Table, and the Control Table. -In addition, the PRCB is used to configure the depth of the -instruction and register caches and the actions when certain -types of faults are encountered. - -The Process Controls (PC) Register is initialized to -0xC01F2002 which sets the i960CA's interrupt level to 0x1F (31 -decimal). In addition, the Interrupt Mask (IMSK) Register -(alternately referred to as Special Function Register 1 or sf1) -is set to 0x00000000 to mask all external and DMA interrupt -sources. Thus, all interrupts are disabled when the first -instruction is executed. - -For more information regarding the i960CA's data -structures and their contents, refer to Intel's i960CA User's -Manual. diff --git a/doc/supplements/i960/callconv.texi b/doc/supplements/i960/callconv.texi deleted file mode 100644 index 2c9c03d513..0000000000 --- a/doc/supplements/i960/callconv.texi +++ /dev/null @@ -1,132 +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 Floating Point Unit, 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:: -* Calling Conventions Leaf Procedures:: -@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. - -@ifinfo -@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions -@end ifinfo -@section Processor Background - -All members of the i960 architecture family support -two methods for performing procedure calls: a RISC-style -branch-and-link and an integrated call and return mechanism. - -On a branch-and-link, the processor branches to the -invoked procedure and saves the return address in a register, -G14. Typically, the invoked procedure will not invoke another -procedure and is referred to as a leaf procedure. Many -high-level language compilers for the i960 family recognize leaf -procedures and automatically optimize them to utilize the -branch-and-link mechanism. Branch-and-link procedures are -invoked using the bal and balx instructions and return control -via the bx instruction. By convention, G14 is zero when not in -a leaf procedure. It is the responsibility of the leaf -procedure to clear G14 before returning. - -The integrated call and return mechanism also -branches to the invoked procedure and saves the return address -as did the branch and link mechanism. However, the important -difference is that the call, callx, and calls instructions save -the local register set (R0 through R15) before transferring -control to the invoked procedure. The ret instruction -automatically restores the previous local register set. The -i960CA provides a register cache which can be configured to -retain the last five to sixteen recent register caches. When -the register cache is full, the oldest cached register set is -written to the stack. - -@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 using either a call -or callx instruction and return to the user via the ret -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 and callx instructions -automatically save the current contents of the local register -set (R0 through R15). The contents of the local registers will -be restored as part of returning to the application. The -contents of global registers G0 through G7 are not preserved by -RTEMS directives. - -@ifinfo -@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions -@end ifinfo -@section Parameter Passing - -RTEMS uses the standard i960 family C parameter -passing mechanism in which G0 contains the first parameter, G1 -the second, and so on for the remaining parameters. No RTEMS -directive requires more than six parameters. - -@ifinfo -@node Calling Conventions User-Provided Routines, Calling Conventions Leaf Procedures, 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. - -@ifinfo -@node Calling Conventions Leaf Procedures, Memory Model, Calling Conventions User-Provided Routines, Calling Conventions -@end ifinfo -@section Leaf Procedures - -RTEMS utilizes leaf procedures internally to improve -performance. This improves execution speed as well as reducing -stack usage and the number of register sets which must be cached. - - diff --git a/doc/supplements/i960/cpumodel.texi b/doc/supplements/i960/cpumodel.texi deleted file mode 100644 index 14223c2646..0000000000 --- a/doc/supplements/i960/cpumodel.texi +++ /dev/null @@ -1,81 +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 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 Name:: -* CPU Model Dependent Features Floating Point Unit:: -@end menu -@end ifinfo - -@ifinfo -@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Name, 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 -SPARC or PA-RISC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across i960 implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -c/src/exec/score/cpu/i960/i960.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 Introduction, CPU Model Dependent Features -@end ifinfo -@section CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the Intel i960CA, -this macro is set to the string "i960ca". - -@ifinfo -@node CPU Model Dependent Features Floating Point Unit, Calling Conventions, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features -@end ifinfo -@section Floating Point Unit - -The macro I960_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. diff --git a/doc/supplements/i960/cputable.texi b/doc/supplements/i960/cputable.texi deleted file mode 100644 index 3feb6389f3..0000000000 --- a/doc/supplements/i960/cputable.texi +++ /dev/null @@ -1,140 +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 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 i960CA version of the RTEMS CPU Dependent -Information Table contains the information required to interface -a Board Support Package and RTEMS on the i960CA. This -information is provided to allow RTEMS to interoperate -effectively with the BSP. The C structure definition is given -here: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - -#if defined(__i960CA__) || defined(__i960_CA__) || defined(__i960CA) - i960ca_PRCB *Prcb; -#endif - -@} rtems_cpu_table; -@end group -@end example - -The contents of the i960CA Processor Control Block -are discussed in Intel's i960CA User's Manual. Structure -definitions for the i960CA PRCB and Control Table are provided -by including the file rtems.h. - -@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 idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS -allocated interrupt stack in bytes. This value must be at least -as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item Prcb -is the base address of the i960CA's Processor -Control Block. It is primarily used by RTEMS to install -interrupt handlers. -@end table - - - - - - diff --git a/doc/supplements/i960/fatalerr.texi b/doc/supplements/i960/fatalerr.texi deleted file mode 100644 index d097822783..0000000000 --- a/doc/supplements/i960/fatalerr.texi +++ /dev/null @@ -1,45 +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 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 is configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@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 31, places the error code in G0, and executes a branch to -self instruction to simulate a halt processor instruction. diff --git a/doc/supplements/i960/intr.t b/doc/supplements/i960/intr.t deleted file mode 100644 index 6b6926c8b2..0000000000 --- a/doc/supplements/i960/intr.t +++ /dev/null @@ -1,228 +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 Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top -@end ifinfo -@chapter Interrupt Processing -@ifinfo -@menu -* Interrupt Processing Introduction:: -* Interrupt Processing Vectoring of Interrupt Handler:: -* Interrupt Processing Interrupt Record:: -* Interrupt Processing Interrupt Levels:: -* Interrupt Processing Disabling of Interrupts by RTEMS:: -* Interrupt Processing Register Cache Flushing:: -* Interrupt Processing Interrupt Stack:: -@end menu -@end ifinfo - -@ifinfo -@node Interrupt Processing Introduction, Interrupt Processing Vectoring of Interrupt Handler, 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 the proper handling of an interrupt. The processor -dependent response to the interrupt which modifies the execution -state and results in the modification of the execution stream. -This modification usually requires that an interrupt handler -utilize the provided control mechanisms to return to the normal -processing stream. Although RTEMS hides many of the processor -dependent details of interrupt processing, it is important to -understand how the RTEMS interrupt manager is mapped onto the -processor's unique architecture. Discussed in this chapter are -the the processor's response and control mechanisms as they -pertain to RTEMS. - -@ifinfo -@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Record, Interrupt Processing Introduction, Interrupt Processing -@end ifinfo -@section Vectoring of Interrupt Handler - -Upon receipt of an interrupt the i960CA -automatically performs the following actions: - -@itemize @bullet -@item saves the local register set, - -@item sets the Frame Pointer (FP) to point to the interrupt -stack, - -@item increments the FP by sixteen (16) to make room for the -Interrupt Record, - -@item saves the current values of the arithmetic-controls (AC) -register, the process-controls (PC) register, and the interrupt -vector number are saved in the Interrupt Record, - -@item the CPU sets the Instruction Pointer (IP) to the address -of the first instruction in the interrupt handler, - -@item the return-status field of the Previous Frame Pointer -(PFP or R0) register is set to interrupt return, - -@item sets the PC state bit to interrupted, - -@item sets the current interrupt disable level in the PC to -the level of the current interrupt, and - -@item disables tracing. -@end itemize - -A nested interrupt is processed similarly by the -i960CA with the exception that the Frame Pointer (FP) already -points to the interrupt stack. This means that the FP is NOT -overwritten before space for the Interrupt Record is allocated. - -The state flag bit of the saved PC register in the -Interrupt Record is examined by RTEMS to determine when an outer -most interrupt is being exited. Therefore, the user application -code MUST NOT modify this bit. - -@ifinfo -@node Interrupt Processing Interrupt Record, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing -@end ifinfo -@section Interrupt Record - -The structure of the Interrupt Record for the i960CA -which is placed on the interrupt stack by the processor in -response to an interrupt is as follows: - -@ifset use-ascii -@example -@group - +---------------------------+ - | Saved Process Controls | NFP-16 - +---------------------------+ - | Saved Arithmetic Controls | NFP-12 - +---------------------------+ - | UNUSED | NFP-8 - +---------------------------+ - | UNUSED | NFP-4 - +---------------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\strut\vrule#& -\hbox to 2.00in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.00in{\enskip\hfil#\hfil} -\cr -\multispan{3}\hrulefill\cr -& Saved Process Controls && NFP-16\cr -\multispan{3}\hrulefill\cr -& Saved Arithmetic Controls && NFP-12\cr -\multispan{3}\hrulefill\cr -& UNUSED && NFP-8\cr -\multispan{3}\hrulefill\cr -& UNUSED && NFP-4\cr -\multispan{3}\hrulefill\cr -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -
- - - - - - - - - -
Saved Process ControlsNFP-16
Saved Arithmetic ControlsNFP-12
UNUSEDNFP-8
UNUSEDNFP-4
-
-@end html -@end ifset - -@ifinfo -@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Record, Interrupt Processing -@end ifinfo -@section Interrupt Levels - -Thirty-two levels (0-31) of interrupt priorities are -supported by the i960CA microprocessor with level thirty-one -(31) being the highest priority. Level zero (0) indicates that -interrupts are fully enabled. Interrupt requests for interrupts -with priorities less than or equal to the current interrupt mask -level are ignored. - -Although RTEMS supports 256 interrupt levels, the -i960CA only supports thirty-two. RTEMS interrupt levels 0 -through 31 directly correspond to i960CA interrupt levels. All -other RTEMS interrupt levels are undefined and their behavior is -unpredictable. - -@ifinfo -@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Register Cache Flushing, 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 thirty-one (31) -before the execution of this section and restores them to the -previous level upon completion of the section. RTEMS has been -optimized to insure that interrupts are disabled for less than -RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz i960CA with zero wait states. -These numbers will vary based the number of wait states and -processor speed present on the target board. [NOTE: This -calculation was most recently performed for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -Non-maskable interrupts (NMI) cannot be disabled, and -ISRs which execute at this level MUST NEVER issue RTEMS system -calls. If a directive is invoked, unpredictable results may -occur due to the inability of RTEMS to protect its critical -sections. However, ISRs that make no system calls may safely -execute as non-maskable interrupts. - -@ifinfo -@node Interrupt Processing Register Cache Flushing, Interrupt Processing Interrupt Stack, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing -@end ifinfo -@section Register Cache Flushing - -The i960CA version of the RTEMS interrupt manager is -optimized to insure that the flushreg instruction is only -executed when a context switch is necessary. The flushreg -instruction flushes the i960CA register set cache and takes (14 -+ 23 * number of sets flushed) cycles to execute. As the i960CA -supports caching of from five to sixteen register sets, this -instruction takes from 129 to 382 cycles (3.90 to 11.57 -microseconds at 33 Mhz) to execute given no wait state memory. -RTEMS flushes the register set cache only at the conclusion of -the outermost ISR when a context switch is necessary. The -register set cache will not be flushed as part of processing a -nested interrupt or when a context switch is not necessary. -This optimization is essential to providing high-performance -interrupt management on the i960CA. - -@ifinfo -@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Register Cache Flushing, Interrupt Processing -@end ifinfo -@section Interrupt Stack - -On the i960CA, RTEMS allocates the interrupt stack -from the Workspace Area. The amount of memory allocated for the -interrupt stack is determined by the interrupt_stack_size field -in the CPU Configuration Table. During the initialization -process, RTEMS will install its interrupt stack. - - diff --git a/doc/supplements/i960/memmodel.texi b/doc/supplements/i960/memmodel.texi deleted file mode 100644 index 1a3383838b..0000000000 --- a/doc/supplements/i960/memmodel.texi +++ /dev/null @@ -1,55 +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 Memory Model, Memory Model Introduction, Calling Conventions Leaf Procedures, 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 i960CA supports a flat 32-bit address space with -addresses ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes). -Although the i960CA reserves portions of this address space, -application code and data may be placed in any non-reserved -areas. Each address is represented by a 32-bit value and is -byte addressable. The address may be used to reference a single -byte, half-word (2-bytes), word (4 bytes), double-word (8 -bytes), triple-word (12 bytes) or quad-word (16 bytes). The -i960CA does not support virtual memory or segmentation. - -The i960CA allows the memory space to be partitioned -into sixteen regions which may be configured individually as big -or little endian. RTEMS assumes that the memory regions in -which its code, data, and the RTEMS Workspace reside are -configured as little endian. - - -- cgit v1.2.3