Prev: accessing a DLL
Next: hugi compo #29- random mazes - how reduce size of this
From: James Harris on 1 Oct 2009 05:20
In case someone else finds this useful I found that

xchg reg, [mem]

was slow. It has to do more work than just exchanging one operand with
another. It will also go through a lock protocol process which, while
it may not assert lock on the bus if the memory is cached, seems
nevertheless to take some time. Locking cannot be inhibited for the
xchg instruction. However, the locking can be avoided with a three-
instruction sequence. I've put it at

http://codewiki.wikispaces.com/fast_xchg_mem.nasm

The timings were made by placing 100 of such instructions or sequences
back to back so include code-read time if it is relevant here.

Note that locking does not apply to xchg reg, reg. This only refers to
exchanges with memory.

James
From: Frank Kotler on 1 Oct 2009 06:59
James Harris wrote:
> In case someone else finds this useful I found that
>
> xchg reg, [mem]
>
> was slow. It has to do more work than just exchanging one operand with
> another. It will also go through a lock protocol process which, while
> it may not assert lock on the bus if the memory is cached, seems
> nevertheless to take some time. Locking cannot be inhibited for the
> xchg instruction. However, the locking can be avoided with a three-
> instruction sequence. I've put it at
>
> http://codewiki.wikispaces.com/fast_xchg_mem.nasm
>
> The timings were made by placing 100 of such instructions or sequences
> back to back so include code-read time if it is relevant here.
>
> Note that locking does not apply to xchg reg, reg. This only refers to
> exchanges with memory.

Just a nitpick, James. Your codewiki page says "xchg eax, mem", where
you mean (in Nasm syntax) "xchg eax, [mem]". Thanks for the tip!

Best,
Frank

From: James Harris on 1 Oct 2009 10:28
On 1 Oct, 11:59, Frank Kotler <fbkot...(a)myfairpoint.net> wrote:
> James Harris wrote:
> > In case someone else finds this useful I found that
>
> >   xchg reg, [mem]
>
> > was slow. It has to do more work than just exchanging one operand with
> > another. It will also go through a lock protocol process which, while
> > it may not assert lock on the bus if the memory is cached, seems
> > nevertheless to take some time. Locking cannot be inhibited for the
> > xchg instruction. However, the locking can be avoided with a three-
> > instruction sequence. I've put it at
>
> >  http://codewiki.wikispaces.com/fast_xchg_mem.nasm
>
> > The timings were made by placing 100 of such instructions or sequences
> > back to back so include code-read time if it is relevant here.
>
> > Note that locking does not apply to xchg reg, reg. This only refers to
> > exchanges with memory.
>
> Just a nitpick, James. Your codewiki page says "xchg eax, mem", where
> you mean (in Nasm syntax) "xchg eax, [mem]". Thanks for the tip!

Thanks, Frank. I've just changed it and added a timing comparison from
another machine. No worries about nitpicking ... we wouldn't be
assembler programmers if we didn't strive to get the nitty gritty
details right!

James
 | 
Pages: 1
Prev: accessing a DLL
Next: hugi compo #29- random mazes - how reduce size of this