Am 27.10.2010 23:50, schrieb Andrew Brunner:
My current largest issue is that due to source from from x86_64.inc
function InterLockedIncrement64 (var Target: int64) : int64; assembler;
asm
{$ifdef win64}
movq%rcx,%rax
{$else win64}
movq%rdi,%rax
{$endif win64}
Am 28.10.2010 10:02, schrieb Jeppe Johansen:
Den 27-10-2010 23:14, Florian Klämpfl skrev:
Am 27.10.2010 22:52, schrieb Andrew Brunner:
My SCS project which is a scalable unified collaboration and
communication server that uses counting for transactions and network
consumption across all
Den 28-10-2010 10:11, Florian Klaempfl skrev:
Am 28.10.2010 10:02, schrieb Jeppe Johansen:
Den 27-10-2010 23:14, Florian Klämpfl skrev:
Am 27.10.2010 22:52, schrieb Andrew Brunner:
My SCS project which is a scalable unified collaboration and
communication server that uses counting for
I tried to use the assembly code from the x64 unit on a i386 build of
FPC but FPC throws error on compile. Why are the specific x64
instructions being blocked? The cpu running the code has the ability
to execute the instructions. I don't see why the compiler is making
the assumption that the
Hi,
On Thu, 28 Oct 2010 08:28:16 -0500, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
I tried to use the assembly code from the x64 unit on a i386 build of
FPC but FPC throws error on compile. Why are the specific x64
instructions being blocked? The cpu running the code has the ability
Some small addition:
On Thu, 28 Oct 2010 16:25:59 +0200, Thomas Schatzl tom_at_w...@gmx.at
wrote:
Hi,
On Thu, 28 Oct 2010 08:28:16 -0500, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
I tried to use the assembly code from the x64 unit on a i386 build of
FPC but FPC throws error on
For those following I've done a lot of reading and it just doesn't
seem doable. So for cross CPU support I'm just creating a class for
statisics which will break down the transaction components in their
thousands and support up to PiBs. This way I'll set a write barrier
and then use the CAS with
I have a 64bit cpu here running 32bit Windows 7. I was compiling my
project under Windows 7 to do some debugging when I came across the
problem when trying to lock increment int64 variables for transactions
and bytecounts (general counter purposes).
I modified the systemh.inc that maps
Andrew Brunner schrieb:
I have a 64bit cpu here running 32bit Windows 7. I was compiling my
project under Windows 7 to do some debugging when I came across the
problem when trying to lock increment int64 variables for transactions
and bytecounts (general counter purposes).
Why must such
My SCS project which is a scalable unified collaboration and
communication server that uses counting for transactions and network
consumption across all implemented protocols. Bytes, when aggregated
can clearly exceed the 2GB limitation within seconds. Partial
transactions (PTX) can exceed over
Am 27.10.2010 22:52, schrieb Andrew Brunner:
My SCS project which is a scalable unified collaboration and
communication server that uses counting for transactions and network
consumption across all implemented protocols. Bytes, when aggregated
can clearly exceed the 2GB limitation within
On Wed, 27 Oct 2010 22:52:03 +0200, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
My SCS project which is a scalable unified collaboration and
communication server that uses counting for transactions and network
consumption across all implemented protocols. Bytes, when aggregated
can
On Wed, Oct 27, 2010 at 4:16 PM, Vinzent Höfler
jellyfish.softw...@gmx.net wrote:
Are you counting up only? Then you can use the 32-bit version of the
InterlockedIncrement on the lower word only. If this turns out to be zero
(the new value is returned) after the operation, you know you also
On Wed, Oct 27, 2010 at 4:14 PM, Florian Klämpfl flor...@freepascal.org wrote:
I propose to add the 64 bit CAS for all 32 bit archs (if available): the
64 bit CAS instruction on a 32 bit target makes makes a lot lock-free
algorithms simpler.
So you can build your 64 bit interlockedincrement
On Wed, 27 Oct 2010 23:26:00 +0200, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
On Wed, Oct 27, 2010 at 4:16 PM, Vinzent Höfler
jellyfish.softw...@gmx.net wrote:
Are you counting up only? Then you can use the 32-bit version of the
InterlockedIncrement on the lower word only. If this
On Wed, Oct 27, 2010 at 4:28 PM, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
I get your logic, and agree, but why not just have ONE call for all
the data types. Why must I use Interlocked*64(...Int64) for the x64
cpu and Interlocked*(...Int64) for the i386 code? Can't we just
On Wed, Oct 27, 2010 at 4:37 PM, Vinzent Höfler
jellyfish.softw...@gmx.net wrote:
On Wed, 27 Oct 2010 23:26:00 +0200, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
I didn't say restart, I said lock out the reader for a moment.
Maybe it's easier to grasp if I put it in some pseudo-code:
My current largest issue is that due to source from from x86_64.inc
function InterLockedIncrement64 (var Target: int64) : int64; assembler;
asm
{$ifdef win64}
movq%rcx,%rax
{$else win64}
movq%rdi,%rax
{$endif win64}
movq$1,%rdx
xchgq %rdx,%rax
On Wed, 27 Oct 2010 23:42:16 +0200, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
On Wed, Oct 27, 2010 at 4:37 PM, Vinzent Höfler
jellyfish.softw...@gmx.net wrote:
On Wed, 27 Oct 2010 23:26:00 +0200, Andrew Brunner
andrew.t.brun...@gmail.com wrote:
I didn't say restart, I said lock out
19 matches
Mail list logo
