From ae68ff085724dd35d60151bd153e80b8b0776873 Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Tue, 27 May 1997 12:40:11 +0000 Subject: Initial revision --- doc/supplements/m68k/MVME136_TIMES | 244 ++++++++++++++++++++++++++++++++++++ doc/supplements/m68k/Makefile | 87 +++++++++++++ doc/supplements/m68k/bsp.t | 110 ++++++++++++++++ doc/supplements/m68k/callconv.t | 121 ++++++++++++++++++ doc/supplements/m68k/cpumodel.t | 128 +++++++++++++++++++ doc/supplements/m68k/cputable.t | 118 +++++++++++++++++ doc/supplements/m68k/fatalerr.t | 44 +++++++ doc/supplements/m68k/intr_NOTIMES.t | 230 +++++++++++++++++++++++++++++++++ doc/supplements/m68k/m68k.texi | 118 +++++++++++++++++ doc/supplements/m68k/memmodel.t | 52 ++++++++ doc/supplements/m68k/preface.texi | 58 +++++++++ doc/supplements/m68k/timeMVME136.t | 143 +++++++++++++++++++++ doc/supplements/m68k/timedata.t | 143 +++++++++++++++++++++ 13 files changed, 1596 insertions(+) create mode 100644 doc/supplements/m68k/MVME136_TIMES create mode 100644 doc/supplements/m68k/Makefile create mode 100644 doc/supplements/m68k/bsp.t create mode 100644 doc/supplements/m68k/callconv.t create mode 100644 doc/supplements/m68k/cpumodel.t create mode 100644 doc/supplements/m68k/cputable.t create mode 100644 doc/supplements/m68k/fatalerr.t create mode 100644 doc/supplements/m68k/intr_NOTIMES.t create mode 100644 doc/supplements/m68k/m68k.texi create mode 100644 doc/supplements/m68k/memmodel.t create mode 100644 doc/supplements/m68k/preface.texi create mode 100644 doc/supplements/m68k/timeMVME136.t create mode 100644 doc/supplements/m68k/timedata.t (limited to 'doc/supplements/m68k') diff --git a/doc/supplements/m68k/MVME136_TIMES b/doc/supplements/m68k/MVME136_TIMES new file mode 100644 index 0000000000..3faa666049 --- /dev/null +++ b/doc/supplements/m68k/MVME136_TIMES @@ -0,0 +1,244 @@ +# +# M68020/MVME136 Timing and Size Information +# + +# +# CPU Model Information +# +RTEMS_CPU_MODEL MC68020 +# +# Interrupt Latency +# +# NOTE: In general, the text says it is hand-calculated to be +# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ +# Mhz and this was last calculated for Release +# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. +# +RTEMS_MAXIMUM_DISABLE_PERIOD TBD +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20 +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.2.1 +# +# Context Switch Times +# +RTEMS_NO_FP_CONTEXTS 35 +RTEMS_RESTORE_1ST_FP_TASK 39 +RTEMS_SAVE_INIT_RESTORE_INIT 66 +RTEMS_SAVE_IDLE_RESTORE_INIT 66 +RTEMS_SAVE_IDLE_RESTORE_IDLE 68 +# +# Task Manager Times +# +RTEMS_TASK_CREATE_ONLY 148 +RTEMS_TASK_IDENT_ONLY 350 +RTEMS_TASK_START_ONLY 76 +RTEMS_TASK_RESTART_CALLING_TASK 95 +RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89 +RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124 +RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92 +RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125 +RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149 +RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142 +RTEMS_TASK_DELETE_CALLING_TASK 170 +RTEMS_TASK_DELETE_SUSPENDED_TASK 138 +RTEMS_TASK_DELETE_BLOCKED_TASK 143 +RTEMS_TASK_DELETE_READY_TASK 144 +RTEMS_TASK_SUSPEND_CALLING_TASK 71 +RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43 +RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45 +RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67 +RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31 +RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64 +RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106 +RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14 +RTEMS_TASK_MODE_NO_RESCHEDULE 16 +RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23 +RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60 +RTEMS_TASK_GET_NOTE_ONLY 33 +RTEMS_TASK_SET_NOTE_ONLY 33 +RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16 +RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56 +RTEMS_TASK_WAKE_WHEN_ONLY 117 +# +# Interrupt Manager +# +RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 +RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9 +RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9 +RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1 +RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8 +RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54 +# +# Clock Manager +# +RTEMS_CLOCK_SET_ONLY 86 +RTEMS_CLOCK_GET_ONLY 1 +RTEMS_CLOCK_TICK_ONLY 17 +# +# Timer Manager +# +RTEMS_TIMER_CREATE_ONLY 28 +RTEMS_TIMER_IDENT_ONLY 343 +RTEMS_TIMER_DELETE_INACTIVE 43 +RTEMS_TIMER_DELETE_ACTIVE 47 +RTEMS_TIMER_FIRE_AFTER_INACTIVE 58 +RTEMS_TIMER_FIRE_AFTER_ACTIVE 61 +RTEMS_TIMER_FIRE_WHEN_INACTIVE 88 +RTEMS_TIMER_FIRE_WHEN_ACTIVE 88 +RTEMS_TIMER_RESET_INACTIVE 54 +RTEMS_TIMER_RESET_ACTIVE 58 +RTEMS_TIMER_CANCEL_INACTIVE 31 +RTEMS_TIMER_CANCEL_ACTIVE 34 +# +# Semaphore Manager +# +RTEMS_SEMAPHORE_CREATE_ONLY 60 +RTEMS_SEMAPHORE_IDENT_ONLY 367 +RTEMS_SEMAPHORE_DELETE_ONLY 58 +RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38 +RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109 +RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66 +RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87 +# +# Message Manager +# +RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200 +RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341 +RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80 +RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101 +RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123 +RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101 +RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123 +RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111 +RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133 +RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43 +RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114 +RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 +RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39 +# +# Event Manager +# +RTEMS_EVENT_SEND_NO_TASK_READIED 24 +RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 +RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 +RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 +RTEMS_EVENT_RECEIVE_AVAILABLE 28 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23 +RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84 +# +# Signal Manager +# +RTEMS_SIGNAL_CATCH_ONLY 15 +RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37 +RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37 +RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54 +# +# Partition Manager +# +RTEMS_PARTITION_CREATE_ONLY 70 +RTEMS_PARTITION_IDENT_ONLY 341 +RTEMS_PARTITION_DELETE_ONLY 42 +RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35 +RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 +RTEMS_PARTITION_RETURN_BUFFER_ONLY 43 +# +# Region Manager +# +RTEMS_REGION_CREATE_ONLY 63 +RTEMS_REGION_IDENT_ONLY 348 +RTEMS_REGION_DELETE_ONLY 39 +RTEMS_REGION_GET_SEGMENT_AVAILABLE 52 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49 +RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123 +RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114 +RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136 +# +# Dual-Ported Memory Manager +# +RTEMS_PORT_CREATE_ONLY 35 +RTEMS_PORT_IDENT_ONLY 340 +RTEMS_PORT_DELETE_ONLY 39 +RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 +RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27 +# +# IO Manager +# +RTEMS_IO_INITIALIZE_ONLY 4 +RTEMS_IO_OPEN_ONLY 2 +RTEMS_IO_CLOSE_ONLY 1 +RTEMS_IO_READ_ONLY 2 +RTEMS_IO_WRITE_ONLY 3 +RTEMS_IO_CONTROL_ONLY 2 +# +# Rate Monotonic Manager +# +RTEMS_RATE_MONOTONIC_CREATE_ONLY 32 +RTEMS_RATE_MONOTONIC_IDENT_ONLY 341 +RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 +RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51 +RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48 +RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54 +RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74 +RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31 +# +# Size Information +# +# +# xxx alloted for numbers +# +RTEMS_DATA_SPACE 723 +RTEMS_MINIMUM_CONFIGURATION 18,980 +RTEMS_MAXIMUM_CONFIGURATION 36,438 +# x,xxx alloted for numbers +RTEMS_CORE_CODE_SIZE 12,674 +RTEMS_INITIALIZATION_CODE_SIZE 970 +RTEMS_TASK_CODE_SIZE 3,562 +RTEMS_INTERRUPT_CODE_SIZE 54 +RTEMS_CLOCK_CODE_SIZE 334 +RTEMS_TIMER_CODE_SIZE 1,110 +RTEMS_SEMAPHORE_CODE_SIZE 1,632 +RTEMS_MESSAGE_CODE_SIZE 1,754 +RTEMS_EVENT_CODE_SIZE 1,000 +RTEMS_SIGNAL_CODE_SIZE 418 +RTEMS_PARTITION_CODE_SIZE 1,164 +RTEMS_REGION_CODE_SIZE 1,494 +RTEMS_DPMEM_CODE_SIZE 724 +RTEMS_IO_CODE_SIZE 686 +RTEMS_FATAL_ERROR_CODE_SIZE 24 +RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212 +RTEMS_MULTIPROCESSING_CODE_SIZE 6.952 +# xxx alloted for numbers +RTEMS_TIMER_CODE_OPTSIZE 184 +RTEMS_SEMAPHORE_CODE_OPTSIZE 172 +RTEMS_MESSAGE_CODE_OPTSIZE 288 +RTEMS_EVENT_CODE_OPTSIZE 56 +RTEMS_SIGNAL_CODE_OPTSIZE 56 +RTEMS_PARTITION_CODE_OPTSIZE 132 +RTEMS_REGION_CODE_OPTSIZE 160 +RTEMS_DPMEM_CODE_OPTSIZE 132 +RTEMS_IO_CODE_OPTSIZE 0 +RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184 +RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332 +# xxx alloted for numbers +RTEMS_BYTES_PER_TASK 400 +RTEMS_BYTES_PER_TIMER 68 +RTEMS_BYTES_PER_SEMAPHORE 124 +RTEMS_BYTES_PER_MESSAGE_QUEUE 148 +RTEMS_BYTES_PER_REGION 144 +RTEMS_BYTES_PER_PARTITION 56 +RTEMS_BYTES_PER_PORT 36 +RTEMS_BYTES_PER_PERIOD 36 +RTEMS_BYTES_PER_EXTENSION 64 +RTEMS_BYTES_PER_FP_TASK 332 +RTEMS_BYTES_PER_NODE 48 +RTEMS_BYTES_PER_GLOBAL_OBJECT 20 +RTEMS_BYTES_PER_PROXY 124 +# x,xxx alloted for numbers +RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872 diff --git a/doc/supplements/m68k/Makefile b/doc/supplements/m68k/Makefile new file mode 100644 index 0000000000..94a56dcf99 --- /dev/null +++ b/doc/supplements/m68k/Makefile @@ -0,0 +1,87 @@ +# +# COPYRIGHT (c) 1996. +# On-Line Applications Research Corporation (OAR). +# All rights reserved. +# + +include ../Make.config + +PROJECT=m68k +REPLACE=../tools/word-replace + +all: + +COMMON_FILES=../common/cpright.texi ../common/setup.texi \ + ../common/timing.texi + +FILES= $(PROJECT).texi \ + bsp.texi callconv.texi cpumodel.texi cputable.texi fatalerr.texi \ + intr.texi memmodel.texi preface.texi timetbl.texi timedata.texi wksheets.texi + +all: + +info: c_m68k + cp c_$(PROJECT) c_$(PROJECT)-* $(INFO_INSTALL) + +c_m68k: $(FILES) + $(MAKEINFO) $(PROJECT).texi + +vinfo: info + $(INFO) -f c_m68k + +dvi: $(PROJECT).dvi +ps: $(PROJECT).ps + +$(PROJECT).ps: $(PROJECT).dvi + dvips -o $(PROJECT).ps $(PROJECT).dvi + cp $(PROJECT).ps $(PS_INSTALL) + +dv: dvi + $(XDVI) $(PROJECT).dvi + +view: ps + $(GHOSTVIEW) $(PROJECT).ps + +$(PROJECT).dvi: $(FILES) + $(TEXI2DVI) $(PROJECT).texi + +replace: timedata.texi + +intr.texi: intr.t MVME136_TIMES + ${REPLACE} -p MVME136_TIMES intr.t + mv intr.t.fixed intr.texi + +timetbl.t: ../common/timetbl.t + sed -e 's/TIMETABLE_NEXT_LINK/Command and Variable Index/' \ + <../common/timetbl.t >timetbl.t + +timetbl.texi: timetbl.t MVME136_TIMES + ${REPLACE} -p MVME136_TIMES timetbl.t + mv timetbl.t.fixed timetbl.texi + +timedata.texi: timedata.t MVME136_TIMES + ${REPLACE} -p MVME136_TIMES timedata.t + mv timedata.t.fixed timedata.texi + +wksheets.t: ../common/wksheets.t + sed -e 's/WORKSHEETS_PREVIOUS_LINK/Processor Dependent Information Table CPU Dependent Information Table/' \ + -e 's/WORKSHEETS_NEXT_LINK/MC68020 Timing Data/' \ + <../common/wksheets.t >wksheets.t + +wksheets.texi: wksheets.t MVME136_TIMES + ${REPLACE} -p MVME136_TIMES wksheets.t + mv wksheets.t.fixed wksheets.texi + +html: $(FILES) + -mkdir $(WWW_INSTALL)/c_m68k + $(TEXI2WWW) $(TEXI2WWW_ARGS) -dir $(WWW_INSTALL)/c_$(PROJECT) \ + $(PROJECT).texi + +clean: + rm -f *.o $(PROG) *.txt core + rm -f *.dvi *.ps *.log *.aux *.cp *.fn *.ky *.pg *.toc *.tp *.vr $(BASE) + rm -f $(PROJECT) $(PROJECT)-* + rm -f c_m68k c_m68k-* + rm -f timedata.texi timetbl.texi intr.texi wksheets.texi + rm -f timetbl.t wksheets.t + rm -f *.fixed _* diff --git a/doc/supplements/m68k/bsp.t b/doc/supplements/m68k/bsp.t new file mode 100644 index 0000000000..60c889c495 --- /dev/null +++ b/doc/supplements/m68k/bsp.t @@ -0,0 +1,110 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Board Support Packages, Board Support Packages Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Top +@end ifinfo +@chapter Board Support Packages +@ifinfo +@menu +* Board Support Packages Introduction:: +* Board Support Packages System Reset:: +* Board Support Packages Processor Initialization:: +@end menu +@end ifinfo + +@ifinfo +@node Board Support Packages Introduction, Board Support Packages System Reset, Board Support Packages, Board Support Packages +@end ifinfo +@section Introduction + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of MC68020 specific BSP +issues. For more information on developing a BSP, refer to the +chapter titled Board Support Packages in the RTEMS C +Applications User's Guide. + +@ifinfo +@node Board Support Packages System Reset, Board Support Packages Processor Initialization, Board Support Packages Introduction, Board Support Packages +@end ifinfo +@section System Reset + +An RTEMS based application is initiated or +re-initiated when the MC68020 processor is reset. When the +MC68020 is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@ifinfo +@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages +@end ifinfo +@section Processor Initialization + +The address of the application's initialization code +should be stored in the first vector of the EVT which will allow +the immediate vectoring to the application code. If the +application requires that the VBR be some value besides zero, +then it should be set to the required value at this point. All +tasks share the same MC68020's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure correct interrupt vectoring. If processor +caching is to be utilized, then it should be enabled during the +reset application initialization code. + +In addition to the requirements described in the +Board Support Packages chapter of the C Applications User's +Manual for the reset code which is executed before the call to +initialize executive, the MC68020 version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the MC68020 remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +MC68020 from the interrupt state. + +@item Must set the master stack pointer (MSP) such that a +minimum stack size of MINIMUM_STACK_SIZE bytes is provided for +the initialize executive directive. + +@item Must initialize the MC68020's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + diff --git a/doc/supplements/m68k/callconv.t b/doc/supplements/m68k/callconv.t new file mode 100644 index 0000000000..2bcc2188fa --- /dev/null +++ b/doc/supplements/m68k/callconv.t @@ -0,0 +1,121 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Extend Byte to Long Instruction, Top +@end ifinfo +@chapter Calling Conventions +@ifinfo +@menu +* Calling Conventions Introduction:: +* Calling Conventions Processor Background:: +* Calling Conventions Calling Mechanism:: +* Calling Conventions Register Usage:: +* Calling Conventions Parameter Passing:: +* Calling Conventions User-Provided Routines:: +@end menu +@end ifinfo + +@ifinfo +@node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions +@end ifinfo +@section Introduction + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@ifinfo +@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions +@end ifinfo +@section Processor Background + +The MC68xxx architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the branch to subroutine (bsr) or the jump to subroutine +(jsr) instructions. These instructions push the return address +on the current stack. The return from subroutine (rts) +instruction pops the return address off the current stack and +transfers control to that instruction. It is is important to +note that the MC68xxx call and return mechanism does not +automatically save or restore any registers. It is the +responsibility of the high-level language compiler to define the +register preservation and usage convention. + +@ifinfo +@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions +@end ifinfo +@section Calling Mechanism + +All RTEMS directives are invoked using either a bsr +or jsr instruction and return to the user application via the +rts instruction. + +@ifinfo +@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions +@end ifinfo +@section Register Usage + +As discussed above, the bsr and jsr instructions do +not automatically save any registers. RTEMS uses the registers +D0, D1, A0, and A1 as scratch registers. These registers are +not preserved by RTEMS directives therefore, the contents of +these registers should not be assumed upon return from any RTEMS +directive. + +@ifinfo +@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions +@end ifinfo +@section Parameter Passing + +RTEMS assumes that arguments are placed on the +current stack before the directive is invoked via the bsr or jsr +instruction. The first argument is assumed to be closest to the +return address on the stack. This means that the first argument +of the C calling sequence is pushed last. The following +pseudo-code illustrates the typical sequence used to call a +RTEMS directive with three (3) arguments: + +@example +@group +push third argument +push second argument +push first argument +invoke directive +remove arguments from the stack +@end group +@end example + +The arguments to RTEMS are typically pushed onto the +stack using a move instruction with a pre-decremented stack +pointer as the destination. These arguments must be removed +from the stack after control is returned to the caller. This +removal is typically accomplished by adding the size of the +argument list in bytes to the current stack pointer. + +@ifinfo +@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions +@end ifinfo +@section User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + diff --git a/doc/supplements/m68k/cpumodel.t b/doc/supplements/m68k/cpumodel.t new file mode 100644 index 0000000000..becfcf123d --- /dev/null +++ b/doc/supplements/m68k/cpumodel.t @@ -0,0 +1,128 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node CPU Model Dependent Features, CPU Model Dependent Features Introduction, Preface, Top +@end ifinfo +@chapter CPU Model Dependent Features +@ifinfo +@menu +* CPU Model Dependent Features Introduction:: +* CPU Model Dependent Features CPU Model Name:: +* CPU Model Dependent Features Floating Point Unit:: +* CPU Model Dependent Features BFFFO Instruction:: +* CPU Model Dependent Features Vector Base Register:: +* CPU Model Dependent Features Separate Stacks:: +* CPU Model Dependent Features Pre-Indexing Address Mode:: +* CPU Model Dependent Features Extend Byte to Long Instruction:: +@end menu +@end ifinfo + +@ifinfo +@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features, CPU Model Dependent Features +@end ifinfo +@section Introduction + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +SPARC or PA-RISC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across SPARC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +c/src/exec/score/cpu/m68k/m68k.h based upon the particular CPU +model defined on the compilation command line. + +@ifinfo +@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features Introduction, CPU Model Dependent Features +@end ifinfo +@section CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the MC68020 +processor, this macro is set to the string "mc68020". + +@ifinfo +@node CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features +@end ifinfo +@section Floating Point Unit + +The macro M68K_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. It does not matter whether the hardware floating +point support is incorporated on-chip or is an external +coprocessor. + +@ifinfo +@node CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features +@end ifinfo +@section BFFFO Instruction + +The macro M68K_HAS_BFFFO is set to 1 to indicate that +this CPU model has the bfffo instruction. + +@ifinfo +@node CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features BFFFO Instruction, CPU Model Dependent Features +@end ifinfo +@section Vector Base Register + +The macro M68K_HAS_VBR is set to 1 to indicate that +this CPU model has a vector base register (vbr). + +@ifinfo +@node CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features Vector Base Register, CPU Model Dependent Features +@end ifinfo +@section Separate Stacks + +The macro M68K_HAS_SEPARATE_STACKS is set to 1 to +indicate that this CPU model has separate interrupt, user, and +supervisor mode stacks. + +@ifinfo +@node CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features Extend Byte to Long Instruction, CPU Model Dependent Features Separate Stacks, CPU Model Dependent Features +@end ifinfo +@section Pre-Indexing Address Mode + +The macro M68K_HAS_PREINDEXING is set to 1 to indicate that +this CPU model has the pre-indexing address mode. + +@ifinfo +@node CPU Model Dependent Features Extend Byte to Long Instruction, Calling Conventions, CPU Model Dependent Features Pre-Indexing Address Mode, CPU Model Dependent Features +@end ifinfo +@section Extend Byte to Long Instruction + +The macro M68K_HAS_EXTB_L is set to 1 to indicate that this CPU model +has the extb.l instruction. This instruction is supposed to be available +in all models based on the cpu32 core as well as mc68020 and up models. diff --git a/doc/supplements/m68k/cputable.t b/doc/supplements/m68k/cputable.t new file mode 100644 index 0000000000..0119084d32 --- /dev/null +++ b/doc/supplements/m68k/cputable.t @@ -0,0 +1,118 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Processor Dependent Information Table, Processor Dependent Information Table Introduction, Board Support Packages Processor Initialization, Top +@end ifinfo +@chapter Processor Dependent Information Table +@ifinfo +@menu +* Processor Dependent Information Table Introduction:: +* Processor Dependent Information Table CPU Dependent Information Table:: +@end menu +@end ifinfo + +@ifinfo +@node Processor Dependent Information Table Introduction, Processor Dependent Information Table CPU Dependent Information Table, Processor Dependent Information Table, Processor Dependent Information Table +@end ifinfo +@section Introduction + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@ifinfo +@node Processor Dependent Information Table CPU Dependent Information Table, Memory Requirements, Processor Dependent Information Table Introduction, Processor Dependent Information Table +@end ifinfo +@section CPU Dependent Information Table + +The MC68xxx version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the MC68xxx. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +struct cpu_configuration_table @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + m68k_isr *interrupt_vector_table; +@}; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the +user provided routine which is invoked once RTEMS initialization +is complete but before interrupts and tasking are enabled. This +field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately before +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +but no device drivers are initialized. This field may be NULL to +indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine which is invoked with tasking enabled immediately after +the MPCI and device drivers are initialized. RTEMS +initialization is complete, interrupts and tasking are enabled, +and the device drivers are initialized. This field may be NULL +to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item interrupt_vector_table +is the base address of the CPU's Exception Vector Table. + +@end table diff --git a/doc/supplements/m68k/fatalerr.t b/doc/supplements/m68k/fatalerr.t new file mode 100644 index 0000000000..5b94c7a9c9 --- /dev/null +++ b/doc/supplements/m68k/fatalerr.t @@ -0,0 +1,44 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Default Fatal Error Processing, Default Fatal Error Processing Introduction, Interrupt Processing Interrupt Stack, Top +@end ifinfo +@chapter Default Fatal Error Processing +@ifinfo +@menu +* Default Fatal Error Processing Introduction:: +* Default Fatal Error Processing Default Fatal Error Handler Operations:: +@end menu +@end ifinfo + +@ifinfo +@node Default Fatal Error Processing Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Default Fatal Error Processing, Default Fatal Error Processing +@end ifinfo +@section Introduction + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@ifinfo +@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing +@end ifinfo +@section Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts to +level 7, places the error code in D0, and executes a stop +instruction to simulate a halt processor instruction. + diff --git a/doc/supplements/m68k/intr_NOTIMES.t b/doc/supplements/m68k/intr_NOTIMES.t new file mode 100644 index 0000000000..07e51b0116 --- /dev/null +++ b/doc/supplements/m68k/intr_NOTIMES.t @@ -0,0 +1,230 @@ +@c +@c +@c Interrupt Stack Frame Picture +@c + +@ifinfo +@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top +@end ifinfo +@chapter Interrupt Processing +@ifinfo +@menu +* Interrupt Processing Introduction:: +* Interrupt Processing Vectoring of an Interrupt Handler:: +* Interrupt Processing Interrupt Levels:: +* Interrupt Processing Disabling of Interrupts by RTEMS:: +* Interrupt Processing Interrupt Stack:: +@end menu +@end ifinfo + +@ifinfo +@node Interrupt Processing Introduction, Interrupt Processing Vectoring of an Interrupt Handler, Interrupt Processing, Interrupt Processing +@end ifinfo +@section Introduction + +Different types of processors respond to the +occurrence of an interrupt in its own unique fashion. In +addition, each processor type provides a control mechanism to +allow for the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the current +execution state and results in a change in the execution stream. +Most processors require that an interrupt handler utilize some +special control mechanisms to return to the normal processing +stream. Although RTEMS hides many of the processor dependent +details of interrupt processing, it is important to understand +how the RTEMS interrupt manager is mapped onto the processor's +unique architecture. Discussed in this chapter are the MC68xxx's +interrupt response and control mechanisms as they pertain to +RTEMS. + +@ifinfo +@node Interrupt Processing Vectoring of an Interrupt Handler, Models Without Separate Interrupt Stacks, Interrupt Processing Introduction, Interrupt Processing +@end ifinfo +@section Vectoring of an Interrupt Handler +@ifinfo +@menu +* Models Without Separate Interrupt Stacks:: +* Models With Separate Interrupt Stacks:: +@end menu +@end ifinfo + +Depending on whether or not the particular CPU +supports a separate interrupt stack, the MC68xxx family has two +different interrupt handling models. + +@ifinfo +@node Models Without Separate Interrupt Stacks, Models With Separate Interrupt Stacks, Interrupt Processing Vectoring of an Interrupt Handler, Interrupt Processing Vectoring of an Interrupt Handler +@end ifinfo +@subsection Models Without Separate Interrupt Stacks + +Upon receipt of an interrupt the MC68xxx family +members without separate interrupt stacks automatically perform +the following actions: + +@itemize @bullet +@item To Be Written +@end itemize + +@ifinfo +@node Models With Separate Interrupt Stacks, Interrupt Processing Interrupt Levels, Models Without Separate Interrupt Stacks, Interrupt Processing Vectoring of an Interrupt Handler +@end ifinfo +@subsection Models With Separate Interrupt Stacks + +Upon receipt of an interrupt the MC68xxx family +members with separate interrupt stacks automatically perform the +following actions: + +@itemize @bullet +@item saves the current status register (SR), + +@item clears the master/interrupt (M) bit of the SR to +indicate the switch from master state to interrupt state, + +@item sets the privilege mode to supervisor, + +@item suppresses tracing, + +@item sets the interrupt mask level equal to the level of the +interrupt being serviced, + +@item pushes an interrupt stack frame (ISF), which includes +the program counter (PC), the status register (SR), and the +format/exception vector offset (FVO) word, onto the supervisor +and interrupt stacks, + +@item switches the current stack to the interrupt stack and +vectors to an interrupt service routine (ISR). If the ISR was +installed with the interrupt_catch directive, then the RTEMS +interrupt handler will begin execution. The RTEMS interrupt +handler saves all registers which are not preserved according to +the calling conventions and invokes the application's ISR. +@end itemize + +A nested interrupt is processed similarly by these +CPU models with the exception that only a single ISF is placed +on the interrupt stack and the current stack need not be +switched. + +The FVO word in the Interrupt Stack Frame is examined +by RTEMS to determine when an outer most interrupt is being +exited. Since the FVO is used by RTEMS for this purpose, the +user application code MUST NOT modify this field. + +The following shows the Interrupt Stack Frame for +MC68xxx CPU models with separate interrupt stacks: + +@ifset use-ascii +@example +@group + +----------------------+ + | Status Register | 0x0 + +----------------------+ + | Program Counter High | 0x2 + +----------------------+ + | Program Counter Low | 0x4 + +----------------------+ + | Format/Vector Offset | 0x6 + +----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\strut\vrule#& +\hbox to 2.00in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 0.50in{\enskip\hfil#\hfil} +\cr +\multispan{3}\hrulefill\cr +& Status Register && 0x0\cr +\multispan{3}\hrulefill\cr +& Program Counter High && 0x2\cr +\multispan{3}\hrulefill\cr +& Program Counter Low && 0x4\cr +\multispan{3}\hrulefill\cr +& Format/Vector Offset && 0x6\cr +\multispan{3}\hrulefill\cr +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + +
Status Register0x0
Program Counter High0x2
Program Counter Low0x4
Format/Vector Offset0x6
+
+@end html +@end ifset + +@ifinfo +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Models With Separate Interrupt Stacks, Interrupt Processing +@end ifinfo +@section Interrupt Levels + +Eight levels (0-7) of interrupt priorities are +supported by MC68xxx family members with level seven (7) being +the highest priority. Level zero (0) indicates that interrupts +are fully enabled. Interrupt requests for interrupts with +priorities less than or equal to the current interrupt mask +level are ignored. + +Although RTEMS supports 256 interrupt levels, the +MC68xxx family only supports eight. RTEMS interrupt levels 0 +through 7 directly correspond to MC68xxx interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@ifinfo +@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing +@end ifinfo +@section Disabling of Interrupts by RTEMS + +During the execution of directive calls, critical +sections of code may be executed. When these sections are +encountered, RTEMS disables interrupts to level seven (7) before +the execution of this section and restores them to the previous +level upon completion of the section. RTEMS has been optimized +to insure that interrupts are disabled for less than +RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz MC68020 with +zero wait states. These numbers will vary based the +number of wait states and processor speed present on the target board. +[NOTE: The maximum period with interrupts disabled is hand calculated. This +calculation was last performed for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +Non-maskable interrupts (NMI) cannot be disabled, and +ISRs which execute at this level MUST NEVER issue RTEMS system +calls. If a directive is invoked, unpredictable results may +occur due to the inability of RTEMS to protect its critical +sections. However, ISRs that make no system calls may safely +execute as non-maskable interrupts. + +@ifinfo +@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing +@end ifinfo +@section Interrupt Stack + +RTEMS allocates the interrupt stack from the +Workspace Area. The amount of memory allocated for the +interrupt stack is determined by the interrupt_stack_size field +in the CPU Configuration Table. During the initialization +process, RTEMS will install its interrupt stack. + +The MC68xxx port of RTEMS supports a software managed +dedicated interrupt stack on those CPU models which do not +support a separate interrupt stack in hardware. + + diff --git a/doc/supplements/m68k/m68k.texi b/doc/supplements/m68k/m68k.texi new file mode 100644 index 0000000000..157dabb594 --- /dev/null +++ b/doc/supplements/m68k/m68k.texi @@ -0,0 +1,118 @@ +\input ../texinfo/texinfo @c -*-texinfo-*- +@c %**start of header +@setfilename c_m68k +@syncodeindex vr fn +@synindex ky cp +@paragraphindent 0 +@c @smallbook +@c %**end of header + +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@c +@c Master file for the Motorola MC68xxx C Applications Supplement +@c + +@include ../common/setup.texi + +@ignore +@ifinfo +@format +START-INFO-DIR-ENTRY +* RTEMS Motorola MC68xxx C Applications Supplement (m68k): +END-INFO-DIR-ENTRY +@end format +@end ifinfo +@end ignore + +@c +@c Title Page Stuff +@c + +@set edition 4.0.0a +@set update-date 25 April 1997 +@set update-month April 1997 + +@c +@c I don't really like having a short title page. --joel +@c +@c @shorttitlepage RTEMS Motorola MC68xxx C Applications Supplement + +@setchapternewpage odd +@settitle RTEMS Motorola MC68xxx C Applications Supplement +@titlepage +@finalout + +@title RTEMS Motorola MC68xxx C Supplement +@subtitle Edition @value{edition}, for RTEMS 4.0.0 +@sp 1 +@subtitle @value{update-month} +@author On-Line Applications Research Corporation +@page + +@include ../common/cpright.texi +@end titlepage + +@c This prevents a black box from being printed on "overflow" lines. +@c The alternative is to rework a sentence to avoid this problem. + +@include preface.texi +@include cpumodel.texi +@include callconv.texi +@include memmodel.texi +@include intr.texi +@include fatalerr.texi +@include bsp.texi +@include cputable.texi +@include wksheets.texi +@include ../common/timing.texi +@include timedata.texi +@ifinfo +@node Top, Preface, (dir), (dir) +@top c_m68k + +This is the online version of the RTEMS Motorola MC68xxx C +Applications Supplement. + +@menu +* Preface:: +* CPU Model Dependent Features:: +* Calling Conventions:: +* Memory Model:: +* Interrupt Processing:: +* Default Fatal Error Processing:: +* Board Support Packages:: +* Processor Dependent Information Table:: +* Memory Requirements:: +* Timing Specification:: +* MC68020 Timing Data:: +* Command and Variable Index:: +* Concept Index:: +@end menu + +@end ifinfo +@c +@c +@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here +@c + +@node Command and Variable Index, Concept Index, MC68020 Timing Data Rate Monotonic Manager, Top +@unnumbered Command and Variable Index + +There are currently no Command and Variable Index entries. + +@c @printindex fn + +@node Concept Index, , Command and Variable Index, Top +@unnumbered Concept Index + +There are currently no Concept Index entries. +@c @printindex cp + +@c @contents +@bye + diff --git a/doc/supplements/m68k/memmodel.t b/doc/supplements/m68k/memmodel.t new file mode 100644 index 0000000000..91ccf8010d --- /dev/null +++ b/doc/supplements/m68k/memmodel.t @@ -0,0 +1,52 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top +@end ifinfo +@chapter Memory Model +@ifinfo +@menu +* Memory Model Introduction:: +* Memory Model Flat Memory Model:: +@end menu +@end ifinfo + +@ifinfo +@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model +@end ifinfo +@section Introduction + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@ifinfo +@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model +@end ifinfo +@section Flat Memory Model + +The MC68xxx family supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +is byte addressable. The address may be used to reference a +single byte, word (2-bytes), or long word (4 bytes). Memory +accesses within this address space are performed in big endian +fashion by the processors in this family. + +Some of the MC68xxx family members such as the +MC68020, MC68030, and MC68040 support virtual memory and +segmentation. The MC68020 requires external hardware support +such as the MC68851 Paged Memory Management Unit coprocessor +which is typically used to perform address translations for +these systems. RTEMS does not support virtual memory or +segmentation on any of the MC68xxx family members. + diff --git a/doc/supplements/m68k/preface.texi b/doc/supplements/m68k/preface.texi new file mode 100644 index 0000000000..e42754c347 --- /dev/null +++ b/doc/supplements/m68k/preface.texi @@ -0,0 +1,58 @@ +@c +@c COPYRIGHT (c) 1988-1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Preface, CPU Model Dependent Features, Top, Top +@end ifinfo +@unnumbered Preface + +The Real Time Executive for Multiprocessor Systems (RTEMS) +is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the Motorola MC68xxx +architecture dependencies in this port of RTEMS. The MC68xxx +family has a wide variety of CPU models within it. The part +numbers for these models are generally divided into MC680xx and +MC683xx. The MC680xx models are more general purpose processors +with no integrated peripherals. The MC683xx models, on the +other hand, are more specialized and have a variety of +peripherals on chip including sophisticated timers and serial +communications controllers. + +It is highly recommended that the Motorola MC68xxx +RTEMS application developer obtain and become familiar with the +documentation for the processor being used as well as the +documentation for the family as a whole. + +@subheading Architecture Documents + +For information on the Motorola MC68xxx architecture, +refer to the following documents available from Motorola +(@file{http//www.moto.com/}): + +@itemize @bullet +@item @cite{M68000 Family Reference, Motorola, FR68K/D}. +@end itemize + +@subheading MODEL SPECIFIC DOCUMENTS + +For information on specific processor models and +their associated coprocessors, refer to the following documents: + +@itemize @bullet +@item @cite{MC68020 User's Manual, Motorola, MC68020UM/AD}. + +@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's +Manual, Motorola, MC68881UM/AD}. +@end itemize + diff --git a/doc/supplements/m68k/timeMVME136.t b/doc/supplements/m68k/timeMVME136.t new file mode 100644 index 0000000000..fe99c38fef --- /dev/null +++ b/doc/supplements/m68k/timeMVME136.t @@ -0,0 +1,143 @@ + +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node MC68020 Timing Data, MC68020 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter MC68020 Timing Data +@ifinfo +@menu +* MC68020 Timing Data Introduction:: +* MC68020 Timing Data Hardware Platform:: +* MC68020 Timing Data Interrupt Latency:: +* MC68020 Timing Data Context Switch:: +* MC68020 Timing Data Directive Times:: +* MC68020 Timing Data Task Manager:: +* MC68020 Timing Data Interrupt Manager:: +* MC68020 Timing Data Clock Manager:: +* MC68020 Timing Data Timer Manager:: +* MC68020 Timing Data Semaphore Manager:: +* MC68020 Timing Data Message Manager:: +* MC68020 Timing Data Event Manager:: +* MC68020 Timing Data Signal Manager:: +* MC68020 Timing Data Partition Manager:: +* MC68020 Timing Data Region Manager:: +* MC68020 Timing Data Dual-Ported Memory Manager:: +* MC68020 Timing Data I/O Manager:: +* MC68020 Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +@ifinfo +@node MC68020 Timing Data Introduction, MC68020 Timing Data Hardware Platform, MC68020 Timing Data, MC68020 Timing Data +@end ifinfo +@section Introduction + +The timing data for the MC68020 version of RTEMS is +provided along with the target dependent aspects concerning the +gathering of the timing data. The hardware platform used to +gather the times is described to give the reader a better +understanding of each directive time provided. Also, provided +is a description of the interrupt latency and the context switch +times as they pertain to the MC68020 version of RTEMS. + +@ifinfo +@node MC68020 Timing Data Hardware Platform, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Introduction, MC68020 Timing Data +@end ifinfo +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Motorola +MVME135 CPU board. The MVME135 is a 20Mhz board with one wait +state dynamic memory and a MC68881 numeric coprocessor. The +Zilog 8036 countdown timer on this board was used to measure +elapsed time with a one-half microsecond resolution. All +sources of hardware interrupts were disabled, although the +interrupt level of the MC68020 allows all interrupts. + +The maximum period interrupts are disabled was +measured by summing the number of CPU cycles required by each +assembly language instruction executed while interrupts were +disabled. The worst case times of the MC68020 microprocessor +were used for each instruction. Zero wait state memory was +assumed. The total CPU cycles executed with interrupts +disabled, including the instructions to disable and enable +interrupts, was divided by 20 to simulate a 20Mhz MC68020. It +should be noted that the worst case instruction times for the +MC68020 assume that the internal cache is disabled and that no +instructions overlap. + +@ifinfo +@node MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Context Switch, MC68020 Timing Data Hardware Platform, MC68020 Timing Data +@end ifinfo +@section Interrupt Latency + +The maximum period with interrupts disabled within +RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD +microseconds including the instructions +which disable and re-enable interrupts. The time required for +the MC68020 to vector an interrupt and for the RTEMS entry +overhead before invoking the user's interrupt handler are a +total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. These combine to yield a worst case +interrupt latency of less than +RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds at 20Mhz. [NOTE: The maximum period with interrupts +disabled was last determined for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +It should be noted again that the maximum period with +interrupts disabled within RTEMS is hand-timed and based upon +worst case (i.e. CPU cache disabled and no instruction overlap) +times for a 20Mhz MC68020. The interrupt vector and entry +overhead time was generated on an MVME135 benchmark platform +using the Multiprocessing Communications registers to generate +as the interrupt source. + +@ifinfo +@node MC68020 Timing Data Context Switch, MC68020 Timing Data Directive Times, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the MVME135 benchmark platform when no floating +point context is saved or restored. Additional execution time +is required when a TASK_SWITCH user extension is configured. +The use of the TASK_SWITCH extension is application dependent. +Thus, its execution time is not considered part of the raw +context switch time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. The state of +the numeric coprocessor is only saved when an FLOATING_POINT +task is dispatched and that task was not the last task to +utilize the coprocessor. In a system with only one +FLOATING_POINT task, the state of the numeric coprocessor will +never be saved or restored. When the first FLOATING_POINT task +is dispatched, RTEMS does not need to save the current state of +the numeric coprocessor. + +The exact amount of time required to save and restore +floating point context is dependent on whether an MC68881 or +MC68882 is being used as well as the state of the numeric +coprocessor. These numeric coprocessors define three operating +states: initialized, idle, and busy. RTEMS places the +coprocessor in the initialized state when a task is started or +restarted. Once the task has utilized the coprocessor, it is in +the idle state when floating point instructions are not +executing and the busy state when floating point instructions +are executing. The state of the coprocessor is task specific. + +The following table summarizes the context switch +times for the MVME135 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex diff --git a/doc/supplements/m68k/timedata.t b/doc/supplements/m68k/timedata.t new file mode 100644 index 0000000000..fe99c38fef --- /dev/null +++ b/doc/supplements/m68k/timedata.t @@ -0,0 +1,143 @@ + +@include ../common/timemac.texi +@tex +\global\advance \smallskipamount by -4pt +@end tex + +@ifinfo +@node MC68020 Timing Data, MC68020 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top +@end ifinfo +@chapter MC68020 Timing Data +@ifinfo +@menu +* MC68020 Timing Data Introduction:: +* MC68020 Timing Data Hardware Platform:: +* MC68020 Timing Data Interrupt Latency:: +* MC68020 Timing Data Context Switch:: +* MC68020 Timing Data Directive Times:: +* MC68020 Timing Data Task Manager:: +* MC68020 Timing Data Interrupt Manager:: +* MC68020 Timing Data Clock Manager:: +* MC68020 Timing Data Timer Manager:: +* MC68020 Timing Data Semaphore Manager:: +* MC68020 Timing Data Message Manager:: +* MC68020 Timing Data Event Manager:: +* MC68020 Timing Data Signal Manager:: +* MC68020 Timing Data Partition Manager:: +* MC68020 Timing Data Region Manager:: +* MC68020 Timing Data Dual-Ported Memory Manager:: +* MC68020 Timing Data I/O Manager:: +* MC68020 Timing Data Rate Monotonic Manager:: +@end menu +@end ifinfo + +@ifinfo +@node MC68020 Timing Data Introduction, MC68020 Timing Data Hardware Platform, MC68020 Timing Data, MC68020 Timing Data +@end ifinfo +@section Introduction + +The timing data for the MC68020 version of RTEMS is +provided along with the target dependent aspects concerning the +gathering of the timing data. The hardware platform used to +gather the times is described to give the reader a better +understanding of each directive time provided. Also, provided +is a description of the interrupt latency and the context switch +times as they pertain to the MC68020 version of RTEMS. + +@ifinfo +@node MC68020 Timing Data Hardware Platform, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Introduction, MC68020 Timing Data +@end ifinfo +@section Hardware Platform + +All times reported except for the maximum period +interrupts are disabled by RTEMS were measured using a Motorola +MVME135 CPU board. The MVME135 is a 20Mhz board with one wait +state dynamic memory and a MC68881 numeric coprocessor. The +Zilog 8036 countdown timer on this board was used to measure +elapsed time with a one-half microsecond resolution. All +sources of hardware interrupts were disabled, although the +interrupt level of the MC68020 allows all interrupts. + +The maximum period interrupts are disabled was +measured by summing the number of CPU cycles required by each +assembly language instruction executed while interrupts were +disabled. The worst case times of the MC68020 microprocessor +were used for each instruction. Zero wait state memory was +assumed. The total CPU cycles executed with interrupts +disabled, including the instructions to disable and enable +interrupts, was divided by 20 to simulate a 20Mhz MC68020. It +should be noted that the worst case instruction times for the +MC68020 assume that the internal cache is disabled and that no +instructions overlap. + +@ifinfo +@node MC68020 Timing Data Interrupt Latency, MC68020 Timing Data Context Switch, MC68020 Timing Data Hardware Platform, MC68020 Timing Data +@end ifinfo +@section Interrupt Latency + +The maximum period with interrupts disabled within +RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD +microseconds including the instructions +which disable and re-enable interrupts. The time required for +the MC68020 to vector an interrupt and for the RTEMS entry +overhead before invoking the user's interrupt handler are a +total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds. These combine to yield a worst case +interrupt latency of less than +RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK +microseconds at 20Mhz. [NOTE: The maximum period with interrupts +disabled was last determined for Release +RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] + +It should be noted again that the maximum period with +interrupts disabled within RTEMS is hand-timed and based upon +worst case (i.e. CPU cache disabled and no instruction overlap) +times for a 20Mhz MC68020. The interrupt vector and entry +overhead time was generated on an MVME135 benchmark platform +using the Multiprocessing Communications registers to generate +as the interrupt source. + +@ifinfo +@node MC68020 Timing Data Context Switch, MC68020 Timing Data Directive Times, MC68020 Timing Data Interrupt Latency, MC68020 Timing Data +@end ifinfo +@section Context Switch + +The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS +microseconds on the MVME135 benchmark platform when no floating +point context is saved or restored. Additional execution time +is required when a TASK_SWITCH user extension is configured. +The use of the TASK_SWITCH extension is application dependent. +Thus, its execution time is not considered part of the raw +context switch time. + +Since RTEMS was designed specifically for embedded +missile applications which are floating point intensive, the +executive is optimized to avoid unnecessarily saving and +restoring the state of the numeric coprocessor. The state of +the numeric coprocessor is only saved when an FLOATING_POINT +task is dispatched and that task was not the last task to +utilize the coprocessor. In a system with only one +FLOATING_POINT task, the state of the numeric coprocessor will +never be saved or restored. When the first FLOATING_POINT task +is dispatched, RTEMS does not need to save the current state of +the numeric coprocessor. + +The exact amount of time required to save and restore +floating point context is dependent on whether an MC68881 or +MC68882 is being used as well as the state of the numeric +coprocessor. These numeric coprocessors define three operating +states: initialized, idle, and busy. RTEMS places the +coprocessor in the initialized state when a task is started or +restarted. Once the task has utilized the coprocessor, it is in +the idle state when floating point instructions are not +executing and the busy state when floating point instructions +are executing. The state of the coprocessor is task specific. + +The following table summarizes the context switch +times for the MVME135 benchmark platform: + +@include timetbl.texi + +@tex +\global\advance \smallskipamount by 4pt +@end tex -- cgit v1.2.3