EmbDev.net

Forum: ARM programming with GCC/GNU tools Fixed Point support for cross GCC compiler


von Mohamed S. (shafi)


Rate this post
useful
not useful
Hello everyone,

I am involved with the porting of GCC for a new arm processor.
The trouble is that I have to add a feature which is not supported by
GCC - Fixed point support.
You know adding a new support along with porting is going to be tough.

Someone told me that one can add support in two ways.
1.  Include the support through the compiler (change the internals).
2.  Outside the compiler, through a library. (library support)

I am not sure which one to pursue.
The processor has a dedicated hardware support for fixed point
operations.
Providing the support through a library is a good option when this is
so?

Could anyone tell me which will be the best approach?
and why it is so?

or better could anyone give me an example so that I can use it as a
reference
while porting?


Thanks in advance.

Mohamed Shafi.
shafitvm@yahoo.com

von Clifford S. (clifford)


Rate this post
useful
not useful
Mohamed Shafi wrote:

> I am involved with the porting of GCC for a new arm processor.

I am not sure what you mean by 'porting GCC' the WinARM tools work out
of the box with all ARM cores supported by GCC. All you have to do is
implement appropriate C (and possibly C++) runtime initialisation, and
implement the syscalls stubs for newlib.

> The trouble is that I have to add a feature which is not supported by
> GCC - Fixed point support.
I've never come across a C/C++ compiler that did have built in support
for fixed point. If it did, it would not be C or C++ (at least not as
defined by the ISO standard)

> You know adding a new support along with porting is going to be tough.
>
> Someone told me that one can add support in two ways.
> 1.  Include the support through the compiler (change the internals).
> 2.  Outside the compiler, through a library. (library support)
>
I would suggest that option 2 is the only practical (and sensible)
approach. Otherwise you will end up with very non-portable code since it
will only ever work with teh compiler you build and no other!. However
if you want to make fixed point arithmentic look like built-in type
arithmetic, you should use C++ and implement a fixed-point class with
operator overloading.

> The processor has a dedicated hardware support for fixed point
> operations.
Use inline assembler (or call separate assembler routines from your
C/C++ code).


In summary I would implement a C++ fixed-point class with member
functions and overloaded operators inplemented in in-line assembler to
build the appropriate fixed point operations. However I am not sure if
the GNU assembler supports these instructions (easy enough to test -
make sure you set the correct CPU type in te compiler options). I
recently wrote some in-line assembler for the Vector Floating Point
coprocessor, and found the inline assembler did not directly support
double precision registers for example. (see
http://en.mikrocontroller.net/topic/61360). If you don't want to use
C++, then a C function API would be fine, but without the syntactic
sugar that C++ operator overloading provides.

Clifford

von Anonymous (Guest)


Rate this post
useful
not useful
Implementing the operations in a library will be easier, if you are not
already intimate with the relevant parts of gcc. You can just define
inline functions or macros with the relevant inline assembler code in a
header file, like for example is done in /usr/include/bits/mathinline.h
in the libc6/glibc2.3.2-headers. You just have to learn gcc's asm()
syntax for that, and your assembler has to know these operations of
course. And most likely you can't use normal operators like in
'1.1+2.3*3.2', but have to write add(1.1,mul(2.3,3.2)). Of course you
have to code your asm carefully to allow gcc to still optimize your
code.
If your CPU doesn't have floating point at all and only fixed point, you
may get away with defining it as a strange floating point type, but I
don't know anything about this.





Clifford Slocombe wrote:
> Mohamed Shafi wrote:
>
>> I am involved with the porting of GCC for a new arm processor.
>
> I am not sure what you mean by 'porting GCC' the WinARM tools work out
> of the box with all ARM cores supported by GCC. All you have to do is
> implement appropriate C (and possibly C++) runtime initialisation, and
> implement the syscalls stubs for newlib.
>
>> The trouble is that I have to add a feature which is not supported by
>> GCC - Fixed point support.
> I've never come across a C/C++ compiler that did have built in support
> for fixed point. If it did, it would not be C or C++ (at least not as
> defined by the ISO standard)
>
>> You know adding a new support along with porting is going to be tough.
>>
>> Someone told me that one can add support in two ways.
>> 1.  Include the support through the compiler (change the internals).
>> 2.  Outside the compiler, through a library. (library support)
>>
> I would suggest that option 2 is the only practical (and sensible)
> approach. Otherwise you will end up with very non-portable code since it
> will only ever work with teh compiler you build and no other!. However
> if you want to make fixed point arithmentic look like built-in type
> arithmetic, you should use C++ and implement a fixed-point class with
> operator overloading.
>
>> The processor has a dedicated hardware support for fixed point
>> operations.
> Use inline assembler (or call separate assembler routines from your
> C/C++ code).
>
>
> In summary I would implement a C++ fixed-point class with member
> functions and overloaded operators inplemented in in-line assembler to
> build the appropriate fixed point operations. However I am not sure if
> the GNU assembler supports these instructions (easy enough to test -
> make sure you set the correct CPU type in te compiler options). I
> recently wrote some in-line assembler for the Vector Floating Point
> coprocessor, and found the inline assembler did not directly support
> double precision registers for example. (see
> http://en.mikrocontroller.net/topic/61360). If you don't want to use
> C++, then a C function API would be fine, but without the syntactic
> sugar that C++ operator overloading provides.
>
> Clifford

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.