Initial revision

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.
+