Hi,
I get a compilation error in the compiler when creating a win32 to
arm-wince crosscompiler with fpc 2.5.1:
cgcpu.pas(2087,88) Error: Identifier not found pasbool
Can
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/pasboolxx/compiler/arm/cgcpu.pas?r1=17847r2=17846pathrev=17847
be
A similar discussion is going on in Lazarus-develop, but this obviously
is a compiler question.
In C, there is the volatile keyword that ensures that after the code
sequence enters the next C instruction after that which modified this
variable, another thread sees the correct state of the
Here is a little idea for an automated check or so, to warn if something odd
is happening or so ;) :):
Assert( SizeOf(byte) = 1, 'SizeOf(byte)(' + IntToStr(SizeOf(byte)) + ') =
1' );
Assert( SizeOf(word) = 2, 'SizeOf(word)(' + IntToStr(SizeOf(word)) + ') =
2' );
Assert( SizeOf(longword) = 4,
Hi,
I compile FPC with success using my tutorial:
http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29
Questions:
1- How can I compile all packages with DEBUG option?
2- How can I compile just one package, eg fcl-xml, with DEBUG
On 06/28/2011 01:20 PM, Henry Vermaak wrote:
Operations on volatile variables are not atomic,
That is of course known.
nor do they establish a proper happens-before relationship for threading.
I see. So maybe part of my question is invalid.
But as pthread_mutex (and the appropriate Windows
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell mschn...@lumino.de wrote:
For variables not defined as volatile, (e.g.) pthread_mutex (and similar
stuff on Windows) can be used to protect them.
A mutex may be able to atomically block access because of its own
memory barrier, but I would
On 28 Jun 2011, at 14:58, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell
mschn...@lumino.de wrote:
For variables not defined as volatile, (e.g.) pthread_mutex (and
similar
stuff on Windows) can be used to protect them.
A mutex may be able to atomically block
On Tue, Jun 28, 2011 at 8:00 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 28 Jun 2011, at 14:58, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell mschn...@lumino.de
wrote:
For variables not defined as volatile, (e.g.) pthread_mutex (and similar
stuff on
On 28 Jun 2011, at 15:05, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:00 AM, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
On 28 Jun 2011, at 14:58, Andrew Brunner wrote:
A mutex may be able to atomically block access because of its own
memory barrier, but I would suggest that
On 28/06/11 14:00, Jonas Maebe wrote:
On 28 Jun 2011, at 14:58, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell mschn...@lumino.de
wrote:
For variables not defined as volatile, (e.g.) pthread_mutex (and similar
stuff on Windows) can be used to protect them.
A mutex
On 28 Jun 2011, at 14:32, Michael Schnell wrote:
So, regarding C, I understand that (even in a single CPU environment):
If all accesses to a variable are protected by a MUTEX, multiple
threads will use the variable as expected, only if it is defined as
volatile. Otherwise is might be
On 06/28/2011 02:58 PM, Andrew Brunner wrote:
A mutex may be able to atomically block access because of its own
memory barrier, but I would suggest that employing such a technique on
multi-core systems will not ensure an accurate value.
If this is true, how can any multithreaded be done ?
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
(point 4.11)
Nope. Nothing about order - just access - and that is entirely on the
application level - not system.
1.) Code execution on die
On Tue, Jun 28, 2011 at 8:16 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
The C (or Pascal) compiler has no idea whether or not the global variable
will be accessed by the pthread_mutex_lock()/unlock() function. As a result,
it will never cache it in a register across function calls, and
On 06/28/2011 03:00 PM, Jonas Maebe wrote:
. I don't know about the Windows equivalents.
see
http://msdn.microsoft.com/en-us/library/ms686355%28v=VS.85%29.aspx
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 28 Jun 2011, at 15:20, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
(point 4.11)
Nope. Nothing about order - just access - and that is entirely on the
On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
1.) Code execution on die is not controlled by pthreads implemention -
as it is unaware at that level.
I have no idea what you mean by this. What would code execution off die be
as opposed to code execution on
On 28 Jun 2011, at 15:39, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
1.) Code execution on die is not controlled by pthreads
implemention -
as it is unaware at that level.
I have no idea what you mean by this. What would code
On 06/28/2011 03:16 PM, Jonas Maebe wrote:
The C (or Pascal) compiler has no idea whether or not the global
variable will be accessed by the pthread_mutex_lock()/unlock()
function. As a result, it will never cache it in a register across
function calls, and the call to the mutex function by
On 06/28/2011 03:23 PM, Andrew Brunner wrote:
Getting developers to
chose the right tool for the job is the key here.
Regarding normal user application there is only one option: Posix. Ans
same happily is encapsulated in the RTL/LCL for FPC/Lazarus programmers.
Advanced (non-portable)
On 06/28/2011 03:23 PM, Andrew Brunner wrote:
There is no problem no need for volatile variables. Compare and Swap
or Interlocked mechanisms will solve any problems.
volatile is a directive to the compiler on how to handle a variable.
Variables that are not handled by the compiler but handled
On 28/06/11 14:20, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebejonas.ma...@elis.ugent.be wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
(point 4.11)
Nope. Nothing about order - just access - and that is entirely on the
application level
On 28/06/11 14:23, Andrew Brunner wrote:
There is no problem no need for volatile variables. Compare and Swap
or Interlocked mechanisms will solve any problems.
Nope. You still need to prevent the cpu from reordering instructions
with memory barriers. I'm starting to sound like a broken
No, that is impossible. That's the whole point of using libraries such as
libpthread. They abstract such issues away. Using atomic operations inside
mutex sections only slows down your program unnecessarily (unless you also
access the target memory location from code not guarded by that mutex,
Of course it is. They issue a hardware memory barrier. This stops the cpu
from reordering operations. How do you think anything using pthreads will
work if they didn't?
Documentation please? If what you are saying is accurate just point
me to the documentation?
Hello FPC,
Tuesday, June 28, 2011, 3:39:29 PM, you wrote:
AB Sort of right. 6 core system. Core 1 locks code block. Code block
AB should still use interlocked statements to make memory assignments so
AB that when Core 1 releases lock - Core 2 can have a real-time image of
AB variable.
On Tue, Jun 28, 2011 at 9:00 AM, Henry Vermaak henry.verm...@gmail.com wrote:
On 28/06/11 14:23, Andrew Brunner wrote:
There is no problem no need for volatile variables. Compare and Swap
or Interlocked mechanisms will solve any problems.
Nope. You still need to prevent the cpu from
On 28/06/11 15:09, Andrew Brunner wrote:
Of course it is. They issue a hardware memory barrier. This stops the cpu
from reordering operations. How do you think anything using pthreads will
work if they didn't?
Documentation please? If what you are saying is accurate just point
me to the
On 28 Jun 2011, at 15:54, Michael Schnell wrote:
static int x;
void play_with_x(void) {
for (i=1; i0; i--) {
x += 1;
};
x = 0;
};
the compiler will see that x is just defined to be 0 in the end and
optimize out thge complete loop.
But if you do the same with
volatile static
Jonas already pointed you to it:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11
Applications shall ensure that access to any memory location by more than
one thread of control (threads or processes) is restricted such that no
thread of control can read or
On 06/28/2011 04:23 PM, Jonas Maebe wrote:
On 28 Jun 2011, at 15:54, Michael Schnell wrote:
I believe that inserting some ptherad_mutex... calls will not force
the compiler to bother about some intermediate values of a non
volatile variable.
You believe wrongly.
As the compiler does not
On Tue, Jun 28, 2011 at 9:23 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On topic, Jonas can you take a few moments to describe how developers
can force code execution in order w/o using a third party library? Is
there a compiler directive we can use?
On 06/28/2011 04:31 PM, Andrew Brunner wrote:
how developers
can force code execution in order w/o using a third party library?
Execution in order only makes sense when there is another thread that
relies on this order.
So if both threads use the same critical section for accessing all
On Tue, Jun 28, 2011 at 9:33 AM, Michael Schnell mschn...@lumino.de wrote:
And this has been discussed in the other message: If the variable in fact is
global the compiler needs to avoid caching it, if it is static and the
function is in another module it might still decide to cache it, but
On 28 Jun 2011, at 16:28, Andrew Brunner wrote:
Jonas already pointed you to it:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11
Applications shall ensure that access to any memory location by
more than
one thread of control (threads or processes) is
On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell mschn...@lumino.de wrote:
On 06/28/2011 04:31 PM, Andrew Brunner wrote:
how developers
can force code execution in order w/o using a third party library?
Execution in order only makes sense when there is another thread that relies
on this
On 06/28/2011 04:38 PM, Andrew Brunner wrote:
1.) How can we get the core to not relent and have the code handed off
to another core until we're finished?
2.) How can we get the core to have a synchronised copy of a
particular variable (aside from CAS)?
I suppose you need to ask these questions
On 06/28/2011 05:02 PM, Andrew Brunner wrote:
Wrong. Sigh... Order of execution is paramount just about everywhere.
It can be disastrous if not understood.
You still did not give an example
Remember ***cores!=threads*** people.
Wrong regarding the issue in question (see the message by
You can stick your head in the sand all you want, just don't run your
code on multi-core cpus and expect valid stability - and come back
here complaining on how unstable your multi-threaded application is
due to FPC design!
User programs are not supposed to bother about anything beyond threads
On Tue, Jun 28, 2011 at 10:17 AM, Michael Schnell mschn...@lumino.de wrote:
You still did not give an example
Don't take my word. Just look at the wikipedia link I already posted
which indicates otherwise.
Remember ***cores!=threads*** people.
Wrong regarding the issue in question (see
On Tue, 28 Jun 2011 15:54:35 +0200, Michael Schnell mschn...@lumino.de
wrote:
But if you do the same with
volatile static int x;
the code will stay and another thread can watch x growing in a time
sharing system.
No, it can't. volatile just ensures that accessing the variable results
On Tue, 28 Jun 2011 15:20:22 +0200, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
(point 4.11)
Nope. Nothing about order - just
Jonas Maebe schrieb:
2.) Blocking access as described in 4.11 does not address execution
order.
It does guarantee that if T1 locks the mutex, changes the value, unlocks
the mutex [...]
Can you explain please, to what changes the value applies?
I could not find a definition of the mutex
Andrew Brunner schrieb:
On Tue, Jun 28, 2011 at 9:23 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On topic, Jonas can you take a few moments to describe how developers
can force code execution in order w/o using a third party library? Is
there a compiler directive we can use?
I think
Michael Schnell schrieb:
Only the ordering decision inside vs outside of the critical section
is necessary for threaded user application. If both Enter and Leave do a
full fence barrier, I suppose we are safe.
Since the condition is only stored *inside* the CS or mutex, no other
code will
28.06.2011 19:42, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
2.) Blocking access as described in 4.11 does not address execution
order.
It does guarantee that if T1 locks the mutex, changes the value,
unlocks the mutex [...]
Can you explain please, to what changes the value applies?
On Tue, 28 Jun 2011 20:09:18 +0200, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
When you have a look at TThreadList.LockList/UnlockList, then you'll see
that LockList enters the critical section, and UnlockList leaves it. All
code executed in between such two calls is absolutely
On Tue, 28 Jun 2011 18:11:29 +0200, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
I think that you should give at least an example, where instruction
reordering makes a difference. Neither a compiler nor a processor is
allowed to reorder instructions in a way, that breaks the def/use
On Tue, 28 Jun 2011 20:34:19 +0200, Nikolai Zhubr n-a-zh...@yandex.ru
wrote:
involving some mutex. Such proper constructs are not enforced by pascal
language automatically (like say in java), so mistakes are quite
possible (and sometimes do happen).
JFTR, but they aren't /enforced/ in
At beginning of June I've found the following link on the ReactOS
mailing list when they were discussing about memory ordering and
volatile as well:
http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
For those interested the following is the link to the starting
discussion:
28.06.2011 22:38, Vinzent Höfler wrote:
involving some mutex. Such proper constructs are not enforced by
pascal language automatically (like say in java), so mistakes are
quite possible (and sometimes do happen).
JFTR, but they aren't /enforced/ in Java, neither.
Well, ok, I didn't mean that
Andrew Brunner schrieb:
On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell mschn...@lumino.de wrote:
On 06/28/2011 04:31 PM, Andrew Brunner wrote:
how developers
can force code execution in order w/o using a third party library?
Execution in order only makes sense when there is another thread
Vinzent Höfler schrieb:
On Tue, 28 Jun 2011 15:54:35 +0200, Michael Schnell mschn...@lumino.de
wrote:
But if you do the same with
volatile static int x;
the code will stay and another thread can watch x growing in a time
sharing system.
No, it can't. volatile just ensures that accessing
Andrew Brunner schrieb:
On Tue, Jun 28, 2011 at 9:33 AM, Michael Schnell mschn...@lumino.de wrote:
And this has been discussed in the other message: If the variable in fact is
global the compiler needs to avoid caching it, if it is static and the
function is in another module it might still
On Tue, 28 Jun 2011 23:29:52 +0200, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Vinzent Höfler schrieb:
No, it can't. volatile just ensures that accessing the variable
results in
actual memory accesses. That does not mean cache-coherence, so another
core may still see other (as in
On Tue, Jun 28, 2011 at 9:23 AM, Marcos Douglas m...@delfire.net wrote:
Hi,
I compile FPC with success using my tutorial:
http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29
Questions:
1- How can I compile all packages with
2011/6/28 Flávio Etrusco flavio.etru...@gmail.com
On Tue, Jun 28, 2011 at 9:23 AM, Marcos Douglas m...@delfire.net wrote:
Hi,
I compile FPC with success using my tutorial:
http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29
Thanks, I will try.
BTW, what that mean DEBUG=1? Is it exists =2, =3, etc?
AFAIK no.
2) Did you try running make inside the dir with debug then running the
normal compileinstall procedure?
No, I didn't because I didn't know this procedure.
AFAICT fpc-pascal was ok (if not better) for
58 matches
Mail list logo
