Re: What's the story with the "end of XP"?



David Brown wrote:

Walter Banks wrote:

David Brown wrote:

For much of the rest of the embedded world,
things like price or time-to-market are more important. And what
applies to the end products applies to the tools.

This implication is a reach. My experience with volume
embedded systems is they would rather spend money
on tools and tool support than spend money on
production. Support gives them access to the larger body
of experience using the particular part. Good tool
vendors give them access to effective code generation.


For high volume products, it is certainly worth spending money on
getting the best tools for development - your development costs are
spread over a large number of units. But the situation is not quite the
same as for safety-critical work - it's a different sort of "best". For
high volume consumer development, your priorities are tools that let you
work quickly, and that generate small and fast code (equating to cheaper
and slower micros in the end product). For safety-critical work, your
priority is your certainty that the compiler (and libraries) generate
correct working code. The same compiler suite may be "best" in both
these categories, but not necessarily.

The difference that I have seen between generic high volume embedded
systems and safety critical work is in the testing. In the safety critical
work product testing is a formal discipline. Code generation tool support
requires product changes be documented both to the change, the root
cause and the impact of the change including side effects on products
created using the tools. We work very closely with our customers to
achieve comfortable working relationship to exchange critical information.

Fully open source (as opposed to the availability of source licenses)
would do very little to help customers, their expertise is in the application
and our expertise is in the tools both their current state and the history of
changes and relationship to generation with a particular piece of silicon.
The job of good tools is to generate code that will run on the target silicon
including accounting for silicon product defects. Fully open sources rarely
help the customer solve tool problems, just look at the problem
understanding the inner workings of a relatively simple compiler like GCC
and relating that information to application implementation on a specific
piece of silicon.

Related to the general argument of open source vs commercial tools I
am seeing many of the open source tools losing ground against their
commercial counterparts. GCC for example still has very little better than
20 year old code generation technology producing okay but not spectacular
code. There is a level of detail that is missing, most GCC compilers have
been implemented for families of ISA's and not individual members. GCC
based compiles have done very badly when used for processors with small
or low number register sets, RISC instruction sets and multiprocessor
single source applications.

The commercial companies have a critical mass of personnel supporting
the silicon that our customers are using and very often tool developers
are part of the support structure. Commercial companies have been
stereotyped as expensive and in-effective, something that just doesn't
stand up to close examination.




I am not arguing against spending money on good tools when appropriate,
or that good tools are not available - I am only trying to explain that
there is no general rule that "closed source is good quality, open
source is poor quality" as Chris seems to believe, and, further, that
top quality is *not* always something to strive after.

In the world of embedded development tools, especially at the higher end
(be it for volume or for safety), you get much closer to "you get what
you pay for" than in many other markets, and certainly much closer than
in most software areas, because there is a healthy competition and
customers emphasis the need for technical quality. But it is *not* the
case in much of the software world. I've seen people who use large,
expensive, commercial embedded development tools that they hate - but
they can't change tools without a large cost, because all the libraries,
linker setups, etc., are incompatible with other tool suites for the
same target. Here, price can be a rough indicator of quality, but is
far from a guarantee.

The interface to most commercial tools libraries are usually well
documented. Most if not all commercial support library sources
are either provided (Byte Craft ships sources to our support libraries)
or are available as separate source licences. I don't actually believe
that price is an indicator of quality there is a relationship. High volume
customers usually use benchmarks to measure quality something we
encourage.

But perhaps you, as a developer of high quality development tools, can
answer a simple question - do you take equal care, and go through as
many code reviews and automated testing procedures, with all parts of
your development tools? I suspect you would be rather more worried if a
bug caused your code generator produced incorrect code than, say, a
spelling mistake in your help files. My point is, code standards and
code quality cost time and money (they also cost if they are too low, of
course), and must therefore suit the task in hand.

Our fundamental product is code generation, IDE's are shipped as
part of our products so our customers have a full solution. BCLide
goes through regular product review as does documentation and
FAQ's. Application requirements evolve as does API's both get
a lot of attention. This is the business we are in.

I think you will find that we do what is appropriate for each of the parts
of our tools set. Our (Byte Craft ) tools conform to industrial standards
of interface and status reporting so they will correctly function with other
tool sets.

Walter Banks
--
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
email walter@xxxxxxxxxxxxx



.