Switch to the standard ARM startup code. This requires adding the
standard interrupt code. The interrupt code does nothing at this
point in time. I do not know if the ARM simulator in GDB supports
interrupts.
The syscall functions overlapped with RTEMS, for example _write, _read, etc.
Change these to be internal to the BSP and avoid any clash with names in
RTEMS. Add support for SWI_Write0.
Change the console driver to use SWI_Write0. This outputs the character
to the host's stdout. Writing to file name 0 is not captured and managed
by GDB's simulation code while the SWI_Write0 is. The managed stdout
data is encapulated in the MI protocol while writes to file handle 0 are
dropped by GDB when in MI mode.
The exit SPARC system call doesn't have a function entry
point like the others do. This is probably why people use
TA 0x0 instruction directly for shutting down the system.
Use __bss_start available via %g2 to clear the BSS section. The usage
of _edata resulted in a copy of [_edata, __bss_start) from ROM to RAM
and then a clear to zero of this area.
Clear now only [__bss_start, _end).
Use the register %g4 for the data content since it must be an even
numbered register due to the std/ldd. Use the register %g2 for the BSS
start address, so that it can be later re-used for the BSS zero loop.
We must not alter the is executing indicator in
_CPU_Context_Initialize() since this would cause an invalid state during
a self restart.
The is executing indicator must be valid at creation time since
otherwise _Thread_Kill_zombies() uses an undefined value for not started
threads. This could result in a system life lock.
The current implementation of task migration in RTEMS has some
implications with respect to the interrupt latency. It is crucial to
preserve the system invariant that a task can execute on at most one
processor in the system at a time. This is accomplished with a boolean
indicator in the task context. The processor architecture specific
low-level task context switch code will mark that a task context is no
longer executing and waits that the heir context stopped execution
before it restores the heir context and resumes execution of the heir
task. So there is one point in time in which a processor is without a
task. This is essential to avoid cyclic dependencies in case multiple
tasks migrate at once. Otherwise some supervising entity is necessary to
prevent life-locks. Such a global supervisor would lead to scalability
problems so this approach is not used. Currently the thread dispatch is
performed with interrupts disabled. So in case the heir task is
currently executing on another processor then this prolongs the time of
disabled interrupts since one processor has to wait for another
processor to make progress.
It is difficult to avoid this issue with the interrupt latency since
interrupts normally store the context of the interrupted task on its
stack. In case a task is marked as not executing we must not use its
task stack to store such an interrupt context. We cannot use the heir
stack before it stopped execution on another processor. So if we enable
interrupts during this transition we have to provide an alternative task
independent stack for this time frame. This issue needs further
investigation.
Provide a file per BSP to list tests that do not build for a BSP. This change
removes the BSP_SMALL_MEMORY hack from the code. That hack was a
mistake.
Provide configuration files for each BSP with tests that cannot build.
Use register g6 for the per-CPU control of the current processor. The
register g6 is reserved for the operating system by the SPARC ABI. On
Linux register g6 is used for a similar purpose with the same method
since 1996.
The register g6 must be initialized during system startup and then must
remain unchanged.
Since the per-CPU control is used in all critical sections of the
operating system, this is a performance optimization for the operating
system core procedures. An additional benefit is that the low-level
context switch and interrupt processing code is now identical on non-SMP
and SMP configurations.
The registers g2 through g4 are reserved for applications. GCC uses
them as volatile registers by default. So they are treated like
volatile registers in RTEMS as well.
