[fpc-devel] ARM "user helpers"

[Michael Schnell]

In the thread "Threading support and C library under Linux/Unix", 
On 24 June 2010 10:05, Henry Vermaak <henry.vermaak at gmail.com> wrote:

Which exposes the user helpers here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l767

768
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l768>
 * User helpers.
769
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l769>
 *
770
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l770>
 * These are segment of kernel provided user code reachable from user space
771
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l771>
 * at a fixed address in kernel memory.  This is used to provide user space
772
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l772>
 * with some operations which require kernel help because of unimplemented
773
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l773>
 * native feature and/or instructions in many ARM CPUs. The idea is for
774
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l774>
 * this code to be executed directly in user mode for best efficiency but
775
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l775>
 * which is too intimate with the kernel counter part to be left to user
776
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l776>
 * libraries.  In fact this code might even differ from one CPU to another
777
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l777>
 * depending on the available  instruction set and restrictions like on
778
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l778>
 * SMP systems.  In other words, the kernel reserves the right to change
779
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l779>
 * this code as needed without warning. Only the entry points and their
780
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l780>
 * results are guaranteed to be stable.

Thus the Kernel creator community provides us with a nice abstraction to
prevent doing different code for different ARM sub-archs.

Moreover, with older ARM sub-archs, some "atomic" operations (called
"interlocked" in the FPC RTL) in fact are not decently doable in user
space without the help of the Kernel (which does not affect the speed of
such operations. See the other thread).

In the RTL, these interlocked operations are used e.g. with memory
management

As it seems to be a good idea to avoid libc binding, it is suggested to
do threading support directly in the RTL, using Kernel APIs instead of
using pthreadib. Besides creating and managing the thread this includes
doing inter-thread communication such as TCriticalSection.

Now, if supported by the Kernel - which is always but with 68K true for
the archs supported by FPC -, pthreadlib uses FUTEX (Fast User space
muTEX) to do pthread_mutex, providing a lot more performance than using
one of the Kernel's interprocess synchronizing APIs.

This quite tricky code (see "FUEXes are tricky":
http://people.redhat.com/drepper/futex.pdf ) but of course can be done
in the RTL. But it does needs certain "atomic" operations.

Right now, the implementation of "atomic" ("interlocked") functions in
the FPC RTL is not optimum with ARM.

 - It uses compiler switches to determine if an older or a newer ARM
sub-arch is used. And of course it is not always know at compile time on
which sub-arch the program will run. So as a default the old sub-arch is
assumed.

 - the code for the old sub-arch is not very good (and it can't be good,
as here Kernel-help is necessary):
.... - it is prune to be slow, as a busy spin lock is used
.... - it will dead lock if the priority of one thread is "realtime"
.... - it might fail as it's not granted that all ARMv5 chips have a
correct implementation of the atomicness of the swap instruction

I feel that this definitely asks for redoing this part of the RTL in a
way using the Kernel-provided "User Helpers", making this part of the
RTL much more reliable, a lot (just redirecting the function calls) and
free of sub-arch related compiler switches..

I feel this should be a quite easy task. The fixed addresses should be
found in the .h files of the ARM Kernel interface and calling a function
with a fixed address should be no problem at all and not even seems to
ask for ASM.

I very likely will start to use FPC for arm some day in Future, but
right now we did not even start to define the hardware and construct the
PCB the software will be running on. So I can't be of much help here at
the moment.

So maybe someone who already has the necessary hardware and experience
might want to get this done....

Thanks a lot !
-Michael


<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l795>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20100625/796f297a/attachment.html>