www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Access 'this' in inline assembly

reply Martin Kinkelin <noone spam.com> writes:
Hi, sorry for the dumb question, but how do i get the address of an object
inside a member function in inline assembly?

I have no experience with assembler yet. It seems like names of variables on
the stack are treated as pointers in inline assembly, but I have no clue about
how to get the address of the object itself (this and [this] do not work).

struct float4
{
    float[4] _data;

    float dot(in float4 rhs) const
    {
        float r = void;
        asm
        {
            movups XMM0, this; // need pointer to _data
            movups XMM1, rhs;
            ...
            movss r, XMM0;
        }
        return r;
    }
}

Please note that even this doesn't work:
float* ptr = cast(float*) _data.ptr;
asm { movups XMM0, ptr; }
=> 2 operands found for movups instead of the expected 1
Mar 07 2011
parent reply Simon <s.d.hammett gmail.com> writes:
On 07/03/2011 15:14, Martin Kinkelin wrote:
 Hi, sorry for the dumb question, but how do i get the address of an object
 inside a member function in inline assembly?

 I have no experience with assembler yet. It seems like names of variables on
 the stack are treated as pointers in inline assembly, but I have no clue about
 how to get the address of the object itself (this and [this] do not work).

 struct float4
 {
      float[4] _data;

      float dot(in float4 rhs) const
      {
          float r = void;
          asm
          {
              movups XMM0, this; // need pointer to _data
              movups XMM1, rhs;
              ...
              movss r, XMM0;
          }
          return r;
      }
 }

 Please note that even this doesn't work:
 float* ptr = cast(float*) _data.ptr;
 asm { movups XMM0, ptr; }
 =>  2 operands found for movups instead of the expected 1

'this' is passed in EAX: See the bit titled 'parameters' http://www.digitalmars.com/d/2.0/abi.html -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Mar 07 2011
next sibling parent reply Martin Kinkelin <noone spam.com> writes:
Thanks,

movups XMM0, [EAX];

works. The SSE version takes more than 160% of the run-time compared to the
naive
version though. ;)
Mar 07 2011
next sibling parent Simon <s.d.hammett gmail.com> writes:
On 07/03/2011 19:45, Emil Madsen wrote:
 On 7 March 2011 20:37, Simen kjaeraas <simen.kjaras gmail.com
 <mailto:simen.kjaras gmail.com>> wrote:

     Martin Kinkelin <noone spam.com <mailto:noone spam.com>> wrote:

         Thanks,

         movups XMM0, [EAX];

         works. The SSE version takes more than 160% of the run-time
         compared to the naive
         version though. ;)


     Yup. Functions using inline assembly are never inlined, so that's rarely
     a good reason to use it.

     --
     Simen


 Is this just a fact of the current state of dmd, or is it by design? -
 and if thats the case, why?

 --
 // Yours sincerely
 // Emil 'Skeen' Madsen

It's by design. I've seen it explicitly stated somewhere (I forget) that the compiler won't optimise across asm blocks and in-lining is just a case of optimisation. As to way, my guess is because of the way a compiler is designed and implemented. Each stage of the compiler processes it's input, converts it to a lower level representation and then hands it off to the next stage. Optimising across asm blocks would require reversing that process; I think it's doable but it's highly non trivial and then you have to implement that across every supported target. Better to spend the time improving the higher level code generation stages so people don't have to resort to ASM at all. I guess in-lining could be separated out from the optimisation passes; but don't hold your breath. DMD is a hodge podge of mashed together functionality, just re-factoring out in-lining would be weeks of work. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Mar 07 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Emil Madsen:

 Is this just a fact of the current state of dmd, or is it by design? - and


It's by design, but it's a bad/wrong design. The LDC compiler has two different ways to inline asm. It's a necessary feature in a system language that want to be more than just a toy. Bye, bearophile
Mar 07 2011
parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Mon, 7 Mar 2011, bearophile wrote:

 Emil Madsen:
 
 Is this just a fact of the current state of dmd, or is it by design? - and


It's by design, but it's a bad/wrong design. The LDC compiler has two different ways to inline asm. It's a necessary feature in a system language that want to be more than just a toy. Bye, bearophile

It's not by design. It's a quality of implementation issue that's solvable given some time to work on it. I intend to, eventually, unless someone has gotten to it ahead of me. The inliner in dmd is conservative and only lines stuff it knows how to. Anything doesn't, isn't. Nothing says it can't be taught how to inline quite a bit more than it currently does, given time to work on it. Later, Brad
Mar 07 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Brad Roberts:

It's not by design.  It's a quality of implementation issue that's solvable
given some time to work on it.  I intend to, eventually, unless someone has
gotten to it ahead of me.<

Good, I am glad to be wrong then. Currently in LDC you have two different ways to tell the compiler to inline some Asm. Such syntaxes are not present in D/DMD. So do you plan to add something like those two syntaxes to D/DMD too? One of them is this pragma: http://www.dsource.org/projects/ldc/wiki/Docs#allow_inline int add(int a, int b) { pragma(allow_inline); asm { mov EAX, a; add EAX, b; } } And the other one is Inline asm expressions: http://www.dsource.org/projects/ldc/wiki/InlineAsmExpressions That are used like this: // store val into dst void store(ref int dst, int val) { __asm("ldw r4, $1 ; stw r4, $0", "=*m,r,~{r4}", &dst, val); } Bye, bearophile
Mar 08 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Martin Kinkelin <noone spam.com> wrote:

 Thanks,

 movups XMM0, [EAX];

 works. The SSE version takes more than 160% of the run-time compared to  
 the naive
 version though. ;)

Yup. Functions using inline assembly are never inlined, so that's rarely a good reason to use it. -- Simen
Mar 07 2011
prev sibling parent Emil Madsen <sovende gmail.com> writes:
--90e6ba1819ba74786b049de9bc04
Content-Type: text/plain; charset=ISO-8859-1

On 7 March 2011 20:37, Simen kjaeraas <simen.kjaras gmail.com> wrote:

 Martin Kinkelin <noone spam.com> wrote:

  Thanks,
 movups XMM0, [EAX];

 works. The SSE version takes more than 160% of the run-time compared to
 the naive
 version though. ;)

Yup. Functions using inline assembly are never inlined, so that's rarely a good reason to use it. -- Simen

Is this just a fact of the current state of dmd, or is it by design? - and if thats the case, why? -- // Yours sincerely // Emil 'Skeen' Madsen --90e6ba1819ba74786b049de9bc04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 March 2011 20:37, Simen kjaeraas <span dir= =3D"ltr">&lt;<a href=3D"mailto:simen.kjaras gmail.com">simen.kjaras gmail.c= om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5">Martin Kinkelin &lt;<a href=3D"mailto:noo= ne spam.com" target=3D"_blank">noone spam.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Thanks,<br> <br> movups XMM0, [EAX];<br> <br> works. The SSE version takes more than 160% of the run-time compared to the= naive<br> version though. ;)<br> </blockquote> <br></div></div> Yup. Functions using inline assembly are never inlined, so that&#39;s rarel= y<br> a good reason to use it.<br> <br> -- <br><font color=3D"#888888"> Simen<br> </font></blockquote></div><br>Is this just a fact of the current state of d= md, or is it by design? - and if thats the case, why?<br clear=3D"all"><br>= -- <br>// Yours sincerely<br>// Emil &#39;Skeen&#39; Madsen<br> --90e6ba1819ba74786b049de9bc04--
Mar 07 2011