I vote for a patch that include the FpcTargetDir function in the RTL !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Michael Schnell schrieb:
>
>> We don't need wait to synchronize caches. It will be done by hardware.
> Right. but waiting performed by the hardware does not take less long
> than waiting performed by software :-) .
>> And i think synchronize cache with ram don't eat hundreads clock cycles.
> In a
Any implementation of thread synchronization need care of cache.
FUTEX, which rely on atomic primitives can't be faster than primitives
alone.
I said that (using locking instructions to implement a semaphore) I
might implement something that works similar to FUTEX. I don't intend to
_use_ FUT
We don't need wait to synchronize caches. It will be done by hardware.
Right. but waiting performed by the hardware does not take less long
than waiting performed by software :-) .
And i think synchronize cache with ram don't eat hundreads clock cycles.
In all cashed that contain the memory l
Hi,
Yes you can emulate all of the listed CPU's, it just have different
executable names. qemu-system-x86_64
for what you require.
The only problem that I found, is that sometimes the hardware you have
using qemu virtualization is not suited for some of the linux distro
you wish to use.
Ido
On
Yes, that is understable, because for example pointers are twice as
big, which results in more memory accesses and less pointers in the
CPU caches and more cache misses.
Is this a software design decision (to allow for large projects using >
4Gig Memory) or does the architecture not provide an
> result:= {$I %FPCTARGETCPU%}+'-'+{$I %FPCTARGETOS%};
Above works for my needs, just wonder if something already exists in RTL
or if it should be added for convenience.
It doesn't exists and i don't see a reason why it should be added. The above
line is simple.
The above line:
{$I %FP
Hi
I don't own a 64bit pc. With the wonderful world of emulators and
virtual pc products like VirtualBox, VMWare and Virtual PC 2007 I
thought, why can't my 32bit Intel P4 emulate a 64bit CPU via software.
If it works, that would be cool. :) If it works it might be slow,
but I don't care, it's
Dariusz Mazur wrote:
Florian Klaempfl pisze:
DarekM schrieb:
Florian Klaempfl pisze:
An if is unimportant, more important is the number of locked
operations,
especially on multi core systems they might eat hundreds of clock
cycles.
There are atomic operations, the should not
Sergei Gorelkin wrote:
Sergei Gorelkin wrote:
I'll be digging further in.
Here goes. I modified the test so that it fails reliably, and patched
the compiler so that is doesn't fail again.
It was a bit tricky to get a string with refcount=1 without telling the
compiler to take its address.
As
Florian Klaempfl pisze:
DarekM schrieb:
Florian Klaempfl pisze:
An if is unimportant, more important is the number of locked operations,
especially on multi core systems they might eat hundreds of clock cycles.
There are atomic operations, the should not eat much more than o
On 29 Jan 2008, at 17:25, Vincent Snijders wrote:
Miklos Cserzo schreef:
Hi Folks,
5) - considering the two versions of a source that will not hit
this bug the generated 32-bit executable runs much faster than its
64-bit equivalent. That indicates the general weakness of the 64-
bit platf
Michael Schnell pisze:
FUTEX is based on atomic operation, the same as I used.
but with lockfree algorithms You don't protect access at all.
I understand this, but I'm nut sure that this really is advantageous.
Any atomic operation in a multicore system with a cache for each core
imposes a
> 2) - when the concurrent installation of the two versions of the
> complier is solved users can control the type of the generated binaries
> by the '-P' switch of the complier. This switch is not mentioned in the
> documentation at all.
Not in the formal user docs, but in bootstrapping and cr
Miklos Cserzo schreef:
Hi Folks,
5) - considering the two versions of a source that will not hit this bug
the generated 32-bit executable runs much faster than its 64-bit
equivalent. That indicates the general weakness of the 64-bit platform
support.
Yes, that is understable, because for
Hi Folks,
here goes the summary of the story:
The task: compiling the same source in 32 and 64 bit environment using
FPC ver. 2.2.0 and compare the results. In ideal case the results should
be the same. I hit the several bugs during this test.
1) - the available 32-bit and 64-bit RPM distri
FUTEX is based on atomic operation, the same as I used.
but with lockfree algorithms You don't protect access at all.
I understand this, but I'm nut sure that this really is advantageous.
Any atomic operation in a multicore system with a cache for each core
imposes a delay for cache synchron
Michael Schnell pisze:
I have to think a bit more about the locking mechanism you suggest.
I;ve added some links on my site
I intended to use a single word as a semaphore to protect the access
to the structure and fall back to an OS-based wait (e.g. by
TCriticalSection) if it can't be acqui
18 matches
Mail list logo
