ASM translation from PB to FB

General FreeBASIC programming questions.
marcov
Posts: 2839
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: ASM translation from PB to FB

Postby marcov » Aug 05, 2015 14:18

caseih wrote:I am a bit confused... AWPStar, what does gcc have to do with things? I thought this was originally a PB file. Now you're using a C file?


I guess it is a namespace conflict in the generated (-gen gcc) source.
MichaelW
Posts: 3500
Joined: May 16, 2006 22:34
Location: USA

Re: ASM translation from PB to FB

Postby MichaelW » Aug 05, 2015 15:25

@AWPStar

I added:

Code: Select all

div BYTE PTR [ff]

To my test source and compiling with -gen gcc did not return any errors, but in the assembly output from gcc the instruction compiled to:

Code: Select all

div BYTE PTR [DWORD PTR [esp+12]]

So something is not right.

You still have not specified how you are compiling your source with gcc.

Also, the byte divisions in the original code suggest to me that the code is not very efficient.
AWPStar
Posts: 38
Joined: May 03, 2009 21:47

Re: ASM translation from PB to FB

Postby AWPStar » Aug 05, 2015 15:30

caseih wrote:I am a bit confused... AWPStar, what does gcc have to do with things? I thought this was originally a PB file. Now you're using a C file?

FreeBasic can generate C-file and then compile it by using gcc with optimizations( -gen gcc -O3).

MichaelW wrote:@AWPStar

I added:

Code: Select all

div BYTE PTR [ff]

To my test source and compiling with -gen gcc did not return any errors, but in the assembly output from gcc the instruction compiled to:

Code: Select all

div BYTE PTR [DWORD PTR [esp+12]]

So something is not right.

You still have not specified how you are compiling your source with gcc.

Also, the byte divisions in the original code suggest to me that the code is not very efficient.

-dll -fpu sse -fpmode fast -vec 2 -gen gcc -O3


I think this is namespace conflict or fbc bug like dkl said. but i haven't used "div" name in code.
dkl
Site Admin
Posts: 3210
Joined: Jul 28, 2005 14:45
Location: Germany

Re: ASM translation from PB to FB

Postby dkl » Aug 05, 2015 15:42

MichaelW wrote:... but in the assembly output from gcc the instruction compiled to:

Code: Select all

div BYTE PTR [DWORD PTR [esp+12]]



That's another issue with fbc -gen gcc. gcc doesn't just insert the stack offset (esp+N or ebp-N or whatever) like -gen gas would do, but it actually inserts the whole DWORD PTR [...] thing aswell, corresponding to the referenced variable's data type. That's how writing dword ptr [a] actually turns to dword ptr [dword ptr [a]] with -gen gcc.

The bad news is that I couldn't find any way to fix this; maybe there are some size-related constraints supported by gcc's inline asm syntax that -gen gcc could use, but for that, fbc would have to parse the inline asm to figure out the wanted access size.

The good news is that from what I've seen the GNU assembler doesn't care and happily accepts this syntax, prefering the outer-most size specifier.

Code: Select all

dim x as long
asm
   div dword ptr [dword ptr [x]]
   div byte ptr [dword ptr [x]]
end asm

objdump -M intel -d wrote:div DWORD PTR [ebp-0x4]
div BYTE PTR [ebp-0x4]

I don't know whether that's documented anywhere.
MichaelW
Posts: 3500
Joined: May 16, 2006 22:34
Location: USA

Re: ASM translation from PB to FB

Postby MichaelW » Aug 06, 2015 0:58

This compiles without warnings or errors (Version 1.02.0 (04-05-2015), built for win32 (32bit)), and executes without triggering an exception:

Code: Select all

SUB ALPHA_C(BYREF SRC AS LONG, BYREF DEST AS LONG, _
          BYVAL W AS LONG, BYVAL H AS LONG, _
          BYVAL WS AS LONG, BYVAL WD AS LONG) EXPORT

    DIM ff AS LONG
    DIM x AS LONG

    asm

        mov dword ptr [ff], 255
        mov edi, [dest]
        mov esi, [src]
        sub esi, edi

        mov eax, [w]
        sub [wd], eax
        shl dword ptr [wd], 2
        sub [ws], eax
        shl dword ptr [ws], 2
        mov eax, [wd]
        sub [ws], eax

        pxor mm2, mm2

    lab0:
        mov ecx, [w]

    lab1:
        mov bl, [esi+edi+3]
        cmp bl, 0
        je  lab2
        mov dh, [edi+3]

        mov al, 255
        sub al, bl
        mul dh
        div byte ptr [ff]

        mov bh, bl
        shl ebx, 8
        mov bl, bh

        mov ah, al
        shl eax, 8
        mov al, ah

        movd mm4, eax
        punpcklbw mm4, mm2

        movd mm5, ebx
        punpcklbw mm5, mm2

        movd mm0, [esi+edi]
        punpcklbw mm0, mm2

        movd mm1, [edi]
        punpcklbw mm1, mm2

        pmullw mm1, mm4
        psrlw mm1, 8

        pmullw mm0, mm5
        psrlw mm0, 8

        paddusw mm0, mm1
        packuswb mm0, mm0
        movd [x], mm0

        mov al, 255
        sub al, dh
        mul bl
        div byte ptr [ff]
        add dh, al

        mov ah, [x]
        div dh
        mov [edi], al

        mov ah, [x+1]
        div dh
        mov [edi+1], al

        mov ah, [x+2]
        div dh
        mov [edi+2], al

        mov [edi+3], dh

    lab2:
        add edi, 4
        dec ecx
        jne lab1

        add esi, [ws]
        add edi, [wd]
        dec dword ptr [h]
        jne lab0
        emms

    end asm

END SUB

dim as long src = &b10101010101010101010101010101010
dim as long dst = &b01010101010101010101010101010101

print bin(dst,32)

ALPHA_C( src, dst, 1, 1, 1, 1 )

print bin(dst,32)

sleep

Code: Select all

01010101010101010101010101010101
11000110100111011001110110011101

I have no idea what exactly it is supposed to do, but I can guess that it has something to do with alpha blending, compare it to the Composite blend (AlphaBlend API replacement) (MMX) code by bitRAKE here, which BTW is probably very good code, in MASM syntax.
AWPStar
Posts: 38
Joined: May 03, 2009 21:47

Re: ASM translation from PB to FB

Postby AWPStar » Aug 06, 2015 9:20

I just tried to compile it with "-gen gcc" in its own dll with single procedure. And it works.
Really fbc bug.
For now, i can split dll.

Return to “General”

Who is online

Users browsing this forum: No registered users and 3 guests