Repurposing CMSIS DSPLIB

[dannyf]

Has anyone tried to repurpose the CMSIS DSPLib for other (non CM) chips?

I took a quick look at it and t he difficulties seem to be 1) 64-bit types and 2) some host-specific macros.

It would be interesting to see if something like that can be ported to a different chip, like PIC24.

[nctnico]

I'd guess the DSP lib also uses assembly to use ARM's DSP extensions. That would be hard to port. If it where easy to port you just can program your algorithm in C because it won't be any faster by using a library.

[westfw]

something like that can be ported to a different chip

It would be Wrong, though.  Probably in violation of the terms under which the DSPLib is licensed.

(although I'd expect the DSPLib to be mostly standard "good" algorithms specifically adapted to run well using the instructions available on the ARM.  Possibly using assembly, since I doubt whether C can be coerced into doing, say, saturated adds, without getting awfully close to assembly.  You would probably be better off starting with a high-level description of the "good" algorithms and porting them directly to your desired cpu.)

[andersm]

It would be Wrong, though.  Probably in violation of the terms under which the DSPLib is licensed.

The copy of CMSIS I have contains the following license, which is a standard BSD-style license. The top-level "CMSIS End-User Agreement" doesn't contain any clauses preventing use on other architectures either, as far as I can tell.

All files contained in the folders "CMSIS\DSP-Lib\Source" and "CMSIS\DSP-Lib\Examples"
are guided by the following license:

Copyright (C) 2009-2012 ARM Limited.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 - Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
 - Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
 - Neither the name of ARM nor the names of its contributors may be used
   to endorse or promote products derived from this software without
   specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDERS AND CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

although I'd expect the DSPLib to be mostly standard "good" algorithms specifically adapted to run well using the instructions available on the ARM.  Possibly using assembly, since I doubt whether C can be coerced into doing, say, saturated adds, without getting awfully close to assembly.

The actual DSP library is pure C, but it depends on a number of functions corresponding to ARM CPU instructions that you would have to port. However, there are already pure C implementations for most if not all of them for the smallest devices (CM0/CM3). The biggest job looks like creating a test suite to validate that your port produces the same results as the original version.

[westfw]

Well, cool!

[tszaboo]

I think it will use the FPU in the CM4F. Or it has SIMD instructions.
Anyway, is there anything wrong with the math.h and float.h?

[dannyf]

Some update:

1) I can confirm that the code can be ported to a non-ARM chip - I have a copy running on windows;
2) I have tested about 10 examples as provided by ARM, and they all passed.
3) I don't yet have a clean way of porting it - what I have is fairly messy.

I benchmarked it against some IEEE 1057 routines that I have and the ARM's q31 routines are about 3 - 5x faster than code natively generated by the compiler so the temptation is definitely there.

[westfw]

Which PC compiler are you using?  I thought most PC C compilers these days were pretty aggressive about using all the fancy execution modules...

[dannyf]

If you want to port it to a non arm platform, some considerations should be given to the following:

- clz: the code from arm uses clz extensively and you will have to find an implementation of it on your target platform. Luckily some compilers have built in implementation for clz. A generic clz will vary greatly in inefficiency.

- addressing or paging: the code has tons of tables and compiles to over 100kb on most platforms. On platforms that uses paging, you have to manually address that. This means extensive but simple changes to the code.

- numeric constants: arms has 32.- bit int vs 16 on most 8-bitters. So all the constants will need to be written as ul. Simple but extensive, as there are thousands of those items.

- flash space: all in, you are looking at over 100kb of flash space for the dsp lib. If your compiler does optimize away unused code, you have to use a large mcu.

I think in the end, you will find that porting it to a 32 bit or over chip, arm or otherwise, is a lot easier and practical.