[fpc-devel] Same 64bit assembly code compiles under windows but not in linux (fpc 260)

[Jeppe Græsdal Johansen]

Integer is not a specifically sized type. It might differ based on what 
platform you are on. For example, it's 16bit on i386-linux when compiled 
with mode fpc. With mode objfpc on the same platform it's 32bit.

Also, wouldn't MOVD XMM5, [Bias] imply that you are moving from the 
address stored in the Bias variable? That would make a whole lot more 
sense as to why it generates this error

Den 03-10-2012 03:29, luiz americo pereira camara skrev:
> Hi,
>
> I'm porting some Delphi assembly code.
>
> It worked fine with fpc 2.6.0 i386-64bit windows compiler
>
> When i tried the same code with fpc 2.6.0 i386-64bit for linux it 
> failed to compile with the following error:
>
> Error: Asm: 16 or 32 Bit references not supported
>
> at the line
>          // Load XMM5 with the bias value.
>         MOVD        XMM5, [Bias]  //Bias = Integer
>
> Is it a know issue or a limitation of linux version?
>
> There's a workaround to this issue?
>
> The complete procedure:
>
> {$ASMMODE INTEL}
>
> procedure AlphaBlendLineConstant(Source, Destination: Pointer; Count: 
> Integer; ConstantAlpha, Bias: Integer);
>
> asm
>
> {$ifdef CPU64}
> // RCX contains Source
> // RDX contains Destination
> // R8D contains Count
> // R9D contains ConstantAlpha
> // Bias is on the stack
>
>         //.NOFRAME
>
>         // Load XMM3 with the constant alpha value (replicate it for 
> every component).
>         // Expand it to word size.
>         MOVD        XMM3, R9D  // ConstantAlpha
>         PUNPCKLWD   XMM3, XMM3
>         PUNPCKLDQ   XMM3, XMM3
>
>         // Load XMM5 with the bias value.
>         MOVD        XMM5, [Bias]
>         PUNPCKLWD   XMM5, XMM5
>         PUNPCKLDQ   XMM5, XMM5
>
>         // Load XMM4 with 128 to allow for saturated biasing.
>         MOV         R10D, 128
>         MOVD        XMM4, R10D
>         PUNPCKLWD   XMM4, XMM4
>         PUNPCKLDQ   XMM4, XMM4
>
> @1:     // The pixel loop calculates an entire pixel in one run.
>         // Note: The pixel byte values are expanded into the higher 
> bytes of a word due
>         //       to the way unpacking works. We compensate for this 
> with an extra shift.
>         MOVD        XMM1, DWORD PTR [RCX]   // data is unaligned
>         MOVD        XMM2, DWORD PTR [RDX]   // data is unaligned
>         PXOR        XMM0, XMM0    // clear source pixel register for 
> unpacking
>         PUNPCKLBW   XMM0, XMM1{[RCX]}    // unpack source pixel byte 
> values into words
>         PSRLW       XMM0, 8       // move higher bytes to lower bytes
>         PXOR        XMM1, XMM1    // clear target pixel register for 
> unpacking
>         PUNPCKLBW   XMM1, XMM2{[RDX]}    // unpack target pixel byte 
> values into words
>         MOVQ        XMM2, XMM1    // make a copy of the shifted 
> values, we need them again
>         PSRLW       XMM1, 8       // move higher bytes to lower bytes
>
>         // calculation is: target = (alpha * (source - target) + 256 * 
> target) / 256
>         PSUBW       XMM0, XMM1    // source - target
>         PMULLW      XMM0, XMM3    // alpha * (source - target)
>         PADDW       XMM0, XMM2    // add target (in shifted form)
>         PSRLW       XMM0, 8       // divide by 256
>
>         // Bias is accounted for by conversion of range 0..255 to 
> -128..127,
>         // doing a saturated add and convert back to 0..255.
>         PSUBW     XMM0, XMM4
>         PADDSW    XMM0, XMM5
>         PADDW     XMM0, XMM4
>         PACKUSWB  XMM0, XMM0      // convert words to bytes with 
> saturation
>         MOVD      DWORD PTR [RDX], XMM0     // store the result
> @3:
>         ADD       RCX, 4
>         ADD       RDX, 4
>         DEC       R8D
>         JNZ       @1
>
> {$endif}
>
> end;
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20121003/c0164ce7/attachment.html>