diff options
Diffstat (limited to 'doc/supplements/hppa1_1')
-rw-r--r-- | doc/supplements/hppa1_1/Makefile | 88 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/SIMHPPA_TIMES | 244 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/TIMES | 244 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/bsp.t | 70 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/bsp.texi | 70 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/callconv.t | 172 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/callconv.texi | 172 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/cpumodel.t | 69 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/cpumodel.texi | 69 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/cputable.t | 124 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/cputable.texi | 124 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/fatalerr.t | 45 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/fatalerr.texi | 45 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/hppa1_1.texi | 118 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/intr.t | 214 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/intr_NOTIMES.t | 214 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/memmodel.t | 80 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/memmodel.texi | 80 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/preface.texi | 34 | ||||
-rw-r--r-- | doc/supplements/hppa1_1/timedata.t | 105 |
20 files changed, 2381 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. + |