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
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
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
Log in with Google account
No account? Register here.