Can I get a more in-depth guide about the inline assembler?

[ZILtoid1991 via Digitalmars-d-learn]

On Wednesday, 1 June 2016 at 23:35:40 UTC, Era Scarecrow wrote:
> On Wednesday, 1 June 2016 at 23:23:49 UTC, ZILtoid1991 wrote:
>> After some debugging, I found out that the p pointer becomes 
>> null at the end instead of pointing to a value. I have no 
>> experience with using in-line assemblers (although I made a 
>> few Hello World programs for MS-Dos with a stand-alone 
>> assembler), so I don't know when and how the compiler will 
>> interpret the types from D.
>
>  In the assembler the variable names actually become just the 
> offset to where they are in the stack in relation to BP. So if 
> you want the full pointer you actually need to convert it into 
> a register first and then just use that register instead. 
> So.... This should be correct.
>
> //unless you are going to actually use ubyte[4] here, just 
> making a pointer will work instead, so cast(uint*) probably
>> ubyte[4] src = *cast(ubyte[4]*)(palette.ptr + 4 * *c);
>> ubyte[4] *p = cast(ubyte[4]*)(workpad + (offsetX + x)*4 + 
>> offsetY);
>> asm{	//moving the values to their destinations
>  movd   ESI, src[EBP]; //get source pointer
>  movd   EDI,   p[EBP]; //get destination pointer
>  movd	MM0,    [EDI]; //use directly
>  movd	MM1,    [ESI];
>> movq	MM5, alpha;
>> movq	MM7, alphaMMXmul_const1;
>> movq	MM6, alphaMMXmul_const2;
>
>> <snip>
>
>  movd	[EDI], MM4;
> }

I could get the code working with a bug after replacing pmulhuw 
with pmullw, but due to integer overflow I get a glitched image. 
I try to get around the fact that pmulhuw stores the high bits of 
the result either with multiplication or with bit shifting.