• Sean Kelly (80/80) Feb 16 2006 I think I may have reported this before, but I was reminded of it when I...

Sean Kelly <sean f4.ca> writes:

I think I may have reported this before, but I was reminded of it when I 
ran across some workaround code today and I wanted to see if someone 
could suggest a better alternative.

Basically, 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 :-)


Sean