diff options
Diffstat (limited to 'doc/supplements')
94 files changed, 11962 insertions, 0 deletions
diff --git a/doc/supplements/hppa1_1/Makefile b/doc/supplements/hppa1_1/Makefile new file mode 100644 index 0000000000..ac49a22b33 --- /dev/null +++ b/doc/supplements/hppa1_1/Makefile @@ -0,0 +1,88 @@ +# +# COPYRIGHT (c) 1996. +# On-Line Applications Research Corporation (OAR). +# All rights reserved. +# + +include ../Make.config + +PROJECT=hppa1_1 +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_hppa1_1 + cp c_$(PROJECT) $(INFO_INSTALL) + +c_hppa1_1: $(FILES) + $(MAKEINFO) $(PROJECT).texi + +vinfo: info + $(INFO) -f c_hppa1_1 + +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 TIMES + ${REPLACE} -p 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 TIMES + ${REPLACE} -p TIMES timetbl.t + mv timetbl.t.fixed timetbl.texi + +timedata.texi: timedata.t TIMES + ${REPLACE} -p 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/HP-7100 Timing Data/' \ + <../common/wksheets.t >wksheets.t + +wksheets.texi: wksheets.t TIMES + ${REPLACE} -p TIMES wksheets.t + mv wksheets.t.fixed wksheets.texi + +html: $(FILES) + -mkdir $(WWW_INSTALL)/c_hppa1_1 + $(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_hppa1_1 c_hppa1_1-* + rm -f timedata.texi timetbl.texi intr.texi wksheets.texi + rm -f timetbl.t wksheets.t + rm -f *.fixed _* + diff --git a/doc/supplements/hppa1_1/SIMHPPA_TIMES b/doc/supplements/hppa1_1/SIMHPPA_TIMES new file mode 100644 index 0000000000..485340715b --- /dev/null +++ b/doc/supplements/hppa1_1/SIMHPPA_TIMES @@ -0,0 +1,244 @@ +# +# PA-RISC Timing and Size Information +# + +# +# CPU Model Information +# +RTEMS_CPU_MODEL HP-7100 +# +# Interrupt Latency +# +# NOTE: In general, the text says it is hand-calculated to be +# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +# Mhz and this was last calculated for Release +# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. +# +RTEMS_MAXIMUM_DISABLE_PERIOD TBD +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ TBD +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD TBD +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 1 +RTEMS_RESTORE_1ST_FP_TASK 2 +RTEMS_SAVE_INIT_RESTORE_INIT 3 +RTEMS_SAVE_IDLE_RESTORE_INIT 4 +RTEMS_SAVE_IDLE_RESTORE_IDLE 5 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 6 +RTEMS_TASK_IDENT_ONLY 7 +RTEMS_TASK_START_ONLY 8 +RTEMS_TASK_RESTART_CALLING_TASK 9 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 9 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 10 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 11 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 12 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 13 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 14 +RTEMS_TASK_DELETE_CALLING_TASK 15 +RTEMS_TASK_DELETE_SUSPENDED_TASK 16 +RTEMS_TASK_DELETE_BLOCKED_TASK 17 +RTEMS_TASK_DELETE_READY_TASK 18 +RTEMS_TASK_SUSPEND_CALLING_TASK 19 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 20 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 21 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 22 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 23 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 24 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 25 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 26 +RTEMS_TASK_MODE_NO_RESCHEDULE 27 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 28 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 29 +RTEMS_TASK_GET_NOTE_ONLY 30 +RTEMS_TASK_SET_NOTE_ONLY 31 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 32 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 33 +RTEMS_TASK_WAKE_WHEN_ONLY 34 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 35 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 36 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 37 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED 38 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 39 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 40 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 41 +RTEMS_CLOCK_GET_ONLY 42 +RTEMS_CLOCK_TICK_ONLY 43 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 44 +RTEMS_TIMER_IDENT_ONLY 45 +RTEMS_TIMER_DELETE_INACTIVE 46 +RTEMS_TIMER_DELETE_ACTIVE 47 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 48 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 49 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 50 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 51 +RTEMS_TIMER_RESET_INACTIVE 52 +RTEMS_TIMER_RESET_ACTIVE 53 +RTEMS_TIMER_CANCEL_INACTIVE 54 +RTEMS_TIMER_CANCEL_ACTIVE 55 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 56 +RTEMS_SEMAPHORE_IDENT_ONLY 57 +RTEMS_SEMAPHORE_DELETE_ONLY 58 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 59 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 60 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 61 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 62 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 63 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 64 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 65 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 66 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 67 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 68 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 69 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 70 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 71 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 72 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 73 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 74 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 75 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 76 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 77 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 78 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 79 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 80 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 81 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 82 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 83 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 85 +RTEMS_EVENT_RECEIVE_AVAILABLE 86 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 87 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 88 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 89 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 90 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 91 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 92 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 93 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 94 +RTEMS_PARTITION_IDENT_ONLY 95 +RTEMS_PARTITION_DELETE_ONLY 96 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 97 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 98 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 99 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 100 +RTEMS_REGION_IDENT_ONLY 101 +RTEMS_REGION_DELETE_ONLY 102 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 103 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 104 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 105 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 106 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 107 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 108 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 109 +RTEMS_PORT_IDENT_ONLY 110 +RTEMS_PORT_DELETE_ONLY 111 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 112 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 113 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 114 +RTEMS_IO_OPEN_ONLY 115 +RTEMS_IO_CLOSE_ONLY 116 +RTEMS_IO_READ_ONLY 117 +RTEMS_IO_WRITE_ONLY 118 +RTEMS_IO_CONTROL_ONLY 119 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 120 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 121 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 122 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 123 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 124 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 125 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 126 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 127 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 128 +RTEMS_MINIMUM_CONFIGURATION xx,129 +RTEMS_MAXIMUM_CONFIGURATION xx,130 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE x,131 +RTEMS_INITIALIZATION_CODE_SIZE x,132 +RTEMS_TASK_CODE_SIZE x,133 +RTEMS_INTERRUPT_CODE_SIZE x,134 +RTEMS_CLOCK_CODE_SIZE x,135 +RTEMS_TIMER_CODE_SIZE x,136 +RTEMS_SEMAPHORE_CODE_SIZE x,137 +RTEMS_MESSAGE_CODE_SIZE x,138 +RTEMS_EVENT_CODE_SIZE x,139 +RTEMS_SIGNAL_CODE_SIZE x,140 +RTEMS_PARTITION_CODE_SIZE x,141 +RTEMS_REGION_CODE_SIZE x,142 +RTEMS_DPMEM_CODE_SIZE x,143 +RTEMS_IO_CODE_SIZE x,144 +RTEMS_FATAL_ERROR_CODE_SIZE x,145 +RTEMS_RATE_MONOTONIC_CODE_SIZE x,146 +RTEMS_MULTIPROCESSING_CODE_SIZE x,147 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 148 +RTEMS_SEMAPHORE_CODE_OPTSIZE 149 +RTEMS_MESSAGE_CODE_OPTSIZE 150 +RTEMS_EVENT_CODE_OPTSIZE 151 +RTEMS_SIGNAL_CODE_OPTSIZE 152 +RTEMS_PARTITION_CODE_OPTSIZE 153 +RTEMS_REGION_CODE_OPTSIZE 154 +RTEMS_DPMEM_CODE_OPTSIZE 155 +RTEMS_IO_CODE_OPTSIZE 156 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 157 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 158 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 159 +RTEMS_BYTES_PER_TIMER 160 +RTEMS_BYTES_PER_SEMAPHORE 161 +RTEMS_BYTES_PER_MESSAGE_QUEUE 162 +RTEMS_BYTES_PER_REGION 163 +RTEMS_BYTES_PER_PARTITION 164 +RTEMS_BYTES_PER_PORT 165 +RTEMS_BYTES_PER_PERIOD 166 +RTEMS_BYTES_PER_EXTENSION 167 +RTEMS_BYTES_PER_FP_TASK 168 +RTEMS_BYTES_PER_NODE 169 +RTEMS_BYTES_PER_GLOBAL_OBJECT 170 +RTEMS_BYTES_PER_PROXY 171 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS x,172 diff --git a/doc/supplements/hppa1_1/TIMES b/doc/supplements/hppa1_1/TIMES new file mode 100644 index 0000000000..485340715b --- /dev/null +++ b/doc/supplements/hppa1_1/TIMES @@ -0,0 +1,244 @@ +# +# PA-RISC Timing and Size Information +# + +# +# CPU Model Information +# +RTEMS_CPU_MODEL HP-7100 +# +# Interrupt Latency +# +# NOTE: In general, the text says it is hand-calculated to be +# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +# Mhz and this was last calculated for Release +# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. +# +RTEMS_MAXIMUM_DISABLE_PERIOD TBD +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ TBD +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD TBD +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 1 +RTEMS_RESTORE_1ST_FP_TASK 2 +RTEMS_SAVE_INIT_RESTORE_INIT 3 +RTEMS_SAVE_IDLE_RESTORE_INIT 4 +RTEMS_SAVE_IDLE_RESTORE_IDLE 5 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 6 +RTEMS_TASK_IDENT_ONLY 7 +RTEMS_TASK_START_ONLY 8 +RTEMS_TASK_RESTART_CALLING_TASK 9 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 9 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 10 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 11 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 12 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 13 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 14 +RTEMS_TASK_DELETE_CALLING_TASK 15 +RTEMS_TASK_DELETE_SUSPENDED_TASK 16 +RTEMS_TASK_DELETE_BLOCKED_TASK 17 +RTEMS_TASK_DELETE_READY_TASK 18 +RTEMS_TASK_SUSPEND_CALLING_TASK 19 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 20 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 21 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 22 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 23 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 24 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 25 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 26 +RTEMS_TASK_MODE_NO_RESCHEDULE 27 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 28 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 29 +RTEMS_TASK_GET_NOTE_ONLY 30 +RTEMS_TASK_SET_NOTE_ONLY 31 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 32 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 33 +RTEMS_TASK_WAKE_WHEN_ONLY 34 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 35 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 36 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 37 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED 38 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 39 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 40 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 41 +RTEMS_CLOCK_GET_ONLY 42 +RTEMS_CLOCK_TICK_ONLY 43 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 44 +RTEMS_TIMER_IDENT_ONLY 45 +RTEMS_TIMER_DELETE_INACTIVE 46 +RTEMS_TIMER_DELETE_ACTIVE 47 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 48 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 49 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 50 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 51 +RTEMS_TIMER_RESET_INACTIVE 52 +RTEMS_TIMER_RESET_ACTIVE 53 +RTEMS_TIMER_CANCEL_INACTIVE 54 +RTEMS_TIMER_CANCEL_ACTIVE 55 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 56 +RTEMS_SEMAPHORE_IDENT_ONLY 57 +RTEMS_SEMAPHORE_DELETE_ONLY 58 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 59 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 60 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 61 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 62 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 63 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 64 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 65 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 66 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 67 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 68 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 69 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 70 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 71 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 72 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 73 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 74 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 75 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 76 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 77 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 78 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 79 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 80 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 81 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 82 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 83 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 85 +RTEMS_EVENT_RECEIVE_AVAILABLE 86 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 87 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 88 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 89 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 90 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 91 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 92 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 93 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 94 +RTEMS_PARTITION_IDENT_ONLY 95 +RTEMS_PARTITION_DELETE_ONLY 96 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 97 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 98 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 99 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 100 +RTEMS_REGION_IDENT_ONLY 101 +RTEMS_REGION_DELETE_ONLY 102 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 103 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 104 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 105 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 106 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 107 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 108 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 109 +RTEMS_PORT_IDENT_ONLY 110 +RTEMS_PORT_DELETE_ONLY 111 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 112 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 113 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 114 +RTEMS_IO_OPEN_ONLY 115 +RTEMS_IO_CLOSE_ONLY 116 +RTEMS_IO_READ_ONLY 117 +RTEMS_IO_WRITE_ONLY 118 +RTEMS_IO_CONTROL_ONLY 119 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 120 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 121 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 122 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 123 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 124 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 125 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 126 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 127 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 128 +RTEMS_MINIMUM_CONFIGURATION xx,129 +RTEMS_MAXIMUM_CONFIGURATION xx,130 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE x,131 +RTEMS_INITIALIZATION_CODE_SIZE x,132 +RTEMS_TASK_CODE_SIZE x,133 +RTEMS_INTERRUPT_CODE_SIZE x,134 +RTEMS_CLOCK_CODE_SIZE x,135 +RTEMS_TIMER_CODE_SIZE x,136 +RTEMS_SEMAPHORE_CODE_SIZE x,137 +RTEMS_MESSAGE_CODE_SIZE x,138 +RTEMS_EVENT_CODE_SIZE x,139 +RTEMS_SIGNAL_CODE_SIZE x,140 +RTEMS_PARTITION_CODE_SIZE x,141 +RTEMS_REGION_CODE_SIZE x,142 +RTEMS_DPMEM_CODE_SIZE x,143 +RTEMS_IO_CODE_SIZE x,144 +RTEMS_FATAL_ERROR_CODE_SIZE x,145 +RTEMS_RATE_MONOTONIC_CODE_SIZE x,146 +RTEMS_MULTIPROCESSING_CODE_SIZE x,147 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 148 +RTEMS_SEMAPHORE_CODE_OPTSIZE 149 +RTEMS_MESSAGE_CODE_OPTSIZE 150 +RTEMS_EVENT_CODE_OPTSIZE 151 +RTEMS_SIGNAL_CODE_OPTSIZE 152 +RTEMS_PARTITION_CODE_OPTSIZE 153 +RTEMS_REGION_CODE_OPTSIZE 154 +RTEMS_DPMEM_CODE_OPTSIZE 155 +RTEMS_IO_CODE_OPTSIZE 156 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 157 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 158 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 159 +RTEMS_BYTES_PER_TIMER 160 +RTEMS_BYTES_PER_SEMAPHORE 161 +RTEMS_BYTES_PER_MESSAGE_QUEUE 162 +RTEMS_BYTES_PER_REGION 163 +RTEMS_BYTES_PER_PARTITION 164 +RTEMS_BYTES_PER_PORT 165 +RTEMS_BYTES_PER_PERIOD 166 +RTEMS_BYTES_PER_EXTENSION 167 +RTEMS_BYTES_PER_FP_TASK 168 +RTEMS_BYTES_PER_NODE 169 +RTEMS_BYTES_PER_GLOBAL_OBJECT 170 +RTEMS_BYTES_PER_PROXY 171 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS x,172 diff --git a/doc/supplements/hppa1_1/bsp.t b/doc/supplements/hppa1_1/bsp.t new file mode 100644 index 0000000000..b4b92a5bdb --- /dev/null +++ b/doc/supplements/hppa1_1/bsp.t @@ -0,0 +1,70 @@ +@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 PA-RISC 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 or +re-initiated when the PA-RISC processor is reset. The behavior +of a PA-RISC upon reset is implementation defined and thus is +beyond the scope of this manual. + +@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 precise requirements for initialization of a +particular implementation of the PA-RISC architecture are +implementation defined. Thus it is impossible to provide exact +details of this procedure in this manual. However, the +requirements of RTEMS which must be satisfied by this +initialization code can be discussed. + +RTEMS assumes that interrupts are disabled when the +initialize_executive directive is invoked. Interrupts are +enabled automatically by RTEMS as part of the initialize +executive directive and device driver initialization occurs +after interrupts are enabled. Thus all interrupt sources should +be quiescent until the system's device drivers have been +initialized and installed their interrupt handlers. + +If the processor requires initialization of the +cache, then it should be be done during the reset application +initialization code. + +Finally, the requirements in the Board Support +Packages chapter of the C Applications User's Manual for the +reset code which is executed before the call to initialize +executive must be satisfied. + + diff --git a/doc/supplements/hppa1_1/bsp.texi b/doc/supplements/hppa1_1/bsp.texi new file mode 100644 index 0000000000..b4b92a5bdb --- /dev/null +++ b/doc/supplements/hppa1_1/bsp.texi @@ -0,0 +1,70 @@ +@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 PA-RISC 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 or +re-initiated when the PA-RISC processor is reset. The behavior +of a PA-RISC upon reset is implementation defined and thus is +beyond the scope of this manual. + +@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 precise requirements for initialization of a +particular implementation of the PA-RISC architecture are +implementation defined. Thus it is impossible to provide exact +details of this procedure in this manual. However, the +requirements of RTEMS which must be satisfied by this +initialization code can be discussed. + +RTEMS assumes that interrupts are disabled when the +initialize_executive directive is invoked. Interrupts are +enabled automatically by RTEMS as part of the initialize +executive directive and device driver initialization occurs +after interrupts are enabled. Thus all interrupt sources should +be quiescent until the system's device drivers have been +initialized and installed their interrupt handlers. + +If the processor requires initialization of the +cache, then it should be be done during the reset application +initialization code. + +Finally, the requirements in the Board Support +Packages chapter of the C Applications User's Manual for the +reset code which is executed before the call to initialize +executive must be satisfied. + + diff --git a/doc/supplements/hppa1_1/callconv.t b/doc/supplements/hppa1_1/callconv.t new file mode 100644 index 0000000000..77f2b8a926 --- /dev/null +++ b/doc/supplements/hppa1_1/callconv.t @@ -0,0 +1,172 @@ +@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 CPU Model Name, Top +@end ifinfo +@chapter Calling Conventions +@ifinfo +@menu +* Calling Conventions Introduction:: +* Calling Conventions Processor Background:: +* Calling Conventions Calling Mechanism:: +* Calling Conventions Register Usage:: +* Calling Conventions Parameter Passing:: +* Calling Conventions User-Provided Routines:: +@end menu +@end ifinfo + +@ifinfo +@node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions +@end ifinfo +@section Introduction + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage + +@item parameter passing + +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +This chapter describes the calling conventions used +by the GNU C and standard HP-UX compilers for the PA-RISC +architecture. + +@ifinfo +@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions +@end ifinfo +@section Processor Background + +The PA-RISC architecture supports a simple yet +effective call and return mechanism for subroutine calls where +the caller and callee are both in the same address space. The +compiler will not automatically generate subroutine calls which +cross address spaces. A subroutine is invoked via the branch +and link (bl) or the branch and link register (blr). These +instructions save the return address in a caller specified +register. By convention, the return address is saved in r2. +The callee is responsible for maintaining the return address so +it can return to the correct address. The branch vectored (bv) +instruction is used to branch to the return address and thus +return from the subroutine to the caller. It is is important to +note that the PA-RISC subroutine call and return mechanism does +not automatically save or restore any registers. It is the +responsibility of the high-level language compiler to define the +register preservation and usage convention. + +@ifinfo +@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions +@end ifinfo +@section Calling Mechanism + +All RTEMS directives are invoked as standard +subroutines via a bl or a blr instruction with the return address +assumed to be in r2 and return to the user application via the +bv instruction. + +@ifinfo +@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions +@end ifinfo +@section Register Usage + +As discussed above, the bl and blr instructions do +not automatically save any registers. RTEMS uses the registers +r1, r19 - r26, and r31 as scratch registers. The PA-RISC +calling convention specifies that the first four (4) arguments +to subroutines are passed in registers r23 - r26. After the +arguments have been used, the contents of these registers may be +altered. Register r31 is the millicode scratch register. +Millicode is the set of routines which support high-level +languages on the PA-RISC by providing routines which are either +too complex or too long for the compiler to generate inline code +when these operations are needed. For example, indirect calls +utilize a millicode routine. The scratch registers are not +preserved by RTEMS directives therefore, the contents of these +registers should not be assumed upon return from any RTEMS +directive. + +Surprisingly, when using the GNU C compiler at least +integer multiplies are performed using the floating point +registers. This is an important optimization because the +PA-RISC does not have otherwise have hardware for multiplies. +This has important ramifications in regards to the PA-RISC port +of RTEMS. On most processors, the floating point unit is +ignored if the code only performs integer operations. This +makes it easy for the application developer to predict whether +or not any particular task will require floating point +operations. This property is taken advantage of by RTEMS on +other architectures to minimize the number of times the floating +point context is saved and restored. However, on the PA-RISC +architecture, every task is implicitly a floating point task. +Additionally the state of the floating point unit must be saved +and restored as part of the interrupt processing because for all +practical purposes it is impossible to avoid the use of the +floating point registers. It is unknown if the HP-UX C compiler +shares this property. + +@itemize @code{ } +@item @b{NOTE}: Later versions of the GNU C has a PA-RISC specific +option to disable use of the floating point registers. RTEMS +currently assumes that this option is not turned on. If the use +of this option sets a built-in define, then it should be +possible to modify the PA-RISC specific code such that all tasks +are considered floating point only when this option is not used. +@end itemize + +@ifinfo +@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions +@end ifinfo +@section Parameter Passing + +RTEMS assumes that the first four (4) arguments are +placed in the appropriate registers (r26, r25, r24, and r23) +and, if needed, additional are placed on the current stack +before the directive is invoked via the bl or blr instruction. +The first argument is placed in r26, the second is placed in +r25, and so forth. The following pseudo-code illustrates the +typical sequence used to call a RTEMS directive with three (3) +arguments: + + +@example +set r24 to the third argument +set r25 to the second argument +set r26 to the first argument +invoke directive +@end example + +The stack on the PA-RISC grows upward -- i.e. +"pushing" onto the stack results in the address in the stack +pointer becoming numerically larger. By convention, r27 is used +as the stack pointer. The standard stack frame consists of a +minimum of sixty-four (64) bytes and is the responsibility of +the callee to maintain. + +@ifinfo +@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions +@end ifinfo +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + + + + diff --git a/doc/supplements/hppa1_1/callconv.texi b/doc/supplements/hppa1_1/callconv.texi new file mode 100644 index 0000000000..77f2b8a926 --- /dev/null +++ b/doc/supplements/hppa1_1/callconv.texi @@ -0,0 +1,172 @@ +@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 CPU Model Name, Top +@end ifinfo +@chapter Calling Conventions +@ifinfo +@menu +* Calling Conventions Introduction:: +* Calling Conventions Processor Background:: +* Calling Conventions Calling Mechanism:: +* Calling Conventions Register Usage:: +* Calling Conventions Parameter Passing:: +* Calling Conventions User-Provided Routines:: +@end menu +@end ifinfo + +@ifinfo +@node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions +@end ifinfo +@section Introduction + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage + +@item parameter passing + +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +This chapter describes the calling conventions used +by the GNU C and standard HP-UX compilers for the PA-RISC +architecture. + +@ifinfo +@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions +@end ifinfo +@section Processor Background + +The PA-RISC architecture supports a simple yet +effective call and return mechanism for subroutine calls where +the caller and callee are both in the same address space. The +compiler will not automatically generate subroutine calls which +cross address spaces. A subroutine is invoked via the branch +and link (bl) or the branch and link register (blr). These +instructions save the return address in a caller specified +register. By convention, the return address is saved in r2. +The callee is responsible for maintaining the return address so +it can return to the correct address. The branch vectored (bv) +instruction is used to branch to the return address and thus +return from the subroutine to the caller. It is is important to +note that the PA-RISC subroutine call and return mechanism does +not automatically save or restore any registers. It is the +responsibility of the high-level language compiler to define the +register preservation and usage convention. + +@ifinfo +@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions +@end ifinfo +@section Calling Mechanism + +All RTEMS directives are invoked as standard +subroutines via a bl or a blr instruction with the return address +assumed to be in r2 and return to the user application via the +bv instruction. + +@ifinfo +@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions +@end ifinfo +@section Register Usage + +As discussed above, the bl and blr instructions do +not automatically save any registers. RTEMS uses the registers +r1, r19 - r26, and r31 as scratch registers. The PA-RISC +calling convention specifies that the first four (4) arguments +to subroutines are passed in registers r23 - r26. After the +arguments have been used, the contents of these registers may be +altered. Register r31 is the millicode scratch register. +Millicode is the set of routines which support high-level +languages on the PA-RISC by providing routines which are either +too complex or too long for the compiler to generate inline code +when these operations are needed. For example, indirect calls +utilize a millicode routine. The scratch registers are not +preserved by RTEMS directives therefore, the contents of these +registers should not be assumed upon return from any RTEMS +directive. + +Surprisingly, when using the GNU C compiler at least +integer multiplies are performed using the floating point +registers. This is an important optimization because the +PA-RISC does not have otherwise have hardware for multiplies. +This has important ramifications in regards to the PA-RISC port +of RTEMS. On most processors, the floating point unit is +ignored if the code only performs integer operations. This +makes it easy for the application developer to predict whether +or not any particular task will require floating point +operations. This property is taken advantage of by RTEMS on +other architectures to minimize the number of times the floating +point context is saved and restored. However, on the PA-RISC +architecture, every task is implicitly a floating point task. +Additionally the state of the floating point unit must be saved +and restored as part of the interrupt processing because for all +practical purposes it is impossible to avoid the use of the +floating point registers. It is unknown if the HP-UX C compiler +shares this property. + +@itemize @code{ } +@item @b{NOTE}: Later versions of the GNU C has a PA-RISC specific +option to disable use of the floating point registers. RTEMS +currently assumes that this option is not turned on. If the use +of this option sets a built-in define, then it should be +possible to modify the PA-RISC specific code such that all tasks +are considered floating point only when this option is not used. +@end itemize + +@ifinfo +@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions +@end ifinfo +@section Parameter Passing + +RTEMS assumes that the first four (4) arguments are +placed in the appropriate registers (r26, r25, r24, and r23) +and, if needed, additional are placed on the current stack +before the directive is invoked via the bl or blr instruction. +The first argument is placed in r26, the second is placed in +r25, and so forth. The following pseudo-code illustrates the +typical sequence used to call a RTEMS directive with three (3) +arguments: + + +@example +set r24 to the third argument +set r25 to the second argument +set r26 to the first argument +invoke directive +@end example + +The stack on the PA-RISC grows upward -- i.e. +"pushing" onto the stack results in the address in the stack +pointer becoming numerically larger. By convention, r27 is used +as the stack pointer. The standard stack frame consists of a +minimum of sixty-four (64) bytes and is the responsibility of +the callee to maintain. + +@ifinfo +@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions +@end ifinfo +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + + + + diff --git a/doc/supplements/hppa1_1/cpumodel.t b/doc/supplements/hppa1_1/cpumodel.t new file mode 100644 index 0000000000..be4541bd87 --- /dev/null +++ b/doc/supplements/hppa1_1/cpumodel.t @@ -0,0 +1,69 @@ +@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:: +@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 PA-RISC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +c/src/exec/score/cpu/hppa1_1/hppa.h based upon the particular CPU +model defined on the compilation command line. + +@ifinfo +@node CPU Model Dependent Features CPU Model Name, Calling Conventions, 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 Hewlett Packard +PA-7100 CPU model, this macro is set to the string "hppa 7100". diff --git a/doc/supplements/hppa1_1/cpumodel.texi b/doc/supplements/hppa1_1/cpumodel.texi new file mode 100644 index 0000000000..be4541bd87 --- /dev/null +++ b/doc/supplements/hppa1_1/cpumodel.texi @@ -0,0 +1,69 @@ +@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:: +@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 PA-RISC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +c/src/exec/score/cpu/hppa1_1/hppa.h based upon the particular CPU +model defined on the compilation command line. + +@ifinfo +@node CPU Model Dependent Features CPU Model Name, Calling Conventions, 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 Hewlett Packard +PA-7100 CPU model, this macro is set to the string "hppa 7100". diff --git a/doc/supplements/hppa1_1/cputable.t b/doc/supplements/hppa1_1/cputable.t new file mode 100644 index 0000000000..651dd69606 --- /dev/null +++ b/doc/supplements/hppa1_1/cputable.t @@ -0,0 +1,124 @@ +@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 PA-RISC version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the PA-RISC. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void * ); + /* end of fields required on all CPUs */ + + hppa_rtems_isr_entry spurious_handler; + + unsigned32 itimer_clicks_per_microsecond; /* for use by Clock driver */ +@} rtems_cpu_table; +@end example + +@table @code +@item pretasking_hook +is the address of the +user provided routine which is invoked once RTEMS initialization +is complete but before interrupts and tasking are enabled. This +field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately before +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +but no device drivers are initialized. This field may be NULL to +indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately after +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +and the device drivers are initialized. This field may be NULL +to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item interrupt_stack_size +is the size of the RTEMS allocated interrupt stack in bytes. +This value must be at least as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item spurious_handler +is the address of the optional user provided routine which is invoked +when a spurious external interrupt occurs. A spurious interrupt is one +for which no handler is installed. + +@item itimer_clicks_per_microsecond +is the number of countdowns in the on-CPU timer which corresponds +to a microsecond. This is a function of the clock speed of the CPU +being used. + +@end table diff --git a/doc/supplements/hppa1_1/cputable.texi b/doc/supplements/hppa1_1/cputable.texi new file mode 100644 index 0000000000..651dd69606 --- /dev/null +++ b/doc/supplements/hppa1_1/cputable.texi @@ -0,0 +1,124 @@ +@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 PA-RISC version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the PA-RISC. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void * ); + /* end of fields required on all CPUs */ + + hppa_rtems_isr_entry spurious_handler; + + unsigned32 itimer_clicks_per_microsecond; /* for use by Clock driver */ +@} rtems_cpu_table; +@end example + +@table @code +@item pretasking_hook +is the address of the +user provided routine which is invoked once RTEMS initialization +is complete but before interrupts and tasking are enabled. This +field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately before +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +but no device drivers are initialized. This field may be NULL to +indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately after +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +and the device drivers are initialized. This field may be NULL +to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item interrupt_stack_size +is the size of the RTEMS allocated interrupt stack in bytes. +This value must be at least as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item spurious_handler +is the address of the optional user provided routine which is invoked +when a spurious external interrupt occurs. A spurious interrupt is one +for which no handler is installed. + +@item itimer_clicks_per_microsecond +is the number of countdowns in the on-CPU timer which corresponds +to a microsecond. This is a function of the clock speed of the CPU +being used. + +@end table diff --git a/doc/supplements/hppa1_1/fatalerr.t b/doc/supplements/hppa1_1/fatalerr.t new file mode 100644 index 0000000000..3caedc2e06 --- /dev/null +++ b/doc/supplements/hppa1_1/fatalerr.t @@ -0,0 +1,45 @@ +@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 Disabling of Interrupts by RTEMS, 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 a user-supplied fatal error +handler. If no user-supplied handler is configured, the RTEMS +provided default fatal error handler is invoked. If the +user-supplied fatal error handler returns to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@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 (i.e. +sets the I bit in the PSW register to 0), places the error code +in r1, and executes a break instruction to simulate a halt +processor instruction. + diff --git a/doc/supplements/hppa1_1/fatalerr.texi b/doc/supplements/hppa1_1/fatalerr.texi new file mode 100644 index 0000000000..3caedc2e06 --- /dev/null +++ b/doc/supplements/hppa1_1/fatalerr.texi @@ -0,0 +1,45 @@ +@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 Disabling of Interrupts by RTEMS, 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 a user-supplied fatal error +handler. If no user-supplied handler is configured, the RTEMS +provided default fatal error handler is invoked. If the +user-supplied fatal error handler returns to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@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 (i.e. +sets the I bit in the PSW register to 0), places the error code +in r1, and executes a break instruction to simulate a halt +processor instruction. + diff --git a/doc/supplements/hppa1_1/hppa1_1.texi b/doc/supplements/hppa1_1/hppa1_1.texi new file mode 100644 index 0000000000..7245b31e01 --- /dev/null +++ b/doc/supplements/hppa1_1/hppa1_1.texi @@ -0,0 +1,118 @@ +\input ../texinfo/texinfo @c -*-texinfo-*- +@c %**start of header +@setfilename c_hppa1_1 +@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 Hewlett Packard PA-RISC C Applications Supplement +@c + +@include ../common/setup.texi + +@ignore +@ifinfo +@format +START-INFO-DIR-ENTRY +* RTEMS Hewlett Packard PA-RISC C Applications Supplement (hppa1_1): +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 Hewlett Packard PA-RISC C Applications Supplement + +@setchapternewpage odd +@settitle RTEMS Hewlett Packard PA-RISC C Applications Supplement +@titlepage +@finalout + +@title RTEMS Hewlett Packard PA-RISC 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_hppa1_1 + +This is the online version of the RTEMS Hewlett Packard PA-RISC 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:: +* HP-7100 Timing Data:: +* Command and Variable Index:: +* Concept Index:: +@end menu + +@end ifinfo +@c +@c +@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here +@c + +@node Command and Variable Index, Concept Index, HP-7100 Timing Data Directive Times, Top + +@unnumbered Command and Variable Index + +There are currently no Command and Variable Index entries. + +@c @printindex fn + +@node Concept Index, , Command and Variable Index, Top +@unnumbered Concept Index + +There are currently no Concept Index entries. +@c @printindex cp + +@c @contents +@bye + diff --git a/doc/supplements/hppa1_1/intr.t b/doc/supplements/hppa1_1/intr.t new file mode 100644 index 0000000000..bea2a3e39e --- /dev/null +++ b/doc/supplements/hppa1_1/intr.t @@ -0,0 +1,214 @@ +@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 Stack Frame:: +* Interrupt Processing External Interrupts and Traps:: +* Interrupt Processing Interrupt Levels:: +* Interrupt Processing Disabling of Interrupts by RTEMS:: +@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 +occurence of an interrupt in their own unique fashion. In +addition, each processor type provides a control mechanism to +allow for the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the current +execution state and results in a change in the execution stream. +Most processors require that an interrupt handler utilize some +special control mechanisms to return to the normal processing +stream. Although RTEMS hides many of the processor dependent +details of interrupt processing, it is important to understand +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the PA-RISC's +interrupt response and control mechanisms as they pertain to +RTEMS. + +@ifinfo +@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Stack Frame, Interrupt Processing Introduction, Interrupt Processing +@end ifinfo +@section Vectoring of Interrupt Handler + +Upon receipt of an interrupt the PA-RISC +automatically performs the following actions: + +@itemize @bullet +@item The PSW (Program Status Word) is saved in the IPSW +(Interrupt Program Status Word). + +@item The current privilege level is set to 0. + +@item The following defined bits in the PSW are set: + +@item E bit is set to the default endian bit + +@item M bit is set to 1 if the interrupt is a high-priority +machine check and 0 otherwise + +@item Q bit is set to zero thuse freezing the IIA +(Instruction Address) queues + +@item C and D bits are set to zero thus disabling all +protection and translation. + +@item I bit is set to zero this disabling all external, +powerfail, and low-priority machine check interrupts. + +@item All others bits are set to zero. + +@item General purpose registers r1, r8, r9, r16, r17, r24, and +r25 are copied to the shadow registers. + +@item Execution begins at the address given by the formula: +Interruption Vector Address + (32 * interrupt vector number). +@end itemize + +Once the processor has completed the actions it is is +required to perform for each interrupt, the RTEMS interrupt +management code (the beginning of which is stored in the +Interruption Vector Table) gains control and performs the +following actions upon each interrupt: + +@itemize @bullet +@item returns the processor to "virtual mode" thus reenabling +all code and data address translation. + +@item saves all necessary interrupt state information + +@item saves all floating point registers + +@item saves all integer registers + +@item switches the current stack to the interrupt stack + +@item dispatches to the appropriate user provided interrupt +service routine (ISR). If the ISR was installed with the +interrupt_catch directive, then it will be executed at this. +Because, the RTEMS interrupt handler saves all registers which +are not preserved according to the calling conventions and +invokes the application's ISR, the ISR can easily be written in +a high-level language. +@end itemize + +RTEMS refers to the combination of the interrupt +state information and registers saved when vectoring an +interrupt as the Interrupt Stack Frame (ISF). A nested +interrupt is processed similarly by the PA-RISC and RTEMS with +the exception that the nested interrupt occurred while executing +on the interrupt stack and, thus, the current stack need not be +switched. + +@ifinfo +@node Interrupt Processing Interrupt Stack Frame, Interrupt Processing External Interrupts and Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing +@end ifinfo +@section Interrupt Stack Frame + +The PA-RISC architecture does not alter the stack +while processing interrupts. However, RTEMS does save +information on the stack as part of processing an interrupt. +This following shows the format of the Interrupt Stack Frame for +the PA-RISC as defined by RTEMS: + +@example +@group + +------------------------+ + | Interrupt Context | 0xXXX + +------------------------+ + | Integer Context | 0xXXX + +------------------------+ + | Floating Point Context | 0xXXX + +------------------------+ +@end group +@end example + +@ifinfo +@node Interrupt Processing External Interrupts and Traps, Interrupt Processing Interrupt Levels, Interrupt Processing Interrupt Stack Frame, Interrupt Processing +@end ifinfo +@section External Interrupts and Traps + +In addition to the thirty-two unique interrupt +sources supported by the PA-RISC architecture, RTEMS also +supports the installation of handlers for each of the thirty-two +external interrupts supported by the PA-RISC architecture. +Except for interrupt vector 4, each of the interrupt vectors 0 +through 31 may be associated with a user-provided interrupt +handler. Interrupt vector 4 is used for external interrupts. +When an external interrupt occurs, the RTEMS external interrupt +handler is invoked and the actual interrupt source is indicated +by status bits in the EIR (External Interrupt Request) register. +The RTEMS external interrupt handler (or interrupt vector four) +examines the EIR to determine which interrupt source requires +servicing. + +RTEMS supports sixty-four interrupt vectors for the +PA-RISC. Vectors 0 through 31 map to the normal interrupt +sources while RTEMS interrupt vectors 32 through 63 are directly +associated with the external interrupt sources indicated by bits +0 through 31 in the EIR. + +The exact set of interrupt sources which are checked +for by the RTEMS external interrupt handler and the order in +which they are checked are configured by the user in the CPU +Configuration Table. If an external interrupt occurs which does +not have a handler configured, then the spurious interrupt +handler will be invoked. The spurious interrupt handler may +also be specifiec by the user in the CPU Configuration Table. + +@ifinfo +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing External Interrupts and Traps, Interrupt Processing +@end ifinfo +@section Interrupt Levels + +Two levels (enabled and disabled) of interrupt +priorities are supported by the PA-RISC architecture. Level +zero (0) indicates that interrupts are fully enabled (i.e. the I +bit of the PSW is 1). Level one (1) indicates that interrupts +are disabled (i.e. the I bit of the PSW is 0). Thirty-two +independent sources of external interrupts are supported by the +PA-RISC architecture. Each of these interrupts sources may be +individually enabled or disabled. When processor interrupts are +disabled, all sources of external interrupts are ignored. When +processor interrupts are enabled, the EIR (External Interrupt +Request) register is used to determine which sources are +currently allowed to generate interrupts. + +Although RTEMS supports 256 interrupt levels, the +PA-RISC architecture only supports two. RTEMS interrupt level 0 +indicates that interrupts are enabled and level 1 indicates that +interrupts are disabled. All other RTEMS interrupt levels are +undefined and their behavior is unpredictable. + +@ifinfo +@node Interrupt Processing Disabling of Interrupts by RTEMS, Default Fatal Error Processing, 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 external interrupts by setting the I +bit in the PSW to 0 before the execution of this section and +restores them to the previous level upon completion of the +section. RTEMS has been optimized to insure that interrupts are +disabled for less than XXX instructions when compiled with GNU +CC at optimization level 4. The exact execution time will vary +based on the based on the processor implementation, amount of +cache, the number of wait states for primary memory, and +processor speed present on the target board. + +Non-maskable interrupts (NMI) such as high-priority +machine checks cannot be disabled, and ISRs which execute at +this level MUST NEVER issue RTEMS system calls. If a directive +is invoked, unpredictable results may occur due to the inability +of RTEMS to protect its critical sections. However, ISRs that +make no system calls may safely execute as non-maskable +interrupts. + diff --git a/doc/supplements/hppa1_1/intr_NOTIMES.t b/doc/supplements/hppa1_1/intr_NOTIMES.t new file mode 100644 index 0000000000..bea2a3e39e --- /dev/null +++ b/doc/supplements/hppa1_1/intr_NOTIMES.t @@ -0,0 +1,214 @@ +@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 Stack Frame:: +* Interrupt Processing External Interrupts and Traps:: +* Interrupt Processing Interrupt Levels:: +* Interrupt Processing Disabling of Interrupts by RTEMS:: +@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 +occurence of an interrupt in their own unique fashion. In +addition, each processor type provides a control mechanism to +allow for the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the current +execution state and results in a change in the execution stream. +Most processors require that an interrupt handler utilize some +special control mechanisms to return to the normal processing +stream. Although RTEMS hides many of the processor dependent +details of interrupt processing, it is important to understand +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the PA-RISC's +interrupt response and control mechanisms as they pertain to +RTEMS. + +@ifinfo +@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Stack Frame, Interrupt Processing Introduction, Interrupt Processing +@end ifinfo +@section Vectoring of Interrupt Handler + +Upon receipt of an interrupt the PA-RISC +automatically performs the following actions: + +@itemize @bullet +@item The PSW (Program Status Word) is saved in the IPSW +(Interrupt Program Status Word). + +@item The current privilege level is set to 0. + +@item The following defined bits in the PSW are set: + +@item E bit is set to the default endian bit + +@item M bit is set to 1 if the interrupt is a high-priority +machine check and 0 otherwise + +@item Q bit is set to zero thuse freezing the IIA +(Instruction Address) queues + +@item C and D bits are set to zero thus disabling all +protection and translation. + +@item I bit is set to zero this disabling all external, +powerfail, and low-priority machine check interrupts. + +@item All others bits are set to zero. + +@item General purpose registers r1, r8, r9, r16, r17, r24, and +r25 are copied to the shadow registers. + +@item Execution begins at the address given by the formula: +Interruption Vector Address + (32 * interrupt vector number). +@end itemize + +Once the processor has completed the actions it is is +required to perform for each interrupt, the RTEMS interrupt +management code (the beginning of which is stored in the +Interruption Vector Table) gains control and performs the +following actions upon each interrupt: + +@itemize @bullet +@item returns the processor to "virtual mode" thus reenabling +all code and data address translation. + +@item saves all necessary interrupt state information + +@item saves all floating point registers + +@item saves all integer registers + +@item switches the current stack to the interrupt stack + +@item dispatches to the appropriate user provided interrupt +service routine (ISR). If the ISR was installed with the +interrupt_catch directive, then it will be executed at this. +Because, the RTEMS interrupt handler saves all registers which +are not preserved according to the calling conventions and +invokes the application's ISR, the ISR can easily be written in +a high-level language. +@end itemize + +RTEMS refers to the combination of the interrupt +state information and registers saved when vectoring an +interrupt as the Interrupt Stack Frame (ISF). A nested +interrupt is processed similarly by the PA-RISC and RTEMS with +the exception that the nested interrupt occurred while executing +on the interrupt stack and, thus, the current stack need not be +switched. + +@ifinfo +@node Interrupt Processing Interrupt Stack Frame, Interrupt Processing External Interrupts and Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing +@end ifinfo +@section Interrupt Stack Frame + +The PA-RISC architecture does not alter the stack +while processing interrupts. However, RTEMS does save +information on the stack as part of processing an interrupt. +This following shows the format of the Interrupt Stack Frame for +the PA-RISC as defined by RTEMS: + +@example +@group + +------------------------+ + | Interrupt Context | 0xXXX + +------------------------+ + | Integer Context | 0xXXX + +------------------------+ + | Floating Point Context | 0xXXX + +------------------------+ +@end group +@end example + +@ifinfo +@node Interrupt Processing External Interrupts and Traps, Interrupt Processing Interrupt Levels, Interrupt Processing Interrupt Stack Frame, Interrupt Processing +@end ifinfo +@section External Interrupts and Traps + +In addition to the thirty-two unique interrupt +sources supported by the PA-RISC architecture, RTEMS also +supports the installation of handlers for each of the thirty-two +external interrupts supported by the PA-RISC architecture. +Except for interrupt vector 4, each of the interrupt vectors 0 +through 31 may be associated with a user-provided interrupt +handler. Interrupt vector 4 is used for external interrupts. +When an external interrupt occurs, the RTEMS external interrupt +handler is invoked and the actual interrupt source is indicated +by status bits in the EIR (External Interrupt Request) register. +The RTEMS external interrupt handler (or interrupt vector four) +examines the EIR to determine which interrupt source requires +servicing. + +RTEMS supports sixty-four interrupt vectors for the +PA-RISC. Vectors 0 through 31 map to the normal interrupt +sources while RTEMS interrupt vectors 32 through 63 are directly +associated with the external interrupt sources indicated by bits +0 through 31 in the EIR. + +The exact set of interrupt sources which are checked +for by the RTEMS external interrupt handler and the order in +which they are checked are configured by the user in the CPU +Configuration Table. If an external interrupt occurs which does +not have a handler configured, then the spurious interrupt +handler will be invoked. The spurious interrupt handler may +also be specifiec by the user in the CPU Configuration Table. + +@ifinfo +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing External Interrupts and Traps, Interrupt Processing +@end ifinfo +@section Interrupt Levels + +Two levels (enabled and disabled) of interrupt +priorities are supported by the PA-RISC architecture. Level +zero (0) indicates that interrupts are fully enabled (i.e. the I +bit of the PSW is 1). Level one (1) indicates that interrupts +are disabled (i.e. the I bit of the PSW is 0). Thirty-two +independent sources of external interrupts are supported by the +PA-RISC architecture. Each of these interrupts sources may be +individually enabled or disabled. When processor interrupts are +disabled, all sources of external interrupts are ignored. When +processor interrupts are enabled, the EIR (External Interrupt +Request) register is used to determine which sources are +currently allowed to generate interrupts. + +Although RTEMS supports 256 interrupt levels, the +PA-RISC architecture only supports two. RTEMS interrupt level 0 +indicates that interrupts are enabled and level 1 indicates that +interrupts are disabled. All other RTEMS interrupt levels are +undefined and their behavior is unpredictable. + +@ifinfo +@node Interrupt Processing Disabling of Interrupts by RTEMS, Default Fatal Error Processing, 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 external interrupts by setting the I +bit in the PSW to 0 before the execution of this section and +restores them to the previous level upon completion of the +section. RTEMS has been optimized to insure that interrupts are +disabled for less than XXX instructions when compiled with GNU +CC at optimization level 4. The exact execution time will vary +based on the based on the processor implementation, amount of +cache, the number of wait states for primary memory, and +processor speed present on the target board. + +Non-maskable interrupts (NMI) such as high-priority +machine checks cannot be disabled, and ISRs which execute at +this level MUST NEVER issue RTEMS system calls. If a directive +is invoked, unpredictable results may occur due to the inability +of RTEMS to protect its critical sections. However, ISRs that +make no system calls may safely execute as non-maskable +interrupts. + diff --git a/doc/supplements/hppa1_1/memmodel.t b/doc/supplements/hppa1_1/memmodel.t new file mode 100644 index 0000000000..8ac774de3d --- /dev/null +++ b/doc/supplements/hppa1_1/memmodel.t @@ -0,0 +1,80 @@ +@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 User-Provided Routines, Top +@end ifinfo +@chapter Memory Model +@ifinfo +@menu +* Memory Model Introduction:: +* Memory Model Flat Memory Model:: +@end menu +@end ifinfo + +@ifinfo +@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model +@end ifinfo +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@ifinfo +@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model +@end ifinfo +@section Flat Memory Model + +RTEMS supports applications in which the application +and the executive execute within a single thirty-two bit address +space. Thus RTEMS and the application share a common four +gigabyte address space within a single space. The PA-RISC +automatically converts every address from a logical to a +physical address each time it is used. The PA-RISC uses +information provided in the page table to perform this +translation. The following protection levels are assumed: + +@itemize @bullet +@item a single code segment at protection level (0) which +contains all application and executive code. + +@item a single data segment at protection level zero (0) which +contains all application and executive data. +@end itemize + +The PA-RISC space registers and associated stack -- +including the stack pointer r27 -- must be initialized when the +initialize_executive directive is invoked. RTEMS treats the +space registers as system resources shared by all tasks and does +not modify or context switch them. + +This memory model supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +memory is addressable. The address may be used to reference a +single byte, half-word (2-bytes), or word (4 bytes). + +RTEMS does not require that logical addresses map +directly to physical addresses, although it is desirable in many +applications to do so. RTEMS does not need any additional +information when physical addresses do not map directly to +physical addresses. By not requiring that logical addresses map +directly to physical addresses, the memory space of an RTEMS +space can be separated from that of a ROM monitor. For example, +a ROM monitor may load application programs into a separate +logical address space from itself. + +RTEMS assumes that the space registers contain the +selector for the single data segment when a directive is +invoked. This assumption is especially important when +developing interrupt service routines. + diff --git a/doc/supplements/hppa1_1/memmodel.texi b/doc/supplements/hppa1_1/memmodel.texi new file mode 100644 index 0000000000..8ac774de3d --- /dev/null +++ b/doc/supplements/hppa1_1/memmodel.texi @@ -0,0 +1,80 @@ +@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 User-Provided Routines, Top +@end ifinfo +@chapter Memory Model +@ifinfo +@menu +* Memory Model Introduction:: +* Memory Model Flat Memory Model:: +@end menu +@end ifinfo + +@ifinfo +@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model +@end ifinfo +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@ifinfo +@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model +@end ifinfo +@section Flat Memory Model + +RTEMS supports applications in which the application +and the executive execute within a single thirty-two bit address +space. Thus RTEMS and the application share a common four +gigabyte address space within a single space. The PA-RISC +automatically converts every address from a logical to a +physical address each time it is used. The PA-RISC uses +information provided in the page table to perform this +translation. The following protection levels are assumed: + +@itemize @bullet +@item a single code segment at protection level (0) which +contains all application and executive code. + +@item a single data segment at protection level zero (0) which +contains all application and executive data. +@end itemize + +The PA-RISC space registers and associated stack -- +including the stack pointer r27 -- must be initialized when the +initialize_executive directive is invoked. RTEMS treats the +space registers as system resources shared by all tasks and does +not modify or context switch them. + +This memory model supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +memory is addressable. The address may be used to reference a +single byte, half-word (2-bytes), or word (4 bytes). + +RTEMS does not require that logical addresses map +directly to physical addresses, although it is desirable in many +applications to do so. RTEMS does not need any additional +information when physical addresses do not map directly to +physical addresses. By not requiring that logical addresses map +directly to physical addresses, the memory space of an RTEMS +space can be separated from that of a ROM monitor. For example, +a ROM monitor may load application programs into a separate +logical address space from itself. + +RTEMS assumes that the space registers contain the +selector for the single data segment when a directive is +invoked. This assumption is especially important when +developing interrupt service routines. + diff --git a/doc/supplements/hppa1_1/preface.texi b/doc/supplements/hppa1_1/preface.texi new file mode 100644 index 0000000000..d93497020d --- /dev/null +++ b/doc/supplements/hppa1_1/preface.texi @@ -0,0 +1,34 @@ +@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 PA-RISC V1.1 architecture in +general, refer to the following documents: + +@itemize @bullet +@item @cite{PA-RISC 1.1 Architecture and Instruction Set Reference +Manual, Third Edition. HP Part Number 09740-90039}. +@end itemize + +It is highly recommended that the PA-RISC RTEMS +application developer also obtain and become familiar with the +Technical Reference Manual for the particular implementation of +the PA-RISC being used. + diff --git a/doc/supplements/hppa1_1/timedata.t b/doc/supplements/hppa1_1/timedata.t new file mode 100644 index 0000000000..a26ce419c3 --- /dev/null +++ b/doc/supplements/hppa1_1/timedata.t @@ -0,0 +1,105 @@ +@ifinfo +@node HP-7100 Timing Data, HP-7100 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter HP-7100 Timing Data +@ifinfo +@menu +* HP-7100 Timing Data Introduction:: +* HP-7100 Timing Data Hardware Platform:: +* HP-7100 Timing Data Interrupt Latency:: +* HP-7100 Timing Data Context Switch:: +* HP-7100 Timing Data Directive Times:: +@end menu +@end ifinfo + +@ifinfo +@node HP-7100 Timing Data Introduction, HP-7100 Timing Data Hardware Platform, HP-7100 Timing Data, HP-7100 Timing Data +@end ifinfo +@section Introduction + +The timing data for the PA-RISC version of RTEMS is +provided along with the target dependent aspects concerning the +gathering of the timing data. The hardware platform used to +gather the times is described to give the reader a better +understanding of each directive time provided. Also, provided +is a description of the interrupt latency and the context +switch times as they pertain to the PA-RISC version of RTEMS. + +@ifinfo +@node HP-7100 Timing Data Hardware Platform, HP-7100 Timing Data Interrupt Latency, HP-7100 Timing Data Introduction, HP-7100 Timing Data +@end ifinfo +@section Hardware Platform + +No directive execution times are reported for the +HP-7100 because the target platform was proprietary and +executions times could not be released. + +@ifinfo +@node HP-7100 Timing Data Interrupt Latency, HP-7100 Timing Data Context Switch, HP-7100 Timing Data Hardware Platform, HP-7100 Timing Data +@end ifinfo +@section Interrupt Latency + +The maximum period with traps disabled or the +processor interrupt level set to it's highest value inside RTEMS +is less than RTEMS_MAXIMUM_DISABLE_PERIOD +microseconds including the instructions which +disable and re-enable interrupts. The time required for the +HP-7100 to vector an interrupt and for the RTEMS entry overhead +before invoking the user's trap handler are a total of +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. These combine to yield a worst case interrupt +latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD + +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at 15 Mhz. +[NOTE: The maximum period with interrupts disabled was last +determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +It should be noted again that the maximum period with +interrupts disabled within RTEMS for the HP-7100 is hand calculated. + +@ifinfo +@node HP-7100 Timing Data Context Switch, HP-7100 Timing Data Directive Times, HP-7100 Timing Data Interrupt Latency, HP-7100 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microsections for the HP-7100 when no floating point context +switch is saved or restored. Saving and restoring the floating +point context adds additional time to the context +switch procedure. Additional execution time is required when a +TASK_SWITCH user extension is configured. The use of the +TASK_SWITCH extension is application dependent. Thus, its +execution time is not considered part of the raw context switch +time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. On many +processors, the state of the numeric coprocessor is only saved +when an FLOATING_POINT task is dispatched and that task was not +the last task to utilize the coprocessor. In a system with only +one FLOATING_POINT task, the state of the numeric coprocessor +will never be saved or restored. When the first FLOATING_POINT +task is dispatched, RTEMS does not need to save the current +state of the numeric coprocessor. As discussed in the Register +Usage section, on the HP-7100 the every task is considered to be +floating point registers and , as a rsule, every context switch +involves saving and restoring the state of the floating point +unit. + +The following table summarizes the context switch +times for the HP-7100 processor: + +@example +no times are available for the HP-7100 +@end example + +@ifinfo +@node HP-7100 Timing Data Directive Times, Command and Variable Index, HP-7100 Timing Data Context Switch, HP-7100 Timing Data +@end ifinfo +@section Directive Times + +No execution times are available for the HP-7100 +because the target platform was proprietary and no timing +information could be released. + diff --git a/doc/supplements/i386/FORCE386_TIMES b/doc/supplements/i386/FORCE386_TIMES new file mode 100644 index 0000000000..19959db3aa --- /dev/null +++ b/doc/supplements/i386/FORCE386_TIMES @@ -0,0 +1,244 @@ +# +# Intel i386/Force CPU-386 Timing and Size Information +# + +# +# CPU Model Information +# +RTEMS_CPU_MODEL i386 +# +# 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 13.0 +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 16 +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.1.0 +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 34 +RTEMS_RESTORE_1ST_FP_TASK 57 +RTEMS_SAVE_INIT_RESTORE_INIT 59 +RTEMS_SAVE_IDLE_RESTORE_INIT 59 +RTEMS_SAVE_IDLE_RESTORE_IDLE 83 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 157 +RTEMS_TASK_IDENT_ONLY 748 +RTEMS_TASK_START_ONLY 86 +RTEMS_TASK_RESTART_CALLING_TASK 118 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 45 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 138 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 105 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 149 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 162 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 156 +RTEMS_TASK_DELETE_CALLING_TASK 187 +RTEMS_TASK_DELETE_SUSPENDED_TASK 147 +RTEMS_TASK_DELETE_BLOCKED_TASK 153 +RTEMS_TASK_DELETE_READY_TASK 157 +RTEMS_TASK_SUSPEND_CALLING_TASK 81 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 45 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 46 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 71 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 30 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 67 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 115 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 19 +RTEMS_TASK_MODE_NO_RESCHEDULE 21 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 27 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 66 +RTEMS_TASK_GET_NOTE_ONLY 32 +RTEMS_TASK_SET_NOTE_ONLY 32 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 18 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 63 +RTEMS_TASK_WAKE_WHEN_ONLY 128 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 13 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 12 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED 10 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 13 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 58 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 85 +RTEMS_CLOCK_GET_ONLY 2 +RTEMS_CLOCK_TICK_ONLY 16 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 34 +RTEMS_TIMER_IDENT_ONLY 729 +RTEMS_TIMER_DELETE_INACTIVE 48 +RTEMS_TIMER_DELETE_ACTIVE 52 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 65 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 69 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 92 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 92 +RTEMS_TIMER_RESET_INACTIVE 58 +RTEMS_TIMER_RESET_ACTIVE 63 +RTEMS_TIMER_CANCEL_INACTIVE 32 +RTEMS_TIMER_CANCEL_ACTIVE 37 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 64 +RTEMS_SEMAPHORE_IDENT_ONLY 787 +RTEMS_SEMAPHORE_DELETE_ONLY 60 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 41 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 40 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 123 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 47 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 70 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 95 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 294 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 730 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 81 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 117 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 118 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 144 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 117 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 116 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 144 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 122 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 146 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 93 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 45 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 127 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 41 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 26 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 89 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS <1 +RTEMS_EVENT_RECEIVE_AVAILABLE 27 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 25 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 94 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 13 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 34 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 59 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 39 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 60 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 83 +RTEMS_PARTITION_IDENT_ONLY 730 +RTEMS_PARTITION_DELETE_ONLY 40 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 34 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 40 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 68 +RTEMS_REGION_IDENT_ONLY 739 +RTEMS_REGION_DELETE_ONLY 39 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 49 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 45 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 127 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 52 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 113 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 138 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 39 +RTEMS_PORT_IDENT_ONLY 728 +RTEMS_PORT_DELETE_ONLY 39 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 26 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 4 +RTEMS_IO_OPEN_ONLY 1 +RTEMS_IO_CLOSE_ONLY 1 +RTEMS_IO_READ_ONLY <1 +RTEMS_IO_WRITE_ONLY 1 +RTEMS_IO_CONTROL_ONLY 1 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 36 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 725 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 53 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 49 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 53 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 82 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 30 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 833 +RTEMS_MINIMUM_CONFIGURATION 22,660 +RTEMS_MAXIMUM_CONFIGURATION 39,592 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE 16,948 +RTEMS_INITIALIZATION_CODE_SIZE 916 +RTEMS_TASK_CODE_SIZE 3,436 +RTEMS_INTERRUPT_CODE_SIZE 52 +RTEMS_CLOCK_CODE_SIZE 296 +RTEMS_TIMER_CODE_SIZE 1,084 +RTEMS_SEMAPHORE_CODE_SIZE 1,500 +RTEMS_MESSAGE_CODE_SIZE 1,596 +RTEMS_EVENT_CODE_SIZE 1,036 +RTEMS_SIGNAL_CODE_SIZE 396 +RTEMS_PARTITION_CODE_SIZE 1,052 +RTEMS_REGION_CODE_SIZE 1,392 +RTEMS_DPMEM_CODE_SIZE 664 +RTEMS_IO_CODE_SIZE 676 +RTEMS_FATAL_ERROR_CODE_SIZE 20 +RTEMS_RATE_MONOTONIC_CODE_SIZE 1,132 +RTEMS_MULTIPROCESSING_CODE_SIZE 6,840 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 144 +RTEMS_SEMAPHORE_CODE_OPTSIZE 136 +RTEMS_MESSAGE_CODE_OPTSIZE 224 +RTEMS_EVENT_CODE_OPTSIZE 44 +RTEMS_SIGNAL_CODE_OPTSIZE 44 +RTEMS_PARTITION_CODE_OPTSIZE 104 +RTEMS_REGION_CODE_OPTSIZE 124 +RTEMS_DPMEM_CODE_OPTSIZE 104 +RTEMS_IO_CODE_OPTSIZE 0 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 136 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 228 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 372 +RTEMS_BYTES_PER_TIMER 68 +RTEMS_BYTES_PER_SEMAPHORE 124 +RTEMS_BYTES_PER_MESSAGE_QUEUE 148 +RTEMS_BYTES_PER_REGION 144 +RTEMS_BYTES_PER_PARTITION 56 +RTEMS_BYTES_PER_PORT 36 +RTEMS_BYTES_PER_PERIOD 36 +RTEMS_BYTES_PER_EXTENSION 64 +RTEMS_BYTES_PER_FP_TASK 108 +RTEMS_BYTES_PER_NODE 48 +RTEMS_BYTES_PER_GLOBAL_OBJECT 20 +RTEMS_BYTES_PER_PROXY 124 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 6,768 diff --git a/doc/supplements/i386/Makefile b/doc/supplements/i386/Makefile new file mode 100644 index 0000000000..e24c227cd5 --- /dev/null +++ b/doc/supplements/i386/Makefile @@ -0,0 +1,88 @@ +# +# COPYRIGHT (c) 1996. +# On-Line Applications Research Corporation (OAR). +# All rights reserved. +# + +include ../Make.config + +PROJECT=i386 +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_i386 + cp c_$(PROJECT) c_$(PROJECT)-* $(INFO_INSTALL) + +c_i386: $(FILES) + $(MAKEINFO) $(PROJECT).texi + +vinfo: info + $(INFO) -f c_i386 + +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 FORCE386_TIMES + ${REPLACE} -p FORCE386_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 FORCE386_TIMES + ${REPLACE} -p FORCE386_TIMES timetbl.t + mv timetbl.t.fixed timetbl.texi + +timedata.texi: timedata.t FORCE386_TIMES + ${REPLACE} -p FORCE386_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/i386 Timing Data/' \ + <../common/wksheets.t >wksheets.t + +wksheets.texi: wksheets.t FORCE386_TIMES + ${REPLACE} -p FORCE386_TIMES wksheets.t + mv wksheets.t.fixed wksheets.texi + +html: $(FILES) + -mkdir $(WWW_INSTALL)/c_i386 + $(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_i386 c_i386-* + rm -f timedata.texi timetbl.texi intr.texi wksheets.texi + rm -f timetbl.t wksheets.t + rm -f *.fixed _* + diff --git a/doc/supplements/i386/bsp.t b/doc/supplements/i386/bsp.t new file mode 100644 index 0000000000..110d155154 --- /dev/null +++ b/doc/supplements/i386/bsp.t @@ -0,0 +1,110 @@ +@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 i386 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 i386 +processor is reset. When the i386 is reset, + +@itemize @bullet +@item The EAX register is set to indicate the results of the +processor's power-up self test. If the self-test was not +executed, the contents of this register are undefined. +Otherwise, a non-zero value indicates the processor is faulty +and a zero value indicates a successful self-test. + +@item The DX register holds a component identifier and +revision level. DH contains 3 to indicate an i386 component and +DL contains a unique revision level indicator. + +@item Control register zero (CR0) is set such that the +processor is in real mode with paging disabled. Other portions +of CR0 are used to indicate the presence of a numeric +coprocessor. + +@item All bits in the extended flags register (EFLAG) which +are not permanently set are cleared. This inhibits all maskable +interrupts. + +@item The Interrupt Descriptor Register (IDTR) is set to point +at address zero. + +@item All segment registers are set to zero. + +@item The instruction pointer is set to 0x0000FFF0. The +first instruction executed after a reset is actually at +0xFFFFFFF0 because the i386 asserts the upper twelve address +until the first intersegment (FAR) JMP or CALL instruction. +When a JMP or CALL is executed, the upper twelve address lines +are lowered and the processor begins executing in the first +megabyte of memory. +@end itemize + +Typically, an intersegment JMP to the application's +initialization code is placed at address 0xFFFFFFF0. + +@ifinfo +@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages +@end ifinfo +@section Processor Initialization + +This initialization code is responsible for +initializing all data structures required by the i386 in +protected mode and for actually entering protected mode. The +i386 must be placed in protected mode and the segment registers +and associated selectors must be initialized before the +initialize_executive directive is invoked. + +The initialization code is responsible for +initializing the Global Descriptor Table such that the i386 is +in the thirty-two bit flat memory model with paging disabled. +In this mode, the i386 automatically converts every address from +a logical to a physical address each time it is used. For more +information on the memory model used by RTEMS, please refer to +the Memory Model chapter in this document. + +If the application requires that the IDTR be some +value besides zero, then it should set it to the required value +at this point. All tasks share the same i386 IDTR value. +Because interrupts are enabled automatically by RTEMS as part of +the initialize_executive directive, the IDTR MUST be set +properly before this directive is invoked to insure correct +interrupt vectoring. If processor caching is to be utilized, +then it should be enabled during the reset application +initialization code. The reset code which is executed before +the call to initialize_executive has the following requirements: + +For more information regarding the i386s data +structures and their contents, refer to Intel's 386 +Programmer's Reference Manual. + diff --git a/doc/supplements/i386/bsp.texi b/doc/supplements/i386/bsp.texi new file mode 100644 index 0000000000..110d155154 --- /dev/null +++ b/doc/supplements/i386/bsp.texi @@ -0,0 +1,110 @@ +@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 i386 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 i386 +processor is reset. When the i386 is reset, + +@itemize @bullet +@item The EAX register is set to indicate the results of the +processor's power-up self test. If the self-test was not +executed, the contents of this register are undefined. +Otherwise, a non-zero value indicates the processor is faulty +and a zero value indicates a successful self-test. + +@item The DX register holds a component identifier and +revision level. DH contains 3 to indicate an i386 component and +DL contains a unique revision level indicator. + +@item Control register zero (CR0) is set such that the +processor is in real mode with paging disabled. Other portions +of CR0 are used to indicate the presence of a numeric +coprocessor. + +@item All bits in the extended flags register (EFLAG) which +are not permanently set are cleared. This inhibits all maskable +interrupts. + +@item The Interrupt Descriptor Register (IDTR) is set to point +at address zero. + +@item All segment registers are set to zero. + +@item The instruction pointer is set to 0x0000FFF0. The +first instruction executed after a reset is actually at +0xFFFFFFF0 because the i386 asserts the upper twelve address +until the first intersegment (FAR) JMP or CALL instruction. +When a JMP or CALL is executed, the upper twelve address lines +are lowered and the processor begins executing in the first +megabyte of memory. +@end itemize + +Typically, an intersegment JMP to the application's +initialization code is placed at address 0xFFFFFFF0. + +@ifinfo +@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages +@end ifinfo +@section Processor Initialization + +This initialization code is responsible for +initializing all data structures required by the i386 in +protected mode and for actually entering protected mode. The +i386 must be placed in protected mode and the segment registers +and associated selectors must be initialized before the +initialize_executive directive is invoked. + +The initialization code is responsible for +initializing the Global Descriptor Table such that the i386 is +in the thirty-two bit flat memory model with paging disabled. +In this mode, the i386 automatically converts every address from +a logical to a physical address each time it is used. For more +information on the memory model used by RTEMS, please refer to +the Memory Model chapter in this document. + +If the application requires that the IDTR be some +value besides zero, then it should set it to the required value +at this point. All tasks share the same i386 IDTR value. +Because interrupts are enabled automatically by RTEMS as part of +the initialize_executive directive, the IDTR MUST be set +properly before this directive is invoked to insure correct +interrupt vectoring. If processor caching is to be utilized, +then it should be enabled during the reset application +initialization code. The reset code which is executed before +the call to initialize_executive has the following requirements: + +For more information regarding the i386s data +structures and their contents, refer to Intel's 386 +Programmer's Reference Manual. + diff --git a/doc/supplements/i386/callconv.t b/doc/supplements/i386/callconv.t new file mode 100644 index 0000000000..6d58ba2f7b --- /dev/null +++ b/doc/supplements/i386/callconv.t @@ -0,0 +1,119 @@ +@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:: +@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 + +The i386 architecture supports a simple yet effective +call and return mechanism. A subroutine is invoked via the call +(call) instruction. This instruction pushes the return address +on the stack. The return from subroutine (ret) instruction pops +the return address off the current stack and transfers control +to that instruction. It is is important to note that the i386 +call and return mechanism does not automatically save or restore +any registers. It is the responsibility of the high-level +language compiler to define the register preservation and usage +convention. + +@ifinfo +@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions +@end ifinfo +@section Calling Mechanism + +All RTEMS directives are invoked using a call +instruction and return to the user application 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 instruction does not +automatically save any registers. RTEMS uses the registers EAX, +ECX, and EDX as scratch registers. These registers are not +preserved by RTEMS directives therefore, the contents of these +registers should not be assumed upon return from any RTEMS +directive. + +@ifinfo +@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions +@end ifinfo +@section Parameter Passing + +RTEMS assumes that arguments are placed on the +current stack before the directive is invoked via the call +instruction. The first argument is assumed to be closest to the +return address on the stack. This means that the first argument +of the C calling sequence is pushed last. The following +pseudo-code illustrates the typical sequence used to call a +RTEMS directive with three (3) arguments: + +@example +push third argument +push second argument +push first argument +invoke directive +remove arguments from the stack +@end example + +The arguments to RTEMS are typically pushed onto the +stack using a push instruction. These arguments must be removed +from the stack after control is returned to the caller. This +removal is typically accomplished by adding the size of the +argument list in bytes to the stack pointer. + +@ifinfo +@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions +@end ifinfo +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + diff --git a/doc/supplements/i386/callconv.texi b/doc/supplements/i386/callconv.texi new file mode 100644 index 0000000000..6d58ba2f7b --- /dev/null +++ b/doc/supplements/i386/callconv.texi @@ -0,0 +1,119 @@ +@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:: +@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 + +The i386 architecture supports a simple yet effective +call and return mechanism. A subroutine is invoked via the call +(call) instruction. This instruction pushes the return address +on the stack. The return from subroutine (ret) instruction pops +the return address off the current stack and transfers control +to that instruction. It is is important to note that the i386 +call and return mechanism does not automatically save or restore +any registers. It is the responsibility of the high-level +language compiler to define the register preservation and usage +convention. + +@ifinfo +@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions +@end ifinfo +@section Calling Mechanism + +All RTEMS directives are invoked using a call +instruction and return to the user application 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 instruction does not +automatically save any registers. RTEMS uses the registers EAX, +ECX, and EDX as scratch registers. These registers are not +preserved by RTEMS directives therefore, the contents of these +registers should not be assumed upon return from any RTEMS +directive. + +@ifinfo +@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions +@end ifinfo +@section Parameter Passing + +RTEMS assumes that arguments are placed on the +current stack before the directive is invoked via the call +instruction. The first argument is assumed to be closest to the +return address on the stack. This means that the first argument +of the C calling sequence is pushed last. The following +pseudo-code illustrates the typical sequence used to call a +RTEMS directive with three (3) arguments: + +@example +push third argument +push second argument +push first argument +invoke directive +remove arguments from the stack +@end example + +The arguments to RTEMS are typically pushed onto the +stack using a push instruction. These arguments must be removed +from the stack after control is returned to the caller. This +removal is typically accomplished by adding the size of the +argument list in bytes to the stack pointer. + +@ifinfo +@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions +@end ifinfo +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + diff --git a/doc/supplements/i386/cpumodel.t b/doc/supplements/i386/cpumodel.t new file mode 100644 index 0000000000..4504572dca --- /dev/null +++ b/doc/supplements/i386/cpumodel.t @@ -0,0 +1,81 @@ +@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 i386 implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +c/src/exec/score/cpu/i386/i386.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 i386 without an +i387 coprocessor, this macro is set to the string "i386 with i387". + +@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 I386_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. The hardware floating point may be on-chip (as in the +case of an i486DX or Pentium) or as a coprocessor (as in the case of +an i386/i387 combination). diff --git a/doc/supplements/i386/cpumodel.texi b/doc/supplements/i386/cpumodel.texi new file mode 100644 index 0000000000..4504572dca --- /dev/null +++ b/doc/supplements/i386/cpumodel.texi @@ -0,0 +1,81 @@ +@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 i386 implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +c/src/exec/score/cpu/i386/i386.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 i386 without an +i387 coprocessor, this macro is set to the string "i386 with i387". + +@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 I386_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. The hardware floating point may be on-chip (as in the +case of an i486DX or Pentium) or as a coprocessor (as in the case of +an i386/i387 combination). diff --git a/doc/supplements/i386/cputable.t b/doc/supplements/i386/cputable.t new file mode 100644 index 0000000000..aea8db223e --- /dev/null +++ b/doc/supplements/i386/cputable.t @@ -0,0 +1,126 @@ +@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 i386 version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the i386. 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 (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + unsigned32 interrupt_segment; + void *interrupt_vector_table; +@}; +@end example + +@table @code +@item pretasking_hook +is the address of the +user provided routine which is invoked once RTEMS initialization +is complete but before interrupts and tasking are enabled. This +field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately before +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +but no device drivers are initialized. This field may be NULL to +indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately after +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +and the device drivers are initialized. This field may be NULL +to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item interrupt_segment +is the value of the selector which should be placed in a segment +register to access the Interrupt Descriptor Table. + +@item interrupt_vector_table +is the base address of the Interrupt Descriptor Table relative to the +interrupt_segment. + +@end table + +The contents of the i386 Interrupt Descriptor Table +are discussed in Intel's i386 User's Manual. Structure +definitions for the i386 IDT is provided by including the file +rtems.h. + diff --git a/doc/supplements/i386/cputable.texi b/doc/supplements/i386/cputable.texi new file mode 100644 index 0000000000..aea8db223e --- /dev/null +++ b/doc/supplements/i386/cputable.texi @@ -0,0 +1,126 @@ +@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 i386 version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the i386. 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 (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + unsigned32 interrupt_segment; + void *interrupt_vector_table; +@}; +@end example + +@table @code +@item pretasking_hook +is the address of the +user provided routine which is invoked once RTEMS initialization +is complete but before interrupts and tasking are enabled. This +field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately before +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +but no device drivers are initialized. This field may be NULL to +indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately after +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +and the device drivers are initialized. This field may be NULL +to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item interrupt_segment +is the value of the selector which should be placed in a segment +register to access the Interrupt Descriptor Table. + +@item interrupt_vector_table +is the base address of the Interrupt Descriptor Table relative to the +interrupt_segment. + +@end table + +The contents of the i386 Interrupt Descriptor Table +are discussed in Intel's i386 User's Manual. Structure +definitions for the i386 IDT is provided by including the file +rtems.h. + diff --git a/doc/supplements/i386/fatalerr.t b/doc/supplements/i386/fatalerr.t new file mode 100644 index 0000000000..2743eb9a05 --- /dev/null +++ b/doc/supplements/i386/fatalerr.t @@ -0,0 +1,44 @@ +@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 are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@ifinfo +@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing +@end ifinfo +@section Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts, +places the error code in EAX, and executes a HLT instruction to +halt the processor. + diff --git a/doc/supplements/i386/fatalerr.texi b/doc/supplements/i386/fatalerr.texi new file mode 100644 index 0000000000..2743eb9a05 --- /dev/null +++ b/doc/supplements/i386/fatalerr.texi @@ -0,0 +1,44 @@ +@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 are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@ifinfo +@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing +@end ifinfo +@section Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts, +places the error code in EAX, and executes a HLT instruction to +halt the processor. + diff --git a/doc/supplements/i386/i386.texi b/doc/supplements/i386/i386.texi new file mode 100644 index 0000000000..8f0be73fda --- /dev/null +++ b/doc/supplements/i386/i386.texi @@ -0,0 +1,123 @@ +@c +@c COPYRIGHT (c) 1988-1997. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +\input ../texinfo/texinfo @c -*-texinfo-*- +@c %**start of header +@setfilename c_i386 +@syncodeindex vr fn +@synindex ky cp +@paragraphindent 0 +@c @smallbook +@c %**end of header + +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@c +@c Master file for the Intel i386 C Applications Supplement +@c + +@include ../common/setup.texi + +@ignore +@ifinfo +@format +START-INFO-DIR-ENTRY +* RTEMS Intel i386 C Applications Supplement (i386): +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 i386 C Applications Supplement + +@setchapternewpage odd +@settitle RTEMS Intel i386 C Applications Supplement +@titlepage +@finalout + +@title RTEMS Intel i386 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_i386 + +This is the online version of the RTEMS Intel i386 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:: +* i386 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, i386 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/i386/intr.t b/doc/supplements/i386/intr.t new file mode 100644 index 0000000000..5c36183970 --- /dev/null +++ b/doc/supplements/i386/intr.t @@ -0,0 +1,191 @@ +@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 Stack Frame:: +* Interrupt Processing Interrupt Levels:: +* Interrupt Processing Disabling of Interrupts by RTEMS:: +* Interrupt Processing Interrupt Stack:: +@end menu +@end ifinfo + +@ifinfo +@node Interrupt Processing Introduction, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing, Interrupt Processing +@end ifinfo +@section Introduction + +Different types of processors respond to the +occurrence of an interrupt in their 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 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 Stack Frame, Interrupt Processing Introduction, Interrupt Processing +@end ifinfo +@section Vectoring of Interrupt Handler + +Although the i386 supports multiple privilege levels, +RTEMS and all user software executes at privilege level 0. This +decision was made by the RTEMS designers to enhance +compatibility with processors which do not provide sophisticated +protection facilities like those of the i386. This decision +greatly simplifies the discussion of i386 processing, as one +need only consider interrupts without privilege transitions. + +Upon receipt of an interrupt the i386 automatically +performs the following actions: + +@itemize @bullet +@item pushes the EFLAGS register + +@item pushes the far address of the interrupted instruction + +@item vectors to the interrupt service routine (ISR). +@end itemize + +A nested interrupt is processed similarly by the +i386. + +@ifinfo +@node Interrupt Processing Interrupt Stack Frame, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing +@end ifinfo +@section Interrupt Stack Frame + +The structure of the Interrupt Stack Frame for the +i386 which is placed on the interrupt stack by the processor in +response to an interrupt is as follows: + +@ifset use-ascii +@example +@group + +----------------------+ + | Old EFLAGS Register | ESP+8 + +----------+-----------+ + | UNUSED | Old CS | ESP+4 + +----------+-----------+ + | Old EIP | ESP + +----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\strut\vrule#& +\hbox to 1.00in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.00in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 0.75in{\enskip\hfil#\hfil} +\cr +\multispan{4}\hrulefill\cr +& \multispan{3} Old EFLAGS Register\quad&&ESP+8\cr +\multispan{4}\hrulefill\cr +&UNUSED &&Old CS &&ESP+4\cr +\multispan{4}\hrulefill\cr +& \multispan{3} Old EIP && ESP\cr +\multispan{4}\hrulefill\cr +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +<CENTER> + <TABLE COLS=3 WIDTH="40%" BORDER=2> +<TR><TD ALIGN=center COLSPAN=2><STRONG>Old EFLAGS Register</STRONG></TD> + <TD ALIGN=center>0x0</TD></TR> +<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD> + <TD ALIGN=center><STRONG>Old CS</STRONG></TD> + <TD ALIGN=center>0x2</TD></TR> +<TR><TD ALIGN=center COLSPAN=2><STRONG>Old EIP</STRONG></TD> + <TD ALIGN=center>0x4</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +@ifinfo +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack Frame, Interrupt Processing +@end ifinfo +@section Interrupt Levels + +Although RTEMS supports 256 interrupt levels, the +i386 only supports two -- enabled and disabled. Interrupts are +enabled when the interrupt-enable flag (IF) in the extended +flags (EFLAGS) is set. Conversely, interrupt processing is +inhibited when the IF is cleared. During a non-maskable +interrupt, all other interrupts, including other non-maskable +ones, are inhibited. + +RTEMS interrupt levels 0 and 1 such that level zero +(0) indicates that interrupts are fully enabled and level one +that interrupts are disabled. All other RTEMS interrupt levels +are undefined and their behavior is unpredictable. + +@ifinfo +@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing +@end ifinfo +@section Disabling of Interrupts by RTEMS + +During the execution of directive calls, critical +sections of code may be executed. When these sections are +encountered, RTEMS disables interrupts 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 i386 with zero +wait states. These numbers will vary based the number of wait states +and processor speed present on the target board. [NOTE: The maximum +period with interrupts disabled within RTEMS was last calculated 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 Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing +@end ifinfo +@section Interrupt Stack + +The i386 family does not support a dedicated hardware +interrupt stack. On this processor, RTEMS allocates and manages +a dedicated interrupt stack. As part of vectoring a non-nested +interrupt service routine, RTEMS switches from the stack of the +interrupted task to a dedicated interrupt stack. When a +non-nested interrupt returns, RTEMS switches back to the stack +of the interrupted stack. The current stack pointer is not +altered by RTEMS on nested interrupt. + +Without a dedicated interrupt stack, every task in +the system MUST have enough stack space to accommodate the worst +case stack usage of that particular task and the interrupt +service routines COMBINED. By supporting a dedicated interrupt +stack, RTEMS significantly lowers the stack requirements for +each task. + +RTEMS allocates the dedicated 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. + diff --git a/doc/supplements/i386/intr_NOTIMES.t b/doc/supplements/i386/intr_NOTIMES.t new file mode 100644 index 0000000000..5c36183970 --- /dev/null +++ b/doc/supplements/i386/intr_NOTIMES.t @@ -0,0 +1,191 @@ +@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 Stack Frame:: +* Interrupt Processing Interrupt Levels:: +* Interrupt Processing Disabling of Interrupts by RTEMS:: +* Interrupt Processing Interrupt Stack:: +@end menu +@end ifinfo + +@ifinfo +@node Interrupt Processing Introduction, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing, Interrupt Processing +@end ifinfo +@section Introduction + +Different types of processors respond to the +occurrence of an interrupt in their 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 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 Stack Frame, Interrupt Processing Introduction, Interrupt Processing +@end ifinfo +@section Vectoring of Interrupt Handler + +Although the i386 supports multiple privilege levels, +RTEMS and all user software executes at privilege level 0. This +decision was made by the RTEMS designers to enhance +compatibility with processors which do not provide sophisticated +protection facilities like those of the i386. This decision +greatly simplifies the discussion of i386 processing, as one +need only consider interrupts without privilege transitions. + +Upon receipt of an interrupt the i386 automatically +performs the following actions: + +@itemize @bullet +@item pushes the EFLAGS register + +@item pushes the far address of the interrupted instruction + +@item vectors to the interrupt service routine (ISR). +@end itemize + +A nested interrupt is processed similarly by the +i386. + +@ifinfo +@node Interrupt Processing Interrupt Stack Frame, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing +@end ifinfo +@section Interrupt Stack Frame + +The structure of the Interrupt Stack Frame for the +i386 which is placed on the interrupt stack by the processor in +response to an interrupt is as follows: + +@ifset use-ascii +@example +@group + +----------------------+ + | Old EFLAGS Register | ESP+8 + +----------+-----------+ + | UNUSED | Old CS | ESP+4 + +----------+-----------+ + | Old EIP | ESP + +----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\strut\vrule#& +\hbox to 1.00in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.00in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 0.75in{\enskip\hfil#\hfil} +\cr +\multispan{4}\hrulefill\cr +& \multispan{3} Old EFLAGS Register\quad&&ESP+8\cr +\multispan{4}\hrulefill\cr +&UNUSED &&Old CS &&ESP+4\cr +\multispan{4}\hrulefill\cr +& \multispan{3} Old EIP && ESP\cr +\multispan{4}\hrulefill\cr +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +<CENTER> + <TABLE COLS=3 WIDTH="40%" BORDER=2> +<TR><TD ALIGN=center COLSPAN=2><STRONG>Old EFLAGS Register</STRONG></TD> + <TD ALIGN=center>0x0</TD></TR> +<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD> + <TD ALIGN=center><STRONG>Old CS</STRONG></TD> + <TD ALIGN=center>0x2</TD></TR> +<TR><TD ALIGN=center COLSPAN=2><STRONG>Old EIP</STRONG></TD> + <TD ALIGN=center>0x4</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +@ifinfo +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack Frame, Interrupt Processing +@end ifinfo +@section Interrupt Levels + +Although RTEMS supports 256 interrupt levels, the +i386 only supports two -- enabled and disabled. Interrupts are +enabled when the interrupt-enable flag (IF) in the extended +flags (EFLAGS) is set. Conversely, interrupt processing is +inhibited when the IF is cleared. During a non-maskable +interrupt, all other interrupts, including other non-maskable +ones, are inhibited. + +RTEMS interrupt levels 0 and 1 such that level zero +(0) indicates that interrupts are fully enabled and level one +that interrupts are disabled. All other RTEMS interrupt levels +are undefined and their behavior is unpredictable. + +@ifinfo +@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing +@end ifinfo +@section Disabling of Interrupts by RTEMS + +During the execution of directive calls, critical +sections of code may be executed. When these sections are +encountered, RTEMS disables interrupts 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 i386 with zero +wait states. These numbers will vary based the number of wait states +and processor speed present on the target board. [NOTE: The maximum +period with interrupts disabled within RTEMS was last calculated 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 Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing +@end ifinfo +@section Interrupt Stack + +The i386 family does not support a dedicated hardware +interrupt stack. On this processor, RTEMS allocates and manages +a dedicated interrupt stack. As part of vectoring a non-nested +interrupt service routine, RTEMS switches from the stack of the +interrupted task to a dedicated interrupt stack. When a +non-nested interrupt returns, RTEMS switches back to the stack +of the interrupted stack. The current stack pointer is not +altered by RTEMS on nested interrupt. + +Without a dedicated interrupt stack, every task in +the system MUST have enough stack space to accommodate the worst +case stack usage of that particular task and the interrupt +service routines COMBINED. By supporting a dedicated interrupt +stack, RTEMS significantly lowers the stack requirements for +each task. + +RTEMS allocates the dedicated 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. + diff --git a/doc/supplements/i386/memmodel.t b/doc/supplements/i386/memmodel.t new file mode 100644 index 0000000000..3d4ca55410 --- /dev/null +++ b/doc/supplements/i386/memmodel.t @@ -0,0 +1,85 @@ +@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 User-Provided Routines, Top +@end ifinfo +@chapter Memory Model +@ifinfo +@menu +* Memory Model Introduction:: +* Memory Model Flat Memory Model:: +@end menu +@end ifinfo + +@ifinfo +@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model +@end ifinfo +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@ifinfo +@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model +@end ifinfo +@section Flat Memory Model + +RTEMS supports the i386 protected mode, flat memory +model with paging disabled. In this mode, the i386 +automatically converts every address from a logical to a +physical address each time it is used. The i386 uses +information provided in the segment registers and the Global +Descriptor Table to convert these addresses. RTEMS assumes the +existence of the following segments: + +@itemize @bullet +@item a single code segment at protection level (0) which +contains all application and executive code. + +@item a single data segment at protection level zero (0) which +contains all application and executive data. +@end itemize + +The i386 segment registers and associated selectors +must be initialized when the initialize_executive directive is +invoked. RTEMS treats the segment registers as system registers +and does not modify or context switch them. + +This i386 memory model supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +is byte addressable. The address may be used to reference a +single byte, half-word (2-bytes), or word (4 bytes). + +RTEMS does not require that logical addresses map +directly to physical addresses, although it is desirable in many +applications to do so. If logical and physical addresses are +not the same, then an additional selector will be required so +RTEMS can access the Interrupt Descriptor Table to install +interrupt service routines. The selector number of this segment +is provided to RTEMS in the CPU Dependent Information Table. + +By not requiring that logical addresses map directly +to physical addresses, the memory space of an RTEMS application +can be separated from that of a ROM monitor. For example, on +the Force Computers CPU386, the ROM monitor loads application +programs into a logical address space where logical address +0x00000000 corresponds to physical address 0x0002000. On this +board, RTEMS and the application use virtual addresses which do +not map to physical addresses. + +RTEMS assumes that the DS and ES registers contain +the selector for the single data segment when a directive is +invoked. This assumption is especially important when +developing interrupt service routines. + diff --git a/doc/supplements/i386/memmodel.texi b/doc/supplements/i386/memmodel.texi new file mode 100644 index 0000000000..3d4ca55410 --- /dev/null +++ b/doc/supplements/i386/memmodel.texi @@ -0,0 +1,85 @@ +@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 User-Provided Routines, Top +@end ifinfo +@chapter Memory Model +@ifinfo +@menu +* Memory Model Introduction:: +* Memory Model Flat Memory Model:: +@end menu +@end ifinfo + +@ifinfo +@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model +@end ifinfo +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@ifinfo +@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model +@end ifinfo +@section Flat Memory Model + +RTEMS supports the i386 protected mode, flat memory +model with paging disabled. In this mode, the i386 +automatically converts every address from a logical to a +physical address each time it is used. The i386 uses +information provided in the segment registers and the Global +Descriptor Table to convert these addresses. RTEMS assumes the +existence of the following segments: + +@itemize @bullet +@item a single code segment at protection level (0) which +contains all application and executive code. + +@item a single data segment at protection level zero (0) which +contains all application and executive data. +@end itemize + +The i386 segment registers and associated selectors +must be initialized when the initialize_executive directive is +invoked. RTEMS treats the segment registers as system registers +and does not modify or context switch them. + +This i386 memory model supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +is byte addressable. The address may be used to reference a +single byte, half-word (2-bytes), or word (4 bytes). + +RTEMS does not require that logical addresses map +directly to physical addresses, although it is desirable in many +applications to do so. If logical and physical addresses are +not the same, then an additional selector will be required so +RTEMS can access the Interrupt Descriptor Table to install +interrupt service routines. The selector number of this segment +is provided to RTEMS in the CPU Dependent Information Table. + +By not requiring that logical addresses map directly +to physical addresses, the memory space of an RTEMS application +can be separated from that of a ROM monitor. For example, on +the Force Computers CPU386, the ROM monitor loads application +programs into a logical address space where logical address +0x00000000 corresponds to physical address 0x0002000. On this +board, RTEMS and the application use virtual addresses which do +not map to physical addresses. + +RTEMS assumes that the DS and ES registers contain +the selector for the single data segment when a directive is +invoked. This assumption is especially important when +developing interrupt service routines. + diff --git a/doc/supplements/i386/preface.texi b/doc/supplements/i386/preface.texi new file mode 100644 index 0000000000..ce96fe2ea4 --- /dev/null +++ b/doc/supplements/i386/preface.texi @@ -0,0 +1,39 @@ +@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 i386 processor, refer to the +following documents: + +@itemize @bullet +@item @cite{386 Programmer's Reference Manual, Intel, Order No. 230985-002}. + +@item @cite{386 Microprocessor Hardware Reference Manual, Intel, +Order No. 231732-003}. + +@item @cite{80386 System Software Writer's Guide, Intel, Order No. 231499-001}. + +@item @cite{80387 Programmer's Reference Manual, Intel, Order No. 231917-001}. +@end itemize + +It is highly recommended that the i386 RTEMS +application developer obtain and become familiar with Intel's +386 Programmer's Reference Manual. + diff --git a/doc/supplements/i386/timeFORCE386.t b/doc/supplements/i386/timeFORCE386.t new file mode 100644 index 0000000000..03362e3c88 --- /dev/null +++ b/doc/supplements/i386/timeFORCE386.t @@ -0,0 +1,135 @@ +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node i386 Timing Data, i386 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter i386 Timing Data +@ifinfo +@menu +* i386 Timing Data Introduction:: +* i386 Timing Data Hardware Platform:: +* i386 Timing Data Interrupt Latency:: +* i386 Timing Data Context Switch:: +* i386 Timing Data Directive Times:: +* i386 Timing Data Task Manager:: +* i386 Timing Data Interrupt Manager:: +* i386 Timing Data Clock Manager:: +* i386 Timing Data Timer Manager:: +* i386 Timing Data Semaphore Manager:: +* i386 Timing Data Message Manager:: +* i386 Timing Data Event Manager:: +* i386 Timing Data Signal Manager:: +* i386 Timing Data Partition Manager:: +* i386 Timing Data Region Manager:: +* i386 Timing Data Dual-Ported Memory Manager:: +* i386 Timing Data I/O Manager:: +* i386 Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +@ifinfo +@node i386 Timing Data Introduction, i386 Timing Data Hardware Platform, i386 Timing Data, i386 Timing Data +@end ifinfo +@section Introduction + +The timing data for the i386 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 i386 version of RTEMS. + +@ifinfo +@node i386 Timing Data Hardware Platform, i386 Timing Data Interrupt Latency, i386 Timing Data Introduction, i386 Timing Data +@end ifinfo +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Force +Computers CPU386 board. The CPU386 is a 16 Mhz board with zero +wait state dynamic memory and an i80387 numeric coprocessor. +One of the count-down timers provided by a Motorola MC68901 was +used to measure elapsed time with one microsecond resolution. +All sources of hardware interrupts are disabled, although the +interrupt level of the i386 allows all interrupts. + +The maximum period interrupts are disabled 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 16 +to simulate a i386 executing at 16 Mhz. + +@ifinfo +@node i386 Timing Data Interrupt Latency, i386 Timing Data Context Switch, i386 Timing Data Hardware Platform, i386 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 i386 to generate an interrupt using the int instruction, +vectoring to an interrupt handler, and for the RTEMS entry +overhead before invoking the user's interrupt handler are a +total of 12 microseconds. These combine to yield a worst case +interrupt latency of less +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 Force +Computers CPU386 benchmark platform using the int instruction as +the interrupt source. + +@ifinfo +@node i386 Timing Data Context Switch, i386 Timing Data Directive Times, i386 Timing Data Interrupt Latency, i386 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the Force Computers CPU386 benchmark platform. +This time represents the raw context switch time with no user +extensions configured. Additional execution time is required +when a TASK_SWITCH user extension is configured. The use of the +TASK_SWITCH extension is application dependent. Thus, its +execution time is not considered part of the base context switch +time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. The state of +the numeric coprocessor is only saved when a FLOATING_POINT task +is dispatched and that task was not the last task to utilize the +coprocessor. In a system with only one FLOATING_POINT task, the +state of the numeric coprocessor will never be saved or +restored. When the first FLOATING_POINT task is dispatched, +RTEMS does not need to save the current state of the numeric +coprocessor. + +The exact amount of time required to save and restore +floating point context is dependent on the state of the numeric +coprocessor. RTEMS places the coprocessor in the initialized +state when a task is started or restarted. Once the task has +utilized the coprocessor, it is in the idle state when floating +point instructions are not executing and the busy state when +floating point instructions are executing. The state of the +coprocessor is task specific. + +The following table summarizes the context switch +times for the Force Computers CPU386 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex diff --git a/doc/supplements/i386/timedata.t b/doc/supplements/i386/timedata.t new file mode 100644 index 0000000000..03362e3c88 --- /dev/null +++ b/doc/supplements/i386/timedata.t @@ -0,0 +1,135 @@ +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node i386 Timing Data, i386 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter i386 Timing Data +@ifinfo +@menu +* i386 Timing Data Introduction:: +* i386 Timing Data Hardware Platform:: +* i386 Timing Data Interrupt Latency:: +* i386 Timing Data Context Switch:: +* i386 Timing Data Directive Times:: +* i386 Timing Data Task Manager:: +* i386 Timing Data Interrupt Manager:: +* i386 Timing Data Clock Manager:: +* i386 Timing Data Timer Manager:: +* i386 Timing Data Semaphore Manager:: +* i386 Timing Data Message Manager:: +* i386 Timing Data Event Manager:: +* i386 Timing Data Signal Manager:: +* i386 Timing Data Partition Manager:: +* i386 Timing Data Region Manager:: +* i386 Timing Data Dual-Ported Memory Manager:: +* i386 Timing Data I/O Manager:: +* i386 Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +@ifinfo +@node i386 Timing Data Introduction, i386 Timing Data Hardware Platform, i386 Timing Data, i386 Timing Data +@end ifinfo +@section Introduction + +The timing data for the i386 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 i386 version of RTEMS. + +@ifinfo +@node i386 Timing Data Hardware Platform, i386 Timing Data Interrupt Latency, i386 Timing Data Introduction, i386 Timing Data +@end ifinfo +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Force +Computers CPU386 board. The CPU386 is a 16 Mhz board with zero +wait state dynamic memory and an i80387 numeric coprocessor. +One of the count-down timers provided by a Motorola MC68901 was +used to measure elapsed time with one microsecond resolution. +All sources of hardware interrupts are disabled, although the +interrupt level of the i386 allows all interrupts. + +The maximum period interrupts are disabled 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 16 +to simulate a i386 executing at 16 Mhz. + +@ifinfo +@node i386 Timing Data Interrupt Latency, i386 Timing Data Context Switch, i386 Timing Data Hardware Platform, i386 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 i386 to generate an interrupt using the int instruction, +vectoring to an interrupt handler, and for the RTEMS entry +overhead before invoking the user's interrupt handler are a +total of 12 microseconds. These combine to yield a worst case +interrupt latency of less +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 Force +Computers CPU386 benchmark platform using the int instruction as +the interrupt source. + +@ifinfo +@node i386 Timing Data Context Switch, i386 Timing Data Directive Times, i386 Timing Data Interrupt Latency, i386 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the Force Computers CPU386 benchmark platform. +This time represents the raw context switch time with no user +extensions configured. Additional execution time is required +when a TASK_SWITCH user extension is configured. The use of the +TASK_SWITCH extension is application dependent. Thus, its +execution time is not considered part of the base context switch +time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. The state of +the numeric coprocessor is only saved when a FLOATING_POINT task +is dispatched and that task was not the last task to utilize the +coprocessor. In a system with only one FLOATING_POINT task, the +state of the numeric coprocessor will never be saved or +restored. When the first FLOATING_POINT task is dispatched, +RTEMS does not need to save the current state of the numeric +coprocessor. + +The exact amount of time required to save and restore +floating point context is dependent on the state of the numeric +coprocessor. RTEMS places the coprocessor in the initialized +state when a task is started or restarted. Once the task has +utilized the coprocessor, it is in the idle state when floating +point instructions are not executing and the busy state when +floating point instructions are executing. The state of the +coprocessor is task specific. + +The following table summarizes the context switch +times for the Force Computers CPU386 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex 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 + diff --git a/doc/supplements/m68k/MVME136_TIMES b/doc/supplements/m68k/MVME136_TIMES new file mode 100644 index 0000000000..3faa666049 --- /dev/null +++ b/doc/supplements/m68k/MVME136_TIMES @@ -0,0 +1,244 @@ +# +# M68020/MVME136 Timing and Size Information +# + +# +# CPU Model Information +# +RTEMS_CPU_MODEL MC68020 +# +# Interrupt Latency +# +# NOTE: In general, the text says it is hand-calculated to be +# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +# Mhz and this was last calculated for Release +# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. +# +RTEMS_MAXIMUM_DISABLE_PERIOD TBD +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20 +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.2.1 +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 35 +RTEMS_RESTORE_1ST_FP_TASK 39 +RTEMS_SAVE_INIT_RESTORE_INIT 66 +RTEMS_SAVE_IDLE_RESTORE_INIT 66 +RTEMS_SAVE_IDLE_RESTORE_IDLE 68 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 148 +RTEMS_TASK_IDENT_ONLY 350 +RTEMS_TASK_START_ONLY 76 +RTEMS_TASK_RESTART_CALLING_TASK 95 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142 +RTEMS_TASK_DELETE_CALLING_TASK 170 +RTEMS_TASK_DELETE_SUSPENDED_TASK 138 +RTEMS_TASK_DELETE_BLOCKED_TASK 143 +RTEMS_TASK_DELETE_READY_TASK 144 +RTEMS_TASK_SUSPEND_CALLING_TASK 71 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14 +RTEMS_TASK_MODE_NO_RESCHEDULE 16 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60 +RTEMS_TASK_GET_NOTE_ONLY 33 +RTEMS_TASK_SET_NOTE_ONLY 33 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56 +RTEMS_TASK_WAKE_WHEN_ONLY 117 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 86 +RTEMS_CLOCK_GET_ONLY 1 +RTEMS_CLOCK_TICK_ONLY 17 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 28 +RTEMS_TIMER_IDENT_ONLY 343 +RTEMS_TIMER_DELETE_INACTIVE 43 +RTEMS_TIMER_DELETE_ACTIVE 47 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 58 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 61 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 88 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 88 +RTEMS_TIMER_RESET_INACTIVE 54 +RTEMS_TIMER_RESET_ACTIVE 58 +RTEMS_TIMER_CANCEL_INACTIVE 31 +RTEMS_TIMER_CANCEL_ACTIVE 34 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 60 +RTEMS_SEMAPHORE_IDENT_ONLY 367 +RTEMS_SEMAPHORE_DELETE_ONLY 58 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 24 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 +RTEMS_EVENT_RECEIVE_AVAILABLE 28 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 15 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 70 +RTEMS_PARTITION_IDENT_ONLY 341 +RTEMS_PARTITION_DELETE_ONLY 42 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 43 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 63 +RTEMS_REGION_IDENT_ONLY 348 +RTEMS_REGION_DELETE_ONLY 39 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 52 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 35 +RTEMS_PORT_IDENT_ONLY 340 +RTEMS_PORT_DELETE_ONLY 39 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 4 +RTEMS_IO_OPEN_ONLY 2 +RTEMS_IO_CLOSE_ONLY 1 +RTEMS_IO_READ_ONLY 2 +RTEMS_IO_WRITE_ONLY 3 +RTEMS_IO_CONTROL_ONLY 2 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 32 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 341 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 723 +RTEMS_MINIMUM_CONFIGURATION 18,980 +RTEMS_MAXIMUM_CONFIGURATION 36,438 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE 12,674 +RTEMS_INITIALIZATION_CODE_SIZE 970 +RTEMS_TASK_CODE_SIZE 3,562 +RTEMS_INTERRUPT_CODE_SIZE 54 +RTEMS_CLOCK_CODE_SIZE 334 +RTEMS_TIMER_CODE_SIZE 1,110 +RTEMS_SEMAPHORE_CODE_SIZE 1,632 +RTEMS_MESSAGE_CODE_SIZE 1,754 +RTEMS_EVENT_CODE_SIZE 1,000 +RTEMS_SIGNAL_CODE_SIZE 418 +RTEMS_PARTITION_CODE_SIZE 1,164 +RTEMS_REGION_CODE_SIZE 1,494 +RTEMS_DPMEM_CODE_SIZE 724 +RTEMS_IO_CODE_SIZE 686 +RTEMS_FATAL_ERROR_CODE_SIZE 24 +RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212 +RTEMS_MULTIPROCESSING_CODE_SIZE 6.952 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 184 +RTEMS_SEMAPHORE_CODE_OPTSIZE 172 +RTEMS_MESSAGE_CODE_OPTSIZE 288 +RTEMS_EVENT_CODE_OPTSIZE 56 +RTEMS_SIGNAL_CODE_OPTSIZE 56 +RTEMS_PARTITION_CODE_OPTSIZE 132 +RTEMS_REGION_CODE_OPTSIZE 160 +RTEMS_DPMEM_CODE_OPTSIZE 132 +RTEMS_IO_CODE_OPTSIZE 0 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 400 +RTEMS_BYTES_PER_TIMER 68 +RTEMS_BYTES_PER_SEMAPHORE 124 +RTEMS_BYTES_PER_MESSAGE_QUEUE 148 +RTEMS_BYTES_PER_REGION 144 +RTEMS_BYTES_PER_PARTITION 56 +RTEMS_BYTES_PER_PORT 36 +RTEMS_BYTES_PER_PERIOD 36 +RTEMS_BYTES_PER_EXTENSION 64 +RTEMS_BYTES_PER_FP_TASK 332 +RTEMS_BYTES_PER_NODE 48 +RTEMS_BYTES_PER_GLOBAL_OBJECT 20 +RTEMS_BYTES_PER_PROXY 124 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872 diff --git a/doc/supplements/m68k/Makefile b/doc/supplements/m68k/Makefile new file mode 100644 index 0000000000..94a56dcf99 --- /dev/null +++ b/doc/supplements/m68k/Makefile @@ -0,0 +1,87 @@ +# +# COPYRIGHT (c) 1996. +# On-Line Applications Research Corporation (OAR). +# All rights reserved. +# + +include ../Make.config + +PROJECT=m68k +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_m68k + cp c_$(PROJECT) c_$(PROJECT)-* $(INFO_INSTALL) + +c_m68k: $(FILES) + $(MAKEINFO) $(PROJECT).texi + +vinfo: info + $(INFO) -f c_m68k + +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 MVME136_TIMES + ${REPLACE} -p MVME136_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 MVME136_TIMES + ${REPLACE} -p MVME136_TIMES timetbl.t + mv timetbl.t.fixed timetbl.texi + +timedata.texi: timedata.t MVME136_TIMES + ${REPLACE} -p MVME136_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/MC68020 Timing Data/' \ + <../common/wksheets.t >wksheets.t + +wksheets.texi: wksheets.t MVME136_TIMES + ${REPLACE} -p MVME136_TIMES wksheets.t + mv wksheets.t.fixed wksheets.texi + +html: $(FILES) + -mkdir $(WWW_INSTALL)/c_m68k + $(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_m68k c_m68k-* + rm -f timedata.texi timetbl.texi intr.texi wksheets.texi + rm -f timetbl.t wksheets.t + rm -f *.fixed _* diff --git a/doc/supplements/m68k/bsp.t b/doc/supplements/m68k/bsp.t new file mode 100644 index 0000000000..60c889c495 --- /dev/null +++ b/doc/supplements/m68k/bsp.t @@ -0,0 +1,110 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 MC68020 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 or +re-initiated when the MC68020 processor is reset. When the +MC68020 is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@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 address of the application's initialization code +should be stored in the first vector of the EVT which will allow +the immediate vectoring to the application code. If the +application requires that the VBR be some value besides zero, +then it should be set to the required value at this point. All +tasks share the same MC68020's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure correct interrupt vectoring. If processor +caching is to be utilized, then it should be enabled during the +reset application initialization code. + +In addition to the requirements described in the +Board Support Packages chapter of the C Applications User's +Manual for the reset code which is executed before the call to +initialize executive, the MC68020 version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the MC68020 remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +MC68020 from the interrupt state. + +@item Must set the master stack pointer (MSP) such that a +minimum stack size of MINIMUM_STACK_SIZE bytes is provided for +the initialize executive directive. + +@item Must initialize the MC68020's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + diff --git a/doc/supplements/m68k/callconv.t b/doc/supplements/m68k/callconv.t new file mode 100644 index 0000000000..2bcc2188fa --- /dev/null +++ b/doc/supplements/m68k/callconv.t @@ -0,0 +1,121 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Extend Byte to Long Instruction, Top +@end ifinfo +@chapter Calling Conventions +@ifinfo +@menu +* Calling Conventions Introduction:: +* Calling Conventions Processor Background:: +* Calling Conventions Calling Mechanism:: +* Calling Conventions Register Usage:: +* Calling Conventions Parameter Passing:: +* Calling Conventions User-Provided Routines:: +@end menu +@end ifinfo + +@ifinfo +@node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions +@end ifinfo +@section Introduction + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@ifinfo +@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions +@end ifinfo +@section Processor Background + +The MC68xxx architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the branch to subroutine (bsr) or the jump to subroutine +(jsr) instructions. These instructions push the return address +on the current stack. The return from subroutine (rts) +instruction pops the return address off the current stack and +transfers control to that instruction. It is is important to +note that the MC68xxx call and return mechanism does not +automatically save or restore any registers. It is the +responsibility of the high-level language compiler to define the +register preservation and usage convention. + +@ifinfo +@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions +@end ifinfo +@section Calling Mechanism + +All RTEMS directives are invoked using either a bsr +or jsr instruction and return to the user application via the +rts 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 bsr and jsr instructions do +not automatically save any registers. RTEMS uses the registers +D0, D1, A0, and A1 as scratch registers. These registers are +not preserved by RTEMS directives therefore, the contents of +these registers should not be assumed upon return from any RTEMS +directive. + +@ifinfo +@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions +@end ifinfo +@section Parameter Passing + +RTEMS assumes that arguments are placed on the +current stack before the directive is invoked via the bsr or jsr +instruction. The first argument is assumed to be closest to the +return address on the stack. This means that the first argument +of the C calling sequence is pushed last. The following +pseudo-code illustrates the typical sequence used to call a +RTEMS directive with three (3) arguments: + +@example +@group +push third argument +push second argument +push first argument +invoke directive +remove arguments from the stack +@end group +@end example + +The arguments to RTEMS are typically pushed onto the +stack using a move instruction with a pre-decremented stack +pointer as the destination. These arguments must be removed +from the stack after control is returned to the caller. This +removal is typically accomplished by adding the size of the +argument list in bytes to the current stack pointer. + +@ifinfo +@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions +@end ifinfo +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + diff --git a/doc/supplements/m68k/cpumodel.t b/doc/supplements/m68k/cpumodel.t new file mode 100644 index 0000000000..becfcf123d --- /dev/null +++ b/doc/supplements/m68k/cpumodel.t @@ -0,0 +1,128 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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:: +* CPU Model Dependent Features BFFFO Instruction:: +* CPU Model Dependent Features Vector Base Register:: +* CPU Model Dependent Features Separate Stacks:: +* CPU Model Dependent Features Pre-Indexing Address Mode:: +* CPU Model Dependent Features Extend Byte to Long Instruction:: +@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 SPARC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +c/src/exec/score/cpu/m68k/m68k.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 MC68020 +processor, this macro is set to the string "mc68020". + +@ifinfo +@node CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features +@end ifinfo +@section Floating Point Unit + +The macro M68K_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. It does not matter whether the hardware floating +point support is incorporated on-chip or is an external +coprocessor. + +@ifinfo +@node CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features +@end ifinfo +@section BFFFO Instruction + +The macro M68K_HAS_BFFFO is set to 1 to indicate that +this CPU model has the bfffo instruction. + +@ifinfo +@node CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features +@end ifinfo +@section Vector Base Register + +The macro M68K_HAS_VBR is set to 1 to indicate that +this CPU model has a vector base register (vbr). + +@ifinfo +@node CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features +@end ifinfo +@section Separate Stacks + +The macro M68K_HAS_SEPARATE_STACKS is set to 1 to +indicate that this CPU model has separate interrupt, user, and +supervisor mode stacks. + +@ifinfo +@node CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features Extend Byte to Long Instruction, CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features +@end ifinfo +@section Pre-Indexing Address Mode + +The macro M68K_HAS_PREINDEXING is set to 1 to indicate that +this CPU model has the pre-indexing address mode. + +@ifinfo +@node CPU Model Dependent Features Extend Byte to Long Instruction, Calling Conventions, CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features +@end ifinfo +@section Extend Byte to Long Instruction + +The macro M68K_HAS_EXTB_L is set to 1 to indicate that this CPU model +has the extb.l instruction. This instruction is supposed to be available +in all models based on the cpu32 core as well as mc68020 and up models. diff --git a/doc/supplements/m68k/cputable.t b/doc/supplements/m68k/cputable.t new file mode 100644 index 0000000000..0119084d32 --- /dev/null +++ b/doc/supplements/m68k/cputable.t @@ -0,0 +1,118 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 MC68xxx version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the MC68xxx. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +struct cpu_configuration_table @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + m68k_isr *interrupt_vector_table; +@}; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the +user provided routine which is invoked once RTEMS initialization +is complete but before interrupts and tasking are enabled. This +field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately before +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +but no device drivers are initialized. This field may be NULL to +indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately after +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +and the device drivers are initialized. This field may be NULL +to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item interrupt_vector_table +is the base address of the CPU's Exception Vector Table. + +@end table diff --git a/doc/supplements/m68k/fatalerr.t b/doc/supplements/m68k/fatalerr.t new file mode 100644 index 0000000000..5b94c7a9c9 --- /dev/null +++ b/doc/supplements/m68k/fatalerr.t @@ -0,0 +1,44 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@ifinfo +@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing +@end ifinfo +@section Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts to +level 7, places the error code in D0, and executes a stop +instruction to simulate a halt processor instruction. + diff --git a/doc/supplements/m68k/intr_NOTIMES.t b/doc/supplements/m68k/intr_NOTIMES.t new file mode 100644 index 0000000000..07e51b0116 --- /dev/null +++ b/doc/supplements/m68k/intr_NOTIMES.t @@ -0,0 +1,230 @@ +@c +@c +@c Interrupt Stack Frame Picture +@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 an Interrupt Handler:: +* Interrupt Processing Interrupt Levels:: +* Interrupt Processing Disabling of Interrupts by RTEMS:: +* Interrupt Processing Interrupt Stack:: +@end menu +@end ifinfo + +@ifinfo +@node Interrupt Processing Introduction, Interrupt Processing Vectoring of an 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 for the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the current +execution state and results in a change in the execution stream. +Most processors require that an interrupt handler utilize some +special control mechanisms to return to the normal processing +stream. Although RTEMS hides many of the processor dependent +details of interrupt processing, it is important to understand +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the MC68xxx's +interrupt response and control mechanisms as they pertain to +RTEMS. + +@ifinfo +@node Interrupt Processing Vectoring of an Interrupt Handler, Models Without Separate Interrupt Stacks, Interrupt Processing Introduction, Interrupt Processing +@end ifinfo +@section Vectoring of an Interrupt Handler +@ifinfo +@menu +* Models Without Separate Interrupt Stacks:: +* Models With Separate Interrupt Stacks:: +@end menu +@end ifinfo + +Depending on whether or not the particular CPU +supports a separate interrupt stack, the MC68xxx family has two +different interrupt handling models. + +@ifinfo +@node Models Without Separate Interrupt Stacks, Models With Separate Interrupt Stacks, Interrupt Processing Vectoring of an Interrupt Handler, Interrupt Processing Vectoring of an Interrupt Handler +@end ifinfo +@subsection Models Without Separate Interrupt Stacks + +Upon receipt of an interrupt the MC68xxx family +members without separate interrupt stacks automatically perform +the following actions: + +@itemize @bullet +@item To Be Written +@end itemize + +@ifinfo +@node Models With Separate Interrupt Stacks, Interrupt Processing Interrupt Levels, Models Without Separate Interrupt Stacks, Interrupt Processing Vectoring of an Interrupt Handler +@end ifinfo +@subsection Models With Separate Interrupt Stacks + +Upon receipt of an interrupt the MC68xxx family +members with separate interrupt stacks automatically perform the +following actions: + +@itemize @bullet +@item saves the current status register (SR), + +@item clears the master/interrupt (M) bit of the SR to +indicate the switch from master state to interrupt state, + +@item sets the privilege mode to supervisor, + +@item suppresses tracing, + +@item sets the interrupt mask level equal to the level of the +interrupt being serviced, + +@item pushes an interrupt stack frame (ISF), which includes +the program counter (PC), the status register (SR), and the +format/exception vector offset (FVO) word, onto the supervisor +and interrupt stacks, + +@item switches the current stack to the interrupt stack and +vectors to an interrupt service routine (ISR). If the ISR was +installed with the interrupt_catch directive, then the RTEMS +interrupt handler will begin execution. The RTEMS interrupt +handler saves all registers which are not preserved according to +the calling conventions and invokes the application's ISR. +@end itemize + +A nested interrupt is processed similarly by these +CPU models with the exception that only a single ISF is placed +on the interrupt stack and the current stack need not be +switched. + +The FVO word in the Interrupt Stack Frame is examined +by RTEMS to determine when an outer most interrupt is being +exited. Since the FVO is used by RTEMS for this purpose, the +user application code MUST NOT modify this field. + +The following shows the Interrupt Stack Frame for +MC68xxx CPU models with separate interrupt stacks: + +@ifset use-ascii +@example +@group + +----------------------+ + | Status Register | 0x0 + +----------------------+ + | Program Counter High | 0x2 + +----------------------+ + | Program Counter Low | 0x4 + +----------------------+ + | Format/Vector Offset | 0x6 + +----------------------+ +@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 0.50in{\enskip\hfil#\hfil} +\cr +\multispan{3}\hrulefill\cr +& Status Register && 0x0\cr +\multispan{3}\hrulefill\cr +& Program Counter High && 0x2\cr +\multispan{3}\hrulefill\cr +& Program Counter Low && 0x4\cr +\multispan{3}\hrulefill\cr +& Format/Vector Offset && 0x6\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>Status Register</STRONG></TD> + <TD ALIGN=center>0x0</TD></TR> +<TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD> + <TD ALIGN=center>0x2</TD></TR> +<TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD> + <TD ALIGN=center>0x4</TD></TR> +<TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD> + <TD ALIGN=center>0x6</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +@ifinfo +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Models With Separate Interrupt Stacks, Interrupt Processing +@end ifinfo +@section Interrupt Levels + +Eight levels (0-7) of interrupt priorities are +supported by MC68xxx family members with level seven (7) 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 +MC68xxx family only supports eight. RTEMS interrupt levels 0 +through 7 directly correspond to MC68xxx interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@ifinfo +@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing +@end ifinfo +@section Disabling of Interrupts by RTEMS + +During the execution of directive calls, critical +sections of code may be executed. When these sections are +encountered, RTEMS disables interrupts to level seven (7) 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 MC68020 with +zero wait states. These numbers will vary based the +number of wait states and processor speed present on the target board. +[NOTE: The maximum period with interrupts disabled is hand calculated. This +calculation was last performed for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +Non-maskable interrupts (NMI) cannot be disabled, and +ISRs which execute at this level MUST NEVER issue RTEMS system +calls. If a directive is invoked, unpredictable results may +occur due to the inability of RTEMS to protect its critical +sections. However, ISRs that make no system calls may safely +execute as non-maskable interrupts. + +@ifinfo +@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing +@end ifinfo +@section Interrupt Stack + +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. + +The MC68xxx port of RTEMS supports a software managed +dedicated interrupt stack on those CPU models which do not +support a separate interrupt stack in hardware. + + diff --git a/doc/supplements/m68k/m68k.texi b/doc/supplements/m68k/m68k.texi new file mode 100644 index 0000000000..157dabb594 --- /dev/null +++ b/doc/supplements/m68k/m68k.texi @@ -0,0 +1,118 @@ +\input ../texinfo/texinfo @c -*-texinfo-*- +@c %**start of header +@setfilename c_m68k +@syncodeindex vr fn +@synindex ky cp +@paragraphindent 0 +@c @smallbook +@c %**end of header + +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@c +@c Master file for the Motorola MC68xxx C Applications Supplement +@c + +@include ../common/setup.texi + +@ignore +@ifinfo +@format +START-INFO-DIR-ENTRY +* RTEMS Motorola MC68xxx C Applications Supplement (m68k): +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 Motorola MC68xxx C Applications Supplement + +@setchapternewpage odd +@settitle RTEMS Motorola MC68xxx C Applications Supplement +@titlepage +@finalout + +@title RTEMS Motorola MC68xxx 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_m68k + +This is the online version of the RTEMS Motorola MC68xxx 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:: +* MC68020 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, MC68020 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/m68k/memmodel.t b/doc/supplements/m68k/memmodel.t new file mode 100644 index 0000000000..91ccf8010d --- /dev/null +++ b/doc/supplements/m68k/memmodel.t @@ -0,0 +1,52 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top +@end ifinfo +@chapter Memory Model +@ifinfo +@menu +* Memory Model Introduction:: +* Memory Model Flat Memory Model:: +@end menu +@end ifinfo + +@ifinfo +@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model +@end ifinfo +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@ifinfo +@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model +@end ifinfo +@section Flat Memory Model + +The MC68xxx family supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +is byte addressable. The address may be used to reference a +single byte, word (2-bytes), or long word (4 bytes). Memory +accesses within this address space are performed in big endian +fashion by the processors in this family. + +Some of the MC68xxx family members such as the +MC68020, MC68030, and MC68040 support virtual memory and +segmentation. The MC68020 requires external hardware support +such as the MC68851 Paged Memory Management Unit coprocessor +which is typically used to perform address translations for +these systems. RTEMS does not support virtual memory or +segmentation on any of the MC68xxx family members. + diff --git a/doc/supplements/m68k/preface.texi b/doc/supplements/m68k/preface.texi new file mode 100644 index 0000000000..e42754c347 --- /dev/null +++ b/doc/supplements/m68k/preface.texi @@ -0,0 +1,58 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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. + +This document discusses the Motorola MC68xxx +architecture dependencies in this port of RTEMS. The MC68xxx +family has a wide variety of CPU models within it. The part +numbers for these models are generally divided into MC680xx and +MC683xx. The MC680xx models are more general purpose processors +with no integrated peripherals. The MC683xx models, on the +other hand, are more specialized and have a variety of +peripherals on chip including sophisticated timers and serial +communications controllers. + +It is highly recommended that the Motorola MC68xxx +RTEMS application developer obtain and become familiar with the +documentation for the processor being used as well as the +documentation for the family as a whole. + +@subheading Architecture Documents + +For information on the Motorola MC68xxx architecture, +refer to the following documents available from Motorola +(@file{http//www.moto.com/}): + +@itemize @bullet +@item @cite{M68000 Family Reference, Motorola, FR68K/D}. +@end itemize + +@subheading MODEL SPECIFIC DOCUMENTS + +For information on specific processor models and +their associated coprocessors, refer to the following documents: + +@itemize @bullet +@item @cite{MC68020 User's Manual, Motorola, MC68020UM/AD}. + +@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's +Manual, Motorola, MC68881UM/AD}. +@end itemize + diff --git a/doc/supplements/m68k/timeMVME136.t b/doc/supplements/m68k/timeMVME136.t new file mode 100644 index 0000000000..fe99c38fef --- /dev/null +++ b/doc/supplements/m68k/timeMVME136.t @@ -0,0 +1,143 @@ + +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node MC68020 Timing Data, MC68020 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter MC68020 Timing Data +@ifinfo +@menu +* MC68020 Timing Data Introduction:: +* MC68020 Timing Data Hardware Platform:: +* MC68020 Timing Data Interrupt Latency:: +* MC68020 Timing Data Context Switch:: +* MC68020 Timing Data Directive Times:: +* MC68020 Timing Data Task Manager:: +* MC68020 Timing Data Interrupt Manager:: +* MC68020 Timing Data Clock Manager:: +* MC68020 Timing Data Timer Manager:: +* MC68020 Timing Data Semaphore Manager:: +* MC68020 Timing Data Message Manager:: +* MC68020 Timing Data Event Manager:: +* MC68020 Timing Data Signal Manager:: +* MC68020 Timing Data Partition Manager:: +* MC68020 Timing Data Region Manager:: +* MC68020 Timing Data Dual-Ported Memory Manager:: +* MC68020 Timing Data I/O Manager:: +* MC68020 Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +@ifinfo +@node MC68020 Timing Data Introduction, MC68020 Timing Data Hardware Platform, MC68020 Timing Data, MC68020 Timing Data +@end ifinfo +@section Introduction + +The timing data for the MC68020 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 MC68020 version of RTEMS. + +@ifinfo +@node MC68020 Timing Data Hardware Platform, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Introduction, MC68020 Timing Data +@end ifinfo +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Motorola +MVME135 CPU board. The MVME135 is a 20Mhz board with one wait +state dynamic memory and a MC68881 numeric coprocessor. The +Zilog 8036 countdown timer on this board was used to measure +elapsed time with a one-half microsecond resolution. All +sources of hardware interrupts were disabled, although the +interrupt level of the MC68020 allows all interrupts. + +The maximum period interrupts are disabled was +measured by summing the number of CPU cycles required by each +assembly language instruction executed while interrupts were +disabled. The worst case times of the MC68020 microprocessor +were used for each instruction. 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 20 to simulate a 20Mhz MC68020. It +should be noted that the worst case instruction times for the +MC68020 assume that the internal cache is disabled and that no +instructions overlap. + +@ifinfo +@node MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Context Switch, MC68020 Timing Data Hardware Platform, MC68020 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 MC68020 to vector an interrupt 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 at 20Mhz. [NOTE: The maximum period with interrupts +disabled was last determined for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +It should be noted again that the maximum period with +interrupts disabled within RTEMS is hand-timed and based upon +worst case (i.e. CPU cache disabled and no instruction overlap) +times for a 20Mhz MC68020. The interrupt vector and entry +overhead time was generated on an MVME135 benchmark platform +using the Multiprocessing Communications registers to generate +as the interrupt source. + +@ifinfo +@node MC68020 Timing Data Context Switch, MC68020 Timing Data Directive Times, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the MVME135 benchmark platform when no floating +point context is saved or restored. Additional execution time +is required when a TASK_SWITCH user extension is configured. +The use of the TASK_SWITCH extension is application dependent. +Thus, its execution time is not considered part of the raw +context switch time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. The state of +the numeric coprocessor is only saved when an FLOATING_POINT +task is dispatched and that task was not the last task to +utilize the coprocessor. In a system with only one +FLOATING_POINT task, the state of the numeric coprocessor will +never be saved or restored. When the first FLOATING_POINT task +is dispatched, RTEMS does not need to save the current state of +the numeric coprocessor. + +The exact amount of time required to save and restore +floating point context is dependent on whether an MC68881 or +MC68882 is being used as well as the state of the numeric +coprocessor. These numeric coprocessors define three operating +states: initialized, idle, and busy. RTEMS places the +coprocessor in the initialized state when a task is started or +restarted. Once the task has utilized the coprocessor, it is in +the idle state when floating point instructions are not +executing and the busy state when floating point instructions +are executing. The state of the coprocessor is task specific. + +The following table summarizes the context switch +times for the MVME135 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex diff --git a/doc/supplements/m68k/timedata.t b/doc/supplements/m68k/timedata.t new file mode 100644 index 0000000000..fe99c38fef --- /dev/null +++ b/doc/supplements/m68k/timedata.t @@ -0,0 +1,143 @@ + +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node MC68020 Timing Data, MC68020 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter MC68020 Timing Data +@ifinfo +@menu +* MC68020 Timing Data Introduction:: +* MC68020 Timing Data Hardware Platform:: +* MC68020 Timing Data Interrupt Latency:: +* MC68020 Timing Data Context Switch:: +* MC68020 Timing Data Directive Times:: +* MC68020 Timing Data Task Manager:: +* MC68020 Timing Data Interrupt Manager:: +* MC68020 Timing Data Clock Manager:: +* MC68020 Timing Data Timer Manager:: +* MC68020 Timing Data Semaphore Manager:: +* MC68020 Timing Data Message Manager:: +* MC68020 Timing Data Event Manager:: +* MC68020 Timing Data Signal Manager:: +* MC68020 Timing Data Partition Manager:: +* MC68020 Timing Data Region Manager:: +* MC68020 Timing Data Dual-Ported Memory Manager:: +* MC68020 Timing Data I/O Manager:: +* MC68020 Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +@ifinfo +@node MC68020 Timing Data Introduction, MC68020 Timing Data Hardware Platform, MC68020 Timing Data, MC68020 Timing Data +@end ifinfo +@section Introduction + +The timing data for the MC68020 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 MC68020 version of RTEMS. + +@ifinfo +@node MC68020 Timing Data Hardware Platform, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Introduction, MC68020 Timing Data +@end ifinfo +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Motorola +MVME135 CPU board. The MVME135 is a 20Mhz board with one wait +state dynamic memory and a MC68881 numeric coprocessor. The +Zilog 8036 countdown timer on this board was used to measure +elapsed time with a one-half microsecond resolution. All +sources of hardware interrupts were disabled, although the +interrupt level of the MC68020 allows all interrupts. + +The maximum period interrupts are disabled was +measured by summing the number of CPU cycles required by each +assembly language instruction executed while interrupts were +disabled. The worst case times of the MC68020 microprocessor +were used for each instruction. 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 20 to simulate a 20Mhz MC68020. It +should be noted that the worst case instruction times for the +MC68020 assume that the internal cache is disabled and that no +instructions overlap. + +@ifinfo +@node MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Context Switch, MC68020 Timing Data Hardware Platform, MC68020 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 MC68020 to vector an interrupt 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 at 20Mhz. [NOTE: The maximum period with interrupts +disabled was last determined for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +It should be noted again that the maximum period with +interrupts disabled within RTEMS is hand-timed and based upon +worst case (i.e. CPU cache disabled and no instruction overlap) +times for a 20Mhz MC68020. The interrupt vector and entry +overhead time was generated on an MVME135 benchmark platform +using the Multiprocessing Communications registers to generate +as the interrupt source. + +@ifinfo +@node MC68020 Timing Data Context Switch, MC68020 Timing Data Directive Times, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the MVME135 benchmark platform when no floating +point context is saved or restored. Additional execution time +is required when a TASK_SWITCH user extension is configured. +The use of the TASK_SWITCH extension is application dependent. +Thus, its execution time is not considered part of the raw +context switch time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. The state of +the numeric coprocessor is only saved when an FLOATING_POINT +task is dispatched and that task was not the last task to +utilize the coprocessor. In a system with only one +FLOATING_POINT task, the state of the numeric coprocessor will +never be saved or restored. When the first FLOATING_POINT task +is dispatched, RTEMS does not need to save the current state of +the numeric coprocessor. + +The exact amount of time required to save and restore +floating point context is dependent on whether an MC68881 or +MC68882 is being used as well as the state of the numeric +coprocessor. These numeric coprocessors define three operating +states: initialized, idle, and busy. RTEMS places the +coprocessor in the initialized state when a task is started or +restarted. Once the task has utilized the coprocessor, it is in +the idle state when floating point instructions are not +executing and the busy state when floating point instructions +are executing. The state of the coprocessor is task specific. + +The following table summarizes the context switch +times for the MVME135 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex diff --git a/doc/supplements/sparc/ERC32_TIMES b/doc/supplements/sparc/ERC32_TIMES new file mode 100644 index 0000000000..5edd01c56f --- /dev/null +++ b/doc/supplements/sparc/ERC32_TIMES @@ -0,0 +1,244 @@ +# +# SPARC/ERC32/SIS Timing and Size Information +# + +# +# CPU Model Information +# +RTEMS_CPU_MODEL ERC32 +# +# Interrupt Latency +# +# NOTE: In general, the text says it is hand-calculated to be +# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +# Mhz and this was last calculated for Release +# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. +# +RTEMS_MAXIMUM_DISABLE_PERIOD TBD +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 15.0 +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.5.17 +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 21 +RTEMS_RESTORE_1ST_FP_TASK 26 +RTEMS_SAVE_INIT_RESTORE_INIT 24 +RTEMS_SAVE_IDLE_RESTORE_INIT 23 +RTEMS_SAVE_IDLE_RESTORE_IDLE 33 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 59 +RTEMS_TASK_IDENT_ONLY 163 +RTEMS_TASK_START_ONLY 30 +RTEMS_TASK_RESTART_CALLING_TASK 64 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 36 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 47 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 37 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 77 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 84 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 75 +RTEMS_TASK_DELETE_CALLING_TASK 91 +RTEMS_TASK_DELETE_SUSPENDED_TASK 47 +RTEMS_TASK_DELETE_BLOCKED_TASK 50 +RTEMS_TASK_DELETE_READY_TASK 51 +RTEMS_TASK_SUSPEND_CALLING_TASK 56 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 16 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 17 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 52 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 10 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 25 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 67 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 5 +RTEMS_TASK_MODE_NO_RESCHEDULE 6 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 9 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 42 +RTEMS_TASK_GET_NOTE_ONLY 10 +RTEMS_TASK_SET_NOTE_ONLY 10 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 6 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 49 +RTEMS_TASK_WAKE_WHEN_ONLY 75 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 7 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 8 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 8 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED 5 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 7 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 14 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 33 +RTEMS_CLOCK_GET_ONLY 4 +RTEMS_CLOCK_TICK_ONLY 6 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 11 +RTEMS_TIMER_IDENT_ONLY 159 +RTEMS_TIMER_DELETE_INACTIVE 15 +RTEMS_TIMER_DELETE_ACTIVE 17 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 21 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 23 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 34 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 34 +RTEMS_TIMER_RESET_INACTIVE 20 +RTEMS_TIMER_RESET_ACTIVE 22 +RTEMS_TIMER_CANCEL_INACTIVE 10 +RTEMS_TIMER_CANCEL_ACTIVE 13 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 19 +RTEMS_SEMAPHORE_IDENT_ONLY 171 +RTEMS_SEMAPHORE_DELETE_ONLY 19 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 12 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 12 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 67 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 14 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 23 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 57 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 114 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 159 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 25 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 36 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 38 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 76 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 36 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 38 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 76 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 15 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 42 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 83 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 30 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 13 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 67 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 9 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 13 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 9 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 22 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 58 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 +RTEMS_EVENT_RECEIVE_AVAILABLE 10 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 9 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 60 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 6 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 14 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 22 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 27 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 56 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 34 +RTEMS_PARTITION_IDENT_ONLY 159 +RTEMS_PARTITION_DELETE_ONLY 14 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 12 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 16 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 22 +RTEMS_REGION_IDENT_ONLY 162 +RTEMS_REGION_DELETE_ONLY 14 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 19 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 19 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 67 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 17 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 44 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 77 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 14 +RTEMS_PORT_IDENT_ONLY 159 +RTEMS_PORT_DELETE_ONLY 13 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 9 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 9 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 2 +RTEMS_IO_OPEN_ONLY 1 +RTEMS_IO_CLOSE_ONLY 1 +RTEMS_IO_READ_ONLY 1 +RTEMS_IO_WRITE_ONLY 1 +RTEMS_IO_CONTROL_ONLY 1 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 12 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 159 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 14 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 19 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 16 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 20 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 55 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 9 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 9059 +RTEMS_MINIMUM_CONFIGURATION 28,288 +RTEMS_MAXIMUM_CONFIGURATION 50,432 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE 20,336 +RTEMS_INITIALIZATION_CODE_SIZE 1,408 +RTEMS_TASK_CODE_SIZE 4,496 +RTEMS_INTERRUPT_CODE_SIZE 72 +RTEMS_CLOCK_CODE_SIZE 576 +RTEMS_TIMER_CODE_SIZE 1,336 +RTEMS_SEMAPHORE_CODE_SIZE 1,888 +RTEMS_MESSAGE_CODE_SIZE 2,032 +RTEMS_EVENT_CODE_SIZE 1,696 +RTEMS_SIGNAL_CODE_SIZE 664 +RTEMS_PARTITION_CODE_SIZE 1,368 +RTEMS_REGION_CODE_SIZE 1,736 +RTEMS_DPMEM_CODE_SIZE 872 +RTEMS_IO_CODE_SIZE 1,144 +RTEMS_FATAL_ERROR_CODE_SIZE 32 +RTEMS_RATE_MONOTONIC_CODE_SIZE 1,656 +RTEMS_MULTIPROCESSING_CODE_SIZE 8,328 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 208 +RTEMS_SEMAPHORE_CODE_OPTSIZE 192 +RTEMS_MESSAGE_CODE_OPTSIZE 320 +RTEMS_EVENT_CODE_OPTSIZE 64 +RTEMS_SIGNAL_CODE_OPTSIZE 64 +RTEMS_PARTITION_CODE_OPTSIZE 152 +RTEMS_REGION_CODE_OPTSIZE 176 +RTEMS_DPMEM_CODE_OPTSIZE 152 +RTEMS_IO_CODE_OPTSIZE 0 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 208 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 408 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 488 +RTEMS_BYTES_PER_TIMER 68 +RTEMS_BYTES_PER_SEMAPHORE 124 +RTEMS_BYTES_PER_MESSAGE_QUEUE 148 +RTEMS_BYTES_PER_REGION 144 +RTEMS_BYTES_PER_PARTITION 56 +RTEMS_BYTES_PER_PORT 36 +RTEMS_BYTES_PER_PERIOD 36 +RTEMS_BYTES_PER_EXTENSION 64 +RTEMS_BYTES_PER_FP_TASK 136 +RTEMS_BYTES_PER_NODE 48 +RTEMS_BYTES_PER_GLOBAL_OBJECT 20 +RTEMS_BYTES_PER_PROXY 124 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10,072 diff --git a/doc/supplements/sparc/Makefile b/doc/supplements/sparc/Makefile new file mode 100644 index 0000000000..510ab94d83 --- /dev/null +++ b/doc/supplements/sparc/Makefile @@ -0,0 +1,90 @@ +# +# COPYRIGHT (c) 1996. +# On-Line Applications Research Corporation (OAR). +# All rights reserved. +# + +include ../Make.config + +PROJECT=sparc +REPLACE=../tools/word-replace + +all: + +COMMON_FILES=../common/cpright.texi ../common/setup.texi \ + ../common/timing.texi + +FILES= $(PROJECT).texi \ + bsp.texi callconv.texi cpumodel.texi cputable.texi fatalerr.texi \ + intr.texi memmodel.texi preface.texi timetbl.texi timedata.texi wksheets.texi + +all: + +INFOFILES=$(wildcard $(PROJECT) $(PROJECT)-*) + +info: c_sparc + cp c_$(PROJECT) c_$(PROJECT)-* $(INFO_INSTALL) + +c_sparc: $(FILES) + $(MAKEINFO) $(PROJECT).texi + +vinfo: info + $(INFO) -f c_sparc + +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 SIS_TIMES + ${REPLACE} -p SIS_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 SIS_TIMES + ${REPLACE} -p SIS_TIMES timetbl.t + mv timetbl.t.fixed timetbl.texi + +timedata.texi: timedata.t SIS_TIMES + ${REPLACE} -p SIS_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/ERC32 Timing Data/' \ + <../common/wksheets.t >wksheets.t + +wksheets.texi: wksheets.t SIS_TIMES + ${REPLACE} -p SIS_TIMES wksheets.t + mv wksheets.t.fixed wksheets.texi + +html: $(FILES) + -mkdir $(WWW_INSTALL)/c_sparc + $(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_sparc c_sparc-* + rm -f timedata.texi timetbl.texi intr.texi wksheets.texi + rm -f timetbl.t wksheets.t + rm -f *.fixed _* + diff --git a/doc/supplements/sparc/SIS_TIMES b/doc/supplements/sparc/SIS_TIMES new file mode 100644 index 0000000000..5edd01c56f --- /dev/null +++ b/doc/supplements/sparc/SIS_TIMES @@ -0,0 +1,244 @@ +# +# SPARC/ERC32/SIS Timing and Size Information +# + +# +# CPU Model Information +# +RTEMS_CPU_MODEL ERC32 +# +# Interrupt Latency +# +# NOTE: In general, the text says it is hand-calculated to be +# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +# Mhz and this was last calculated for Release +# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. +# +RTEMS_MAXIMUM_DISABLE_PERIOD TBD +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 15.0 +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.5.17 +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 21 +RTEMS_RESTORE_1ST_FP_TASK 26 +RTEMS_SAVE_INIT_RESTORE_INIT 24 +RTEMS_SAVE_IDLE_RESTORE_INIT 23 +RTEMS_SAVE_IDLE_RESTORE_IDLE 33 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 59 +RTEMS_TASK_IDENT_ONLY 163 +RTEMS_TASK_START_ONLY 30 +RTEMS_TASK_RESTART_CALLING_TASK 64 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 36 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 47 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 37 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 77 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 84 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 75 +RTEMS_TASK_DELETE_CALLING_TASK 91 +RTEMS_TASK_DELETE_SUSPENDED_TASK 47 +RTEMS_TASK_DELETE_BLOCKED_TASK 50 +RTEMS_TASK_DELETE_READY_TASK 51 +RTEMS_TASK_SUSPEND_CALLING_TASK 56 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 16 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 17 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 52 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 10 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 25 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 67 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 5 +RTEMS_TASK_MODE_NO_RESCHEDULE 6 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 9 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 42 +RTEMS_TASK_GET_NOTE_ONLY 10 +RTEMS_TASK_SET_NOTE_ONLY 10 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 6 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 49 +RTEMS_TASK_WAKE_WHEN_ONLY 75 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 7 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 8 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 8 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED 5 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 7 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 14 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 33 +RTEMS_CLOCK_GET_ONLY 4 +RTEMS_CLOCK_TICK_ONLY 6 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 11 +RTEMS_TIMER_IDENT_ONLY 159 +RTEMS_TIMER_DELETE_INACTIVE 15 +RTEMS_TIMER_DELETE_ACTIVE 17 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 21 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 23 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 34 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 34 +RTEMS_TIMER_RESET_INACTIVE 20 +RTEMS_TIMER_RESET_ACTIVE 22 +RTEMS_TIMER_CANCEL_INACTIVE 10 +RTEMS_TIMER_CANCEL_ACTIVE 13 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 19 +RTEMS_SEMAPHORE_IDENT_ONLY 171 +RTEMS_SEMAPHORE_DELETE_ONLY 19 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 12 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 12 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 67 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 14 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 23 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 57 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 114 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 159 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 25 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 36 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 38 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 76 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 36 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 38 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 76 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 15 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 42 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 83 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 30 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 13 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 67 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 9 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 13 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 9 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 22 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 58 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 +RTEMS_EVENT_RECEIVE_AVAILABLE 10 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 9 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 60 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 6 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 14 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 22 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 27 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 56 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 34 +RTEMS_PARTITION_IDENT_ONLY 159 +RTEMS_PARTITION_DELETE_ONLY 14 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 12 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 16 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 22 +RTEMS_REGION_IDENT_ONLY 162 +RTEMS_REGION_DELETE_ONLY 14 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 19 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 19 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 67 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 17 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 44 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 77 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 14 +RTEMS_PORT_IDENT_ONLY 159 +RTEMS_PORT_DELETE_ONLY 13 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 9 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 9 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 2 +RTEMS_IO_OPEN_ONLY 1 +RTEMS_IO_CLOSE_ONLY 1 +RTEMS_IO_READ_ONLY 1 +RTEMS_IO_WRITE_ONLY 1 +RTEMS_IO_CONTROL_ONLY 1 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 12 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 159 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 14 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 19 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 16 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 20 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 55 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 9 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 9059 +RTEMS_MINIMUM_CONFIGURATION 28,288 +RTEMS_MAXIMUM_CONFIGURATION 50,432 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE 20,336 +RTEMS_INITIALIZATION_CODE_SIZE 1,408 +RTEMS_TASK_CODE_SIZE 4,496 +RTEMS_INTERRUPT_CODE_SIZE 72 +RTEMS_CLOCK_CODE_SIZE 576 +RTEMS_TIMER_CODE_SIZE 1,336 +RTEMS_SEMAPHORE_CODE_SIZE 1,888 +RTEMS_MESSAGE_CODE_SIZE 2,032 +RTEMS_EVENT_CODE_SIZE 1,696 +RTEMS_SIGNAL_CODE_SIZE 664 +RTEMS_PARTITION_CODE_SIZE 1,368 +RTEMS_REGION_CODE_SIZE 1,736 +RTEMS_DPMEM_CODE_SIZE 872 +RTEMS_IO_CODE_SIZE 1,144 +RTEMS_FATAL_ERROR_CODE_SIZE 32 +RTEMS_RATE_MONOTONIC_CODE_SIZE 1,656 +RTEMS_MULTIPROCESSING_CODE_SIZE 8,328 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 208 +RTEMS_SEMAPHORE_CODE_OPTSIZE 192 +RTEMS_MESSAGE_CODE_OPTSIZE 320 +RTEMS_EVENT_CODE_OPTSIZE 64 +RTEMS_SIGNAL_CODE_OPTSIZE 64 +RTEMS_PARTITION_CODE_OPTSIZE 152 +RTEMS_REGION_CODE_OPTSIZE 176 +RTEMS_DPMEM_CODE_OPTSIZE 152 +RTEMS_IO_CODE_OPTSIZE 0 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 208 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 408 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 488 +RTEMS_BYTES_PER_TIMER 68 +RTEMS_BYTES_PER_SEMAPHORE 124 +RTEMS_BYTES_PER_MESSAGE_QUEUE 148 +RTEMS_BYTES_PER_REGION 144 +RTEMS_BYTES_PER_PARTITION 56 +RTEMS_BYTES_PER_PORT 36 +RTEMS_BYTES_PER_PERIOD 36 +RTEMS_BYTES_PER_EXTENSION 64 +RTEMS_BYTES_PER_FP_TASK 136 +RTEMS_BYTES_PER_NODE 48 +RTEMS_BYTES_PER_GLOBAL_OBJECT 20 +RTEMS_BYTES_PER_PROXY 124 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10,072 diff --git a/doc/supplements/sparc/bsp.t b/doc/supplements/sparc/bsp.t new file mode 100644 index 0000000000..78ffa3ac26 --- /dev/null +++ b/doc/supplements/sparc/bsp.t @@ -0,0 +1,103 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 SPARC 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 or +re-initiated when the SPARC processor is reset. When the SPARC +is reset, the processor performs the following actions: + +@itemize @bullet +@item the enable trap (ET) of the psr is set to 0 to disable +traps, + +@item the supervisor bit (S) of the psr is set to 1 to enter +supervisor mode, and + +@item the PC is set 0 and the nPC is set to 4. +@end itemize + +The processor then begins to execute the code at +location 0. It is important to note that all fields in the psr +are not explicitly set by the above steps and all other +registers retain their value from the previous execution mode. +This is true even of the Trap Base Register (TBR) whose contents +reflect the last trap which occurred before the reset. + +@ifinfo +@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages +@end ifinfo +@section Processor Initialization + +It is the responsibility of the application's +initialization code to initialize the TBR and install trap +handlers for at least the register window overflow and register +window underflow conditions. Traps should be enabled before +invoking any subroutines to allow for register window +management. However, interrupts should be disabled by setting +the Processor Interrupt Level (pil) field of the psr to 15. +RTEMS installs it's own Trap Table as part of initialization +which is initialized with the contents of the Trap Table in +place when the rtems_initialize_executive directive was invoked. +Upon completion of executive initialization, interrupts are +enabled. + +If this SPARC implementation supports on-chip caching +and this is to be utilized, then it should be enabled during the +reset application initialization code. + +In addition to the requirements described in the +Board Support Packages chapter of the C Applications User's +Manual for the reset code which is executed before the call to +rtems_initialize executive, the SPARC version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the SPARC remains in the supervisor state. + +@item Must set stack pointer (sp) such that a minimum stack +size of MINIMUM_STACK_SIZE bytes is provided for the +rtems_initialize executive directive. + +@item Must disable all external interrupts (i.e. set the pil +to 15). + +@item Must enable traps so window overflow and underflow +conditions can be properly handled. + +@item Must initialize the SPARC's initial trap table with at +least trap handlers for register window overflow and register +window underflow. +@end itemize + diff --git a/doc/supplements/sparc/bsp.texi b/doc/supplements/sparc/bsp.texi new file mode 100644 index 0000000000..78ffa3ac26 --- /dev/null +++ b/doc/supplements/sparc/bsp.texi @@ -0,0 +1,103 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 SPARC 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 or +re-initiated when the SPARC processor is reset. When the SPARC +is reset, the processor performs the following actions: + +@itemize @bullet +@item the enable trap (ET) of the psr is set to 0 to disable +traps, + +@item the supervisor bit (S) of the psr is set to 1 to enter +supervisor mode, and + +@item the PC is set 0 and the nPC is set to 4. +@end itemize + +The processor then begins to execute the code at +location 0. It is important to note that all fields in the psr +are not explicitly set by the above steps and all other +registers retain their value from the previous execution mode. +This is true even of the Trap Base Register (TBR) whose contents +reflect the last trap which occurred before the reset. + +@ifinfo +@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages +@end ifinfo +@section Processor Initialization + +It is the responsibility of the application's +initialization code to initialize the TBR and install trap +handlers for at least the register window overflow and register +window underflow conditions. Traps should be enabled before +invoking any subroutines to allow for register window +management. However, interrupts should be disabled by setting +the Processor Interrupt Level (pil) field of the psr to 15. +RTEMS installs it's own Trap Table as part of initialization +which is initialized with the contents of the Trap Table in +place when the rtems_initialize_executive directive was invoked. +Upon completion of executive initialization, interrupts are +enabled. + +If this SPARC implementation supports on-chip caching +and this is to be utilized, then it should be enabled during the +reset application initialization code. + +In addition to the requirements described in the +Board Support Packages chapter of the C Applications User's +Manual for the reset code which is executed before the call to +rtems_initialize executive, the SPARC version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the SPARC remains in the supervisor state. + +@item Must set stack pointer (sp) such that a minimum stack +size of MINIMUM_STACK_SIZE bytes is provided for the +rtems_initialize executive directive. + +@item Must disable all external interrupts (i.e. set the pil +to 15). + +@item Must enable traps so window overflow and underflow +conditions can be properly handled. + +@item Must initialize the SPARC's initial trap table with at +least trap handlers for register window overflow and register +window underflow. +@end itemize + diff --git a/doc/supplements/sparc/callconv.t b/doc/supplements/sparc/callconv.t new file mode 100644 index 0000000000..fd9b9a5846 --- /dev/null +++ b/doc/supplements/sparc/callconv.t @@ -0,0 +1,445 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top +@end ifinfo +@chapter Calling Conventions +@ifinfo +@menu +* Calling Conventions Introduction:: +* Calling Conventions Programming Model:: +* Calling Conventions Register Windows:: +* Calling Conventions Call and Return Mechanism:: +* Calling Conventions Calling Mechanism:: +* Calling Conventions Register Usage:: +* Calling Conventions Parameter Passing:: +* Calling Conventions User-Provided Routines:: +@end menu +@end ifinfo + +@ifinfo +@node Calling Conventions Introduction, Calling Conventions Programming Model, Calling Conventions, Calling Conventions +@end ifinfo +@section Introduction + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage + +@item parameter passing + +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@ifinfo +@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions +@end ifinfo +@section Programming Model +@ifinfo +@menu +* Non-Floating Point Registers:: +* Floating Point Registers:: +* Special Registers:: +@end menu +@end ifinfo + +This section discusses the programming model for the +SPARC architecture. + +@ifinfo +@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model +@end ifinfo +@subsection Non-Floating Point Registers + +The SPARC architecture defines thirty-two +non-floating point registers directly visible to the programmer. +These are divided into four sets: + +@itemize @bullet +@item input registers + +@item local registers + +@item output registers + +@item global registers +@end itemize + +Each register is referred to by either two or three +names in the SPARC reference manuals. First, the registers are +referred to as r0 through r31 or with the alternate notation +r[0] through r[31]. Second, each register is a member of one of +the four sets listed above. Finally, some registers have an +architecturally defined role in the programming model which +provides an alternate name. The following table describes the +mapping between the 32 registers and the register sets: + +@ifset use-ascii +@example +@group + +-----------------+----------------+------------------+ + | Register Number | Register Names | Description | + +-----------------+----------------+------------------+ + | 0 - 7 | g0 - g7 | Global Registers | + +-----------------+----------------+------------------+ + | 8 - 15 | o0 - o7 | Output Registers | + +-----------------+----------------+------------------+ + | 16 - 23 | l0 - l7 | Local Registers | + +-----------------+----------------+------------------+ + | 24 - 31 | i0 - i7 | Input Registers | + +-----------------+----------------+------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} +&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} +&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} +&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} +&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +<CENTER> + <TABLE COLS=3 WIDTH="80%" BORDER=2> +<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD> + <TD ALIGN=center><STRONG>Register Names</STRONG></TD> + <TD ALIGN=center><STRONG>Description</STRONG></TD> +<TR><TD ALIGN=center>0 - 7</TD> + <TD ALIGN=center>g0 - g7</TD> + <TD ALIGN=center>Global Registers</TD></TR> +<TR><TD ALIGN=center>8 - 15</TD> + <TD ALIGN=center>o0 - o7</TD> + <TD ALIGN=center>Output Registers</TD></TR> +<TR><TD ALIGN=center>16 - 23</TD> + <TD ALIGN=center>l0 - l7</TD> + <TD ALIGN=center>Local Registers</TD></TR> +<TR><TD ALIGN=center>24 - 31</TD> + <TD ALIGN=center>i0 - i7</TD> + <TD ALIGN=center>Input Registers</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +As mentioned above, some of the registers serve +defined roles in the programming model. The following table +describes the role of each of these registers: + +@ifset use-ascii +@example +@group + +---------------+----------------+----------------------+ + | Register Name | Alternate Name | Description | + +---------------+----------------+----------------------+ + | g0 | na | reads return 0 | + | | | writes are ignored | + +---------------+----------------+----------------------+ + | o6 | sp | stack pointer | + +---------------+----------------+----------------------+ + | i6 | fp | frame pointer | + +---------------+----------------+----------------------+ + | i7 | na | return address | + +---------------+----------------+----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} +&g0&&NA&&reads return 0; &\cr +&&&&&writes are ignored&\cr\noalign{\hrule} +&o6&&sp&&stack pointer&\cr\noalign{\hrule} +&i6&&fp&&frame pointer&\cr\noalign{\hrule} +&i7&&NA&&return address&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +<CENTER> + <TABLE COLS=3 WIDTH="80%" BORDER=2> +<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD> + <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD> + <TD ALIGN=center><STRONG>Description</STRONG></TD></TR> +<TR><TD ALIGN=center>g0</TD> + <TD ALIGN=center>NA</TD> + <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR> +<TR><TD ALIGN=center>o6</TD> + <TD ALIGN=center>sp</TD> + <TD ALIGN=center>stack pointer</TD></TR> +<TR><TD ALIGN=center>i6</TD> + <TD ALIGN=center>fp</TD> + <TD ALIGN=center>frame pointer</TD></TR> +<TR><TD ALIGN=center>i7</TD> + <TD ALIGN=center>NA</TD> + <TD ALIGN=center>return address</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + + +@ifinfo +@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model +@end ifinfo +@subsection Floating Point Registers + +The SPARC V7 architecture includes thirty-two, +thirty-two bit registers. These registers may be viewed as +follows: + +@itemize @bullet +@item 32 single precision floating point or integer registers +(f0, f1, ... f31) + +@item 16 double precision floating point registers (f0, f2, +f4, ... f30) + +@item 8 extended precision floating point registers (f0, f4, +f8, ... f28) +@end itemize + +The floating point status register (fpsr) specifies +the behavior of the floating point unit for rounding, contains +its condition codes, version specification, and trap information. + +A queue of the floating point instructions which have +started execution but not yet completed is maintained. This +queue is needed to support the multiple cycle nature of floating +point operations and to aid floating point exception trap +handlers. Once a floating point exception has been encountered, +the queue is frozen until it is emptied by the trap handler. +The floating point queue is loaded by launching instructions. +It is emptied normally when the floating point completes all +outstanding instructions and by floating point exception +handlers with the store double floating point queue (stdfq) +instruction. + +@ifinfo +@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model +@end ifinfo +@subsection Special Registers + +The SPARC architecture includes two special registers +which are critical to the programming model: the Processor State +Register (psr) and the Window Invalid Mask (wim). The psr +contains the condition codes, processor interrupt level, trap +enable bit, supervisor mode and previous supervisor mode bits, +version information, floating point unit and coprocessor enable +bits, and the current window pointer (cwp). The cwp field of +the psr and wim register are used to manage the register windows +in the SPARC architecture. The register windows are discussed +in more detail below. + +@ifinfo +@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions +@end ifinfo +@section Register Windows + +The SPARC architecture includes the concept of +register windows. An overly simplistic way to think of these +windows is to imagine them as being an infinite supply of +"fresh" register sets available for each subroutine to use. In +reality, they are much more complicated. + +The save instruction is used to obtain a new register +window. This instruction decrements the current window pointer, +thus providing a new set of registers for use. This register +set includes eight fresh local registers for use exclusively by +this subroutine. When done with a register set, the restore +instruction increments the current window pointer and the +previous register set is once again available. + +The two primary issues complicating the use of +register windows are that (1) the set of register windows is +finite, and (2) some registers are shared between adjacent +registers windows. + +Because the set of register windows is finite, it is +possible to execute enough save instructions without +corresponding restore's to consume all of the register windows. +This is easily accomplished in a high level language because +each subroutine typically performs a save instruction upon +entry. Thus having a subroutine call depth greater than the +number of register windows will result in a window overflow +condition. The window overflow condition generates a trap which +must be handled in software. The window overflow trap handler +is responsible for saving the contents of the oldest register +window on the program stack. + +Similarly, the subroutines will eventually complete +and begin to perform restore's. If the restore results in the +need for a register window which has previously been written to +memory as part of an overflow, then a window underflow condition +results. Just like the window overflow, the window underflow +condition must be handled in software by a trap handler. The +window underflow trap handler is responsible for reloading the +contents of the register window requested by the restore +instruction from the program stack. + +The Window Invalid Mask (wim) and the Current Window +Pointer (cwp) field in the psr are used in conjunction to manage +the finite set of register windows and detect the window +overflow and underflow conditions. The cwp contains the index +of the register window currently in use. The save instruction +decrements the cwp modulo the number of register windows. +Similarly, the restore instruction increments the cwp modulo the +number of register windows. Each bit in the wim represents +represents whether a register window contains valid information. +The value of 0 indicates the register window is valid and 1 +indicates it is invalid. When a save instruction causes the cwp +to point to a register window which is marked as invalid, a +window overflow condition results. Conversely, the restore +instruction may result in a window underflow condition. + +Other than the assumption that a register window is +always available for trap (i.e. interrupt) handlers, the SPARC +architecture places no limits on the number of register windows +simultaneously marked as invalid (i.e. number of bits set in the +wim). However, RTEMS assumes that only one register window is +marked invalid at a time (i.e. only one bit set in the wim). +This makes the maximum possible number of register windows +available to the user while still meeting the requirement that +window overflow and underflow conditions can be detected. + +The window overflow and window underflow trap +handlers are a critical part of the run-time environment for a +SPARC application. The SPARC architectural specification allows +for the number of register windows to be any power of two less +than or equal to 32. The most common choice for SPARC +implementations appears to be 8 register windows. This results +in the cwp ranging in value from 0 to 7 on most implementations. + + +The second complicating factor is the sharing of +registers between adjacent register windows. While each +register window has its own set of local registers, the input +and output registers are shared between adjacent windows. The +output registers for register window N are the same as the input +registers for register window ((N - 1) modulo RW) where RW is +the number of register windows. An alternative way to think of +this is to remember how parameters are passed to a subroutine on +the SPARC. The caller loads values into what are its output +registers. Then after the callee executes a save instruction, +those parameters are available in its input registers. This is +a very efficient way to pass parameters as no data is actually +moved by the save or restore instructions. + +@ifinfo +@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions +@end ifinfo +@section Call and Return Mechanism + +The SPARC architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the call (call) instruction. This instruction places the +return address in the caller's output register 7 (o7). After +the callee executes a save instruction, this value is available +in input register 7 (i7) until the corresponding restore +instruction is executed. + +The callee returns to the caller via a jmp to the +return address. There is a delay slot following this +instruction which is commonly used to execute a restore +instruction -- if a register window was allocated by this +subroutine. + +It is important to note that the SPARC subroutine +call and return mechanism does not automatically save and +restore any registers. This is accomplished via the save and +restore instructions which manage the set of registers windows. + +@ifinfo +@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions +@end ifinfo +@section Calling Mechanism + +All RTEMS directives are invoked using the regular +SPARC calling convention via the call instruction. + +@ifinfo +@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions +@end ifinfo +@section Register Usage + +As discussed above, the call instruction does not +automatically save any registers. The save and restore +instructions are used to allocate and deallocate register +windows. When a register window is allocated, the new set of +local registers are available for the exclusive use of the +subroutine which allocated this register set. + +@ifinfo +@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions +@end ifinfo +@section Parameter Passing + +RTEMS assumes that arguments are placed in the +caller's output registers with the first argument in output +register 0 (o0), the second argument in output register 1 (o1), +and so forth. Until the callee executes a save instruction, the +parameters are still visible in the output registers. After the +callee executes a save instruction, the parameters are visible +in the corresponding input registers. The following pseudo-code +illustrates the typical sequence used to call a RTEMS directive +with three (3) arguments: + +@example +load third argument into o2 +load second argument into o1 +load first argument into o0 +invoke directive +@end example + +@ifinfo +@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions +@end ifinfo +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + diff --git a/doc/supplements/sparc/callconv.texi b/doc/supplements/sparc/callconv.texi new file mode 100644 index 0000000000..fd9b9a5846 --- /dev/null +++ b/doc/supplements/sparc/callconv.texi @@ -0,0 +1,445 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top +@end ifinfo +@chapter Calling Conventions +@ifinfo +@menu +* Calling Conventions Introduction:: +* Calling Conventions Programming Model:: +* Calling Conventions Register Windows:: +* Calling Conventions Call and Return Mechanism:: +* Calling Conventions Calling Mechanism:: +* Calling Conventions Register Usage:: +* Calling Conventions Parameter Passing:: +* Calling Conventions User-Provided Routines:: +@end menu +@end ifinfo + +@ifinfo +@node Calling Conventions Introduction, Calling Conventions Programming Model, Calling Conventions, Calling Conventions +@end ifinfo +@section Introduction + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage + +@item parameter passing + +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@ifinfo +@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions +@end ifinfo +@section Programming Model +@ifinfo +@menu +* Non-Floating Point Registers:: +* Floating Point Registers:: +* Special Registers:: +@end menu +@end ifinfo + +This section discusses the programming model for the +SPARC architecture. + +@ifinfo +@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model +@end ifinfo +@subsection Non-Floating Point Registers + +The SPARC architecture defines thirty-two +non-floating point registers directly visible to the programmer. +These are divided into four sets: + +@itemize @bullet +@item input registers + +@item local registers + +@item output registers + +@item global registers +@end itemize + +Each register is referred to by either two or three +names in the SPARC reference manuals. First, the registers are +referred to as r0 through r31 or with the alternate notation +r[0] through r[31]. Second, each register is a member of one of +the four sets listed above. Finally, some registers have an +architecturally defined role in the programming model which +provides an alternate name. The following table describes the +mapping between the 32 registers and the register sets: + +@ifset use-ascii +@example +@group + +-----------------+----------------+------------------+ + | Register Number | Register Names | Description | + +-----------------+----------------+------------------+ + | 0 - 7 | g0 - g7 | Global Registers | + +-----------------+----------------+------------------+ + | 8 - 15 | o0 - o7 | Output Registers | + +-----------------+----------------+------------------+ + | 16 - 23 | l0 - l7 | Local Registers | + +-----------------+----------------+------------------+ + | 24 - 31 | i0 - i7 | Input Registers | + +-----------------+----------------+------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} +&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} +&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} +&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} +&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +<CENTER> + <TABLE COLS=3 WIDTH="80%" BORDER=2> +<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD> + <TD ALIGN=center><STRONG>Register Names</STRONG></TD> + <TD ALIGN=center><STRONG>Description</STRONG></TD> +<TR><TD ALIGN=center>0 - 7</TD> + <TD ALIGN=center>g0 - g7</TD> + <TD ALIGN=center>Global Registers</TD></TR> +<TR><TD ALIGN=center>8 - 15</TD> + <TD ALIGN=center>o0 - o7</TD> + <TD ALIGN=center>Output Registers</TD></TR> +<TR><TD ALIGN=center>16 - 23</TD> + <TD ALIGN=center>l0 - l7</TD> + <TD ALIGN=center>Local Registers</TD></TR> +<TR><TD ALIGN=center>24 - 31</TD> + <TD ALIGN=center>i0 - i7</TD> + <TD ALIGN=center>Input Registers</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +As mentioned above, some of the registers serve +defined roles in the programming model. The following table +describes the role of each of these registers: + +@ifset use-ascii +@example +@group + +---------------+----------------+----------------------+ + | Register Name | Alternate Name | Description | + +---------------+----------------+----------------------+ + | g0 | na | reads return 0 | + | | | writes are ignored | + +---------------+----------------+----------------------+ + | o6 | sp | stack pointer | + +---------------+----------------+----------------------+ + | i6 | fp | frame pointer | + +---------------+----------------+----------------------+ + | i7 | na | return address | + +---------------+----------------+----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} +&g0&&NA&&reads return 0; &\cr +&&&&&writes are ignored&\cr\noalign{\hrule} +&o6&&sp&&stack pointer&\cr\noalign{\hrule} +&i6&&fp&&frame pointer&\cr\noalign{\hrule} +&i7&&NA&&return address&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +<CENTER> + <TABLE COLS=3 WIDTH="80%" BORDER=2> +<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD> + <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD> + <TD ALIGN=center><STRONG>Description</STRONG></TD></TR> +<TR><TD ALIGN=center>g0</TD> + <TD ALIGN=center>NA</TD> + <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR> +<TR><TD ALIGN=center>o6</TD> + <TD ALIGN=center>sp</TD> + <TD ALIGN=center>stack pointer</TD></TR> +<TR><TD ALIGN=center>i6</TD> + <TD ALIGN=center>fp</TD> + <TD ALIGN=center>frame pointer</TD></TR> +<TR><TD ALIGN=center>i7</TD> + <TD ALIGN=center>NA</TD> + <TD ALIGN=center>return address</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + + +@ifinfo +@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model +@end ifinfo +@subsection Floating Point Registers + +The SPARC V7 architecture includes thirty-two, +thirty-two bit registers. These registers may be viewed as +follows: + +@itemize @bullet +@item 32 single precision floating point or integer registers +(f0, f1, ... f31) + +@item 16 double precision floating point registers (f0, f2, +f4, ... f30) + +@item 8 extended precision floating point registers (f0, f4, +f8, ... f28) +@end itemize + +The floating point status register (fpsr) specifies +the behavior of the floating point unit for rounding, contains +its condition codes, version specification, and trap information. + +A queue of the floating point instructions which have +started execution but not yet completed is maintained. This +queue is needed to support the multiple cycle nature of floating +point operations and to aid floating point exception trap +handlers. Once a floating point exception has been encountered, +the queue is frozen until it is emptied by the trap handler. +The floating point queue is loaded by launching instructions. +It is emptied normally when the floating point completes all +outstanding instructions and by floating point exception +handlers with the store double floating point queue (stdfq) +instruction. + +@ifinfo +@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model +@end ifinfo +@subsection Special Registers + +The SPARC architecture includes two special registers +which are critical to the programming model: the Processor State +Register (psr) and the Window Invalid Mask (wim). The psr +contains the condition codes, processor interrupt level, trap +enable bit, supervisor mode and previous supervisor mode bits, +version information, floating point unit and coprocessor enable +bits, and the current window pointer (cwp). The cwp field of +the psr and wim register are used to manage the register windows +in the SPARC architecture. The register windows are discussed +in more detail below. + +@ifinfo +@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions +@end ifinfo +@section Register Windows + +The SPARC architecture includes the concept of +register windows. An overly simplistic way to think of these +windows is to imagine them as being an infinite supply of +"fresh" register sets available for each subroutine to use. In +reality, they are much more complicated. + +The save instruction is used to obtain a new register +window. This instruction decrements the current window pointer, +thus providing a new set of registers for use. This register +set includes eight fresh local registers for use exclusively by +this subroutine. When done with a register set, the restore +instruction increments the current window pointer and the +previous register set is once again available. + +The two primary issues complicating the use of +register windows are that (1) the set of register windows is +finite, and (2) some registers are shared between adjacent +registers windows. + +Because the set of register windows is finite, it is +possible to execute enough save instructions without +corresponding restore's to consume all of the register windows. +This is easily accomplished in a high level language because +each subroutine typically performs a save instruction upon +entry. Thus having a subroutine call depth greater than the +number of register windows will result in a window overflow +condition. The window overflow condition generates a trap which +must be handled in software. The window overflow trap handler +is responsible for saving the contents of the oldest register +window on the program stack. + +Similarly, the subroutines will eventually complete +and begin to perform restore's. If the restore results in the +need for a register window which has previously been written to +memory as part of an overflow, then a window underflow condition +results. Just like the window overflow, the window underflow +condition must be handled in software by a trap handler. The +window underflow trap handler is responsible for reloading the +contents of the register window requested by the restore +instruction from the program stack. + +The Window Invalid Mask (wim) and the Current Window +Pointer (cwp) field in the psr are used in conjunction to manage +the finite set of register windows and detect the window +overflow and underflow conditions. The cwp contains the index +of the register window currently in use. The save instruction +decrements the cwp modulo the number of register windows. +Similarly, the restore instruction increments the cwp modulo the +number of register windows. Each bit in the wim represents +represents whether a register window contains valid information. +The value of 0 indicates the register window is valid and 1 +indicates it is invalid. When a save instruction causes the cwp +to point to a register window which is marked as invalid, a +window overflow condition results. Conversely, the restore +instruction may result in a window underflow condition. + +Other than the assumption that a register window is +always available for trap (i.e. interrupt) handlers, the SPARC +architecture places no limits on the number of register windows +simultaneously marked as invalid (i.e. number of bits set in the +wim). However, RTEMS assumes that only one register window is +marked invalid at a time (i.e. only one bit set in the wim). +This makes the maximum possible number of register windows +available to the user while still meeting the requirement that +window overflow and underflow conditions can be detected. + +The window overflow and window underflow trap +handlers are a critical part of the run-time environment for a +SPARC application. The SPARC architectural specification allows +for the number of register windows to be any power of two less +than or equal to 32. The most common choice for SPARC +implementations appears to be 8 register windows. This results +in the cwp ranging in value from 0 to 7 on most implementations. + + +The second complicating factor is the sharing of +registers between adjacent register windows. While each +register window has its own set of local registers, the input +and output registers are shared between adjacent windows. The +output registers for register window N are the same as the input +registers for register window ((N - 1) modulo RW) where RW is +the number of register windows. An alternative way to think of +this is to remember how parameters are passed to a subroutine on +the SPARC. The caller loads values into what are its output +registers. Then after the callee executes a save instruction, +those parameters are available in its input registers. This is +a very efficient way to pass parameters as no data is actually +moved by the save or restore instructions. + +@ifinfo +@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions +@end ifinfo +@section Call and Return Mechanism + +The SPARC architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the call (call) instruction. This instruction places the +return address in the caller's output register 7 (o7). After +the callee executes a save instruction, this value is available +in input register 7 (i7) until the corresponding restore +instruction is executed. + +The callee returns to the caller via a jmp to the +return address. There is a delay slot following this +instruction which is commonly used to execute a restore +instruction -- if a register window was allocated by this +subroutine. + +It is important to note that the SPARC subroutine +call and return mechanism does not automatically save and +restore any registers. This is accomplished via the save and +restore instructions which manage the set of registers windows. + +@ifinfo +@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions +@end ifinfo +@section Calling Mechanism + +All RTEMS directives are invoked using the regular +SPARC calling convention via the call instruction. + +@ifinfo +@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions +@end ifinfo +@section Register Usage + +As discussed above, the call instruction does not +automatically save any registers. The save and restore +instructions are used to allocate and deallocate register +windows. When a register window is allocated, the new set of +local registers are available for the exclusive use of the +subroutine which allocated this register set. + +@ifinfo +@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions +@end ifinfo +@section Parameter Passing + +RTEMS assumes that arguments are placed in the +caller's output registers with the first argument in output +register 0 (o0), the second argument in output register 1 (o1), +and so forth. Until the callee executes a save instruction, the +parameters are still visible in the output registers. After the +callee executes a save instruction, the parameters are visible +in the corresponding input registers. The following pseudo-code +illustrates the typical sequence used to call a RTEMS directive +with three (3) arguments: + +@example +load third argument into o2 +load second argument into o1 +load first argument into o0 +invoke directive +@end example + +@ifinfo +@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions +@end ifinfo +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + diff --git a/doc/supplements/sparc/cpumodel.t b/doc/supplements/sparc/cpumodel.t new file mode 100644 index 0000000000..6f137ad48d --- /dev/null +++ b/doc/supplements/sparc/cpumodel.t @@ -0,0 +1,169 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 Feature Flags:: +* CPU Model Dependent Features CPU Model Implementation Notes:: +@end menu +@end ifinfo + +@ifinfo +@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features, CPU Model Dependent Features +@end ifinfo +@section Introduction + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +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. + +@ifinfo +@node CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Introduction, CPU Model Dependent Features +@end ifinfo +@section CPU Model Feature Flags +@ifinfo +@menu +* CPU Model Dependent Features CPU Model Name:: +* CPU Model Dependent Features Floating Point Unit:: +* CPU Model Dependent Features Bitscan Instruction:: +* CPU Model Dependent Features Number of Register Windows:: +* CPU Model Dependent Features Low Power Mode:: +@end menu +@end ifinfo + +Each processor family supported by RTEMS has a +list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This section presents the set of features which vary +across SPARC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +c/src/exec/score/cpu/sparc/sparc.h based upon the particular CPU +model defined on the compilation command line. + +@ifinfo +@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the European Space +Agency's ERC32 SPARC model, this macro is set to the string +"erc32". + +@ifinfo +@node CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features Bitscan Instruction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection Floating Point Unit + +The macro SPARC_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. + +@ifinfo +@node CPU Model Dependent Features Bitscan Instruction, CPU Model Dependent Features Number of Register Windows, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection Bitscan Instruction + +The macro SPARC_HAS_BITSCAN is set to 1 to indicate +that this CPU model has the bitscan instruction. For example, +this instruction is supported by the Fujitsu SPARClite family. + +@ifinfo +@node CPU Model Dependent Features Number of Register Windows, CPU Model Dependent Features Low Power Mode, CPU Model Dependent Features Bitscan Instruction, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection Number of Register Windows + +The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to +indicate the number of register window sets implemented by this +CPU model. The SPARC architecture allows a for a maximum of +thirty-two register window sets although most implementations +only include eight. + +@ifinfo +@node CPU Model Dependent Features Low Power Mode, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Number of Register Windows, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection Low Power Mode + +The macro SPARC_HAS_LOW_POWER_MODE is set to one to +indicate that this CPU model has a low power mode. If low power +is enabled, then there must be CPU model specific implementation +of the IDLE task in c/src/exec/score/cpu/sparc/cpu.c. The low +power mode IDLE task should be of the form: + +@example +while ( TRUE ) @{ + enter low power mode +@} +@end example + +The code required to enter low power mode is CPU model specific. + +@ifinfo +@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Mode, CPU Model Dependent Features +@end ifinfo +@section CPU Model Implementation Notes + +The ERC is a custom SPARC V7 implementation based on the Cypress 601/602 +chipset. This CPU has a number of on-board peripherals and was developed by +the European Space Agency to target space applications. RTEMS currently +provides support for the following peripherals: + +@itemize @bullet +@item UART Channels A and B +@item General Purpose Timer +@item Real Time Clock +@item Watchdog Timer (so it can be disabled) +@item Control Register (so powerdown mode can be enabled) +@item Memory Control Register +@item Interrupt Control +@end itemize + +The General Purpose Timer and Real Time Clock Timer provided with the ERC32 +share the Timer Control Register. Because the Timer Control Register is write +only, we must mirror it in software and insure that writes to one timer do not +alter the current settings and status of the other timer. Routines are +provided in erc32.h which promote the view that the two timers are completely +independent. By exclusively using these routines to access the Timer Control +Register, the application can view the system as having a General Purpose +Timer Control Register and a Real Time Clock Timer Control Register +rather than the single shared value. + +The RTEMS Idle thread take advantage of the low power mode provided by the +ERC32. Low power mode is entered during idle loops and is enabled at +initialization time. diff --git a/doc/supplements/sparc/cpumodel.texi b/doc/supplements/sparc/cpumodel.texi new file mode 100644 index 0000000000..6f137ad48d --- /dev/null +++ b/doc/supplements/sparc/cpumodel.texi @@ -0,0 +1,169 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 Feature Flags:: +* CPU Model Dependent Features CPU Model Implementation Notes:: +@end menu +@end ifinfo + +@ifinfo +@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features, CPU Model Dependent Features +@end ifinfo +@section Introduction + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +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. + +@ifinfo +@node CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Introduction, CPU Model Dependent Features +@end ifinfo +@section CPU Model Feature Flags +@ifinfo +@menu +* CPU Model Dependent Features CPU Model Name:: +* CPU Model Dependent Features Floating Point Unit:: +* CPU Model Dependent Features Bitscan Instruction:: +* CPU Model Dependent Features Number of Register Windows:: +* CPU Model Dependent Features Low Power Mode:: +@end menu +@end ifinfo + +Each processor family supported by RTEMS has a +list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This section presents the set of features which vary +across SPARC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +c/src/exec/score/cpu/sparc/sparc.h based upon the particular CPU +model defined on the compilation command line. + +@ifinfo +@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the European Space +Agency's ERC32 SPARC model, this macro is set to the string +"erc32". + +@ifinfo +@node CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features Bitscan Instruction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection Floating Point Unit + +The macro SPARC_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. + +@ifinfo +@node CPU Model Dependent Features Bitscan Instruction, CPU Model Dependent Features Number of Register Windows, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection Bitscan Instruction + +The macro SPARC_HAS_BITSCAN is set to 1 to indicate +that this CPU model has the bitscan instruction. For example, +this instruction is supported by the Fujitsu SPARClite family. + +@ifinfo +@node CPU Model Dependent Features Number of Register Windows, CPU Model Dependent Features Low Power Mode, CPU Model Dependent Features Bitscan Instruction, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection Number of Register Windows + +The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to +indicate the number of register window sets implemented by this +CPU model. The SPARC architecture allows a for a maximum of +thirty-two register window sets although most implementations +only include eight. + +@ifinfo +@node CPU Model Dependent Features Low Power Mode, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Number of Register Windows, CPU Model Dependent Features CPU Model Feature Flags +@end ifinfo +@subsection Low Power Mode + +The macro SPARC_HAS_LOW_POWER_MODE is set to one to +indicate that this CPU model has a low power mode. If low power +is enabled, then there must be CPU model specific implementation +of the IDLE task in c/src/exec/score/cpu/sparc/cpu.c. The low +power mode IDLE task should be of the form: + +@example +while ( TRUE ) @{ + enter low power mode +@} +@end example + +The code required to enter low power mode is CPU model specific. + +@ifinfo +@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Mode, CPU Model Dependent Features +@end ifinfo +@section CPU Model Implementation Notes + +The ERC is a custom SPARC V7 implementation based on the Cypress 601/602 +chipset. This CPU has a number of on-board peripherals and was developed by +the European Space Agency to target space applications. RTEMS currently +provides support for the following peripherals: + +@itemize @bullet +@item UART Channels A and B +@item General Purpose Timer +@item Real Time Clock +@item Watchdog Timer (so it can be disabled) +@item Control Register (so powerdown mode can be enabled) +@item Memory Control Register +@item Interrupt Control +@end itemize + +The General Purpose Timer and Real Time Clock Timer provided with the ERC32 +share the Timer Control Register. Because the Timer Control Register is write +only, we must mirror it in software and insure that writes to one timer do not +alter the current settings and status of the other timer. Routines are +provided in erc32.h which promote the view that the two timers are completely +independent. By exclusively using these routines to access the Timer Control +Register, the application can view the system as having a General Purpose +Timer Control Register and a Real Time Clock Timer Control Register +rather than the single shared value. + +The RTEMS Idle thread take advantage of the low power mode provided by the +ERC32. Low power mode is entered during idle loops and is enabled at +initialization time. diff --git a/doc/supplements/sparc/cputable.t b/doc/supplements/sparc/cputable.t new file mode 100644 index 0000000000..6aabd6cfa5 --- /dev/null +++ b/doc/supplements/sparc/cputable.t @@ -0,0 +1,109 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 SPARC version of the RTEMS CPU Dependent +Information Table is given by the C structure definition is +shown below: + +@example +struct cpu_configuration_table @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + +@}; +@end example + +@table @code +@item pretasking_hook +is the address of the +user provided routine which is invoked once RTEMS initialization +is complete but before interrupts and tasking are enabled. This +field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately before +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +but no device drivers are initialized. This field may be NULL to +indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately after +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +and the device drivers are initialized. This field may be NULL +to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item interrupt_stack_size +is the size of the RTEMS allocated interrupt stack in bytes. +This value must be at least as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@end table + diff --git a/doc/supplements/sparc/cputable.texi b/doc/supplements/sparc/cputable.texi new file mode 100644 index 0000000000..6aabd6cfa5 --- /dev/null +++ b/doc/supplements/sparc/cputable.texi @@ -0,0 +1,109 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 SPARC version of the RTEMS CPU Dependent +Information Table is given by the C structure definition is +shown below: + +@example +struct cpu_configuration_table @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + +@}; +@end example + +@table @code +@item pretasking_hook +is the address of the +user provided routine which is invoked once RTEMS initialization +is complete but before interrupts and tasking are enabled. This +field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately before +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +but no device drivers are initialized. This field may be NULL to +indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately after +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +and the device drivers are initialized. This field may be NULL +to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item interrupt_stack_size +is the size of the RTEMS allocated interrupt stack in bytes. +This value must be at least as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@end table + diff --git a/doc/supplements/sparc/fatalerr.t b/doc/supplements/sparc/fatalerr.t new file mode 100644 index 0000000000..1406097f3a --- /dev/null +++ b/doc/supplements/sparc/fatalerr.t @@ -0,0 +1,45 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@ifinfo +@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing +@end ifinfo +@section Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts to +level 15, places the error code in g1, and goes into an infinite +loop to simulate a halt processor instruction. + + diff --git a/doc/supplements/sparc/fatalerr.texi b/doc/supplements/sparc/fatalerr.texi new file mode 100644 index 0000000000..1406097f3a --- /dev/null +++ b/doc/supplements/sparc/fatalerr.texi @@ -0,0 +1,45 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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 are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@ifinfo +@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing +@end ifinfo +@section Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts to +level 15, places the error code in g1, and goes into an infinite +loop to simulate a halt processor instruction. + + diff --git a/doc/supplements/sparc/intr.t b/doc/supplements/sparc/intr.t new file mode 100644 index 0000000000..73224c1008 --- /dev/null +++ b/doc/supplements/sparc/intr.t @@ -0,0 +1,226 @@ +@ifinfo +@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top +@end ifinfo +@chapter Interrupt Processing +@ifinfo +@menu +* Interrupt Processing Introduction:: +* Interrupt Processing Synchronous Versus Asynchronous Traps:: +* Interrupt Processing Vectoring of Interrupt Handler:: +* Interrupt Processing Traps and Register Windows:: +* Interrupt Processing Interrupt Levels:: +* Interrupt Processing Disabling of Interrupts by RTEMS:: +* Interrupt Processing Interrupt Stack:: +@end menu +@end ifinfo + +@ifinfo +@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing +@end ifinfo +@section Introduction + +Different types of processors respond to the +occurrence of an interrupt in its own unique fashion. In +addition, each processor type provides a control mechanism to +allow for the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the current +execution state and results in a change in the execution stream. +Most processors require that an interrupt handler utilize some +special control mechanisms to return to the normal processing +stream. Although RTEMS hides many of the processor dependent +details of interrupt processing, it is important to understand +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the SPARC's +interrupt response and control mechanisms as they pertain to +RTEMS. + +RTEMS and associated documentation uses the terms +interrupt and vector. In the SPARC architecture, these terms +correspond to traps and trap type, respectively. The terms will +be used interchangeably in this manual. + +@ifinfo +@node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing +@end ifinfo +@section Synchronous Versus Asynchronous Traps + +The SPARC architecture includes two classes of traps: +synchronous and asynchronous. Asynchronous traps occur when an +external event interrupts the processor. These traps are not +associated with any instruction executed by the processor and +logically occur between instructions. The instruction currently +in the execute stage of the processor is allowed to complete +although subsequent instructions are annulled. The return +address reported by the processor for asynchronous traps is the +pair of instructions following the current instruction. + +Synchronous traps are caused by the actions of an +instruction. The trap stimulus in this case either occurs +internally to the processor or is from an external signal that +was provoked by the instruction. These traps are taken +immediately and the instruction that caused the trap is aborted +before any state changes occur in the processor itself. The +return address reported by the processor for synchronous traps +is the instruction which caused the trap and the following +instruction. + +@ifinfo +@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing +@end ifinfo +@section Vectoring of Interrupt Handler + +Upon receipt of an interrupt the SPARC automatically +performs the following actions: + +@itemize @bullet +@item disables traps (sets the ET bit of the psr to 0), + +@item the S bit of the psr is copied into the Previous +Supervisor Mode (PS) bit of the psr, + +@item the cwp is decremented by one (modulo the number of +register windows) to activate a trap window, + +@item the PC and nPC are loaded into local register 1 and 2 +(l0 and l1), + +@item the trap type (tt) field of the Trap Base Register (TBR) +is set to the appropriate value, and + +@item if the trap is not a reset, then the PC is written with +the contents of the TBR and the nPC is written with TBR + 4. If +the trap is a reset, then the PC is set to zero and the nPC is +set to 4. +@end itemize + +Trap processing on the SPARC has two features which +are noticeably different than interrupt processing on other +architectures. First, the value of psr register in effect +immediately before the trap occurred is not explicitly saved. +Instead only reversible alterations are made to it. Second, the +Processor Interrupt Level (pil) is not set to correspond to that +of the interrupt being processed. When a trap occurs, ALL +subsequent traps are disabled. In order to safely invoke a +subroutine during trap handling, traps must be enabled to allow +for the possibility of register window overflow and underflow +traps. + +If the interrupt handler was installed as an RTEMS +interrupt handler, then upon receipt of the interrupt, the +processor passes control to the RTEMS interrupt handler which +performs the following actions: + +@itemize @bullet +@item saves the state of the interrupted task on it's stack, + +@item insures that a register window is available for +subsequent traps, + +@item if this is the outermost (i.e. non-nested) interrupt, +then the RTEMS interrupt handler switches from the current stack +to the interrupt stack, + +@item enables traps, + +@item invokes the vectors to a user interrupt service routine (ISR). +@end itemize + +Asynchronous interrupts are ignored while traps are +disabled. Synchronous traps which occur while traps are +disabled result in the CPU being forced into an error mode. + +A nested interrupt is processed similarly with the +exception that the current stack need not be switched to the +interrupt stack. + +@ifinfo +@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing +@end ifinfo +@section Traps and Register Windows + +One of the register windows must be reserved at all +times for trap processing. This is critical to the proper +operation of the trap mechanism in the SPARC architecture. It +is the responsibility of the trap handler to insure that there +is a register window available for a subsequent trap before +re-enabling traps. It is likely that any high level language +routines invoked by the trap handler (such as a user-provided +RTEMS interrupt handler) will allocate a new register window. +The save operation could result in a window overflow trap. This +trap cannot be correctly processed unless (1) traps are enabled +and (2) a register window is reserved for traps. Thus, the +RTEMS interrupt handler insures that a register window is +available for subsequent traps before enabling traps and +invoking the user's interrupt handler. + +@ifinfo +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing +@end ifinfo +@section Interrupt Levels + +Sixteen levels (0-15) of interrupt priorities are +supported by the SPARC architecture with level fifteen (15) +being the highest priority. Level zero (0) indicates that +interrupts are fully enabled. Interrupt requests for interrupts +with priorities less than or equal to the current interrupt mask +level are ignored. + +Although RTEMS supports 256 interrupt levels, the +SPARC only supports sixteen. RTEMS interrupt levels 0 through +15 directly correspond to SPARC processor interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@ifinfo +@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing +@end ifinfo +@section Disabling of Interrupts by RTEMS + +During the execution of directive calls, critical +sections of code may be executed. When these sections are +encountered, RTEMS disables interrupts to level seven (15) +before the execution of this section and restores them to the +previous level upon completion of the section. RTEMS has been +optimized to insure that interrupts are disabled for less than +RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +Mhz ERC32 with zero wait states. +These numbers will vary based the number of wait states and +processor speed present on the target board. +[NOTE: The maximum period with interrupts disabled is hand calculated. This +calculation was last performed for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +[NOTE: It is thought that the length of time at which +the processor interrupt level is elevated to fifteen by RTEMS is +not anywhere near as long as the length of time ALL traps are +disabled as part of the "flush all register windows" operation.] + +Non-maskable interrupts (NMI) cannot be disabled, and +ISRs which execute at this level MUST NEVER issue RTEMS system +calls. If a directive is invoked, unpredictable results may +occur due to the inability of RTEMS to protect its critical +sections. However, ISRs that make no system calls may safely +execute as non-maskable interrupts. + +@ifinfo +@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing +@end ifinfo +@section Interrupt Stack + +The SPARC architecture does not provide for a +dedicated interrupt stack. Thus by default, trap handlers would +execute on the stack of the RTEMS task which they interrupted. +This artificially inflates the stack requirements for each task +since EVERY task stack would have to include enough space to +account for the worst case interrupt stack requirements in +addition to it's own worst case usage. RTEMS addresses this +problem on the SPARC by providing a dedicated interrupt stack +managed by software. + +During system initialization, RTEMS allocates the +interrupt stack from the Workspace Area. The amount of memory +allocated for the interrupt stack is determined by the +interrupt_stack_size field in the CPU Configuration Table. As +part of processing a non-nested interrupt, RTEMS will switch to +the interrupt stack before invoking the installed handler. + diff --git a/doc/supplements/sparc/intr_NOTIMES.t b/doc/supplements/sparc/intr_NOTIMES.t new file mode 100644 index 0000000000..73224c1008 --- /dev/null +++ b/doc/supplements/sparc/intr_NOTIMES.t @@ -0,0 +1,226 @@ +@ifinfo +@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top +@end ifinfo +@chapter Interrupt Processing +@ifinfo +@menu +* Interrupt Processing Introduction:: +* Interrupt Processing Synchronous Versus Asynchronous Traps:: +* Interrupt Processing Vectoring of Interrupt Handler:: +* Interrupt Processing Traps and Register Windows:: +* Interrupt Processing Interrupt Levels:: +* Interrupt Processing Disabling of Interrupts by RTEMS:: +* Interrupt Processing Interrupt Stack:: +@end menu +@end ifinfo + +@ifinfo +@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing +@end ifinfo +@section Introduction + +Different types of processors respond to the +occurrence of an interrupt in its own unique fashion. In +addition, each processor type provides a control mechanism to +allow for the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the current +execution state and results in a change in the execution stream. +Most processors require that an interrupt handler utilize some +special control mechanisms to return to the normal processing +stream. Although RTEMS hides many of the processor dependent +details of interrupt processing, it is important to understand +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the SPARC's +interrupt response and control mechanisms as they pertain to +RTEMS. + +RTEMS and associated documentation uses the terms +interrupt and vector. In the SPARC architecture, these terms +correspond to traps and trap type, respectively. The terms will +be used interchangeably in this manual. + +@ifinfo +@node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing +@end ifinfo +@section Synchronous Versus Asynchronous Traps + +The SPARC architecture includes two classes of traps: +synchronous and asynchronous. Asynchronous traps occur when an +external event interrupts the processor. These traps are not +associated with any instruction executed by the processor and +logically occur between instructions. The instruction currently +in the execute stage of the processor is allowed to complete +although subsequent instructions are annulled. The return +address reported by the processor for asynchronous traps is the +pair of instructions following the current instruction. + +Synchronous traps are caused by the actions of an +instruction. The trap stimulus in this case either occurs +internally to the processor or is from an external signal that +was provoked by the instruction. These traps are taken +immediately and the instruction that caused the trap is aborted +before any state changes occur in the processor itself. The +return address reported by the processor for synchronous traps +is the instruction which caused the trap and the following +instruction. + +@ifinfo +@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing +@end ifinfo +@section Vectoring of Interrupt Handler + +Upon receipt of an interrupt the SPARC automatically +performs the following actions: + +@itemize @bullet +@item disables traps (sets the ET bit of the psr to 0), + +@item the S bit of the psr is copied into the Previous +Supervisor Mode (PS) bit of the psr, + +@item the cwp is decremented by one (modulo the number of +register windows) to activate a trap window, + +@item the PC and nPC are loaded into local register 1 and 2 +(l0 and l1), + +@item the trap type (tt) field of the Trap Base Register (TBR) +is set to the appropriate value, and + +@item if the trap is not a reset, then the PC is written with +the contents of the TBR and the nPC is written with TBR + 4. If +the trap is a reset, then the PC is set to zero and the nPC is +set to 4. +@end itemize + +Trap processing on the SPARC has two features which +are noticeably different than interrupt processing on other +architectures. First, the value of psr register in effect +immediately before the trap occurred is not explicitly saved. +Instead only reversible alterations are made to it. Second, the +Processor Interrupt Level (pil) is not set to correspond to that +of the interrupt being processed. When a trap occurs, ALL +subsequent traps are disabled. In order to safely invoke a +subroutine during trap handling, traps must be enabled to allow +for the possibility of register window overflow and underflow +traps. + +If the interrupt handler was installed as an RTEMS +interrupt handler, then upon receipt of the interrupt, the +processor passes control to the RTEMS interrupt handler which +performs the following actions: + +@itemize @bullet +@item saves the state of the interrupted task on it's stack, + +@item insures that a register window is available for +subsequent traps, + +@item if this is the outermost (i.e. non-nested) interrupt, +then the RTEMS interrupt handler switches from the current stack +to the interrupt stack, + +@item enables traps, + +@item invokes the vectors to a user interrupt service routine (ISR). +@end itemize + +Asynchronous interrupts are ignored while traps are +disabled. Synchronous traps which occur while traps are +disabled result in the CPU being forced into an error mode. + +A nested interrupt is processed similarly with the +exception that the current stack need not be switched to the +interrupt stack. + +@ifinfo +@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing +@end ifinfo +@section Traps and Register Windows + +One of the register windows must be reserved at all +times for trap processing. This is critical to the proper +operation of the trap mechanism in the SPARC architecture. It +is the responsibility of the trap handler to insure that there +is a register window available for a subsequent trap before +re-enabling traps. It is likely that any high level language +routines invoked by the trap handler (such as a user-provided +RTEMS interrupt handler) will allocate a new register window. +The save operation could result in a window overflow trap. This +trap cannot be correctly processed unless (1) traps are enabled +and (2) a register window is reserved for traps. Thus, the +RTEMS interrupt handler insures that a register window is +available for subsequent traps before enabling traps and +invoking the user's interrupt handler. + +@ifinfo +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing +@end ifinfo +@section Interrupt Levels + +Sixteen levels (0-15) of interrupt priorities are +supported by the SPARC architecture with level fifteen (15) +being the highest priority. Level zero (0) indicates that +interrupts are fully enabled. Interrupt requests for interrupts +with priorities less than or equal to the current interrupt mask +level are ignored. + +Although RTEMS supports 256 interrupt levels, the +SPARC only supports sixteen. RTEMS interrupt levels 0 through +15 directly correspond to SPARC processor interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@ifinfo +@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing +@end ifinfo +@section Disabling of Interrupts by RTEMS + +During the execution of directive calls, critical +sections of code may be executed. When these sections are +encountered, RTEMS disables interrupts to level seven (15) +before the execution of this section and restores them to the +previous level upon completion of the section. RTEMS has been +optimized to insure that interrupts are disabled for less than +RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +Mhz ERC32 with zero wait states. +These numbers will vary based the number of wait states and +processor speed present on the target board. +[NOTE: The maximum period with interrupts disabled is hand calculated. This +calculation was last performed for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +[NOTE: It is thought that the length of time at which +the processor interrupt level is elevated to fifteen by RTEMS is +not anywhere near as long as the length of time ALL traps are +disabled as part of the "flush all register windows" operation.] + +Non-maskable interrupts (NMI) cannot be disabled, and +ISRs which execute at this level MUST NEVER issue RTEMS system +calls. If a directive is invoked, unpredictable results may +occur due to the inability of RTEMS to protect its critical +sections. However, ISRs that make no system calls may safely +execute as non-maskable interrupts. + +@ifinfo +@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing +@end ifinfo +@section Interrupt Stack + +The SPARC architecture does not provide for a +dedicated interrupt stack. Thus by default, trap handlers would +execute on the stack of the RTEMS task which they interrupted. +This artificially inflates the stack requirements for each task +since EVERY task stack would have to include enough space to +account for the worst case interrupt stack requirements in +addition to it's own worst case usage. RTEMS addresses this +problem on the SPARC by providing a dedicated interrupt stack +managed by software. + +During system initialization, RTEMS allocates the +interrupt stack from the Workspace Area. The amount of memory +allocated for the interrupt stack is determined by the +interrupt_stack_size field in the CPU Configuration Table. As +part of processing a non-nested interrupt, RTEMS will switch to +the interrupt stack before invoking the installed handler. + diff --git a/doc/supplements/sparc/memmodel.t b/doc/supplements/sparc/memmodel.t new file mode 100644 index 0000000000..d99ef26f96 --- /dev/null +++ b/doc/supplements/sparc/memmodel.t @@ -0,0 +1,117 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top +@end ifinfo +@chapter Memory Model +@ifinfo +@menu +* Memory Model Introduction:: +* Memory Model Flat Memory Model:: +@end menu +@end ifinfo + +@ifinfo +@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model +@end ifinfo +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@ifinfo +@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model +@end ifinfo +@section Flat Memory Model + +The SPARC architecture supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +is byte addressable. The address may be used to reference a +single byte, half-word (2-bytes), word (4 bytes), or doubleword +(8 bytes). Memory accesses within this address space are +performed in big endian fashion by the SPARC. Memory accesses +which are not properly aligned generate a "memory address not +aligned" trap (type number 7). The following table lists the +alignment requirements for a variety of data accesses: + +@ifset use-ascii +@example +@group + +--------------+-----------------------+ + | Data Type | Alignment Requirement | + +--------------+-----------------------+ + | byte | 1 | + | half-word | 2 | + | word | 4 | + | doubleword | 8 | + +--------------+-----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} +&byte&&1&\cr\noalign{\hrule} +&half-word&&2&\cr\noalign{\hrule} +&word&&4&\cr\noalign{\hrule} +&doubleword&&8&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +<CENTER> + <TABLE COLS=2 WIDTH="60%" BORDER=2> +<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD> + <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR> +<TR><TD ALIGN=center>byte</TD> + <TD ALIGN=center>1</TD></TR> +<TR><TD ALIGN=center>half-word</TD> + <TD ALIGN=center>2</TD></TR> +<TR><TD ALIGN=center>word</TD> + <TD ALIGN=center>4</TD></TR> +<TR><TD ALIGN=center>doubleword</TD> + <TD ALIGN=center>8</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +Doubleword load and store operations must use a pair +of registers as their source or destination. This pair of +registers must be an adjacent pair of registers with the first +of the pair being even numbered. For example, a valid +destination for a doubleword load might be input registers 0 and +1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE: +Some assemblers for the SPARC do not generate an error if an odd +numbered register is specified as the beginning register of the +pair. In this case, the assembler assumes that what the +programmer meant was to use the even-odd pair which ends at the +specified register. This may or may not have been a correct +assumption.] + +RTEMS does not support any SPARC Memory Management +Units, therefore, virtual memory or segmentation systems +involving the SPARC are not supported. + diff --git a/doc/supplements/sparc/memmodel.texi b/doc/supplements/sparc/memmodel.texi new file mode 100644 index 0000000000..d99ef26f96 --- /dev/null +++ b/doc/supplements/sparc/memmodel.texi @@ -0,0 +1,117 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top +@end ifinfo +@chapter Memory Model +@ifinfo +@menu +* Memory Model Introduction:: +* Memory Model Flat Memory Model:: +@end menu +@end ifinfo + +@ifinfo +@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model +@end ifinfo +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@ifinfo +@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model +@end ifinfo +@section Flat Memory Model + +The SPARC architecture supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +is byte addressable. The address may be used to reference a +single byte, half-word (2-bytes), word (4 bytes), or doubleword +(8 bytes). Memory accesses within this address space are +performed in big endian fashion by the SPARC. Memory accesses +which are not properly aligned generate a "memory address not +aligned" trap (type number 7). The following table lists the +alignment requirements for a variety of data accesses: + +@ifset use-ascii +@example +@group + +--------------+-----------------------+ + | Data Type | Alignment Requirement | + +--------------+-----------------------+ + | byte | 1 | + | half-word | 2 | + | word | 4 | + | doubleword | 8 | + +--------------+-----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} +&byte&&1&\cr\noalign{\hrule} +&half-word&&2&\cr\noalign{\hrule} +&word&&4&\cr\noalign{\hrule} +&doubleword&&8&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +<CENTER> + <TABLE COLS=2 WIDTH="60%" BORDER=2> +<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD> + <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR> +<TR><TD ALIGN=center>byte</TD> + <TD ALIGN=center>1</TD></TR> +<TR><TD ALIGN=center>half-word</TD> + <TD ALIGN=center>2</TD></TR> +<TR><TD ALIGN=center>word</TD> + <TD ALIGN=center>4</TD></TR> +<TR><TD ALIGN=center>doubleword</TD> + <TD ALIGN=center>8</TD></TR> + </TABLE> +</CENTER> +@end html +@end ifset + +Doubleword load and store operations must use a pair +of registers as their source or destination. This pair of +registers must be an adjacent pair of registers with the first +of the pair being even numbered. For example, a valid +destination for a doubleword load might be input registers 0 and +1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE: +Some assemblers for the SPARC do not generate an error if an odd +numbered register is specified as the beginning register of the +pair. In this case, the assembler assumes that what the +programmer meant was to use the even-odd pair which ends at the +specified register. This may or may not have been a correct +assumption.] + +RTEMS does not support any SPARC Memory Management +Units, therefore, virtual memory or segmentation systems +involving the SPARC are not supported. + diff --git a/doc/supplements/sparc/preface.texi b/doc/supplements/sparc/preface.texi new file mode 100644 index 0000000000..572d24a174 --- /dev/null +++ b/doc/supplements/sparc/preface.texi @@ -0,0 +1,89 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@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. + +This document discusses the SPARC architecture +dependencies in this port of RTEMS. Currently, only +implementations of SPARC Version 7 are supported by RTEMS. + +It is highly recommended that the SPARC RTEMS +application developer obtain and become familiar with the +documentation for the processor being used as well as the +specification for the revision of the SPARC architecture which +corresponds to that processor. + +@subheading SPARC Architecture Documents + +For information on the SPARC architecture, refer to +the following documents available from SPARC International, Inc. +(http://www.sparc.com): + +@itemize @bullet +@item SPARC Standard Version 7. + +@item SPARC Standard Version 8. + +@item SPARC Standard Version 9. +@end itemize + +@subheading ERC32 Specific Information + +The European Space Agency's ERC32 is a three chip +computing core implementing a SPARC V7 processor and associated +support circuitry for embedded space applications. The integer +and floating-point units (90C601E & 90C602E) are based on the +Cypress 7C601 and 7C602, with additional error-detection and +recovery functions. The memory controller (MEC) implements +system support functions such as address decoding, memory +interface, DMA interface, UARTs, timers, interrupt control, +write-protection, memory reconfiguration and error-detection. +The core is designed to work at 25MHz, but using space qualified +memories limits the system frequency to around 15 MHz, resulting +in a performance of 10 MIPS and 2 MFLOPS. + +Information on the ERC32 and a number of development +support tools, such as the SPARC Instruction Simulator (SIS), +are freely available on the Internet. The following documents +and SIS are available via anonymous ftp or pointing your web +browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. + +@itemize @bullet +@item ERC32 System Design Document + +@item MEC Device Specification +@end itemize + +Additionally, the SPARC RISC User's Guide from Matra +MHS documents the functionality of the integer and floating +point units including the instruction set information. To +obtain this document as well as ERC32 components and VHDL models +contact: + +@example +Matra MHS SA +3 Avenue du Centre, BP 309, +78054 St-Quentin-en-Yvelines, +Cedex, France +VOICE: +31-1-30607087 +FAX: +31-1-30640693 +@end example + +Amar Guennon (amar.guennon@@matramhs.fr) is familiar with the ERC32. + diff --git a/doc/supplements/sparc/sparc.texi b/doc/supplements/sparc/sparc.texi new file mode 100644 index 0000000000..763da87f35 --- /dev/null +++ b/doc/supplements/sparc/sparc.texi @@ -0,0 +1,117 @@ +\input ../texinfo/texinfo @c -*-texinfo-*- +@c %**start of header +@setfilename c_sparc +@syncodeindex vr fn +@synindex ky cp +@paragraphindent 0 +@c @smallbook +@c %**end of header + +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@c +@c Master file for the SPARC C Applications Supplement +@c + +@include ../common/setup.texi + +@ignore +@ifinfo +@format +START-INFO-DIR-ENTRY +* RTEMS SPARC C Applications Supplement (sparc): +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 SPARC C Applications Supplement + +@setchapternewpage odd +@settitle RTEMS SPARC C Applications Supplement +@titlepage +@finalout + +@title RTEMS SPARC 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_sparc + +This is the online version of the RTEMS SPARC 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:: +* ERC32 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, ERC32 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/sparc/timeERC32.t b/doc/supplements/sparc/timeERC32.t new file mode 100644 index 0000000000..22cc6a1202 --- /dev/null +++ b/doc/supplements/sparc/timeERC32.t @@ -0,0 +1,156 @@ +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node ERC32 Timing Data, ERC32 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter ERC32 Timing Data +@ifinfo +@menu +* ERC32 Timing Data Introduction:: +* ERC32 Timing Data Hardware Platform:: +* ERC32 Timing Data Interrupt Latency:: +* ERC32 Timing Data Context Switch:: +* ERC32 Timing Data Directive Times:: +* ERC32 Timing Data Task Manager:: +* ERC32 Timing Data Interrupt Manager:: +* ERC32 Timing Data Clock Manager:: +* ERC32 Timing Data Timer Manager:: +* ERC32 Timing Data Semaphore Manager:: +* ERC32 Timing Data Message Manager:: +* ERC32 Timing Data Event Manager:: +* ERC32 Timing Data Signal Manager:: +* ERC32 Timing Data Partition Manager:: +* ERC32 Timing Data Region Manager:: +* ERC32 Timing Data Dual-Ported Memory Manager:: +* ERC32 Timing Data I/O Manager:: +* ERC32 Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +@ifinfo +@node ERC32 Timing Data Introduction, ERC32 Timing Data Hardware Platform, ERC32 Timing Data, ERC32 Timing Data +@end ifinfo +@section Introduction + +The timing data for RTEMS on the ERC32 implementation +of the SPARC architecture is provided along with the target +dependent aspects concerning the gathering of the timing data. +The hardware platform used to gather the times is described to +give the reader a better understanding of each directive time +provided. Also, provided is a description of the interrupt +latency and the context switch times as they pertain to the +SPARC version of RTEMS. + +@ifinfo +@node ERC32 Timing Data Hardware Platform, ERC32 Timing Data Interrupt Latency, ERC32 Timing Data Introduction, ERC32 Timing Data +@end ifinfo +@section Hardware Platform + +All times reported in this chapter were measured +using the SPARC Instruction Simulator (SIS) developed by the +European Space Agency. SIS simulates the ERC32 -- a custom low +power implementation combining the Cypress 90C601 integer unit, +the Cypress 90C602 floating point unit, and a number of +peripherals such as counter timers, interrupt controller and a +memory controller. + +For the RTEMS tests, SIS is configured with the +following characteristics: + +@itemize @bullet +@item 15 Mhz clock speed + +@item 0 wait states for PROM accesses + +@item 0 wait states for RAM accesses +@end itemize + +The ERC32's General Purpose Timer was used to gather +all timing information. This timer was programmed to operate +with one microsecond accuracy. All sources of hardware +interrupts were disabled, although traps were enabled and the +interrupt level of the SPARC allows all interrupts. + +@ifinfo +@node ERC32 Timing Data Interrupt Latency, ERC32 Timing Data Context Switch, ERC32 Timing Data Hardware Platform, ERC32 Timing Data +@end ifinfo +@section Interrupt Latency + +The maximum period with traps disabled or the +processor interrupt level set to it's highest value inside RTEMS +is less than RTEMS_MAXIMUM_DISABLE_PERIOD +microseconds including the instructions which +disable and re-enable interrupts. The time required for the +ERC32 to vector an interrupt and for the RTEMS entry overhead +before invoking the user's trap handler are a total of +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. These combine to yield a worst case interrupt +latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD + +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz. +[NOTE: The maximum period with interrupts disabled was last +determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +The maximum period with interrupts disabled within +RTEMS is hand-timed with some assistance from SIS. The maximum +period with interrupts disabled with RTEMS occurs during a +context switch when traps are disabled to flush all the register +windows to memory. The length of time spent flushing the +register windows varies based on the number of windows which +must be flushed. Based on the information reported by SIS, it +takes from 4.0 to 18.0 microseconds (37 to 122 instructions) to +flush the register windows. It takes approximately 41 CPU +cycles (2.73 microseconds) to flush each register window set to +memory. The register window flush operation is heavily memory +bound. + +[NOTE: All traps are disabled during the register +window flush thus disabling both software generate traps and +external interrupts. During a normal RTEMS critical section, +the processor interrupt level (pil) is raised to level 15 and +traps are left enabled. The longest path for a normal critical +section within RTEMS is less than 50 instructions.] + +The interrupt vector and entry overhead time was +generated on the SIS benchmark platform using the ERC32's +ability to forcibly generate an arbitrary interrupt as the +source of the "benchmark" interrupt. + +@ifinfo +@node ERC32 Timing Data Context Switch, RTEMS_CPU_MODEL Timing Data Directive Times, ERC32 Timing Data Interrupt Latency, ERC32 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is 10 +microseconds on the SIS benchmark platform when no floating +point context is saved or restored. Additional execution time +is required when a TASK_SWITCH user extension is configured. +The use of the TASK_SWITCH extension is application dependent. +Thus, its execution time is not considered part of the raw +context switch time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. The state of +the numeric coprocessor is only saved when an FLOATING_POINT +task is dispatched and that task was not the last task to +utilize the coprocessor. In a system with only one +FLOATING_POINT task, the state of the numeric coprocessor will +never be saved or restored. When the first FLOATING_POINT task +is dispatched, RTEMS does not need to save the current state of +the numeric coprocessor. + +The following table summarizes the context switch +times for the ERC32 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex + + diff --git a/doc/supplements/sparc/timedata.t b/doc/supplements/sparc/timedata.t new file mode 100644 index 0000000000..22cc6a1202 --- /dev/null +++ b/doc/supplements/sparc/timedata.t @@ -0,0 +1,156 @@ +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node ERC32 Timing Data, ERC32 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter ERC32 Timing Data +@ifinfo +@menu +* ERC32 Timing Data Introduction:: +* ERC32 Timing Data Hardware Platform:: +* ERC32 Timing Data Interrupt Latency:: +* ERC32 Timing Data Context Switch:: +* ERC32 Timing Data Directive Times:: +* ERC32 Timing Data Task Manager:: +* ERC32 Timing Data Interrupt Manager:: +* ERC32 Timing Data Clock Manager:: +* ERC32 Timing Data Timer Manager:: +* ERC32 Timing Data Semaphore Manager:: +* ERC32 Timing Data Message Manager:: +* ERC32 Timing Data Event Manager:: +* ERC32 Timing Data Signal Manager:: +* ERC32 Timing Data Partition Manager:: +* ERC32 Timing Data Region Manager:: +* ERC32 Timing Data Dual-Ported Memory Manager:: +* ERC32 Timing Data I/O Manager:: +* ERC32 Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +@ifinfo +@node ERC32 Timing Data Introduction, ERC32 Timing Data Hardware Platform, ERC32 Timing Data, ERC32 Timing Data +@end ifinfo +@section Introduction + +The timing data for RTEMS on the ERC32 implementation +of the SPARC architecture is provided along with the target +dependent aspects concerning the gathering of the timing data. +The hardware platform used to gather the times is described to +give the reader a better understanding of each directive time +provided. Also, provided is a description of the interrupt +latency and the context switch times as they pertain to the +SPARC version of RTEMS. + +@ifinfo +@node ERC32 Timing Data Hardware Platform, ERC32 Timing Data Interrupt Latency, ERC32 Timing Data Introduction, ERC32 Timing Data +@end ifinfo +@section Hardware Platform + +All times reported in this chapter were measured +using the SPARC Instruction Simulator (SIS) developed by the +European Space Agency. SIS simulates the ERC32 -- a custom low +power implementation combining the Cypress 90C601 integer unit, +the Cypress 90C602 floating point unit, and a number of +peripherals such as counter timers, interrupt controller and a +memory controller. + +For the RTEMS tests, SIS is configured with the +following characteristics: + +@itemize @bullet +@item 15 Mhz clock speed + +@item 0 wait states for PROM accesses + +@item 0 wait states for RAM accesses +@end itemize + +The ERC32's General Purpose Timer was used to gather +all timing information. This timer was programmed to operate +with one microsecond accuracy. All sources of hardware +interrupts were disabled, although traps were enabled and the +interrupt level of the SPARC allows all interrupts. + +@ifinfo +@node ERC32 Timing Data Interrupt Latency, ERC32 Timing Data Context Switch, ERC32 Timing Data Hardware Platform, ERC32 Timing Data +@end ifinfo +@section Interrupt Latency + +The maximum period with traps disabled or the +processor interrupt level set to it's highest value inside RTEMS +is less than RTEMS_MAXIMUM_DISABLE_PERIOD +microseconds including the instructions which +disable and re-enable interrupts. The time required for the +ERC32 to vector an interrupt and for the RTEMS entry overhead +before invoking the user's trap handler are a total of +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. These combine to yield a worst case interrupt +latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD + +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz. +[NOTE: The maximum period with interrupts disabled was last +determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +The maximum period with interrupts disabled within +RTEMS is hand-timed with some assistance from SIS. The maximum +period with interrupts disabled with RTEMS occurs during a +context switch when traps are disabled to flush all the register +windows to memory. The length of time spent flushing the +register windows varies based on the number of windows which +must be flushed. Based on the information reported by SIS, it +takes from 4.0 to 18.0 microseconds (37 to 122 instructions) to +flush the register windows. It takes approximately 41 CPU +cycles (2.73 microseconds) to flush each register window set to +memory. The register window flush operation is heavily memory +bound. + +[NOTE: All traps are disabled during the register +window flush thus disabling both software generate traps and +external interrupts. During a normal RTEMS critical section, +the processor interrupt level (pil) is raised to level 15 and +traps are left enabled. The longest path for a normal critical +section within RTEMS is less than 50 instructions.] + +The interrupt vector and entry overhead time was +generated on the SIS benchmark platform using the ERC32's +ability to forcibly generate an arbitrary interrupt as the +source of the "benchmark" interrupt. + +@ifinfo +@node ERC32 Timing Data Context Switch, RTEMS_CPU_MODEL Timing Data Directive Times, ERC32 Timing Data Interrupt Latency, ERC32 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is 10 +microseconds on the SIS benchmark platform when no floating +point context is saved or restored. Additional execution time +is required when a TASK_SWITCH user extension is configured. +The use of the TASK_SWITCH extension is application dependent. +Thus, its execution time is not considered part of the raw +context switch time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. The state of +the numeric coprocessor is only saved when an FLOATING_POINT +task is dispatched and that task was not the last task to +utilize the coprocessor. In a system with only one +FLOATING_POINT task, the state of the numeric coprocessor will +never be saved or restored. When the first FLOATING_POINT task +is dispatched, RTEMS does not need to save the current state of +the numeric coprocessor. + +The following table summarizes the context switch +times for the ERC32 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex + + |