#271 lock prefix is not allowed

[Ficko]

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"

[Ficko]

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

[japheth]

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]

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]

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]

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]

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.

[Ficko]

You right, it does cause an GPF.

[dosfan01]

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.