[ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Øyvind Harboe]

On 09 Aug 2006 21:05:33 +0100, Bart Veer <bartv@ecoscentric.com> wrote:
> >>>>> "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

I'm not convinced that it is better to solve this in the TCL domain.
There are very few engineers who can or want to use TCL(I certainly
try to hide those skills so I don't get that sort of work :-) as
opposed to other solution domains where static cdl files can be
generated. I'm not sure why it is important that a repository is write
only. It's better to have this problem solved in a slightly
sub-optimal programming language where multiple engineers can actually
touch the code.

ecos.ecc is generated, modified and still part of my source code/goes
into source control, so why not a dynamic HAL as well? Especially
since a generated HAL can be part of a seperate eCos repository...

(The fact that ECOS_REPOSITORY can support multiple repositories
surprised me and has me hatching evil plans as I write :-)





-- 
Øyvind Harboe
http://www.zylin.com

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