[Bug 13] New: Difficulty accessing byte and short inout parameters from inline asm

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Mar 5 11:01:16 PST 2006


http://d.puremagic.com/bugzilla/show_bug.cgi?id=13

           Summary: Difficulty accessing byte and short inout parameters
                    from inline asm
           Product: D
           Version: 0.148
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: braddr at puremagic.com
        ReportedBy: sean at f4.ca


I'm having problems manipulating inout function parameters within asm blocks if
those parameters are not 32 bits in size.  Since inout parameters are pointers,
I first tried the obvious method:

C:\code\d>type test.d
import std.c.stdio;

void fn( inout byte val )
{
    asm
    {
        mov EAX, val;
        inc [EAX];
    }
}

void main()
{
    byte b;
    printf( "%i\n", b );
    fn( b );
    printf( "i%\n", b );
}


C:\code\d>dmd test
test.d(7): bad type/size of operands 'mov'

C:\code\d>

When that didn't work, I tried simply adding a "byte ptr" descriptor to the
variable, but got similar results:

C:\code\d>type test.d
import std.c.stdio;

void fn( inout byte val )
{
    asm
    {
        mov EAX, byte ptr val;
        inc [EAX];
    }
}

void main()
{
    byte b;
    printf( "%i\n", b );
    fn( b );
    printf( "%i\n", b );
}


C:\code\d>dmd test
test.d(7): bad type/size of operands 'mov'

C:\code\d>

So finally I thought that perhaps the assembler was outsmarting me and treating
'val' like an actual value instead of a pointer:

C:\code\d>type test.d
import std.c.stdio;

void fn( inout byte val )
{
    asm
    {
        lea EAX, val;
        inc [EAX];
    }
}

void main()
{
    byte b;
    printf( "%i\n", b );
    fn( b );
    printf( "%i\n", b );
}


C:\code\d>dmd test
C:\bin\dmd\bin\..\..\dm\bin\link.exe test,,,user32+kernel32/noi;

C:\code\d>test
0
0

C:\code\d>

But the above result makes it clear that it does not, as the second value
shoule be 1.

Is there any way to force the inline assembler to treat 'val' as a pointer
without declaring a temporary?  And is this something that can be fixed?  I
know I could write naked asm, but I don't consider that a viable option


-- 




More information about the Digitalmars-d-bugs mailing list