#271 lock prefix is not allowed

generic
open
nobody
None
5
2013-10-27
2013-07-01
Ficko
No

JWASM can't compile the following code:

.686p
.model flat,stdcall
option casemap :none ; case sensitive
; ---------------------------------------------------------
.data
tdat dd 0
.code
xor eax, eax
lock or eax, tdat
end

Gives: "Error A2028: Instruction prefix not allowed"

Discussion

  • Ficko
    Ficko
    2013-07-01

    This should be "Milestone:Generic" perhabs but don't know how to change it.

     
  • japheth
    japheth
    2013-07-07

    • Group: v207 --> generic
     
  • japheth
    japheth
    2013-07-07

    Masm accepts the lock, so it probably has to be changed.

    However, is the lock prefix useful at all if the memory operand is used as source only?

     
  • Ficko
    Ficko
    2013-07-08

    I am not thoroughly sure what you mean.

    If you use openMP and follow up “interlockedincrement” as “fetch_and_add” atomic operation and your C++ is inlining the code you get:

    00010 f0 lock
    00011 0f c1 02 xadd DWORD PTR [rdx], eax

    I not really see a difference between addressing a memory trough a GPR and using it directly. Perhabs no C++ compiler would do it but why not in assembler ?

     
  • japheth
    japheth
    2013-07-09

    I am not thoroughly sure what you mean.

    I meant: if the memory operand is used for reading only ( as in "or eax, tdat" ), the lock prefix is useless.

     
  • Ficko
    Ficko
    2013-07-09

    If you say so, but IMO an other thread can write to the memory (tdat) the same time you are trying to read it so lock indeed needed.

     
  • japheth
    japheth
    2013-07-09

    quoting the Intel manual:


    To explicitly force the LOCK semantics, software can use the LOCK prefix with the
    following instructions when they are used to modify a memory location. An invalid-
    opcode exception (#UD) is generated when the LOCK prefix is used with any other
    instruction or when no write operation is made to memory (that is, when the destination operand is in a register).


    I interpret this that your "or eax, tdat" instruction will even cause a GPF.

     
    Last edit: japheth 2013-07-09
  • Ficko
    Ficko
    2013-07-09

    You right, it does cause an GPF.

     
    Last edit: Ficko 2013-07-10
  • dosfan01
    dosfan01
    2013-10-27

    This is not a bug in JWasm, it is a bug in MASM that "lock or eax,[mem]" is allowed since the lock prefix is only for read-modify-write instructions. JWasm should not duplicate obvious MASM bugs so this should likely be closed.