Kris et al,
> All Opts ON, and Cross Calling Maximum :
> 19,504 bytes
> All Opts ON, and Cross Calling Standard :
> 19,510 bytes
> The only down point I think is the long linking
time for
> maximum opt, but since that's only for release code, it seems
> non-intrusive.
After liberal snipping... The difference between Maximum and Standard
isn't very big on this test. In fact, it's not really very big at all
(3 instructions out of 9755 insns) at 0.03%. I sometimes wish I hadn't
added Maximum as it's just too darn slow and perhaps it should have been
called "Benchmark Mode" as that's what prompted the drive to
reduce code
size. However, we should have also improved execution speed for this
release too.
For the next point release, I'm working on speeding up cross jumping and
tail merging, which are now slower than cross calling for some programs.
I'd recommend that users stick to Cross Calling set to Standard in
Release mode, it's the most useful setting.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors
Hi all,
I've done a test with the RC5 code generator, and the results are quite
impressive, for those
that are interested. For all others, I apologise for the disturbance.
My test project used 24,146 bytes in RC4 (15 % more code than IAR) but ran
remarkably faster than IAR
and compiled/linked through RC5 these are the findings :
All Opts ON, and Cross Calling Maximum : 19,504
bytes
All Opts ON, and Cross Calling Standard :
19,510 bytes
All Opts ON, and Cross Calling Off :
20,938 bytes
All Opts ON, but Opt for Speed, Not Size - Cross Calling Off : 20,948 bytes
This puts code size (24 K -> 19.5 K) about 5% lower at highest Opt than
IAR's code , and the floats run
~ 15-20% faster than IAR - if you like floats like I do.
I think this is a fair test, as it draws upon most operations on all of C's
datatypes.
Overall code execution is definitely faster than IAR too, but I can't test
it on the latest V2.XX version of
IAR for improvements that might have been introduced since then. Most on here
seem to be using V1.26B anyway.
The Tasking Library is a great addition, and the Threads window makes for some
really nice
"Kernel aware" debugging, combined with the Enable/Disable Interrupts
feature.
Of course there are all the other numerous features of CrossWorks for MSP430
that makes it a
value packed package, and one to be reckoned with for its competition I'd
say :-)
The only down point I think is the long linking time for maximum opt, but since
that's only for
release code, it seems non-intrusive.
Next when I have spare time I'll be doing more tests on HITECH-C for
MSP430, as I've seen some great
optimisations last time I tested with it. More on those tests later.
I only wish there was that much quality and diversity when I started using
MSP430 a few years ago.
This is not to say that ImageCraft and Quadravox aren't worthwile, they
just aren't in the top contender
list IMO, and carry a lower price tag anyway.
-- Kris
Reply by Paul Curtis●January 7, 20042004-01-07
Richard,
> At 09:00 AM 1/6/2004 +0000, you wrote:
> >....the back end. Our optimizer goes beyond the IAR
> optimizer in that
> >it can find common sequences between compilation units, not
> just in a
> >single compilation unit. I suppose it's rather like
Richard's Code
> >Compressor whole-program-optimization technology, but I must
> admit that
> >I haven't seen Code Compressor for the MSP430 so I can't
> really judge.
> >...
>
> Yes, this is what we (will) do. Is this what you call the Cross Call
> optimization?
Cross Calling is where you find two or more common code sequences and
then you hoist them out and replace them with calls to a common code
sequence. It's also called common block subroutine packing by the Other
AVR Compiler. It's only part of what our optimizer does now.
> I am finishing up debugging the Code Compressor
> for the ICC08
> for HC08, then I will finish debugging the Code Compressor
> for the MSP430.
The MSP430 is much more difficult to do cross calling on because the
call adjusts the stack pointer, so references to locals need to be
patched up. Our cross calling optimization will correctly adjust stack
references and ensures that calls are not put in inappropriate places
(e.g. in the middle of building an argument list on the stack).
> I am also debugging an extended block CSE as well,
this seems
> to be a minor
> win in some cases, mostly the caching of references to global
> variables
> will now be cached into registers (within extended basic block).
Copy propagation is good; however, I've never found that CSE was a big
winner in well-written C code as the CSEs are usually written out by the
programmer. Save for induction expressions, in C they're just not worth
the effort.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors
Reply by Richard F. Man●January 7, 20042004-01-07
At 09:00 AM 1/6/2004 +0000, you wrote:
>....the back end. Our optimizer goes beyond the
IAR optimizer in that it
>can find common sequences between compilation units, not just in a
>single compilation unit. I suppose it's rather like Richard's
Code
>Compressor whole-program-optimization technology, but I must admit that
>I haven't seen Code Compressor for the MSP430 so I can't really
judge.
>...
Yes, this is what we (will) do. Is this what you call the Cross Call
optimization? I am finishing up debugging the Code Compressor for the ICC08
for HC08, then I will finish debugging the Code Compressor for the MSP430.
I am also debugging an extended block CSE as well, this seems to be a minor
win in some cases, mostly the caching of references to global variables
will now be cached into registers (within extended basic block).
// richard (This email is for mailing lists. To reach me directly, please
use richard@rich...)
Reply by Paul Curtis●January 7, 20042004-01-07
Hi Claus,
> I have 6-8 different projects now on the MSP430
(different versions)
> and I installed the new RC5 version of the compiler. I most say the
> difference is huge! My biggest project is using a F149 and the total
> Flash space taken is 41245 bytes. That is the total amount, e.g. both
> code and constants and in this project the constants is around 13000
> bytes because of a graphic display (font) and a menu system.
> After recompiling the same project using the new linker the total
> size went down to 32489 bytes. For me that really make a different
> because I was supposed to do two different version to support two
> different printers. Now I'm sure I can fit it all in one!
> To be fair, it took the linker a very, very long time to get there. I
> think it was around 10 minutes on a 3.0 GHz Pentium 4 with 1GB RAM.
> This is the extreme and with one step less optimization it is a few
> seconds.
The savings made by Cross Calling at Maximum and Cross Calling at
Standard isn't that much for many programs. The difference between the
two at the start of development of the optimization was big, but I've
narrowed the gap pretty effectively. At Standard optimization, as Claus
says, the linker is still very quick. However, if you need to squeeze a
few hundred words or so out of an application above and beyond Standard
optimization, at least you have the possibility.
> I think I have exchanged 100 email with Paul and
most of them have
> been answered within minutes and a few hours. The funny think, I
> always ask questions in the evening, and Paul is answering in the
> evening. I guess we both have nothing better to do ;-)
Oh, I possibly have better things to do, but what interests me is good
code generation and good tools. So, I spend spare time tinkering and
developing. I have another two MSP430 projects on the go, so we'll have
more MSP430 offerings fairly soon I hope.
> I will recommend this development suite to all
that is using a
> MSP430. The time I save using the new CrossStudio together with the
> new CrossConnects makes the investment payback time very short.
Thanks for the kind words, Claus. We know we have a winner in v1.2, and
I'm not through yet!
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors
Reply by claus_lm●January 7, 20042004-01-07
Hi all
I have been using the CrossWorks since the beta version and I'm a
very happy customer.
I changed from the Atmel AVR to TI MSP430 and was porting my code
using the beta version. I was a little chocked about the code size
and mailed Paul some examples on the AVR and MSP430 code generation.
Right away he changed the compiler and I got more or less the same
code density as on the AVR. Some less and some more, but more or less
the same.
I have 6-8 different projects now on the MSP430 (different versions)
and I installed the new RC5 version of the compiler. I most say the
difference is huge! My biggest project is using a F149 and the total
Flash space taken is 41245 bytes. That is the total amount, e.g. both
code and constants and in this project the constants is around 13000
bytes because of a graphic display (font) and a menu system.
After recompiling the same project using the new linker the total
size went down to 32489 bytes. For me that really make a different
because I was supposed to do two different version to support two
different printers. Now I'm sure I can fit it all in one!
To be fair, it took the linker a very, very long time to get there. I
think it was around 10 minutes on a 3.0 GHz Pentium 4 with 1GB RAM.
This is the extreme and with one step less optimization it is a few
seconds.
I think I have exchanged 100 email with Paul and most of them have
been answered within minutes and a few hours. The funny think, I
always ask questions in the evening, and Paul is answering in the
evening. I guess we both have nothing better to do ;-)
I will recommend this development suite to all that is using a
MSP430. The time I save using the new CrossStudio together with the
new CrossConnects makes the investment payback time very short.
All the best wishes for 2004.
Kind regards
Claus Lok Mortensen
Denmark
PS. This mail is just to give other MSP430 users a real example from
a real project and not from some prewritten, suitable code for
optimization!
PPS. If you want the sizes for the other projects, let me know.
--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> Hi All,
>
> I have just uploaded CrossWorks for MSP430 v1.2 RC5 to the web
site. If
> there are no major calamaties, this is the version
that will make
it out
> as v1.2 Gold.
>
> This new version of our software features the brand new optimizer
that I
> added to the tools during the v1.2 upgrade. This
optimizer
features:
>
> * inter-module cross calling optimization which significantly
reduces
> code size at the expense of execution speed.
>
> * inter-module cross jumping optimization which reduces code size.
>
> * inter-module common tail merging which reduces code size.
>
> * inter-module jump threading which increases execution speed and
can
> reduce code size.
>
> * inter-module code motion that rearranges code to reduce the
number of
> jumps and hence overall code size.
>
> In addition, the compiler has been updated with some extra
intrinsics
> that you asked for, such as support for BCD
arithmetic, GNU-
compatible
> min and max operators ?< and ?>. We have
better register
allocation and
> will place variable and function addresses in
registers for the
lifetime
> of a function, and we generate better code all
around. The code
> generator and optimizer find more common idioms and generate
tailored
> code sequences for them.
>
> I even added the much-requested absolute and section declaration to
> easily place variables in RAM or in a section, e.g.
>
> int I @ 0x200; // place I at 0x200
> int J @ "INFOA" = 10; // place J in the INFOA segment and
initialise to
> 10
> void foo(void) @ "BOOTSECT" {...} // place the function foo in
the
> section "BOOTSECT"
>
> We now believe that we have a compiler that is genuinely the best.
For
> every benchmark that we have run, on customer code
and on
independent
> benchmark suites, we generate smaller code than
*all* our
competitors.
> Period. There is no question.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for MSP430 and ARM processors
Reply by Paul Curtis●January 6, 20042004-01-06
Hi Joel,
> Good job, Paul -- those sound like great
improvements. I don't
> suppose you happen to have 'before' and 'after' code
size comparisons
> for, e.g., the TI TCP/IP web servlet application? I would think
> it's 'big enough' that it could noticeably benefit from the
new
> features?
Sure do.
CrossWorks, no optimization: 7162 bytes
CrossWorks, w/ optimization: 6360 bytes
To show the optimizer to best effect, you could always compile the
MiBench susan code that IAR use for their benchmarking. IAR did a
really good job of optimizing that benchmark using a technique called
Cross Calling to reduce the code size. If you don't perform that
optimization, as we found to our cost, the benchmark results will be
poor. That's possibly one reason why IAR chose this single benchmark.
This spurred me on a bit, so I implemented some more optimizations in
the back end. Our optimizer goes beyond the IAR optimizer in that it
can find common sequences between compilation units, not just in a
single compilation unit. I suppose it's rather like Richard's Code
Compressor whole-program-optimization technology, but I must admit that
I haven't seen Code Compressor for the MSP430 so I can't really judge.
As a backgrounder, TI are working on a standard set of benchmarks for
MSP430 compilers. TI will publish the numbers after consent is given by
the various vendors.
On another note, related to TCP/IP, I now have uIP 0.9.1 running on the
Olimex EasyWeb-II and SoftBaugh TCP430 boards. I'll post a link when
I'm through with it.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors
Reply by Joel Kolstad●January 6, 20042004-01-06
Good job, Paul -- those sound like great improvements. I don't
suppose you happen to have 'before' and 'after' code size
comparisons
for, e.g., the TI TCP/IP web servlet application? I would think
it's 'big enough' that it could noticeably benefit from the new
features?
---Joel
Reply by Paul Curtis●January 5, 20042004-01-05
Hi Richard,
> At 06:51 PM 1/5/2004 +0000, Paul Curtis wrote:
> >Hi All,
> >
> >I have just uploaded CrossWorks for MSP430 v1.2 RC5 to the
> web site.
> >If there are no major calamaties, this is the version that
> will make it
> >out as v1.2 Gold. ...
>
> Oh good, now we have another target to shoot at :-)
Well, I'll take potshots at the AVR marketplace too. ;-)
> Happy New Year from this side of the pond.
Same to you. At least the MSP430 is looking like it'll be strong this
year...
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors
Reply by Richard F. Man●January 5, 20042004-01-05
At 06:51 PM 1/5/2004 +0000, Paul Curtis wrote:
>Hi All,
>
>I have just uploaded CrossWorks for MSP430 v1.2 RC5 to the web site. If
>there are no major calamaties, this is the version that will make it out
>as v1.2 Gold.
>...
Oh good, now we have another target to shoot at :-)
Happy New Year from this side of the pond.
// richard (This email is for mailing lists. To reach me directly, please
use richard@rich...)