Michael Schnell schrieb:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must take care to ensure that control of the memory is not
removed from the ARM
processor while it is performing this instruction.
This seems to apply
Michael Schnell schrieb:
> On 06/23/2010 04:49 PM, Henry Vermaak wrote:
>> No, SWP is atomic, so the implementation looks good (at a glance).
>>
>
> Seemingly not on all ARM sub-archs:
>
>>From some ARM manual:
>
> The ARM7500FE does not use the lock feature available in the ARM701
> macroce
Can un-specialized generics have abstract methods and have the class
implement of the specialized generic contain the actual methods? I'm
getting abstract errors presently but want to know if it is even
possible...
Thanks
___
fpc-devel maillist - fpc-
On 23/06/10 16:19, Michael Schnell wrote:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
mac
Michael Schnell wrote:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
>From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must
Op Wed, 23 Jun 2010, schreef Michael Schnell:
On 06/23/2010 05:18 PM, Mattias Gaertner wrote:
What system has such an unfair scheduler?
A "fair" Scheduler only can be fair if time slices are to be managed. If
you set a thread to a "realtime priority" (OK, you need to be root to be
allowed t
Sorry if I have been sounding rude:(.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 06/23/2010 05:18 PM, Mattias Gaertner wrote:
> What system has such an unfair scheduler?
A "fair" Scheduler only can be fair if time slices are to be managed. If
you set a thread to a "realtime priority" (OK, you need to be root to be
allowed to do that :) ) it's priority is above all the norma
On 06/23/2010 05:15 PM, Micha Nelissen wrote:
>
> Priority inversion? Isn't this a problem with any InterlockedC/E?
>
Priority inversion here leads to an unavoidable deadlock. "Normal"
priority inversion only reduces the priority of a high priority thread
to that of a lower priority thread that hol
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
>
> No, SWP is atomic, so the implementation looks good (at a glance).
>
Seemingly not on all ARM sub-archs:
>From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must take care to ensure that
On Wed, 23 Jun 2010 17:12:29 +0200
Michael Schnell wrote:
> On 06/23/2010 04:49 PM, Henry Vermaak wrote:
> > On 23/06/10 15:26, Michael Schnell wrote:
> >>
> >> Other ARMs (including thumb2) uses a loop with result compare. AFAIK
> >> this does not work reliably. I am not sure it it's really true
Michael Schnell wrote:
unfortunately we are in a "realtime" system and the priority of thread 2
is set higher than that of thread 1 and thus thread 1 never gets a CPU
Priority inversion? Isn't this a problem with any InterlockedC/E?
Micha
___
fpc-dev
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
> On 23/06/10 15:26, Michael Schnell wrote:
>>
>> Other ARMs (including thumb2) uses a loop with result compare. AFAIK
>> this does not work reliably. I am not sure it it's really true that ARM
>
> No, SWP is atomic, so the implementation looks good (at
On 06/23/2010 04:38 PM, Florian Klaempfl wrote:
>
> I can only speak for sparc (because I implemented them initially): they
> are implemented according to official sparc docs. Do you know more then
> them?
>
Sorry if I have been sounding rude :(.
I learned that If there is no hardware support,
On 23/06/10 15:26, Michael Schnell wrote:
Other ARMs (including thumb2) uses a loop with result compare. AFAIK
this does not work reliably. I am not sure it it's really true that ARM
No, SWP is atomic, so the implementation looks good (at a glance).
Henry
_
Michael Schnell schrieb:
> PPC, PPC64, Sparc: loop: not reliable
I can only speak for sparc (because I implemented them initially): they
are implemented according to official sparc docs. Do you know more then
them?
___
fpc-devel maillist - fpc-devel@li
On 23 Jun 2010, at 16:26, Michael Schnell wrote:
PPC, PPC64, Sparc: loop: not reliable
interlocked* is implemented correctly in the RTL and functions 100%
reliably on the above architectures. Please don't make such
categorical statements if you are unfamiliar with the architectures
(and
On 06/23/2010 03:56 PM, Henry Vermaak wrote:
>
> We've got this already, then:
>
> http://www.freepascal.org/docs-html/rtl/system/interlockedcompareexchange.html
>
nice !
X86, X68-64: good.
"ARMV6" uses ldrex (seemingly = "load locked"): good
Other ARMs (including thumb2) uses a loop with r
On 23 Jun 2010, at 16:14, Doriano Blengino wrote:
Jonas wrote:
First of all: please mention in the future that you are not
subscribed (also in replies, because people may forget), so that
people who reply know that they should CC you.
Sorry - I didn't notice (is it mentioned somewhere?).
Jonas wrote:
First of all: please mention in the future that you are not subscribed
(also in replies, because people may forget), so that people who reply
know that they should CC you.
Sorry - I didn't notice (is it mentioned somewhere?).
** I'am not subscribed to this list, at present **
On 23 June 2010 13:58, Michael Schnell wrote:
> On 06/23/2010 02:45 PM, Henry Vermaak wrote:
>> I think you'll first have to worry porting fpc to those architectures.
>>
> Right you are :)
>
> But anyway, if not using libc, you need to do the FUTEX user space part
> in Pascal/Assembler
>
> - With
Michael Van Canneyt schrieb:
At this time I am trying to finish a good auto-completion, so I need to
extract symbols from pre-compiled PPUs (especially the runtime standard
libraries). Right now I use ppudump(1) to extract symbols, but I could
Interesting, is that actually faster/better than p
Marco van de Voort schrieb:
The Kylix-like addition of an C compiler would help to solve such
issues, that arise from the use of *any* C code with FPC.
Well, since this is about a maintenance problem, it would only solve
it if the maintenance of the C compiler would be lower than the
maintenan
Am 23.06.2010 15:34, schrieb Henry Vermaak:
On 23 June 2010 14:22, Henry Vermaak wrote:
On 23 June 2010 14:13, Daniël Mantione wrote:
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
A futex syscall doesn't know anything about threads, it's for locking.
Perhaps I'm misunderstanding you?
I ha
On 23 June 2010 14:22, Henry Vermaak wrote:
> On 23 June 2010 14:13, Daniël Mantione wrote:
>>
>>
>> Op Wed, 23 Jun 2010, schreef Henry Vermaak:
>>
>>> A futex syscall doesn't know anything about threads, it's for locking.
>>> Perhaps I'm misunderstanding you?
>>
>> I have should have written "fu
On 23 June 2010 14:13, Daniël Mantione wrote:
>
>
> Op Wed, 23 Jun 2010, schreef Henry Vermaak:
>
>> A futex syscall doesn't know anything about threads, it's for locking.
>> Perhaps I'm misunderstanding you?
>
> I have should have written "futex" instead of "threads". With a Futex, you
> only cal
On 06/23/2010 03:08 PM, Henry Vermaak wrote:
> A futex syscall doesn't know anything about threads, it's for locking.
> Perhaps I'm misunderstanding you?
>
The Futex syscall does not lock a Mutex at all. It's a helper for the
user space locking action and performs the putting a thread to sleep
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
A futex syscall doesn't know anything about threads, it's for locking.
Perhaps I'm misunderstanding you?
I have should have written "futex" instead of "threads". With a Futex, you
only call the Futex syscall, if the Futex is locked. You still have
On 06/23/2010 03:00 PM, Henry Vermaak wrote:
> Why would you want to do that? Just use the futex syscall.
Here you are definitely wrong.
Futex is all about _not_ doing a syscall (i.e. change from user space to
Kernel space and back) but doing the Mutex operation in user space, if
possible (i.e. i
On 23 June 2010 14:03, Daniël Mantione wrote:
>
>
> Op Wed, 23 Jun 2010, schreef Henry Vermaak:
>
>> On 23 June 2010 13:58, Michael Schnell wrote:
>>>
>>> On 06/23/2010 02:45 PM, Henry Vermaak wrote:
I think you'll first have to worry porting fpc to those architectures.
>>> Right y
Op Wed, 23 Jun 2010, schreef Henry Vermaak:
On 23 June 2010 13:58, Michael Schnell wrote:
On 06/23/2010 02:45 PM, Henry Vermaak wrote:
I think you'll first have to worry porting fpc to those architectures.
Right you are :)
But anyway, if not using libc, you need to do the FUTEX user spac
On 23 June 2010 13:58, Michael Schnell wrote:
> On 06/23/2010 02:45 PM, Henry Vermaak wrote:
>> I think you'll first have to worry porting fpc to those architectures.
>>
> Right you are :)
>
> But anyway, if not using libc, you need to do the FUTEX user space part
> in Pascal/Assembler
Why would
On 06/23/2010 02:45 PM, Henry Vermaak wrote:
> I think you'll first have to worry porting fpc to those architectures.
>
Right you are :)
But anyway, if not using libc, you need to do the FUTEX user space part
in Pascal/Assembler
- With X86 using the appropriate assembler instructions (such as
On 23 June 2010 13:23, Michael Schnell wrote:
>
> If they show up that does not mean there really is a valid
> implementation. I don't know which archs are provided with the "Linus
> Tree", but at least with some "embedded" Kernels trees there only is
> some dummy code, just providing an error.
On 06/23/2010 01:37 PM, Henry Vermaak wrote:
>
> I still can't find which arches miss futex, and I can't find this
> information in the manpages, either. Can you point me to where you've
> found this information?
At least in the Linux Kernel Mailing list there are several discussions
on Futex (e.
On 06/23/2010 01:21 PM, Henry Vermaak wrote:
> There are no magic NPTL APIs: both NPTL and LinuxThreads use the
> "clone" system call.
Yep. Additional "clone flags" have been added with newer Kernels (see
"man clone").
Moreover for NPTL there are thread IDs additional to process IDs Same
can be o
On Wed, 23 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-22 14:40, Doriano Blengino het geskryf:
At this time I am trying to finish a good auto-completion, so I need to
extract symbols from pre-compiled PPUs (especially the runtime standard
libraries). Right now I use ppudump(1) to extract s
Op 2010-06-22 14:40, Doriano Blengino het geskryf:
>
> At this time I am trying to finish a good auto-completion, so I need to
> extract symbols from pre-compiled PPUs (especially the runtime standard
> libraries). Right now I use ppudump(1) to extract symbols, but I could
Interesting, is that
On 06/22/2010 03:12 PM, Henry Vermaak wrote:
>
> No, the syscall api is very stable, so minimum maintenance is
> required. Which architectures don't provide futex? I'm not aware of
> any.
>
The FUTEX Kernel API only makes sense, if the arch provides the
appropriate atomic operations to perform
In our previous episode, Hans-Peter Diettrich said:
> > start with a translated glibc in a good month), but the continuous
> > maintenance (for every distribution separately, since they could use
> > different kernels, options etc) , and interoperability with C code would be
> > killing.
>
> The K
On 23/06/10 12:13, Michael Schnell wrote:
On 06/22/2010 02:55 PM, Michael Van Canneyt wrote:
For the kernel interface: Not so much. (on some archs, FUTEX is missing).
Yep.
I still can't find which arches miss futex, and I can't find this
information in the manpages, either. Can you point
On 23/06/10 11:44, Michael Schnell wrote:
On 06/22/2010 05:18 PM, Florian Klaempfl wrote:
At least according to Linus, the kernel api/syscall interface will never
break.
Regarding Threads, as far as I understand, the thread aware APIs (e.g.
NPTL and FUTEX) have been added, while the other APIs
On 06/22/2010 02:57 PM, Graeme Geldenhuys wrote:
>
>> Of course you can avoid using the library, do the stuff in Pascal and
>> directly access the Kernel API, but this might be dangerous in case the
>> API might be modified some time in the future
>>
> Wouldn't the same apply to the pthreads l
On 06/22/2010 02:55 PM, Michael Van Canneyt wrote:
>
>
> For the kernel interface: Not so much. (on some archs, FUTEX is missing).
Yep.
>
> The problem starts if you start linking to C libraries. In that case
> you're
> pretty much forced to use pthreads; each distribution can make different
> choi
First of all: please mention in the future that you are not subscribed
(also in replies, because people may forget), so that people who reply
know that they should CC you.
On 22 Jun 2010, at 14:40, Doriano Blengino wrote:
At this time I am trying to finish a good auto-completion, so I nee
On 06/22/2010 02:49 PM, Graeme Geldenhuys wrote:
> http://linas.org/linux/threads-faq.html
This is _very_ old (1996).
they say:
"Kernel-Threads
Kernel-level threads often are implemented in the kernel using several
tables"
This might be true, but we now have a ubiquitous and stable NPTL
implement
On Tue, 22 Jun 2010, Doriano Blengino wrote:
Hi,
I am writing a Freepascal IDE in Linux+GTK2 (using freepascal, of course!). I
attach a screenshot for your curiosity, just in case.
At this time I am trying to finish a good auto-completion, so I need to
extract symbols from pre-compiled PP
On 06/22/2010 03:35 PM, Henry Vermaak wrote:
>
> So maybe the fpc syscall interface needs to be updated. Can you give
> any examples of what got reworked?
I don't suppose we already have NPTL and FUTEX, as same are used by
libc, anyway. If we want perfect performance and good (Posix-like)
behavi
On 06/22/2010 05:18 PM, Florian Klaempfl wrote:
> At least according to Linus, the kernel api/syscall interface will never
> break.
>
Regarding Threads, as far as I understand, the thread aware APIs (e.g.
NPTL and FUTEX) have been added, while the other APIs were not affected.
(No wonder, as I u
Marco van de Voort schrieb:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution separately, since they could use
different kernels, options etc) , and interoperability w
Op Wed, 23 Jun 2010, schreef Graeme Geldenhuys:
Op 2010-06-22 15:31, Marco van de Voort het geskryf:
Same problem. You still have to interface with the kernel, and it would be
incompatible with C libraries that use threads.
Well, if I don't use C libraries (only Object Pascal code), then i
Op 2010-06-22 15:31, Marco van de Voort het geskryf:
>
> Same problem. You still have to interface with the kernel, and it would be
> incompatible with C libraries that use threads.
Well, if I don't use C libraries (only Object Pascal code), then it should
still be beneficial. I can then write p
52 matches
Mail list logo
