Hi Hugh,
> More capable than GNU ? How ?
In code generation. Going from One Of Our Big Customer's perspective,
they compiled their code with Greenhills, ARM's own, and GCC. They
provide libraries to developers to integrate their silicon's facilities.
The GCC-based version runs slower than either of the other two and is
bigger. This is a big issue as the part has internal FLASH, needs to
support battery operation, so the apps need to be small and fast. We
think there could be room for improvement at the £495/$850 price point.
Don't be in any doubt that we can't pull off the ARM code generation
issue as we were contracted, a long time ago, to move our Modula-2
compiler to RISC iX for ARM. After doing that, the code generator was
just as good as the ARM one, and better in many cases.
> We've been using GNU ARM in one our products (similar to yours I
think)
> for over a year and we're impressed. Once you have an IDE on top, its
> pretty much plug&play for Windows users. Code generation is good and
its
> very stable (we/our customers found very few code generation bugs, the
> most notable being when using the "interrupt keyword").
Getting an ARM product wasn't the only reason to do the port to
ELF/DWARF.
> Our guesstimate is that it is within 5% of the code size capabilities
of
> the big guys (ARM ARM, GHS, IAR, etc). As for Hi-Tech, my experience
in
> the past has been good with their command line tools (8/16-bit),
however,
> my experience with Java front-ends (not Hi-Tech's) has not. Some other
> tool companies have tried this approach and have suffered from
performance
> and mysterious VM crashes ("write once, test everywhere").
Command line tools should port easily between different flavours of Unix
and Windows. However, it's a different matter for a GUI. My experience
with Java as a language to write commercial-grade GUI programs isn't
good. Admittedly, I evaluated a long time ago, before the advent of
Swing/JFC, and the only reliable platform was Solaris. Running the same
class files on Solaris and Windows was horrid; the JVMs were different,
gulped memory, ran like pigs, and gave different results.
> It will of course take time for the new Hi-Tech ARM tools to "mature"
to
> the level of GNU. Note that Keil also plan to bring out their own
native
> compiler next year making the ARM market super competitive from a
compiler
> vendors pov (I can think of ~10 vendors).
Keil have been promising their GCC-based ARM tools for ages. Our price
point for something that supports multiple ARM processors, has
integrated downloading and flashing, and has a nice IDE for code cutting
and debugging is, we feel, competetive. We don't use GDB as the
debugger, for instance, we have our own built in. We don't use the
newlib library, we wrote our own, so things are compact.
We get portability through Qt. We could offer a Linux version, and
probably will, it's just that nobody has asked for one. Perhaps this is
the self-fulfiling prophesy.
-- Paul.