> David Brown wrote:
>
> [snippage]
>
> >In the meantime, it is quite possible to use gcc along with C-spy for
> >debugging. It's a mildly absurd system of compiling, linking,
> >disassembling, assembling and linking again, and you miss symbolic
> >information on variables (I suspect I could achieve that with some glue
> >programs, but I keep putting it off while waiting for complete gdb-jtag),
> >but it does work.
>
> Are you going through these steps so you can produce a symbol table? My
> method (which does not produce symbols) is to:
>
> /usr/local/msp430/bin/msp430-objcopy -O ihex analog analog.hex
> /usr/local/msp430/bin/msp430-objdump -dSt analog > analog.lst
>
> and just view the listing file while I'm in C-Spy.
The final objdump is
msp430-objdump -dSt --disassembler-options=IAR analog.elf >
analog_iar.s43
This is followed by IAR assembler and linker:
a430 -S -x -r -l analog_iar.lis analog_iar.s43
xlink -o analog_iar.d43 -S -r -xems -l analog_iar.map -f iar.xcl
analog_iar.r43
Then you can load the r43 file into C-Spy, which has the disassembly mixed
with the original C code as comments. So you don't get the data symbols,
but it is extremly easy to find where you are in the code.
>
> >In the long term, the msp compiler market is going to be split between
gcc
> >(for those that want the top quality code, or want a more hands-on
> approach,
> >and are not scared off by lack of a telephone support line and gcc's
"great
> >once you've got it working" image) and ImageCraft (for those that want a
> >neat, pre-packaged compiler and debugger with excellent commercial
support
> >for a modest cost). Once ImageCraft have completed their compiler (they
> are
> >in alpha/beta testing now) and debugger, I suspect they will quickly
become
> >the dominant choice for those looking for a commercial compiler.
>
> Richard has an excellent product. I use the AVR compiler, since I feel
it's
> more stable and better rounded than the current implementations of GCC and
> the libraries. These are steadily improving, and may be ready for prime
> time, but I see enough traffic about problems that I'm still a little gun
> shy.
>
> Richard provides excellent support, and the front end of the compiler is
> well tested, and is ANSI certified. The code generator is pretty good,
and
> regularly improving. Except for a few of the lesser common string
functions
> supporting one of the arguments being in FLASH, the libraries are
complete.
>
Yes, I too use ImageCraft's AVR compiler. There are some types of code for
which it does not generate very tight object code, but that steadily
improves (helped by me - I have sent Richard a fair number of emails with
suggestions for better code, and he has implemented several of them).
> What ICC does have that I'd love to see an implementation of for both the
> MSP430 and the AVR is the code compressor. This is similiar in principle
to
> a common sub-expression eliminator in the compiler. It looks for repeated
> code blocks and converts them to subs. It's quite effective, and I've
seen
> around 20% compression. However, it's only available in the $500 package,
> which puts it out the range of most hobbiests.
>
I would love for Richard to drop the code compressor. In my experiance, it
is quite simply not worth the effort. In effect, finds common expressions
in the generated object code and makes them into little subroutines. I have
seldom found that it saves more than about 10%, and it makes the executable
slightly slower and messes with debugging (stepping through code at an
assembly level jumps all over the place, and breakpoints can get messy).
With the AVR chips getting bigger memories all the time, it is simply not
worth it. I think he would be far better dropping the code compressor and
concentrating on other optomisations which would improve the code size much
more and often speed up execution. Common sub-expression elimination at the
source code level would have more effect, and without the code compressor,
the code generated for switches could be vastly improved.
