[ECOS] Re: Use of ifdefs a hinderance for portability.

[ECOS] Re: Use of ifdefs a hinderance for portability.

[Bart Veer]

> Having had significant experience in porting and supporting a
> commercial multiprocessor real-time operating system to a number of
> processor architectures, (as well as numerous SBC and devices), I am
> concerned about the amount of "#ifdefs" in the startup and platform
> code. (The HAL)

I believe the situation is not as bad as you might think. Looking at
the PowerPC architectural HAL package and the cogent platform package,
the most popular #ifdefs are the following:

7 * CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
5 * CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
5 * CYG_HAL_POWERPC_MPC860
3 * CYG_KERNEL_USE_INIT_PRIORITY
3 * CYG_HAL_STARTUP_ROM
2 * CYG_HAL_STARTUP_RAM
...

Many of the #ifdef's relate to the gdb support. The current
implementation of this is not as clean as it should be, but will be
improved. Unfortunately target-side debug stubs tend to be fairly
intrusive.

The three uses of CYG_KERNEL_USE_INIT_PRIORITY should really be
removed. These date from a time when the compiler support for this was
still experimental.

Switching between ROM and RAM startups has an impact on both the
linker script and the source code. I am not sure it is possible to
reduce the #ifdef's for these without making ROM and RAM systems
separate platforms, but that would involve duplicating a lot of other
code.

It is the five occurrences of MPC860 that justify concern. The current
implementation of the HAL basically operates at two levels:
architecture and platform (i.e. board). It should operate at three
levels, architecture, processor implementation, and platform. In fact
the existing documentation makes clear that this is how it should
work, but we did not have time before the release to actually organize
things that way. It is also possible that some of these #ifdef's are
not actually necessary, but they indicate areas where people porting
to other PowerPC variants should pay special attention.

Now that we have made a release and there are people out there who are
actually using the system and providing constructive feedback, ports,
etc. we can start to sort out issues like these. Things may not end up
exactly as you suggest. For example there is an argument for doing
device driver initialization by means of C++ static constructors with
suitable priorities. That way the platform code does not need to know
in advance which device drivers the user has selected. However your
comments will certainly be read and considered by the relevant people
in the eCos team.

There are already some instances of doing things on a function-level
basis rather than a #ifdef basis, for example the architectural _start
code invokes a function hal_hardware_init which should be provided by
the platform package. There are other cases such as the gdb support
and interrupt instrumentation where #ifdef's are the best way to
select the desired functionality, and we will continue to use them
when appropriate.

Bart Veer // eCos net maintainer
`

[ECOS] Use of ifdefs a hinderance for portability.

[Robert Klinkhammer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

Having had significant experience in porting and 
supporting a commercial multiprocessor real-time operating system to a number of 
processor architectures, (as well as numerous SBC and devices), I am concerned 
about the amount of "#ifdefs" in the startup and platform code.  
(The HAL)
 
As developers port to numerous BSPs and 
processors, the use of #ifdefs will become unwieldy and complicated.  As I 
recall, one of the first iterations that we made was very similar to eCos 
HAL.  Our lives became a whole lot easier as we moved toward link-time 
configuration.  It requires a little more work to define the interfaces, 
but it is worth it.
 
For example, a possible 
solution for the reset and initialization of a processor and platform could 
be:
 
ResetVSR:
    minimal processor 
initialization
    jump 
ResetPlatform
        (ResetPlatform is linked in as a separate model and when finished, 
jumps back to PlatformResetFinished).
 
PlatformResetFinished:
 
    Initialization continues and establishes a C-Runtime 
environment
    with the following 
properties:
        hardware devices in a 
reset state.
        processor 
interrupts disabled
        
caches invalidated and disabled.
        MMU 
disabled.
     
Call Generic C startup and Initialization Routine.
        (This will further call 
"standard" BSP specific functions)
 
This way, an eCos 
configuration would be based on linking rather than conditional 
compilation.  Note that the purpose of the ResetPlatform "function" is 
to initialize the hardware to a known "reset" state, not to do a 
complete platform initialization.  Similar changes could also be made 
elsewhere.
 
=========================================== Robert 
Klinkhammer Principal Software Engineer
 
klink@medaone.net http://people.ne.mediaone.net/klink