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

Walter Banks wrote:

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.

For some situations, being open source provides great benefits to the customer, and (if your business model is appropriate) to the vendor. But in other situations, it would not help. In the case of ByteCraft compilers, you are truly expert in your field, you work closely and rapidly with customers if there are any issues, and you have top class testing and quality control. There are very few users of your compilers who could improve on your tools if they had the source, and even fewer who could do so more cost-effectively than you.

But there are many other tools in the embedded development industry which do not match that quality. Clearly, there is a difference between code running on the host (like the compiler) and code running on the target (libraries, OS's, etc.) - for code running on the target, source code access (open or not) is obviously a benefit to end users, while on the host, code access is less useful. At the higher end of the market, there is less use in code access - the vendor makes better software in the first place, and the crucial code is often beyond the understanding of non-experts. But at the lower end, which covers a wide range of users, this is not necessarily true. I have certainly used commercial closed source development tools that I am confident I could have improved upon if I had the source, and would have been able to share those changes with other like-minded users and the original supplier, resulting in a better tool. (Whether I would have the time to do this is, of course, another matter!)

The point is, while open source offers little to the vendors or customers of good quality tools, it offers benefits for other kinds of programs.

There is also nothing in this to say that open source software cannot also be of high quality (though economics usually limit things like verification and certification).

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.


gcc is a different sort of compiler from ByteCraft's - you can see there is very little (if any) overlap in the processor targets they support. As you say, gcc is aimed at larger processors, with multiple registers, a single memory space, and preferably at least 32-bit registers (though 16-bit is fine, and the 8-bit AVR port is not bad). ByteCraft, on the other hand, deals with optimising code for 8-bit micros with specialised registers, multiple address spaces, and other C-unfriendly aspects. Your compilers can happily spend significant host time getting the best code possible out of perhaps 10,000 lines of C code - gcc has to be able to chew through programs of millions of lines in a reasonable time. For your compilers, knowledge of the individual family members can be important (for example, when you know the size of a chip's flash, you can tell whether the code should be optimised for speed or size), while for gcc, it is not relevant which, say, MCF52xx chip you have, since they all have the same core. (Having said that, for many gcc ports, you *can* specify exactly which microcontroller you have - it makes it easier to get the right header and library files, and saves the user a little thought.)

So there is no way gcc can lose ground to ByteCraft, or vice versa - the targets are completely different. It might be more relevant to compare ByteCraft to sdcc (which is not related to gcc, but is open source - and by all accounts, it works well enough but can't compare in code quality to the good commercial 8051 compilers), or to compare gcc to Green Hills. I'm afraid I don't have any clue as to the numbers here, and who might be "winning" or "losing".

One place where gcc clearly is "winning" is in support for new architectures. There was a time when a company designing a new processor would look to one of the large commercial compiler developers for compiler tools. Now, at least in the 32-bit arena, they are looking at gcc - making or supporting a gcc port gives enormous value for money for the processor vendor. Atmel, Xilinx, Altera, Microchip, and many others rely on gcc as their initial compiler support for modern cores. That is not to say they don't support commercial compiler developers as well, but gcc gets them started faster and cheaper.

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.


These final paragraphs confirms much of what I have been trying to say to Chris Hills in this thread - you put your greatest efforts into the part of the toolsuite that you are experts in, and that is most important to the end user (code generation), and you put appropriate effort into all the individual parts of your products so that the end result has the quality you need.

mvh.,

David


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



.

Relevant Pages

  • Re: Idea: Multitasking graphical OS for the GS
    ... IIgs 65816 compiler that has nearly the number of ... gcc also has a much larger support infrastructure where it will be easier to ... The software developer and the hardware ...
    (comp.sys.apple2)
  • Re: Non ASCII characters in CFString litteral, HELP !
    ... CodeWarrior is PPC-only and very dead, ... compilers listed don't even support Objective-C. ... It is indeed lamentable that we have pretty much only one compiler ... For this particular case, blame C or Cocoa, not gcc. ...
    (comp.sys.mac.programmer.help)
  • Re: Compiling Tcl with Msys/MinGW on Windows XP
    ... checking for gcc... ... checking whether the C compiler is a cross-compiler... ... checking for EXCEPTION_DISPOSITION support in include files... ... I saw one case were people had to use msys 1.0.6 ...
    (comp.lang.tcl)
  • Re: Code generation from the Gospel according to f0dder
    ... > idea of the quality of VC++. ... And it lays to rest the theory that GCC ... using the Microsoft compiler from Visual Studio 6. ... and Jibz has told me of some cases where it did STL ...
    (alt.lang.asm)
  • Re: RFC: drop support for gcc < 4.0
    ... gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost ... use gcc-3 as the default kernel compiler will take it seriously (if it ... looks to have an impact to our kernel builds) otherwise we can tell you ... badly broken" would be "only support what the GCC team supports", ...
    (Linux-Kernel)