llvm dev - Aug 2005 - [LLVMdev] Anyone is building a DSP-C frontend?

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'.

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.

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);

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

-- 
Tzu-Chien Chiu,
3D Graphics Hardware Architect
<URL:http://www.csie.nctu.edu.tw/~jwchiu>

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/

I have a doubt.

This is an excerpt of the raw report I get after running Spec benchmarks through
llvm-test.I am trying to calculate the program execution time.Does the output
result in bold corresponds to "lli time" in Makefile.spec ? I am not
interested in llc, jit or cbe.I simply need the normal bytecode and native code
execution times after running my pass over them.I have modified the Makefile for
the same.
>>> ========= '/External/SPEC/CFP2000/177.mesa/177.mesa'
Program
---------------------------------------------------------------

TEST-PASS: compile /External/SPEC/CFP2000/177.mesa/177.mesa

TEST-RESULT-compile: Total Execution Time: 45.1751 seconds (45.1877 wall clock)

TEST-RESULT-compile: 541814 Output/177.mesa.llvm.bc

 

TEST-RESULT-nat-time: program 2.870000

TEST-PASS: llc /External/SPEC/CFP2000/177.mesa/177.mesa

TEST-RESULT-llc: Total Execution Time: 12.9200 seconds (12.9080 wall clock)

TEST-RESULT-llc-time: program 5.040000

------------------------------------------------------------------

Thanks

Tanu

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050904/5024c9ac/attachment.html>