[Xenomai-help] using floating point in rtdm

[Xenomai-help] using floating point in rtdm

[ramon costa]

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

Hi,

I would like to use floating point arithmetics (double, ..) and operations
(sin, cos) inside a rtdm task.
How should I do this ?

Can anyone provide and example (Makefile+code) or point me to one ?

Best wishes.
Ramon

[-- Attachment #2: Type: text/html, Size: 252 bytes --]

Re: [Xenomai-help] using floating point in rtdm

[Gilles Chanteperdrix]

ramon costa wrote:
> Hi,
> 
> I would like to use floating point arithmetics (double, ..) and operations
> (sin, cos) inside a rtdm task.
> How should I do this ?

You should not.

If you really want to, you have two solutions:
- let the kernel compile your module as is, this will generated
"soft-float" code, which means that the operations will be done in
software. Your module will contain undefined references to functions
actually implemented in libgcc. So, you will have to extract the needed
.o from libgcc.a and put them in your module.
- try and use "hardware" floating points. This means that you will have
to change the kernel build system to allow compiling hardware floating
points in kernel space. Here again, your module will contain undefined
references, but that will be undefined references to the libm functions
(such as sin, cos). So, you will have to compile the libm as a kernel
module. You will also have to patch RTDM to allow setting the XNFPU bit
to RTDM threads, and also note that you will be only able to use FPU
from such threads (and particularily, not from module initialization and
cleanup code).

If you decide to go either way, no code helping doing this will ever be
merged into Xenomai, so you will have to maintain your own version of
Xenomai.

> 
> Can anyone provide and example (Makefile+code) or point me to one ?

I am afraid nobody every did something like this because this is not
worth it.

-- 
					    Gilles.

Re: [Xenomai-help] using floating point in rtdm

[ramon costa]

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

Hi,

I'm trying to port some old stuff from RTLinuxfree.  As a first step I would
like to recompile
and check everything. Latter I will try to modify the code structure to  fit
xenomai structure.


- let the kernel compile your module as is, this will generated
> "soft-float" code, which means that the operations will be done in
> software. Your module will contain undefined references to functions
> actually implemented in libgcc. So, you will have to extract the needed
> .o from libgcc.a and put them in your module.
>

As this is only "temporary" this is the best option. I think my old
RTLinuxfree
code does something similar.

How can I do this in the Xenomai framework ?

Does RTDM task store the floating point context during task switching ?

Best wishes
Ramon





> - try and use "hardware" floating points. This means that you will have
> to change the kernel build system to allow compiling hardware floating
> points in kernel space. Here again, your module will contain undefined
> references, but that will be undefined references to the libm functions
> (such as sin, cos). So, you will have to compile the libm as a kernel
> module. You will also have to patch RTDM to allow setting the XNFPU bit
> to RTDM threads, and also note that you will be only able to use FPU
> from such threads (and particularily, not from module initialization and
> cleanup code).
>
> If you decide to go either way, no code helping doing this will ever be
> merged into Xenomai, so you will have to maintain your own version of
> Xenomai.
>
> >
> > Can anyone provide and example (Makefile+code) or point me to one ?
>
> I am afraid nobody every did something like this because this is not
> worth it.
>
> --
>                                             Gilles.
>

[-- Attachment #2: Type: text/html, Size: 2336 bytes --]

Re: [Xenomai-help] using floating point in rtdm

[Gilles Chanteperdrix]

ramon costa wrote:
> Hi,
> 
> I'm trying to port some old stuff from RTLinuxfree.  As a first step I would
> like to recompile
> and check everything. Latter I will try to modify the code structure to  fit
> xenomai structure.
> 
> 
> - let the kernel compile your module as is, this will generated
>> "soft-float" code, which means that the operations will be done in
>> software. Your module will contain undefined references to functions
>> actually implemented in libgcc. So, you will have to extract the needed
>> .o from libgcc.a and put them in your module.
>>
> 
> As this is only "temporary" this is the best option. I think my old
> RTLinuxfree
> code does something similar.
> 
> How can I do this in the Xenomai framework ?

You can do this any way you like. You will have absolutely no help from
the Xenomai framework.

> 
> Does RTDM task store the floating point context during task switching ?

With "soft-float", there is no floating point context to be saved.

-- 
					    Gilles.

Re: [Xenomai-help] using floating point in rtdm

[Gilles Chanteperdrix]

ramon costa wrote:
> Hi,
> 
> I'm trying to port some old stuff from RTLinuxfree.  As a first step I would
> like to recompile
> and check everything. Latter I will try to modify the code structure to  fit
> xenomai structure.
> 
> 
> - let the kernel compile your module as is, this will generated
>> "soft-float" code, which means that the operations will be done in
>> software. Your module will contain undefined references to functions
>> actually implemented in libgcc. So, you will have to extract the needed
>> .o from libgcc.a and put them in your module.
>>
> 
> As this is only "temporary" this is the best option. I think my old
> RTLinuxfree
> code does something similar.
> 
> How can I do this in the Xenomai framework ?
> 
> Does RTDM task store the floating point context during task switching ?

Also note that if you need libm functions, you will need a soft-float
kernel-mode libm.

-- 
					    Gilles.

Re: [Xenomai-help] using floating point in rtdm

[Gilles Chanteperdrix]

ramon costa wrote:
> Hi
> 
> There are some differences with RTLinuxfree which are making things
> difficult ... .
> 
> One last question (offtopic ?¿)....
> 
> In user space I can use outb commands (using ioperm). For example :
> 
> 
> #define PORT_PARALLEL 0x378
>  outb(valor,PORT_PARALLEL);
> 
> This can easily done for fixed addresses like the Parallel PORT. Although it
> is not nice
> it is working fine (and it very useful during the porting process )
> 
> 
> 
> This is more difficult for PCI devices which address is not fixed. In the
> kernel space (RTDM) I could use "pci_find_device" commands to obtain the
> base device base address.
> 
> Once this is done I could do something like:
> 
> outw(yint,PCI_BASE_ADRESS_1711 + PCI171x_DA0);
> 
> If I Know the device base address   (PCI_BASE_ADRESS_1711), this commands
> would also work
> in the user space ?

Well probably. Addresses such as PCI_BASE_ADDRESS_1711 live in a
separate address space, only accessible with outb/inb, etc... Accessing
I/O mapped PCI registers is another story. One way to access them is to
use libpci (package pciutils) to obtain their physical address, then
mmap it using /dev/mem.

> 
> How can I obtain the base address in the user space ?
> 
> (As this is temporary, could I obtain the address in kernel space by a
> simple program and
> use it in the user space ?)

PCI_BASE_ADDRESS_1771 looks like a macro to me, so surely, it may be
used in user-space without "passing it".

The design we encourage to use is the same as for regular Linux
applications and drivers: driver code in kernel-space using the RTDM
skin, application code in user-space using the native or posix skin
(posix is most probably what you are looking for).

-- 
					    Gilles.

Re: [Xenomai-help] using floating point in rtdm

[Bob Feretich]

  I haven't tried to implement the below yet, but it seems that it 
should work...

One of the drivers that I am creating requires OMAP3 Neon processing 
(hard SIMD floating point). In a standard Linux environment the Neon 
code would be executed in the driver's "back end" tasklet. I plan to 
implement this "back end" code as a Xenomai RT user task. That moves the 
Neon code execution from the RTDM interrupt context to the Xenomai user 
context. I believe that I read that the Xenomai user context supports 
hard floating point in versions of Linux newer than 2.6.30. Do I 
understand correctly?

I also plan to isolate the Neon code to a separately compiled module 
that uses hard floating point and static libraries. I'm planning this 
because I may need to use a different compiler to generate good Neon 
code and I want to prevent library conflicts. I have used the Angstrom 
(glibc) supplied compiler to build my entire Linux system, including 
Xenomai and my drivers. My Angstrom compiled "back end" task (a RT user 
task) will call the Neon module. I expect that the Neon module will make 
very little use of library functions, so compiling statically should not 
increase its size significantly.

In the worst case, I can  just have the Angstrom compiler link the Neon 
module's assembly file into the "back end" task. I have already verified 
that this module contains Neon instructions rather than calls to 
floating point library functions.

I don't know if this approach will work for your application, but you 
may want to consider it.

Regards,
Bob Feretich

On 8/19/2010 3:00 AM, xenomai-help-request@domain.hid wrote:
> Date: Thu, 19 Aug 2010 11:13:35 +0200
> From: Gilles Chanteperdrix<gilles.chanteperdrix@xenomai.org>
> Subject: Re: [Xenomai-help] using floating point in rtdm
> To: ramon costa<ramoncostacastello@domain.hid>
> Cc: Xenomai help<xenomai@xenomai.org>
> Message-ID:<4C6CF5BF.3060405@domain.hid>
> Content-Type: text/plain; charset=UTF-8
>
> ramon costa wrote:
>> Hi,
>>
>> I would like to use floating point arithmetics (double, ..) and operations
>> (sin, cos) inside a rtdm task.
>> How should I do this ?
> You should not.
>
> If you really want to, you have two solutions:
> - let the kernel compile your module as is, this will generated
> "soft-float" code, which means that the operations will be done in
> software. Your module will contain undefined references to functions
> actually implemented in libgcc. So, you will have to extract the needed
> .o from libgcc.a and put them in your module.
> - try and use "hardware" floating points. This means that you will have
> to change the kernel build system to allow compiling hardware floating
> points in kernel space. Here again, your module will contain undefined
> references, but that will be undefined references to the libm functions
> (such as sin, cos). So, you will have to compile the libm as a kernel
> module. You will also have to patch RTDM to allow setting the XNFPU bit
> to RTDM threads, and also note that you will be only able to use FPU
> from such threads (and particularily, not from module initialization and
> cleanup code).
>
> If you decide to go either way, no code helping doing this will ever be
> merged into Xenomai, so you will have to maintain your own version of
> Xenomai.
> ... snipped...

Re: [Xenomai-help] using floating point in rtdm

[Gilles Chanteperdrix]

Bob Feretich wrote:
>   I haven't tried to implement the below yet, but it seems that it 
> should work...
> 
> One of the drivers that I am creating requires OMAP3 Neon processing 
> (hard SIMD floating point). In a standard Linux environment the Neon 
> code would be executed in the driver's "back end" tasklet. I plan to 
> implement this "back end" code as a Xenomai RT user task. That moves the 
> Neon code execution from the RTDM interrupt context to the Xenomai user 
> context. I believe that I read that the Xenomai user context supports 
> hard floating point in versions of Linux newer than 2.6.30. Do I 
> understand correctly?

Yes, it should work. At least, FPU unit tests + LTP FPU tests seem to
work well together. And in fact, even if FPU is supported for
kernel-space tasks, it is hard to get working for the reasons explained
earlier. With regard to FPU, Xenomai is not very different from Linux:
we encourage people to only use FPU in user-space.

> I also plan to isolate the Neon code to a separately compiled module 
> that uses hard floating point and static libraries. I'm planning this 
> because I may need to use a different compiler to generate good Neon 
> code and I want to prevent library conflicts. I have used the Angstrom 
> (glibc) supplied compiler to build my entire Linux system, including 
> Xenomai and my drivers. My Angstrom compiled "back end" task (a RT user 
> task) will call the Neon module. I expect that the Neon module will make 
> very little use of library functions, so compiling statically should not 
> increase its size significantly.
> 
> In the worst case, I can  just have the Angstrom compiler link the Neon 
> module's assembly file into the "back end" task. I have already verified 
> that this module contains Neon instructions rather than calls to 
> floating point library functions.

In order to mix easily the NEON compiled code with the Armstrong
toolchain code (which, I suppose, is soft-float?), you may want to use
-mfloat-abi=soft. This allows mixing hardware FP code with software FP code.

-- 
					    Gilles.