> For example can the optimizer perform vectorisation?

This answers that one http://gnuarm.org/pdf/gccint.pdf, but I'd be
interested if any has any experience of GCC and VFP.

Thanks,
Clifford

An update on this for anyone interested. I have had the opportunity to
evaluate the LPC3180 using GCC 4.0.2(WinARM).

To build VFP code use the options -mfpu=vfp -mfloat-abi=softfp

Philips' claim of 5x performance improvement for floating point
operations over software floating point seems about fair. For
algorithims heavily dependent on multiply-accumulate operations, or
square-root, performance may be even more drastically improved as the
VFP has instructions for these operations. The compiler will correctly
translate statments such as fx += fy * fz into a single FP MAC
instruction.

I have seen no evidence that the code generation employs
auto-vectorisation, even when the appropriate options are set. It is
still not clear to me what platforms apart from PowerPC G5 this has been
implemented on.

On the Nohau board, for single precison code, the performance with code
and data running from external SDR SDRAM was about half of that when
running from internal RAM, and worse for double precision code. This is
because the external bus runs at half the CPU clock rate. The
performance using DDR SDRAM would presumably be comparable to the
internal RAM performance. Enabling the instruction and data caches has a
dramatic effect on performance, especially for short algorithms working
on small data sets.

None of the default Newlib builds support the VFP, you will need to
rebuild the library specifically. Newlib does not include VFP specific
code for sqrt(), so it will still use a software algorithm rather than a
single instruction, although the individual operations in the algorithm
would still use hardware floating point of course. To realise the
advantage of the VFP square-root instruction you'd need to code your own
in assembler or modify Newlib.

The GDB and Insight debuggers are not VFP aware. VFP has a 'natural'
byte order for double precision values rather than the rather
unconventioanl 'cross-endian' format used by the older ARM FPA unit and
by GCC for softfp. Consequently the debugger displays doubles
incorrectly, single precision values work correctly however.

When -mfpu=vfp is used in conjunction with optimisation, the compiler
will seg. fault when certain code constructs are encountered. This will
for example prevent a Newlib build from completing. I have reproduced
the error with the following test code:


double test( double x )           // Line 1
{                                 // Line 2
  return (x >= 0 ? 0 : -1.0);     // Line 3
}                                 // Line 4 - error reproted here.

whnen compiled with:

arm-elf-gcc -c -O2 -mfpu=vfp -mfloat-abi=softfp test.c

Rewriting the code thus:

double test( double x )
{
    double y ;

    if( x >= 0 )
        y = 0 ;
     else
        y -1.0 ;

    return ( y );
}

seems to work around the problem. I have encountered other constructs
that exhibit this error, but in all cases I have been able to recode an
equivilent that solves the problem. I raised a bug report at
http://gcc.gnu.org/bugzilla, the response was simply that the bug could
not be reproduced in the mainline development stream 4.2.0 I have not
yet tried it on 4.1.1, and it may be an issue specific to the WinARM
build, or even only occuring on my PC. It would be interesting if any
one could reproduce this error with the same or other versions.

Supply of these chips from Philips is not yet at production level.

Clifford

Clifford, thanks for passing the info, the Philips LPC3180 (Nohau board)
is my current target as well.  I'm not using the VFP yet but probably
will later.  Cheers, --Bill

Clifford Slocombe wrote:
> ...I have not yet tried it on 4.1.1...

I have now, no problems found. I thought I'd already posted a message to
that effect, since I tested it a couple of weeks ago, but obviously in
my head only!

Here is some VFP square-root code I cooked up. It compiles, but have
moved on and put the LPC3180 evaluation board away for the moment, so it
is untested. I checked the generated code and I believe it should work:

#if !defined _VFP_FP_

    #error This code requires compiler options: -mfpu=vfp
-mfloat-abi=softfp

#else

    float vfp_sqrtf( float x )
    {
        float rootx ;
        __asm__( "fsqrts %0, %1\n" : "=w" (rootx) : "w" ( x ) ) ;
        return rootx ;
    }


    double vfp_sqrtd( double x )
    {
        double root ;

        __asm__( "fldd    d0, %1\t\n"
                 "fsqrtd  d1, d0\t\n"
                 "fstd    d1, %0\t\n"
                 : "=m" (rootx)
                 : "m" (x)
               ) ;
        return rootx ;
    }

