Re: [Xenomai-help] Re : sqrt() function in xenomai kernel module

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

Paul wrote:
> On Wednesday 29 August 2007 14:20, Gilles Chanteperdrix wrote:
>> On 8/29/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>>> On 8/29/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>> Mathieu JOINIE-MAURIN wrote:
>>>>> The application I used is a small controller for robot developped by
>>>>> people in the lab. Before it used to be in RTAI. But now they are
>>>>> trying to use Xenomai. The application is splitted in two parts: the
>>>>> user side which saves data, manages interfaces and the kernel module
>>>>> which realise all the real time tisk (sampling, writing to electronic
>>>>> card, controler). The communications between the two is made by 5
>>>>> pipes (command, parameters, acknowledgment, save, status).
>>>>>
>>>>> This is why i need to make my sqrt() function (of double variables) 
>>>>> into my kernel modul part.
>>>> Given that this is also a "small" application, I bet it will be far
>>>> easier for you to port it to user-space (POSIX or native skin) than
>>>> porting a math lib into kernel space.
>>> Compiling a libm in kernel-space is not hard at all, especially since
>>> a libm does not use any system call. But Mathieu could even do a
>>> simpler thing: if the only math function used is sqrt, he could simply
>>> add an implementation of this function into his kernel module.
>> Actually the rtai_math module seems to have no external dependency.
>> So, you can use it freely with Xenomai. If you want to port it a bit
>> more cleanly to xenomai, all you have to do is replacing libm_errno
>> with *xnthread_get_errno_location() (defined in nucleus/thread.h).
> 
> Running the x86_64 build here, I found a GCC flag (-mno-sse IIRC) being used 
> by the kernel make that prevents any floating point instructions from being 
> used. So a port/cleanup of rtai_math would most likely only work for i386 & 
> ppc architectures..
> 

And that rtai_math stuff is arch-independent, i.e. the slower your CPU
is, the less efficient that code gets. Back in the old days when we used
RTAI kernel space modules (LXRT was unstable), we had to hack our own
i386 math lib with inline assembly for accelerated hw support, thus
acceptable performance.

Kernel-space math remains a dead end, just the point where it ends may
vary. We should really encourage people to port away from it whenever
possible.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]