[LLVMdev] Anyone is building a DSP-C frontend?

[Chris Lattner]

On Wed, 31 Aug 2005, Tzu-Chien Chiu wrote:

> fixed-point number could be stored in LLVM first class integer types.
> i cannot see the problem now. but to be type-safe, there should be a
> first class 'fixed'.

There is no need.  Lowering is fine, in the same way that enums or 
typedefs are currently lowered to llvm integer types.

> some llvm extensions required to mapping dsp-c lanaguages could be
> implemented as qualifiers.
>
> 1. _sat qualifier
>
> Saturate the result within [0.0, +1.0> or [-1.0,+1.0> (unsigned/singed).
>
> sat signed fixed a;
> sat signed fixed b;
> sat signed fixed c;
> a = -0.75r; // 'r' is fixed-point number postfix
> b = -0.75r;
> c = a + b; /* c = -1.0r !!! */
>
> this qualifier can be implemented just like the 'const' qualifier.

This shouldn't be a type qualifier, if implemented in llvm, this should be 
new operations (e.g. add_sat).  Saturating arithmetic would also be 
interesting for the vector/simd people.

> btw, in some implementation, the saturation is explicitly specifiedby
> the arithmetic operation, not the variable itself. for example:
>
> /* add the operands, saturate the result before it's assigned to c */
> c = add_sat(-0.75, -0.75);

The way it is expressed at the source language isn't important.  However 
it is expressed there, it should be lowered to llvm operations that 
express what happens to the data (e.g. add_sat, sub_sat, etc).

> 2. memory space qualifier
>
> a typical program will have its global variables and constant in
> different data segments. a segment is just a block with continuous
> memory. there is no difference where the segment is. however, it's
> different in the embedded system. usually constants are preferred to
> be put in the ROM, while the global vars in SRAM. however, sometimes
> the dsp programmer wants to explicitly specify where the data is. for
> example, to put constant in RAM. for some strange reasons like cost
> and access time.
>
> int __rom x = 0; // const in ROM
> int __ram y = 1; // const in RAM

There are two pieces to this.  Again, this shouldn't be a type qualifier. 
Instead it is an attribute on: globals, loads, and stores.  An example of 
this is the volatile flag, which in C goes on the declaration but in llvm 
it goes on the access.  Here you need to specify ram vs rom on the global 
itself presumably so the code generator knows where to emit the decl.

Adding these things to llvm is a very reasonable thing to do.  If you're 
interested, it would probably be good to start with a basic code generator 
for a target that uses these things.  Once the basic features are working, 
new extensions like these can natually be added to both the target and 
llvm itself.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/