#endif

The double precision version is more complex syntactically because the
"w" register hint seems to apply only to single precision, you have to
select them explicitly for double precision as far as I can tell.
Possibly a clobber list should be used here?

Another hint to anyone using and RTOS, if the RTOS does not preserve the
floating point registers during context switches (most do not, since
most ARM cores do not have an FPU), you will need to restrict floating
point operations to one task only or otherwise ensure that floating
point operations are not preempted by a task that may also perform
floating point operations. Ideally an RTOS should allow you to specify
whether a task uses FP operations so that the FP registers are only
saved and restored on switched from and to such tasks in order to
minimise context switch time otherwise (VxWorks does this for example).

Clifford

Another note: I have been in discussion with Rowley Associates
http://www.rowley.co.uk/ with respect to VFP support in their
proprietary library and debugger. It seems as soon as that can obtain a
suitable evaluation board they will start developing their GCC based
toolchain for the LPC3180. I have provided then with a long list of
requests and ideas for such a product, so possibly one to watch if you
are after a commercial quality GCC based solution.

In the meantime I am continuing to roll-my-own with the help of WinARM,
but I would really like not to have to use Insight/GDB, or have to worry
about whether my custom Newlib build is correct.

Clifford.

Clifford Slocombe wrote:
> ...I would really like not to have to use Insight/GDB, or have to worry
> about whether my custom Newlib build is correct.

Clifford, I am using Eclipse with its CDT plugin, along with the GNU
toolchain under the hood (is the idiom "under the bonnet" used in the
UK?).  By using ARM's RealView ICE -- that supports remote gdb! -- for
JTAG connectivity over the ethernet one needs no special drivers or
tools, just vanilla Eclipse/CDT.  It is all working spectacularly well,
and even better, it runs fine on my preferred platform (OS X).  It
certainly develops as well for me as CodeWarrior for Embedded 68K ever
did.  My only complaint is that Eclipse sometimes feels a bit slow on my
1.25 GHz G4, perhaps due to its Java nature.

Granted this approach does not address GDB's and Newlib's
questionable/nonexistent abilities with the VFP at present, but perhaps
it would make life easier while waiting for a commercial product that
explicitly supports the LPC3180?

Best, --Bill

Bill Burgess wrote:
> Clifford, I am using Eclipse with its CDT plugin, along with the GNU
> toolchain under the hood

I have experimented with Eclipse a little - I instantly disliked it. It
seemed very prescriptive about how my project was organised, and had a
lot of excess-baggage. Perhaps I could learn to love it (or configure
it!). I am using an Abatron BDI2000 JTAG debuggger with ARM/GDB
firmware, so it should work as well. Currently I use a looser
integration of CodeWright, GNU, Insight, and a 'self-build' makefile
generation tool.

> (is the idiom "under the bonnet" used in the UK?).
Due to the similarity of the language, and the import of US TV and Film,
must UK citizens are bi-lingual ;-) "under the hood" is the more likely
term, since it somehow sounds cooler and less quaint!

Clifford

Clifford Slocombe wrote:
> I have experimented with Eclipse a little - I instantly disliked it.

