Loading and Unloading the Package

The M68K architectural HAL package CYGPKG_HAL_M68K 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. CYGPKG_HAL_M68K serves primarily as a container for lower-level HALs and has only a small number of configuration options.

Stacks

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 cyg_start 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 startup stack.

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 CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK. 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 following scenarios:

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 different hardware.

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 option 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 %fpcr. By default this is initialized to 0, giving IEE754 standard behaviour, but another initial value can be specified using the configuration option 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.

	Warning
	At the time of writing eCos has not run on an M68K processor with hardware floating point so the support for this is untested.

Other Options

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