Re: [ECOS] package definition with CDL

[Bart Veer <bartv at redhat dot com>]

>>>>> "Robin" == Robin Kirkham <Robin.Kirkham@cmst.csiro.au> writes:

    <snip>

    Robin> Beware, the 68k family is complicated. Many people assume,
    Robin> for instance, that all the 683xx have the same CPU, but
    Robin> different IO peripherals. This is not true.

    Robin> Motorola use at least three different CPU cores in the
    Robin> 683xx series microcontrollers:

    Robin>     EC68000
    Robin>     CPU32
    Robin>     CPU32+

    Robin> These are in addition to the cores of their standard
    Robin> microprocessor line, 68000, 68010, 68020, 68030, 68040,
    Robin> 68060. The EC68000 is maybe the same as the 68000, but the
    Robin> CPU32 and CPU32+ are both unique.

    Robin> [There is also the Coldfire line to consider. gcc regards this as part of
    Robin> the 68k family.]

    Robin> This suggests to me a four-level HAL structure:

    Robin>     + architecture 68k HAL
    Robin>     + architecture variant HAL
    Robin> 	(for each of the 68000, 68010, 68020, ..., EC68000, CPU32,
    Robin> 	    and CPU32+ cores)
    Robin>     + chip variant HAL
    Robin> 	(for each of the 68000, 68010, 68020, ..., 68300, 68331, 68332,
    Robin> 	    68333, ..., chips)
    Robin>     + platform HAL
    
    Robin> I don't know enough about eCos and in particular its HALs
    Robin> to comment further.

    Robin> I would, however, hope that an eCos HAL structure could be
    Robin> developed that fits the whole 68k family (even if not all
    Robin> tartgets are initially supported) without lots of "the same
    Robin> but different" code.

I am fairly confident that the eCos configuration technology can cope
with whatever HAL structure is needed to support the 68K family - but
it may not be possible to figure out the optimal organization just
yet. 

Increasing the number of packages has both advantages and
disadvantages. It makes it easier to add support for more variants,
hopefully without having to change any existing packages. It reduces
the need for #ifdef's or similar techniques in any particular package
because there are fewer possibilities to cope with. The main
disadvantage is the risk of code duplication. This is not just for the
C source code, you also need to consider the other files involved such
as the CDL scripts. Some sort of balance needs to be struck.

Since the work is being done by a net contributor, I would be happy to
see any reasonable 68K support added to the system. There may well be
problems with the initial implementation, which can be sorted out in
time. In fact the first eCos release had no support for architectural
variants at all, but gradually Red Hat has been adding such support to
the appropriate HAL's as the need arises.

Don't get me wrong: if people want to discuss the best way to organize
68K HAL packages that is fine - as long as it does not interfere too
much with actually getting the code written and usable by the various
people who want it.

Bart Veer // eCos net maintainer