[rtl] rtlinux and fpemu

[dalugli <danlugli@tin.it>]

Thanks to Eric Sorton, who explained me how, I succeeded in using fpemu.

(It is not difficult; of course you must have a kernel compiled with
MATH_EMULATION enabled in menuconfig, and then it is sufficient to boot
it  with the following option in lilo.conf:
append="no387"
or in the specific case:
append="mem=63m no387"
as I use shared memory. Then cat /proc/cpuinfo confirms that the fpu is
not used).

So I tried rtlinux (the fp example) with fpemu.
The pc hangs completely immediately after insmoding rt_process.o. Even
the mouse arrow is frozen and the only possible thing to do is power
off.
This happens both with standard rt0.6 for 2.0.29 and with Paolo's
variant.

Regards, Daniele



> Short summary. Using the coprocessor in an rt task appears to give the

> following problems:
> 1) NaNs in non-rt tasks. This is the most widespread problem but
should
> be solved by Paolo's method. I confirm that using Paolo's variant I
have
> never seen a NaN in frontend, even when rt divides by zero.
> 2) Problems with IDE, like "hda: write_intr: status=0xd0 {Busy}".
These
> are much less common.  If I remember well, William Montgomery had one
> last year. I've seen one too, once. Moreover recently, during an
> experiment with fp, I (almost) trashed an IDE disk, with no error
> message. It could be the same kind of problem.
> 3) Increase of task jitter. I think I am the only one to complain
about
> this point, but probably other rtlinuxers do not have jitter on top of

> their interests and haven't made measurements.
> To be quantitative, I have a task with a period of 1 ms and a jitter
of
> better than 30 us without fpu, worse than 100 us with fpu (200 MHz
> Pentium). That's too much for my application.

> Conclusion. Quoting Paolo, FPU is a Cadillac; but its steering seems
> broken. With regret, and at least until fixings in RTL2.2 become
> available (provided they address points 2 and 3 too), it is safer to
go
> by bike today. In fact some of us (at least Siering and myself) are
> using bikes, that is homebrewed emulation of fixed or floating point
> numbers (what caused some sarcastic comment about reinvented wheels).
> I didn't try Siering's fixed point numbers yet; I can imagine that
they
> are very fast but not hyperprecise (Till please correct me if I am
> wrong). On the other hand, my floating point numbers are fairly
precise,
> at least enough for my purposes, but slow. By slow I mean 60 us for a
> sqrt, 200 us for a sin/cos (200 MHz Pentium, again). That's too slow
for
> me.

> Before throwing away my reinvented wheel, or spending more time to
make
> it glitter, I would like to try the standard emulation which comes
with
> the kernel. It is surely precise and maybe also fast enough.
> Until now I haven't been able to have it working. How do I persuade my

> Pentium to leave its precious fpu sleeping and use fpemu instead? Will

> anybody be so kind to give me a hint?


--- [rtl] ---
For more information on Real-Time Linux see:
http://rtlinux.cs.nmt.edu/