[sdiy] was how_you_got_started...

[Jay Schwichtenberg]

I do embedded code professionally. One of the things that I found about
fixed point code that I've implemented is that it is usually application
dependent. A lot depends on word length and where you need your accuracy
(either in the integer or fractional part). While a generic library could
handle this still think a more optimal solution would be just writing the
code yourself in assembly.

For C++ in the small processor realm, don't even go there. As mentioned
there are memory management issues but also to support C++ reasonably the
libraries needed to support it are huge. C++ is ok for things like databases
or code where you have a lot of real objects that you need to support. For
most small embedded projects it isn't needed, takes a lot of space and isn't
all that fast relative to asm and C code. Last project I worked on was an
dual core ARM based one with 256 mbytes of Flash and 4 gbytes of RAM. They
wouldn't touch C++ because they didn't think they had the room. IMHO I think
C++ has become way to complex, most people don't code it a consistent way
which makes it hard to follow and it's just a pain to use.

Jay S.
 
-----Original Message-----
From: synth-diy-bounces at dropmix.xs4all.nl
[mailto:synth-diy-bounces at dropmix.xs4all.nl] On Behalf Of
rsdio at audiobanshee.com
Sent: Saturday, September 26, 2015 2:22 PM
To: Thomas Strathmann
Cc: synth-diy at dropmix.xs4all.nl
Subject: Re: [sdiy] was how_you_got_started...


On Sep 26, 2015, at 12:44 AM, Thomas Strathmann <thomas at pdp7.org> wrote:
> On 26/09/15 04:31, Scott Gravenhorst wrote:
>> Yes, I found this to be true by doing it.  I've been able to write a
>> nice additive flute model monosynth for dsPIC33F in C, but my best
>> efforts at polysynths are in assembly language.  The main issue for me
>> is the fact that there is no native data type support for 16 bit fixed
>> point arithmetic.  Worse yet is that sometimes designs need more than
>> one definition for 16 bit fixed point.  Usually 1.15 works, but there
>> are times other configurations are necessary.  This is rather difficult
>> and at least ugly in C even using typedef etc.  Just ugly.  And in C I
>> had to write several functions in assembly language anyway that handle
>> the use of DSP instructions because they are not used by the C compiler
>> even if it's logical to do so.  At least in my experience...  can anyone
>> tell me how to make an FIR filter in C30 that uses the MAC
>> instruction... ??
> 
> What about using C++ for such cases. Seems like a good fit for hiding the
complexity of custom arithmetic code. Probably not ideal, but surely better
than writing raw assembly code all the way.

The origin of the problem is that C does not have fixed-point types. Sure,
you might be able to cover that up as much as possible in the source by
using C++, but it's not as straightforward as using assembly, because
assembly does have support for fixed-point.

I'm surprised there isn't a C derivative that has native support for
fixed-point, and which would therefore possibly optimize well on a DSP
platform.

Even though I generally prefer to use C for most development because it is
faster, especially for high level, broad scope coding, there are times when
assembly is actually faster and easier. Assembly usually wins when the scope
is focused in a narrow area, or when C simply doesn't have the necessary
types to represent what's actually going on in the hardware. Mixing C and
assembly usually gives the best overall advantage. If you put the high
performance math in assembly subroutines, then you can orchestrate at a high
level from C without ever touching individual fixed-point samples.

Brian
_______________________________________________
Synth-diy mailing list
Synth-diy at dropmix.xs4all.nl
http://dropmix.xs4all.nl/mailman/listinfo/synth-diy