In the thread "Threading support and C library under Linux/Unix", On 24 June 2010 10:05, Henry Vermaak <henry.verm...@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>
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel