www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feature Request: enhanced inline ASM

reply Davidl <Davidl 126.com> writes:
dynamic arrays in D is so common used that u will feel painful of dealing  
with them in inline ASM.
i hope the following would be compilable:
char[] name
asm
{
	mov EAX, name.ptr;
	mov EBX, name.length;
}

For AA's we would still need to use the extern C func to deal with. but  
the above code would give
devs great experience with inline ASM
Apr 02 2007
parent reply Dan <murpsoft hotmail.com> writes:
Davidl Wrote:
...
 	mov EAX, name.ptr;
 	mov EBX, name.length;
 

 For AA's we would still need to use the extern C func to deal with.

I agree m8. That syntax is much more attractive to us assembly programmers as well. The thing that I'm sure Walter doesn't want to do though is trick assembler programmers into thinking they can access a ways down the "." chain all the time. Let me explain: If we have: struct b { char[] s; } struct a { void* x = b; union y { int z; } } You can access a.y.z, but not a.x.s.ptr The first just performs a structure offset while the second has to lea through x, and then again through b.s.ptr; more than one instruction ought to be illegal. It's asm after all. You can theoretically have D perform any single asm op to do the correct lookup into a structure or object - but you have to be aware of what's happening.
Apr 03 2007
next sibling parent reply Davidl <Davidl 126.com> writes:
u should use classes to explain the confusion there ;)
coz ur example, the type of x is just void* so no attribute
of s or even s.ptr :p

 Davidl Wrote:
 ...
 	mov EAX, name.ptr;
 	mov EBX, name.length;

 For AA's we would still need to use the extern C func to deal with.

I agree m8. That syntax is much more attractive to us assembly =

 programmers as well.  The thing that I'm sure Walter doesn't want to d=

 though is trick assembler programmers into thinking they can access a =

 ways down the "." chain all the time.

 Let me explain: If we have:

 struct b {
   char[] s;
 }

 struct a {
   void* x =3D b;
   union y {
     int z;
   }
 }



 You can access a.y.z, but not a.x.s.ptr  The first just performs a  =

 structure offset while the second has to lea through x, and then again=

 through b.s.ptr; more than one instruction ought to be illegal.  It's =

 asm after all.

 You can theoretically have D perform any single asm op to do the corre=

 lookup into a structure or object - but you have to be aware of what's=

 happening.

Apr 03 2007
parent Dan <murpsoft hotmail.com> writes:
Actually, no.  But I failed to static the structs or test it.
So we're going to do something that looks like:

mov ECX, a.x[EAX];
mov ECX, b.s.ptr[ECX];

Excuse if my notation is off - but I think that should mean ECX is now a char*
to b.s[0], which is technically null still.  : p  Most importantly though was
the point, not the example.

You can't follow pointer chains in one instruction in ASM, but you can do it in
one line in D.  Structure offsets?  Sure!  Pointers?  No.

Davidl Wrote:
 u should use classes to explain the confusion there ;)
 coz ur example, the type of x is just void* so no attribute
 of s or even s.ptr :p

Dan Wrote:
 struct b {
   char[] s;
 }

 struct a {
   void* x = b;
   union y {
     int z;
   }
 }


Apr 03 2007
prev sibling parent "Joel C. Salomon" <JoelCSalomon Gmail.com> writes:
Dan wrote:
 The thing that I'm sure Walter doesn't want to do though is trick assembler
programmers into thinking they can access a ways down the "." chain all the
time.
 
 Let me explain: If we have:
 
 struct b {
   char[] s;
 }
 
 struct a {
   void* x = b;
   union y {
     int z;
   }
 }
 
 
 
 You can access a.y.z, but not a.x.s.ptr  The first just performs a structure
offset while the second has to lea through x, and then again through b.s.ptr;
more than one instruction ought to be illegal.  It's asm after all.

I come at this from the Plan 9 perspective, where the assembler adds LEAs to give the impression that the x86 instruction set is more regular than it really is, or to implement convenient addressing modes we’d like to pretend the CPU had. I’d vote to put the LEAs in transparently — but on low priority; that’s a nice assembler feature, not so much for a compiler. --Joel
Apr 04 2007