• Davidl (12/12) Apr 02 2007 dynamic arrays in D is so common used that u will feel painful of dealin...
• Dan (17/21) Apr 03 2007 ...
• Davidl (9/38) Apr 03 2007 u should use classes to explain the confusion there ;)
• Dan (8/21) Apr 03 2007 Actually, no. But I failed to static the structs or test it.
• Joel C. Salomon (8/26) Apr 04 2007 I come at this from the Plan 9 perspective, where the assembler adds

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

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.

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=

o  =

 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=

ct  =

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

  =

 happening.

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;
   }
 }

"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