On Mon, 2012-04-23 at 09:32 +0100, Julius Baxter wrote: > On Mon, Apr 23, 2012 at 9:17 AM, Jeremy Bennett > <[email protected]> wrote: > > On Mon, 2012-04-23 at 09:12 +0100, Julius Baxter wrote: > >> On Mon, Apr 23, 2012 at 8:55 AM, Jeremy Bennett > >> <[email protected]> wrote: > > > > <snip> > > > >> > As note above you most certainly do want the compiler to emit MAC > >> > instructions. > >> > >> And we think it's going to be used or useful enough to warrant > >> inclusion in the multilib combinations? If I were doing the multilib > >> stuff for the tool chain I wouldn't bother with it. > > > > If you have MAC instructions its because they matter for your > > applications, which are likely written in C/C++. You probably care > > deeply that the compiler emit them. > > I'm not sure - aren't most critical DSP loops written in assembly > anyway? Who relies on the C compiler to correctly and efficiently > implement the particular algorithm you want? But I'm not an expert > here and haven't done much DSP software stuff.
Hi Julius, Sometimes they are, particularly if your application has one location where all the compute is focussed. The penalty is you lose any other optimizations that the compiler might have been able to incorporate (for example observing that the code didn't need to be executed at all in certain circumstances). For larger and more diffuse systems, this doesn't scale. Increasingly users are relying on compilers to take advantage of these instructions. For example the recent work on TI C6000 series for GCC (new in 4.7). A lot of our commercial work has been in this field. Best wishes, Jeremy -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: [email protected] Web: www.embecosm.com _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
