Re: [ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:

    Oyvind>> Though I can see how a soft-CPU with a dynamic number of
    Oyvind>> peripherals would be a poor impeadance match with eCos
    Oyvind>> static cdl files.

    >> According to the design, CDL files do not have to be static. CDL is
    >> embedded in a general-purpose scripting language, Tcl. Conceptually
    >> that gives it the flexibility to adapt to changing hardware, including
    >> reconfigurable systems. The problems are:
    >> 
    >> 1) the CDL implementation is still incomplete, for a variety of
    >> reasons I do not intend to go into here.
    >> 
    >> 2) not all the concepts behind CDL are widely understood, leading to
    >> flawed approaches like generating static CDL files.

    Oyvind> I knew that, but forgot while I wrote what I did. I can
    Oyvind> see how a non-TCL guru would want to generate CDL instead
    Oyvind> of understanding the finer point of TCL+CDL :-)

    Oyvind> Is there a fundamental reason why CDL should not be
    Oyvind> generated?

With configurable h/w there are two main ways of handling things:

1) have a separate tool which takes the h/w definition file and
   generates static CDL, the HAL header files defining things like I/O
   addresses and interrupt vectors, etc. Then run up ecosconfig or the
   graphical configuration tool, as desired.

2) have an intelligent CDL script which processes the h/w definition
   file, either directly or by invoking a separate utility and reading
   its output, and generates the appropriate configuration options in
   memory. In addition have a define_proc which will create the HAL
   header files etc.

Approach (2) involves one less step for the user so there is less to
go wrong. It also maintains the idea of a read-only component
repository as far as application developers are concerned. The
generated CDL options only live in memory, there is no need to write
them to a file. The generated HAL headers live in the build tree
alongside other generated headers like <pkgconf/system.h>. So from the
eCos perspective everything pretty much works the same as with more
traditional h/w targets.

Writing the intelligent CDL script is obviously going to be more
challenging. There is also the problem of telling that script where
the h/w definition file is located, but that should not be a major
obstacle.

So although there is nothing to stop people from generating static CDL
scripts, I do consider it to be a sub-optimal solution. If a CDL/Tcl
guru is required there is always http://www.ecoscentric.com/develop.shtml

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss