www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 988] New: Win32 Exception using asm lock prefix

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=988

           Summary: Win32 Exception using asm lock prefix
           Product: D
           Version: 1.006
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: sean f4.ca


This one is kind of weird, because the code generated using obj2asm looks fine.
 Here's the test case:

    void main()
    {
        int i    = 5;
        int j    = 0;
        int* val = &i;

        asm
        {
            mov EAX, val;
            lock;
            mov EAX, [EAX];
            mov j, EAX;
        }
        printf( "%d\n", j );
    }

If the 'lock' instruction is commented out, the program works as expected.


--
Feb 20 2007
next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=988


fvbommel wxs.nl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         OS/Version|Windows                     |All
         Resolution|                            |INVALID
            Summary|Win32 Exception using asm   |DMD allows invalid LOCK
                   |lock prefix                 |prefix in inline assembler




------- Comment #1 from fvbommel wxs.nl  2007-02-21 03:34 -------
From the Intel manual (vol. 2A, Instruction Set Reference A-M):
---
The LOCK prefix can be prepended only to the following instructions and only to
those forms
of the instructions where the destination operand is a memory operand: ADD,
ADC, AND,
BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR,
XADD, and XCHG. If the LOCK prefix is used with one of these instructions and
the source
operand is a memory operand, an undefined opcode exception (#UD) may be
generated. An
undefined opcode exception will also be generated if the LOCK prefix is used
with any instruc-
tion not in the above list. The XCHG instruction always asserts the LOCK#
signal regardless of
the presence or absence of the LOCK prefix.
---

AMD agrees (Architecture Programmer's Manual, vol. 3):
---
The LOCK prefix can only be used with forms of the following instructions that
write a memory
operand: ADC, ADD, AND, BTC, BTR, BTS, CMPXCHG, CMPXCHG8B, DEC, INC, NEG, NOT,
OR, SBB, SUB, XADD, XCHG, and XOR. An invalid-opcode exception occurs if the
LOCK prefix is
used with any other instruction.
---

So you're using the lock prefix where it isn't allowed.
It's both not allowed on MOV and on other instructions on which it can be used
it's only allowed if the destination is a memory operand. Those all seem to be
instructions which both read and write their destination (memory) operand.
(I didn't know any of this until I looked it up just now)

Sorry, it seems the bug is in your code...


--
Feb 21 2007
parent reply Sean Kelly <sean f4.ca> writes:
d-bugmail puremagic.com wrote:

 The LOCK prefix can be prepended only to the following instructions and only to
 those forms
 of the instructions where the destination operand is a memory operand: ADD,
 ADC, AND,
 BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR,
 XADD, and XCHG.


Darnit, I dunno why I thought this was supposed to work.  It's not like 
I haven't read this clause enough :-p  I'll use CAS instead.  Thanks!
Feb 21 2007
parent kris <foo bar.com> writes:
Sean Kelly wrote:

 d-bugmail puremagic.com wrote:
 

 The LOCK prefix can be prepended only to the following instructions 
 and only to
 those forms
 of the instructions where the destination operand is a memory operand: 
 ADD,
 ADC, AND,
 BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR,
 XADD, and XCHG.


 
 
 Darnit, I dunno why I thought this was supposed to work.  It's not like 
 I haven't read this clause enough :-p  I'll use CAS instead.  Thanks!


Well, there's conflicting info out there so it's hardly surprising:

Here's just one page that says MOV is just fine :) 
http://www.cs.tut.fi/~siponen/upros/intel/instr/lock.html
Feb 21 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=988


fvbommel wxs.nl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|DMD allows invalid LOCK     |Win32 Exception using asm
                   |prefix in inline assembler  |lock prefix




------- Comment #2 from fvbommel wxs.nl  2007-02-21 03:43 -------
Oops, I at first wanted to change this to an enhancement request to make the
code an error, but then changed my mind. Forgot to change the summary back
though.


--
Feb 21 2007