My first reaction to Eclipse was also negative.  In retrospect this was
primarily because (a) it was not immediately obvious to me how to make
it do what I wanted, i.e., frustration; and (b) CDT's minimal built-in
niceties for embedded work forced me to brush off my manuals and
re-learn how to write my own makefile (horrors!).  However once I took
the time to learn Eclipse properly (primarily using the book "Eclipse
Distilled"), and realized that an explicit makefile makes a project more
portable, these concerns evaporated.

Even now there are some annoyances, like display of global variables in
the debugger (lots of "$d" variables listed but static file-scoped
globals apparently cannot be displayed) and somewhat sluggish
responsiveness on my 1.25 GHz G4.  I also wish that the built-in text
editor was just a bit smarter, for example with more elaborate syntax
coloring and by allowing triple-click to select a whole line.  One can
use an external text editor quite easily -- Eclipse explicitly supports
this -- but then one loses access to project-wide symbol refactoring and
other language-aware capabilities.

But on the whole it seems like a very big win, at least in my situation.

Cheers, --Bill

I have just started looking at the Green Hills ARM tools since they seem
to have the best available VFP support and optimisation technology
(outside of Intel's XScale specific compilers). I am not expecting it to
be cheap however, but cost was never the prime reason for using WinARM
in the first instance (and it's not my money of course!)

Green Hills heve their own IDE (MULTI), but also have integration
support for standard Eclipse/CDT (not a modified version like
WindRiver's).

If I move on this I'll let you know how it turns out.

Clifford

Hello,

a little off topic, but:

> As for Eclipse, I found it very hard to get on with to start with.

I have make a small tutorial how to work with Eclipse and an
ARM toolchain, take a look here:

http://www.yagarto.de/howto.html

Perhaps this will help to start with Eclipse.

But yes, you must create your own makefile.

An other very detailed tutorial from James Lynch can be found at the
Olimex page:

http://www.olimex.com/dev/arm-usb-ocd.html

Search for:

"ARM Cross Development with Eclipse (10MB) REV-3"

Best regards,

Michael

FordP wrote:
> I have used Green Hills in the past. I am very pleased it is in the past
> too. The Tools are competent, but the licencing is a nightmare.

I have spoken to Green Hills and it seems more flexible than you suggest
in that respect. It seems thay have reationalised thier licensing
somewhat.

I am also looking at Keil ARM MDK which combines the uVision IDE with
ARM's RealView compiler - it seems like it may have better VFP support,
but not even the compiler vendors seem to be able to give me a straight
answer on code generation for VFP SIMD (Single Instriction Multiple
Data) instructions.

If floating-point performance was not so critical, I too would stick
with GCC, or specifically WinARM's build of GCC.

Clifford

FordP wrote:
> I am pleased to hear the licencing has improved. I find this a bit
> strange however as our last experince with Green Hills Licencing was
> only a couple of months ago.

Maybe then I need to be more wary. However I have now had some time to
evaluate GHS's VFP code generation; the evaluation license agreement
prevents me from reporting my findings (yes I actually read it!).
However I wonder why I have to do this and cannot just get a straight
answer from the vendor!?

Clifford.

Clifford Slocombe wrote:
> I am also looking at Keil ARM MDK which combines the uVision IDE with
> ARM's RealView compiler - it seems like it may have better VFP support,
> but not even the compiler vendors seem to be able to give me a straight
> answer on code generation for VFP SIMD (Single Instriction Multiple
> Data) instructions.
>
> If floating-point performance was not so critical, I too would stick
> with GCC, or specifically WinARM's build of GCC.

My current project uses an LPC3180 and we started out with Keil for many
of the same reasons you say. Although I've successfully used Keil before
(mostly on Luminary Micro's ARM Cortex-M3 parts), I had nothing  but
trouble with it using the LPC3180. In one month, it went through 3
revisions which cured most of the major problems (such as not running at
all!), but there were still some nasties lurking which I regularly
stumbled upon. Finally, we gave up and moved to IAR and everything's
been fine ever since. Also, even though IAR's quoted price was about
$1000 higher than Keil's, after a bit of negotiation, they matched
Keil's price so the financial hit wasn't that bad. My admittedly limited
experience with Green Hills pretty much matches what's already been
posted in this thread.

Perhaps by now, Keil has gotten their LPC3180 act together, but caveat
emptor.

Bob Stout wrote:
> of the same reasons you say. Although I've successfully used Keil before
> (mostly on Luminary Micro's ARM Cortex-M3 parts), I had nothing  but
> trouble with it using the LPC3180.

Direct LPC3180 support from all tools was pretty limited when I first
looked at them, but seems to have improved. The intended project for
this part has been delayed, so hopefully they will be matured by the
time I return to it.

Our current solution uses a Samsung S3C2410X and WinARM with a
commercial RTOS, so we had to implement all the chip specific code,
board support and bootloader mechnaism ourselves in any case. So long as
the compiler generates valid code, my primary concern was code
performance. All the chip specific support and integrated tools provided
by Keil and IAR are a nice-to-have since it saves a lot of board
bring-up effort, but would probably not be the primary factor in any
decision.

I wonder what precisely you had problems with?

Clifford

Clifford Slocombe wrote:
> I wonder what precisely you had problems with?

To begin with, the quick start "Blinky" program wouldn't link. If I
can't get the demo code to link and run out of the box, that's strikes
1, 2, and 3 as far as I'm concerned. After the three updates from Keil
in rapid succession, I could finally get the demos running, but later
had major problems getting project code to build and run since the clock
speed setting code wouldn't work. That was back in August. If Keil
maintained their three update/month track record, I would expect there
to have been some 21 updates released since then.  Maybe it's all fixed
now. In any case, IAR builds a superior tool chain, IMO.

Too much pain, too little gain...

Bob Stout wrote:
> Clifford Slocombe wrote:
>> I wonder what precisely you had problems with?
>
> To begin with, the quick start "Blinky" program wouldn't link. If I
> can't get the demo code to link and run out of the box, that's strikes
> 1, 2, and 3 as far as I'm concerned. After the three updates from Keil
> in rapid succession, I could finally get the demos running, but later
> had major problems getting project code to build and run since the clock
> speed setting code wouldn't work. That was back in August. If Keil
> maintained their three update/month track record, I would expect there
> to have been some 21 updates released since then.  Maybe it's all fixed
> now. In any case, IAR builds a superior tool chain, IMO.
>
> Too much pain, too little gain...

I am wondering why you will have had such problems since I imagine teh
the compiler and linker are unchanged, the LPC3180 is an ARM9 with a VFP
nothing more. When I used Keil, they had only rudumentary support for
LPC3180, I wrote code in the CRT start-up code to set the clock and map
memory.

Would it be fair to say that the problems you had were with the LPC3180
specific support rather than the compiler/linker, because I obviously
did not rely upon any of that? I would not be too worried about that and
would assume that it would mature over time. The compiler itself is
ARM's RealView compiler, it is unlikely that it is seriously broken it
seems.

I've had poor support from IAR, and problems with their floating license
manager.

Clifford Slocombe wrote:
> I am wondering why you will have had such problems since I imagine teh
> the compiler and linker are unchanged, the LPC3180 is an ARM9 with a VFP
> nothing more. When I used Keil, they had only rudumentary support for
> LPC3180, I wrote code in the CRT start-up code to set the clock and map
> memory.
>
> Would it be fair to say that the problems you had were with the LPC3180
> specific support rather than the compiler/linker, because I obviously
> did not rely upon any of that? I would not be too worried about that and
> would assume that it would mature over time. The compiler itself is
> ARM's RealView compiler, it is unlikely that it is seriously broken it
> seems.

I have no doubt that my problems were LPC3180-specific. I've use Keil's
tools on other ARM chips without any problems. Possibly a large part of
it may be NXP. The 3180 is a relatively new chips and NXP's
documentation and tech support are abysmal! OTOH, if I wanted to roll my
own support, I'd be using GNU tools rather than spending the money for a
commercial tool chain. I know what my time is worth (as do my clients!)
and the money spent on a good commercial tool chain is well spent if it
means I can hit the ground running.

Unfortunately, in this case, we wasted a week or two discovering that we
could not hit the ground running with Keil. Having discovered that, I
could have wasted more time rolling my own LPC3180 configuration or
switch to another commercial tool chain. Since I'm only a consultant and
other folks with less experience are going to be maintaining this
project, the decision to dump Keil was a no brainer.

> I've had poor support from IAR, and problems with their floating license
> manager.

I've had probably fewer problems with IAR than most other tools vendors.
When I did have problems, their tech support was very helpful Of course,
YMMV. My past experience with IAR was mostly using MSP430 chips. Other
than that, I have the most experience using tools from Mentor Graphics
and Freescale/Metrowerks (I spent most of 2001 consulting for Metrowerks
writing compiler test automation for their StarCore tool chain).

Bob Stout wrote:
> [...]  OTOH, if I wanted to roll my
> own support, I'd be using GNU tools rather than spending the money for a
> commercial tool chain. I know what my time is worth (as do my clients!)
> and the money spent on a good commercial tool chain is well spent if it
> means I can hit the ground running.

Indeed, but in this application performance was the prime motivation,
and I was attempting to determine which compiler best supported VFP.
Library support was generally rudimentary (i.e. simply a
re-compilation), none I tested used the square root instruction to
implement the sqrt() function for example. And optimisation between
compilers varied widely in the techniques applied. The GNU compilers
in-line assembler did not fully support double precision in the way it
supports single precision (see the code I posted near the start of this
thread).

As you can probably tell from the start date of this thread,
time-to-market is not the driving factor here, and the project has many
other issues being researched such that the processor implementation is
not on the critical path.

Thanks for your input, it will certainly make me somewhat wary.

Clifford

Clifford Slocombe wrote:
> Indeed, but in this application performance was the prime motivation,
> and I was attempting to determine which compiler best supported VFP.
> Library support was generally rudimentary (i.e. simply a
> re-compilation), none I tested used the square root instruction to
> implement the sqrt() function for example. And optimisation between
> compilers varied widely in the techniques applied. The GNU compilers
> in-line assembler did not fully support double precision in the way it
> supports single precision (see the code I posted near the start of this
> thread).
>
> As you can probably tell from the start date of this thread,
> time-to-market is not the driving factor here, and the project has many
> other issues being researched such that the processor implementation is
> not on the critical path.

Different projects, different requirements. In my case, we're using the
3180 as a dedicated DSP processor in a multiprocessor architecture with
an LPC224x to handle supervisory and communications functions. The
reason the client hired me is that they have no one on staff currently,
either here in Houston, in California, or in India, who knows much about
DSP. My goal was therefore to come up with something that could be
easily maintained once I'm out of the picture. The DSP code (IIR
filters) is machine generated by some filter CAE software and I wanted a
processor which could run it with minimal modification at the necessary
speeds. The 3180 pretty much had the field to itself at the price point
the client wanted. Testing with the IAR tools has shown that it can run
the filters at speed without using up all the processor bandwidth.
That's good enough, so no further performance issues came into play.

> Thanks for your input, it will certainly make me somewhat wary.

Ultimately, that's all I was saying... If someone's going to use the
3180 with the Keil tool chain, they should be aware of the problems I
encountered, although hopefully subsequent Keil releases have fixed
everything. Also note that this was a very CPU-specific caveat and not a
blanket indictment of Keil's products which I have found to be otherwise
quite good on other CPUs.

Thanks for this very helpful discussion.  I'm still using Eclipse+GNU to
develop for the LPC3180 with no regrets.  But yes, I'm "rolling my own"
for just about everything, including hardware.  And I'm not using the
VFP (yet).

I spoke with a representative of BDTI, a DSP benchmarking company, at
the Embedded Systems Conference last year and he had never heard of the
ARM VFP.  If the VFP remains relatively unknown it could explain why the
tools are lagging.

A quick check of the BDTI site just now however revealed a new reference
to the VFP as bundled with recent Cortex solutions.  This is somewhat
off-topic but here is a beautifully-presented discussion of using (what
I think must be) Cortex-specific instructions for tight filter coding.
MIght be interesting?

http://www.bdti.com/articles/200710_armcortex.pdf

Also Clifford mentioned Rowley earlier in the thread and they do appear
to be supporting the LPC3180:

http://www.rowleydownload.co.uk/arm/packages/Nohau_Phytec_LPC3180.htm

--Bill

Bill Burgess wrote:
> A quick check of the BDTI site just now however revealed a new reference
> to the VFP as bundled with recent Cortex solutions.  This is somewhat
> off-topic but here is a beautifully-presented discussion of using (what
> I think must be) Cortex-specific instructions for tight filter coding.
> MIght be interesting?
>
> http://www.bdti.com/articles/200710_armcortex.pdf

Thanks for the link! Due to low production volume, most of my work has
to use off the shelf parts. I wonder if Luminary Micro could be coaxed
into offering Cortex-R4 parts?

> Also Clifford mentioned Rowley earlier in the thread and they do appear
> to be supporting the LPC3180:

I may be doing some work with ImageCraft so they might support it soon
as well, since I happen to have a Phytec 3180 board to test on. ;-)