Loading and Unloading the Package
The M68K architectural HAL package
should be loaded automatically when eCos is configured for M68K-based
target hardware. It should never be necessary to load this package
explicitly. Unloading the package should only happen as a side effect
of switching target hardware.
serves primarily as a container for lower-level HALs and has only a
small number of configuration options.
By default the architectural HAL provides a single block of memory to act as both the startup stack and the interrupt stack. The variant, processor or platform HAL may override this. For example if there are several banks of RAM with different performance characteristics it may be desirable to place the interrupt stack in fast RAM rather than in ordinary RAM.
The assembler startup code sets the stack pointer to the startup stack
before switching to C code. This stack used for all HAL
initialization, running any C++ static constructors defined either by
eCos or by the application, and the
entry point. In configurations containing the eCos kernel
cyg_start will enable interrupts, activate the
scheduler and threads will then run on their own stacks. In non-kernel
single-threaded applications the whole system continues to run on the
When an interrupt occurs the default behaviour is to switch to a
separate interrupt stack. This behaviour is controlled by the common
HAL configuration option
It reduces the stack requirements of all threads in the system, at the
cost of some extra instructions during interrupt handling. In kernel
configurations the startup stack is no longer used once the scheduler
starts running so its memory can be reused for the interrupt stack. To
handle the possibility of nested interrupts the interrupt handling
code will detect if it is already on the interrupt stack, so in
non-kernel configurations it is also safe to use the same area of
memory for both startup and interrupt stacks. This leads to the
If interrupt stacks are enabled via
CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACKand the interrupt stack is not provided by the variant, processor or platform HAL then a single block of memory will be used for both startup and interrupt stacks. The size of this block is determined by the common HAL configuration option
CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE, with a default value
CYGNUM_HAL_DEFAULT_INTERRUPT_STACK_SIZEprovided by the M68K architectural HAL.
If the use of an interrupt stack is disabled then the M68K architectural HAL will provide just the startup stack, unless this is done by the variant, processor or platform HAL. The size of the startup stack is controlled by
Otherwise the interrupt and/or startup stacks are provided by other packages and it is up to those packages to provide configuration options for setting the sizes.
Floating Point Support
There are many variants of the basic M68K architecture. Some of these have hardware floating point support. Originally this came in the form of a separate 68881 coprocessor, but with modern variants it will be part of the main processor chip. If the processor does not have hardware floating point then software emulation will be used instead.
If the processor on the target hardware has a floating point unit then
the variant or processor HAL will implement the CDL interface
CYGINT_HAL_M68K_VARIANT_FPU. This allows the
architectural HAL and other packages to do the right thing on
Saving and restoring hardware floating point context increases
interrupt and dispatch latency, code size, and data size. If the
application does not actually use floating point then these overheads
are unnecessary, and can be suppressed by disabling the configuration
CYGIMP_HAL_M68K_FPU_SAVE. Some applications
do use floating point but only in one thread. In that scenario it is
also unnecessary to save the floating point context during interrupts
and context switches, so the configuration option can be disabled.
The exact behaviour of the hardware floating point unit is determined
by the floating point control register
default this is initialized to 0, giving IEE754 standard behaviour,
but another initial value can be specified using the configuration
CYGNUM_HAL_M68K_FPU_CR_DEFAULT. For details
of the various bits in this control register see appropriate hardware
documentation. eCos assumes that the control register does not change
on a per-thread basis and hence the register is not saved or restored
during interrupt handling or a context switch.
At the time of writing eCos has not run on an M68K processor with hardware floating point so the support for this is untested.
There are configuration options to change the compiler flags used for
building this packages.
The M68K architectural HAL package does not define any other
configuration options that can be manipulated by the user. It does
define a number of interfaces such as
which can be used by lower levels of the M68K HAL hierarchy to enable
certain functionality within the architectural package. Usually these
are of no interest to application developers.