m68k-port.html

ecos3.0 beta 的官方文档,html格式

If so then the <CODE
CLASS="FUNCTION"
>HAL_VSR_SET</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_VSR_SET_TO_ECOS_HANDLER</CODE
> macros will not be
defined. Portable code may need to consider this possibility and test
for the existence of these macros before using them.
      </P
><P
>The architectural HAL provides an entry point
<CODE
CLASS="FUNCTION"
>hal_m68k_interrupt_vsr</CODE
> in the file
<TT
CLASS="FILENAME"
>hal_arch.S</TT
>. When an interrupt occurs the original
68000 pushed the program counter and the status register on to the
stack, and then called the VSR via the exception table. On newer
variants some additional information is pushed, including details of
the interrupt source. <CODE
CLASS="FUNCTION"
>hal_m68k_interrupt_vsr</CODE
>
assumes the latter and can be used directly as the VSR on these newer
variants. On older variants a small trampoline is needed which pushes
the additional information and then jumps to the generic VSR.
Interpreting the additional information is handled via an assembler
macro <CODE
CLASS="FUNCTION"
>hal_context_extract_isr_vector_shl2</CODE
> 
which should be defined by the variant, matching the behaviour of the
hardware or the trampoline.
      </P
><P
>At the architecture level there is no fixed mapping between VSR and
ISR vectors. Instead that is left to the variant or platform HAL. The
architectural HAL does provide default implementations of
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_ATTACH</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_DETACH</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_IN_USE</CODE
> since these just involve
updating a static table.
      </P
><P
>By default the interrupt state control macros
<CODE
CLASS="FUNCTION"
>HAL_DISABLE_INTERRUPTS</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_RESTORE_INTERRUPTS</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_ENABLE_INTERRUPTS</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_QUERY_INTERRUPTS</CODE
> are implemented by the
architectural HAL, and simply involve updating the status register.
Disabling interrupts involves setting the three IPL bits to 0x07.
Enabling interrupts involves setting those bits to a smaller value,
<CODE
CLASS="VARNAME"
>CYGNUM_HAL_INTERRUPT_DEFAULT_IPL_LEVEL</CODE
>, which
defaults to 0. 
      </P
><P
><CODE
CLASS="FUNCTION"
>HAL_DISABLE_INTERRUPTS</CODE
> has no effect on
non-maskable interrupts. This causes a problem because parts of the
system assume that all normal interrupt sources are affected by this
macro. If the target hardware can raise non-maskable interrupts then
it is the responsibility of application code to install a suitable VSR
and handle non-maskable interrupts entirely within the application,
bypassing the usual eCos ISR and DSR mechanisms.
      </P
><P
>The architectural HAL does not provide any support for the interrupt
controller management macros like
<CODE
CLASS="FUNCTION"
>HAL_INTERRUPT_MASK</CODE
>. These can only be implemented
on a per-variant, per-processor or per-platform basis.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-EXCEPTIONS"
></A
><H3
>Exception Handling</H3
><P
>Synchronous exception handling is done in much the same way as
interrupt handling. The architectural HAL provides a generic entry
point <CODE
CLASS="FUNCTION"
>hal_m68k_exception_vsr</CODE
>. On some variants
this can be used directly as the exception VSR, on others it will be
called via a small trampoline.
      </P
><P
>The details of exception handling vary widely from one variant to the
next. Some variants push a great deal of additional information on to
the stack for certain exceptions, but not all. The pushed program
counter may correspond to the specific instruction that caused the
exception, or the next instruction, or there may be only a loose
correlation because of buffered writes. The architectural HAL makes no
attempt to cope with all these differences, although some variants may
provide more advanced support. Otherwise if an exception needs to be
handled in a very specific way then it is up to the application to
install a suitable VSR and handle the exception directly.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-STACKS"
></A
><H3
>Stacks and Stack Sizes</H3
><P
><TT
CLASS="FILENAME"
>cyg/hal/hal_arch.h</TT
> defines
values for minimal and recommended thread stack sizes,
<CODE
CLASS="VARNAME"
>CYGNUM_HAL_STACK_SIZE_MINIMUM</CODE
> and
<CODE
CLASS="VARNAME"
>CYGNUM_HAL_STACK_SIZE_TYPICAL</CODE
>. These values are
specific to the current configuration, and are affected mainly by
options related to interrupt handling.
      </P
><P
>By default eCos uses a separate interrupt stack, although this can be
disabled through the configuration option
<CODE
CLASS="VARNAME"
>CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK</CODE
>.
When an interrupt or exception occurs eCos will save the context on
the current stack and then switch to the interrupt stack before
calling the appropriate ISR interrupt handler. This means that thread
stacks can be significantly smaller because there is no need to worry
about interrupt handling overheads, just the thread context. However
switching the stack does require some extra work and hence increases
the interrupt latency. Disabling the interrupt stack removes this
processing overhead but requires larger stack sizes. It depends on
the application whether or not this is a sensible trade off.
      </P
><P
>By default eCos does not allow nested interrupts, but this can be
controlled via the configuration option
<CODE
CLASS="VARNAME"
>CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING</CODE
>.
Supporting nested interrupts requires larger thread stacks, especially
if the separate interrupt stack is also disabled. 
      </P
><P
>Although the M68K has enough registers for typical operation, the
calling conventions are memory-oriented. In particular all arguments
are pushed on the stack rather than held in registers, and the return
address is also pushed rather than ending up in a link register. To
allow for this the recommended minimum stack sizes are a little bit
larger than for some other architectures. Variant HALs cannot directly
affect these stack sizes. However the sizes do depend in part on the
size of a thread context, so if for example the processor supports
hardware floating point and support for that is enabled then the stack
sizes will increase.
      </P
><P
>Usually the M68K architectural HAL will provide a single block of
memory which acts as both the startup and interrupt stack, and there
are <A
HREF="m68k-configuration.html#M68K-CONFIG-STACKS"
>configuration options</A
> to
control the size of this block. Alternatively a variant, processor or
platform HAL may define either or both of
<CODE
CLASS="VARNAME"
>_HAL_M68K_STARTUP_STACK_</CODE
> and
<CODE
CLASS="VARNAME"
>_HAL_M68K_INTERRUPT_STACK_BASE_</CODE
> if for some reason
the stacks should not be placed in ordinary RAM.
      </P
></DIV
><DIV
CLASS="REFSECT2"
><A
NAME="M68K-PORT-CONTEXT"
></A
><H3
>Thread Contexts and Setjmp/Longjmp</H3
><P
>A typical thread context consists of the following:
      </P
><P
></P
><OL
TYPE="1"
><LI
><P
>The integer context. This consists of the data registers
<CODE
CLASS="VARNAME"
>%d0</CODE
> to <CODE
CLASS="VARNAME"
>%d7</CODE
> and the address
registers <CODE
CLASS="VARNAME"
>%a0</CODE
> to <CODE
CLASS="VARNAME"
>%a6</CODE
>, The stack
pointer register <CODE
CLASS="VARNAME"
>%a7</CODE
> does not have to be saved
explicitly since it is implicit in the pointer to the saved context.
        </P
><P
>The caller-save registers are <CODE
CLASS="VARNAME"
>%d0</CODE
>,
<CODE
CLASS="VARNAME"
>%d1</CODE
>, <CODE
CLASS="VARNAME"
>%a0</CODE
>,
<CODE
CLASS="VARNAME"
>%a1</CODE
>, <CODE
CLASS="VARNAME"
>%a7</CODE
> and the status
register. The remaining registers are callee-save. Function arguments
are always passed on the stack. The result is held in
<CODE
CLASS="VARNAME"
>%d0</CODE
>.
        </P
></LI
><LI
><P
>Floating point context, consisting of eight 64-bit floating point
registers <CODE
CLASS="VARNAME"
>%fp0</CODE
> to <CODE
CLASS="VARNAME"
>%fp7</CODE
> and two
support registers <CODE
CLASS="VARNAME"
>%fpsr</CODE
> and
<CODE
CLASS="VARNAME"
>%fpiar</CODE
>. Support for this is only relevant if the
processor variant has a hardware floating point unit, and even then
saving floating point context is optional and can be disabled using a
configuration option <CODE
CLASS="VARNAME"
>CYGIMP_HAL_M68K_FPU_SAVE</CODE
>. The
control register <CODE
CLASS="VARNAME"
>%fpcr</CODE
> is not saved as part of the
context. It is assumed that a single <CODE
CLASS="VARNAME"
>%fpcr</CODE
> value,
usually <TT
CLASS="LITERAL"
>0</TT
>, will be used throughout the application.
        </P
><P
>The architectural HAL provides support for the hardware floating point
unit. The variant or processor HAL should implement the CDL interface
<CODE
CLASS="VARNAME"
>CYGINT_HAL_M68K_VARIANT_FPU</CODE
> if this hardware unit
is actually present.
        </P
></LI
><LI
><P
>Some M68K variants have additional hardware units, for example the
multiply-accumulate units in certain ColdFire processors. The
architectural HAL allows the context to be extended through various
macros such as <CODE
CLASS="VARNAME"
>HAL_CONTEXT_OTHER</CODE
>.
        </P
></LI
><LI
><P
>The status register <CODE
CLASS="VARNAME"
>%sr</CODE
> and the program counter.
These are special because when an interrupt occurs the hardware
automatically pushes these onto the stack, but exactly what gets
pushed depends on the variant.
        </P
></LI
></OL
><P
><CODE
CLASS="FUNCTION"
>setjmp</CODE
> and <CODE
CLASS="FUNCTION"
>longjmp</CODE
> only deal
with the integer and fpu contexts. It is assumed that any special
hardware units will only be used by application code, not by the
compiler. Hence it is the responsibility of application code to
define and implement appropriate setjmp semantics for these units.
The variant HAL package can override the default implementations if
necessary.
      </P
><P
>When porting to a new M68K variant, if this has a hardware floating
point unit then the variant HAL should implement the CDL interface
<CODE
CLASS="VARNAME"
>CYGINT_HAL_M68K_VARIANT_FPU</CODE
>, thus enabling support
provided by the architectural HAL. If the variant has additional
hardware units involving state that should be preserved during a
context switch or when an interrupt occurs, the variant HAL should
define a number of macros. The header file <TT
CLASS="FILENAME"