diff options
Diffstat (limited to 'doc/supplements/i960')
| -rw-r--r-- | doc/supplements/i960/CVME961_TIMES | 244 | ||||
| -rw-r--r-- | doc/supplements/i960/Makefile | 88 | ||||
| -rw-r--r-- | doc/supplements/i960/bsp.t | 71 | ||||
| -rw-r--r-- | doc/supplements/i960/bsp.texi | 71 | ||||
| -rw-r--r-- | doc/supplements/i960/callconv.t | 130 | ||||
| -rw-r--r-- | doc/supplements/i960/callconv.texi | 130 | ||||
| -rw-r--r-- | doc/supplements/i960/cpumodel.t | 79 | ||||
| -rw-r--r-- | doc/supplements/i960/cpumodel.texi | 79 | ||||
| -rw-r--r-- | doc/supplements/i960/cputable.t | 130 | ||||
| -rw-r--r-- | doc/supplements/i960/cputable.texi | 130 | ||||
| -rw-r--r-- | doc/supplements/i960/fatalerr.t | 43 | ||||
| -rw-r--r-- | doc/supplements/i960/fatalerr.texi | 43 | ||||
| -rw-r--r-- | doc/supplements/i960/i960.texi | 117 | ||||
| -rw-r--r-- | doc/supplements/i960/intr.t | 220 | ||||
| -rw-r--r-- | doc/supplements/i960/intr_NOTIMES.t | 220 | ||||
| -rw-r--r-- | doc/supplements/i960/memmodel.t | 53 | ||||
| -rw-r--r-- | doc/supplements/i960/memmodel.texi | 53 | ||||
| -rw-r--r-- | doc/supplements/i960/preface.texi | 38 | ||||
| -rw-r--r-- | doc/supplements/i960/timeCVME961.t | 123 | ||||
| -rw-r--r-- | doc/supplements/i960/timedata.t | 123 |
20 files changed, 2185 insertions, 0 deletions
diff --git a/doc/supplements/i960/CVME961_TIMES b/doc/supplements/i960/CVME961_TIMES new file mode 100644 index 0000000000..f148a32d5c --- /dev/null +++ b/doc/supplements/i960/CVME961_TIMES @@ -0,0 +1,244 @@ +# +# Intel i960/Cyclone CVME961 (i960CA) Timing and Size Information +# + +# +# CPU Model Information +# +RTEMS_CPU_MODEL i960CA +# +# Interrupt Latency +# +# NOTE: In general, the text says it is hand-calculated to be +# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +# Mhz and this was last calculated for Release +# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. +# +RTEMS_MAXIMUM_DISABLE_PERIOD 2.5 +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 33 +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.2.1 +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 1 +RTEMS_RESTORE_1ST_FP_TASK 2 +RTEMS_SAVE_INIT_RESTORE_INIT 3 +RTEMS_SAVE_IDLE_RESTORE_INIT 4 +RTEMS_SAVE_IDLE_RESTORE_IDLE 5 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 6 +RTEMS_TASK_IDENT_ONLY 7 +RTEMS_TASK_START_ONLY 8 +RTEMS_TASK_RESTART_CALLING_TASK 9 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 9 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 10 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 11 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 12 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 13 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 14 +RTEMS_TASK_DELETE_CALLING_TASK 15 +RTEMS_TASK_DELETE_SUSPENDED_TASK 16 +RTEMS_TASK_DELETE_BLOCKED_TASK 17 +RTEMS_TASK_DELETE_READY_TASK 18 +RTEMS_TASK_SUSPEND_CALLING_TASK 19 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 20 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 21 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 22 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 23 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 24 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 25 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 26 +RTEMS_TASK_MODE_NO_RESCHEDULE 27 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 28 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 29 +RTEMS_TASK_GET_NOTE_ONLY 30 +RTEMS_TASK_SET_NOTE_ONLY 31 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 32 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 33 +RTEMS_TASK_WAKE_WHEN_ONLY 34 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 35 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 36 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 37 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED 38 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 39 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 40 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 41 +RTEMS_CLOCK_GET_ONLY 42 +RTEMS_CLOCK_TICK_ONLY 43 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 44 +RTEMS_TIMER_IDENT_ONLY 45 +RTEMS_TIMER_DELETE_INACTIVE 46 +RTEMS_TIMER_DELETE_ACTIVE 47 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 48 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 49 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 50 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 51 +RTEMS_TIMER_RESET_INACTIVE 52 +RTEMS_TIMER_RESET_ACTIVE 53 +RTEMS_TIMER_CANCEL_INACTIVE 54 +RTEMS_TIMER_CANCEL_ACTIVE 55 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 56 +RTEMS_SEMAPHORE_IDENT_ONLY 57 +RTEMS_SEMAPHORE_DELETE_ONLY 58 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 59 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 60 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 61 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 62 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 63 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 64 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 65 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 66 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 67 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 68 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 69 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 70 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 71 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 72 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 73 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 74 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 75 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 76 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 77 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 78 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 79 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 80 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 81 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 82 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 83 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 85 +RTEMS_EVENT_RECEIVE_AVAILABLE 86 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 87 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 88 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 89 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 90 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 91 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 92 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 93 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 94 +RTEMS_PARTITION_IDENT_ONLY 95 +RTEMS_PARTITION_DELETE_ONLY 96 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 97 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 98 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 99 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 100 +RTEMS_REGION_IDENT_ONLY 101 +RTEMS_REGION_DELETE_ONLY 102 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 103 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 104 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 105 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 106 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 107 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 108 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 109 +RTEMS_PORT_IDENT_ONLY 110 +RTEMS_PORT_DELETE_ONLY 111 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 112 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 113 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 114 +RTEMS_IO_OPEN_ONLY 115 +RTEMS_IO_CLOSE_ONLY 116 +RTEMS_IO_READ_ONLY 117 +RTEMS_IO_WRITE_ONLY 118 +RTEMS_IO_CONTROL_ONLY 119 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 120 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 121 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 122 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 123 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 124 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 125 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 126 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 127 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 128 +RTEMS_MINIMUM_CONFIGURATION xx,129 +RTEMS_MAXIMUM_CONFIGURATION xx,130 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE x,131 +RTEMS_INITIALIZATION_CODE_SIZE x,132 +RTEMS_TASK_CODE_SIZE x,133 +RTEMS_INTERRUPT_CODE_SIZE x,134 +RTEMS_CLOCK_CODE_SIZE x,135 +RTEMS_TIMER_CODE_SIZE x,136 +RTEMS_SEMAPHORE_CODE_SIZE x,137 +RTEMS_MESSAGE_CODE_SIZE x,138 +RTEMS_EVENT_CODE_SIZE x,139 +RTEMS_SIGNAL_CODE_SIZE x,140 +RTEMS_PARTITION_CODE_SIZE x,141 +RTEMS_REGION_CODE_SIZE x,142 +RTEMS_DPMEM_CODE_SIZE x,143 +RTEMS_IO_CODE_SIZE x,144 +RTEMS_FATAL_ERROR_CODE_SIZE x,145 +RTEMS_RATE_MONOTONIC_CODE_SIZE x,146 +RTEMS_MULTIPROCESSING_CODE_SIZE x,147 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 148 +RTEMS_SEMAPHORE_CODE_OPTSIZE 149 +RTEMS_MESSAGE_CODE_OPTSIZE 150 +RTEMS_EVENT_CODE_OPTSIZE 151 +RTEMS_SIGNAL_CODE_OPTSIZE 152 +RTEMS_PARTITION_CODE_OPTSIZE 153 +RTEMS_REGION_CODE_OPTSIZE 154 +RTEMS_DPMEM_CODE_OPTSIZE 155 +RTEMS_IO_CODE_OPTSIZE 156 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 157 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 158 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 159 +RTEMS_BYTES_PER_TIMER 160 +RTEMS_BYTES_PER_SEMAPHORE 161 +RTEMS_BYTES_PER_MESSAGE_QUEUE 162 +RTEMS_BYTES_PER_REGION 163 +RTEMS_BYTES_PER_PARTITION 164 +RTEMS_BYTES_PER_PORT 165 +RTEMS_BYTES_PER_PERIOD 166 +RTEMS_BYTES_PER_EXTENSION 167 +RTEMS_BYTES_PER_FP_TASK 168 +RTEMS_BYTES_PER_NODE 169 +RTEMS_BYTES_PER_GLOBAL_OBJECT 170 +RTEMS_BYTES_PER_PROXY 171 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS x,172 diff --git a/doc/supplements/i960/Makefile b/doc/supplements/i960/Makefile new file mode 100644 index 0000000000..13a1ebdef9 --- /dev/null +++ b/doc/supplements/i960/Makefile @@ -0,0 +1,88 @@ +# +# COPYRIGHT (c) 1996. +# On-Line Applications Research Corporation (OAR). +# All rights reserved. +# + +include ../Make.config + +PROJECT=i960 +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: + +info: c_i960 + cp c_$(PROJECT) $(INFO_INSTALL) + +c_i960: $(FILES) + $(MAKEINFO) $(PROJECT).texi + +vinfo: info + $(INFO) -f c_i960 + +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 CVME961_TIMES + ${REPLACE} -p CVME961_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 CVME961_TIMES + ${REPLACE} -p CVME961_TIMES timetbl.t + mv timetbl.t.fixed timetbl.texi + +timedata.texi: timedata.t CVME961_TIMES + ${REPLACE} -p CVME961_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/i960CA Timing Data/' \ + <../common/wksheets.t >wksheets.t + +wksheets.texi: wksheets.t CVME961_TIMES + ${REPLACE} -p CVME961_TIMES wksheets.t + mv wksheets.t.fixed wksheets.texi + +html: $(FILES) + -mkdir $(WWW_INSTALL)/c_i960 + $(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_i960 c_i960-* + rm -f timedata.texi timetbl.texi intr.texi wksheets.texi + rm -f timetbl.t wksheets.t + rm -f *.fixed _* + diff --git a/doc/supplements/i960/bsp.t b/doc/supplements/i960/bsp.t new file mode 100644 index 0000000000..423cde737c --- /dev/null +++ b/doc/supplements/i960/bsp.t @@ -0,0 +1,71 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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 C +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/bsp.texi b/doc/supplements/i960/bsp.texi new file mode 100644 index 0000000000..423cde737c --- /dev/null +++ b/doc/supplements/i960/bsp.texi @@ -0,0 +1,71 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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 C +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.t b/doc/supplements/i960/callconv.t new file mode 100644 index 0000000000..7998baee2f --- /dev/null +++ b/doc/supplements/i960/callconv.t @@ -0,0 +1,130 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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/callconv.texi b/doc/supplements/i960/callconv.texi new file mode 100644 index 0000000000..7998baee2f --- /dev/null +++ b/doc/supplements/i960/callconv.texi @@ -0,0 +1,130 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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.t b/doc/supplements/i960/cpumodel.t new file mode 100644 index 0000000000..18ec1d7311 --- /dev/null +++ b/doc/supplements/i960/cpumodel.t @@ -0,0 +1,79 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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/cpumodel.texi b/doc/supplements/i960/cpumodel.texi new file mode 100644 index 0000000000..18ec1d7311 --- /dev/null +++ b/doc/supplements/i960/cpumodel.texi @@ -0,0 +1,79 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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.t b/doc/supplements/i960/cputable.t new file mode 100644 index 0000000000..dbeebd5a68 --- /dev/null +++ b/doc/supplements/i960/cputable.t @@ -0,0 +1,130 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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 +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_free_hook)( void* ); + /* end of fields required on all CPUs */ + +#if defined(__i960CA__) || defined(__i960_CA__) || defined(__i960CA) + i960ca_PRCB *Prcb; +#endif + +@}; +@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 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/cputable.texi b/doc/supplements/i960/cputable.texi new file mode 100644 index 0000000000..dbeebd5a68 --- /dev/null +++ b/doc/supplements/i960/cputable.texi @@ -0,0 +1,130 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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 +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_free_hook)( void* ); + /* end of fields required on all CPUs */ + +#if defined(__i960CA__) || defined(__i960_CA__) || defined(__i960CA) + i960ca_PRCB *Prcb; +#endif + +@}; +@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 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.t b/doc/supplements/i960/fatalerr.t new file mode 100644 index 0000000000..6ce95fe669 --- /dev/null +++ b/doc/supplements/i960/fatalerr.t @@ -0,0 +1,43 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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/fatalerr.texi b/doc/supplements/i960/fatalerr.texi new file mode 100644 index 0000000000..6ce95fe669 --- /dev/null +++ b/doc/supplements/i960/fatalerr.texi @@ -0,0 +1,43 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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/i960.texi b/doc/supplements/i960/i960.texi new file mode 100644 index 0000000000..a1cc5aad45 --- /dev/null +++ b/doc/supplements/i960/i960.texi @@ -0,0 +1,117 @@ +\input ../texinfo/texinfo @c -*-texinfo-*- +@c %**start of header +@setfilename c_i960 +@syncodeindex vr fn +@synindex ky cp +@paragraphindent 0 +@c @smallbook +@c %**end of header + +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@c +@c Master file for the Intel i960 C Applications Supplement +@c + +@include ../common/setup.texi + +@ignore +@ifinfo +@format +START-INFO-DIR-ENTRY +* RTEMS Intel i960 C Applications Supplement (i960): +END-INFO-DIR-ENTRY +@end format +@end ifinfo +@end ignore + +@c +@c Title Page Stuff +@c + +@set edition 4.0.0a +@set update-date 25 April 1997 +@set update-month April 1997 + +@c +@c I don't really like having a short title page. --joel +@c +@c @shorttitlepage RTEMS Intel i960 C Applications Supplement + +@setchapternewpage odd +@settitle RTEMS Intel i960 C Applications Supplement +@titlepage +@finalout + +@title RTEMS Intel i960 C Supplement +@subtitle Edition @value{edition}, for RTEMS 4.0.0 +@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_i960 + +This is the online version of the RTEMS Intel i960 C +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:: +* i960CA 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, i960CA 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 + diff --git a/doc/supplements/i960/intr.t b/doc/supplements/i960/intr.t new file mode 100644 index 0000000000..45b80fead9 --- /dev/null +++ b/doc/supplements/i960/intr.t @@ -0,0 +1,220 @@ +@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 +<CENTER> + <TABLE COLS=2 WIDTH="40%" BORDER=2> +<TR><TD ALIGN=center><STRONG>Saved Process Controls</STRONG></TD> + <TD ALIGN=center>NFP-16</TD></TR> +<TR><TD ALIGN=center><STRONG>Saved Arithmetic Controls</STRONG></TD> + <TD ALIGN=center>NFP-12</TD></TR> +<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD> + <TD ALIGN=center>NFP-8</TD></TR> +<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD> + <TD ALIGN=center>NFP-4</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +@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/intr_NOTIMES.t b/doc/supplements/i960/intr_NOTIMES.t new file mode 100644 index 0000000000..45b80fead9 --- /dev/null +++ b/doc/supplements/i960/intr_NOTIMES.t @@ -0,0 +1,220 @@ +@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 +<CENTER> + <TABLE COLS=2 WIDTH="40%" BORDER=2> +<TR><TD ALIGN=center><STRONG>Saved Process Controls</STRONG></TD> + <TD ALIGN=center>NFP-16</TD></TR> +<TR><TD ALIGN=center><STRONG>Saved Arithmetic Controls</STRONG></TD> + <TD ALIGN=center>NFP-12</TD></TR> +<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD> + <TD ALIGN=center>NFP-8</TD></TR> +<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD> + <TD ALIGN=center>NFP-4</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +@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.t b/doc/supplements/i960/memmodel.t new file mode 100644 index 0000000000..ce057bc94c --- /dev/null +++ b/doc/supplements/i960/memmodel.t @@ -0,0 +1,53 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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. + + diff --git a/doc/supplements/i960/memmodel.texi b/doc/supplements/i960/memmodel.texi new file mode 100644 index 0000000000..ce057bc94c --- /dev/null +++ b/doc/supplements/i960/memmodel.texi @@ -0,0 +1,53 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@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. + + diff --git a/doc/supplements/i960/preface.texi b/doc/supplements/i960/preface.texi new file mode 100644 index 0000000000..713f58156a --- /dev/null +++ b/doc/supplements/i960/preface.texi @@ -0,0 +1,38 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Preface, CPU Model Dependent Features, Top, Top +@end ifinfo +@unnumbered Preface + +The Real Time Executive for Multiprocessor Systems +(RTEMS) is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +For information on the i960CA and the i960 processor +family in general, refer to the following documents: + +@itemize @bullet +@item @cite{80960CA User's Manual, Intel, Order No. 270710}. + +@item @cite{32-Bit Embedded Controller Handbook, Intel, Order No. 270647}. + +@item @cite{Glenford J. Meyers and David L. Budde. The 80960 +Microprocessor Architecture. Wiley. New York. 1988}. +@end itemize + +It is highly recommended that the i960CA RTEMS +application developer obtain and become familiar with Intel's +i960CA User's Manual. + + diff --git a/doc/supplements/i960/timeCVME961.t b/doc/supplements/i960/timeCVME961.t new file mode 100644 index 0000000000..e8dd9736b1 --- /dev/null +++ b/doc/supplements/i960/timeCVME961.t @@ -0,0 +1,123 @@ +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node i960CA Timing Data, i960CA Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter Timing Data +@ifinfo +@menu +* i960CA Timing Data Introduction:: +* i960CA Timing Data Hardware Platform:: +* i960CA Timing Data Interrupt Latency:: +* i960CA Timing Data Context Switch:: +* i960CA Timing Data Directive Times:: +* i960CA Timing Data Task Manager:: +* i960CA Timing Data Interrupt Manager:: +* i960CA Timing Data Clock Manager:: +* i960CA Timing Data Timer Manager:: +* i960CA Timing Data Semaphore Manager:: +* i960CA Timing Data Message Manager:: +* i960CA Timing Data Event Manager:: +* i960CA Timing Data Signal Manager:: +* i960CA Timing Data Partition Manager:: +* i960CA Timing Data Region Manager:: +* i960CA Timing Data Dual-Ported Memory Manager:: +* i960CA Timing Data I/O Manager:: +* i960CA Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +NOTE: The i960CA board used by the RTEMS Project to +obtain i960CA times is currently broken. The information in +this chapter was obtained using Release 3.2.1. + +@ifinfo +@node i960CA Timing Data Introduction, i960CA Timing Data Hardware Platform, i960CA Timing Data, i960CA Timing Data +@end ifinfo +@section Introduction + +The timing data for the i960CA version of RTEMS is +provided along with the target dependent aspects concerning the +gathering of the timing data. The hardware platform used to +gather the times is described to give the reader a better +understanding of each directive time provided. Also, provided +is a description of the interrupt latency and the context +switch times as they pertain to the i960CA version of RTEMS. + +@ifinfo +@node i960CA Timing Data Hardware Platform, i960CA Timing Data Interrupt Latency, i960CA Timing Data Introduction, i960CA Timing Data +@end ifinfo +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Cyclone +Microsystems CVME961 board. The CVME961 is a 33 Mhz board with +dynamic RAM which has two wait state dynamic memory (four CPU +cycles) for read accesses and one wait state (two CPU cycles) +for write accesses. The Z8536 on a SQUALL SQSIO4 mezzanine +board was used to measure elapsed time with one-half microsecond +resolution. All sources of hardware interrupts are disabled, +although the interrupt level of the i960CA allows all interrupts. + +The maximum interrupt disable period was measured by +summing the number of CPU cycles required by each assembly +language instruction executed while interrupts were disabled. +Zero wait state memory was assumed. The total CPU cycles +executed with interrupts disabled, including the instructions to +disable and enable interrupts, was divided by 33 to simulate a +i960CA executing at 33 Mhz with zero wait states. + +@ifinfo +@node i960CA Timing Data Interrupt Latency, i960CA Timing Data Context Switch, i960CA Timing Data Hardware Platform, i960CA Timing Data +@end ifinfo +@section Interrupt Latency + +The maximum period with interrupts disabled within +RTEMS is less than +RTEMS_MAXIMUM_DISABLE_PERIOD microseconds including the instructions +which disable and re-enable interrupts. The time required for +the i960CA to generate an interrupt using the sysctl +instruction, vectoring to an interrupt handler, and for the +RTEMS entry overhead before invoking the user's interrupt +handler are a total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. These combine to yield +a worst case interrupt latency of less than +RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. [NOTE: The maximum period with interrupts +disabled within RTEMS was last calculated for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +It should be noted again that the maximum period with +interrupts disabled within RTEMS is hand-timed. The interrupt +vector and entry overhead time was generated on the Cyclone +CVME961 benchmark platform using the sysctl instruction as the +interrupt source. + +@ifinfo +@node i960CA Timing Data Context Switch, i960CA Timing Data Directive Times, i960CA Timing Data Interrupt Latency, i960CA Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the Cyclone CVME961 benchmark platform. This +time represents the raw context switch time with no user +extensions configured. Additional execution time is required +when a TSWITCH user extension is configured. The use of the +TSWITCH extension is application dependent. Thus, its execution +time is not considered part of the base context switch time. + +The i960CA has no hardware floating point capability +and floating point tasks are not supported. + +The following table summarizes the context switch +times for the CVME961 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex + diff --git a/doc/supplements/i960/timedata.t b/doc/supplements/i960/timedata.t new file mode 100644 index 0000000000..e8dd9736b1 --- /dev/null +++ b/doc/supplements/i960/timedata.t @@ -0,0 +1,123 @@ +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node i960CA Timing Data, i960CA Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter Timing Data +@ifinfo +@menu +* i960CA Timing Data Introduction:: +* i960CA Timing Data Hardware Platform:: +* i960CA Timing Data Interrupt Latency:: +* i960CA Timing Data Context Switch:: +* i960CA Timing Data Directive Times:: +* i960CA Timing Data Task Manager:: +* i960CA Timing Data Interrupt Manager:: +* i960CA Timing Data Clock Manager:: +* i960CA Timing Data Timer Manager:: +* i960CA Timing Data Semaphore Manager:: +* i960CA Timing Data Message Manager:: +* i960CA Timing Data Event Manager:: +* i960CA Timing Data Signal Manager:: +* i960CA Timing Data Partition Manager:: +* i960CA Timing Data Region Manager:: +* i960CA Timing Data Dual-Ported Memory Manager:: +* i960CA Timing Data I/O Manager:: +* i960CA Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +NOTE: The i960CA board used by the RTEMS Project to +obtain i960CA times is currently broken. The information in +this chapter was obtained using Release 3.2.1. + +@ifinfo +@node i960CA Timing Data Introduction, i960CA Timing Data Hardware Platform, i960CA Timing Data, i960CA Timing Data +@end ifinfo +@section Introduction + +The timing data for the i960CA version of RTEMS is +provided along with the target dependent aspects concerning the +gathering of the timing data. The hardware platform used to +gather the times is described to give the reader a better +understanding of each directive time provided. Also, provided +is a description of the interrupt latency and the context +switch times as they pertain to the i960CA version of RTEMS. + +@ifinfo +@node i960CA Timing Data Hardware Platform, i960CA Timing Data Interrupt Latency, i960CA Timing Data Introduction, i960CA Timing Data +@end ifinfo +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Cyclone +Microsystems CVME961 board. The CVME961 is a 33 Mhz board with +dynamic RAM which has two wait state dynamic memory (four CPU +cycles) for read accesses and one wait state (two CPU cycles) +for write accesses. The Z8536 on a SQUALL SQSIO4 mezzanine +board was used to measure elapsed time with one-half microsecond +resolution. All sources of hardware interrupts are disabled, +although the interrupt level of the i960CA allows all interrupts. + +The maximum interrupt disable period was measured by +summing the number of CPU cycles required by each assembly +language instruction executed while interrupts were disabled. +Zero wait state memory was assumed. The total CPU cycles +executed with interrupts disabled, including the instructions to +disable and enable interrupts, was divided by 33 to simulate a +i960CA executing at 33 Mhz with zero wait states. + +@ifinfo +@node i960CA Timing Data Interrupt Latency, i960CA Timing Data Context Switch, i960CA Timing Data Hardware Platform, i960CA Timing Data +@end ifinfo +@section Interrupt Latency + +The maximum period with interrupts disabled within +RTEMS is less than +RTEMS_MAXIMUM_DISABLE_PERIOD microseconds including the instructions +which disable and re-enable interrupts. The time required for +the i960CA to generate an interrupt using the sysctl +instruction, vectoring to an interrupt handler, and for the +RTEMS entry overhead before invoking the user's interrupt +handler are a total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. These combine to yield +a worst case interrupt latency of less than +RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. [NOTE: The maximum period with interrupts +disabled within RTEMS was last calculated for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +It should be noted again that the maximum period with +interrupts disabled within RTEMS is hand-timed. The interrupt +vector and entry overhead time was generated on the Cyclone +CVME961 benchmark platform using the sysctl instruction as the +interrupt source. + +@ifinfo +@node i960CA Timing Data Context Switch, i960CA Timing Data Directive Times, i960CA Timing Data Interrupt Latency, i960CA Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the Cyclone CVME961 benchmark platform. This +time represents the raw context switch time with no user +extensions configured. Additional execution time is required +when a TSWITCH user extension is configured. The use of the +TSWITCH extension is application dependent. Thus, its execution +time is not considered part of the base context switch time. + +The i960CA has no hardware floating point capability +and floating point tasks are not supported. + +The following table summarizes the context switch +times for the CVME961 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex + |