VS2017 64Bit Build

[wnjj]

Originally Posted by routerunner

Exactly, and that means that the assembly code doesn't need to change, but the Microsoft assembler (MASM) need to be instructed properly. Please look for conditional compilation part in the assembly source file and flags in the MASM part of your MSVC2017 project. Best hint is to look for existing conditionals and flags for the 32bit compiled version for Windows as starting point.

Huge and massive thanks to wnjj for doing this, it might help me to find time to complete the new generation of the TS decrypter + commercial skipper for the 64bit architectures (Linux/Windows) I've been working on

Cheers
Eddy

FFmpeg is compiled under MinGW which uses gcc/yasm so it’s not too different than Linux. All of the codecs compile OK and with asm disabled it all compiles. There’s just this one hang up. I found some “cmp” instructions in the code in the form of “cmp reg, constant” which the interwebs say is “Intel” syntax so I suspect Yasm needs to be told that. I’m just not sure why it’s only a 64-bit issue. 32-bit FFmpeg compiles fine.

Also, I am using VS2015 for the rest. I hijacked this thread but really should have started a new one. Oh well.

Thanks for the suggestions.

[routerunner]

Originally Posted by wnjj

There’s just this one hang up. I found some “cmp” instructions in the code in the form of “cmp reg, constant” which the interwebs say is “Intel” syntax so I suspect Yasm needs to be told that. I’m just not sure why it’s only a 64-bit issue. 32-bit FFmpeg compiles fine.

It might a stupid question but is that "cmp" refers to the RXX (ie. RAX) which is 64 bit vs EXX (i.e EAX) which is the 32bit version of the same register? Is also the constant 64bit? You cannot have "cmp" with a mix of 32 and 64 bit reg/constant combo.

Eddy

[wnjj]

Originally Posted by routerunner

It might a stupid question but is that "cmp" refers to the RXX (ie. RAX) which is 64 bit vs EXX (i.e EAX) which is the 32bit version of the same register? Is also the constant 64bit? You cannot have "cmp" with a mix of 32 and 64 bit reg/constant combo.

Eddy

It’s “cmp r4d, 0”. To be honest I don’t have a clue if that’s the one causing the error since the compiler puts the asm together into a temp file which it then conveniently deletes so I can’t check the line listed. This is just one of the cmp’s I found in the source using grep. There may be others. I assume the constant is coerced the the right size by the compiler?

If 64-bit compiles for Linux there must be a flag that tells yasm how to treat these sorts of things that MinGW is missing.

[wnjj]

Originally Posted by wnjj

It’s “cmp r4d, 0”. To be honest I don’t have a clue if that’s the one causing the error since the compiler puts the asm together into a temp file which it then conveniently deletes so I can’t check the line listed. This is just one of the cmp’s I found in the source using grep. There may be others. I assume the constant is coerced the the right size by the compiler?

If 64-bit compiles for Linux there must be a flag that tells yasm how to treat these sorts of things that MinGW is missing.

Ok, so by commenting out and iterating, I found the statement that it's choking on:

https://github.com/google/sagetv/blo...mplate.c#L2491

"cmp %2, %%"REG_a" \n\t"

"REG_a is defined as "rax" for x64 and "eax" x86 for in a header file.

Ok, now that I read up a little on this. "%2" is argument 2 to the function this inline asm is in. Here's the function:

static inline void RENAME(hcscale_fast)(SwsContext *c, int16_t *dst,
                                        long dstWidth, const uint8_t *src1,
                                        const uint8_t *src2, int srcW, int xInc)

Arg 2 is a 'long' which is 32-bits.

Then I found this section:

/* GCC 3.3 makes MPlayer crash on IA-32 machines when using "g" operand here,
which is needed to support GCC 4.0. */
#if ARCH_X86_64 && AV_GCC_VERSION_AT_LEAST(3,4)
            :: "m" (src1), "m" (dst), "g" (dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#else
            :: "m" (src1), "m" (dst), "m" (dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#endif

This is what must help the arguments to match the register sizes. When I forced it to take the 'else', it works. So this may be the GCC version Stuckless referred to. I'll try to figure out how to make this work for us. I'm not sure supporting IA-32 matters specifically for Sage so I could just comment it out, or add our own #define to override.

[routerunner]

Originally Posted by wnjj

Ok, so by commenting out and iterating, I found the statement that it's choking on:

https://github.com/google/sagetv/blo...mplate.c#L2491

"cmp %2, %%"REG_a" \n\t"

"REG_a is defined as "rax" for x64 and "eax" x86 for in a header file.

Ok, now that I read up a little on this. "%2" is argument 2 to the function this inline asm is in. Here's the function:

static inline void RENAME(hcscale_fast)(SwsContext *c, int16_t *dst,
                                        long dstWidth, const uint8_t *src1,
                                        const uint8_t *src2, int srcW, int xInc)

Arg 2 is a 'long' which is 32-bits.

Then I found this section:

/* GCC 3.3 makes MPlayer crash on IA-32 machines when using "g" operand here,
which is needed to support GCC 4.0. */
#if ARCH_X86_64 && AV_GCC_VERSION_AT_LEAST(3,4)
            :: "m" (src1), "m" (dst), "g" (dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#else
            :: "m" (src1), "m" (dst), "m" (dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#endif

This is what must help the arguments to match the register sizes. When I forced it to take the 'else', it works. So this may be the GCC version Stuckless referred to. I'll try to figure out how to make this work for us. I'm not sure supporting IA-32 matters specifically for Sage so I could just comment it out, or add our own #define to override.

Yep, sounds like it, the #2 argument must be a long long, or you could change the register to be EAX regardless the architecture, chances are the maximum number does still fit the 32bit, I was using a very similar mechanism in the 90' when developing for 16/32 bits architectures E[AX].

I would also find out what the 'm' and 'g' means.

Eddy

[wnjj]

Originally Posted by routerunner

Yep, sounds like it, the #2 argument must be a long long, or you could change the register to be EAX regardless the architecture, chances are the maximum number does still fit the 32bit, I was using a very similar mechanism in the 90' when developing for 16/32 bits architectures E[AX].

I would also find out what the 'm' and 'g' means.

Eddy

Changing to this makes it happy too (adding a cast to the arg):

#if ARCH_X86_64 && AV_GCC_VERSION_AT_LEAST(3,4)
            :: "m" (src1), "m" (dst), "g" ((long long) dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#else
            :: "m" (src1), "m" (dst), "m" (dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#endif

Here's some explanation of constraints (https://gcc.gnu.org/onlinedocs/gcc-4...le-Constraints) but it doesn't really help decide the correct answer. I think I'll stick with the cast since that's what I'd do in pure C when faced with a long value headed to a 64-bit destination.

[routerunner]

Originally Posted by wnjj

Changing to this makes it happy too (adding a cast to the arg):

#if ARCH_X86_64 && AV_GCC_VERSION_AT_LEAST(3,4)
            :: "m" (src1), "m" (dst), "g" ((long long) dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#else
            :: "m" (src1), "m" (dst), "m" (dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#endif

Here's some explanation of constraints (https://gcc.gnu.org/onlinedocs/gcc-4...le-Constraints) but it doesn't really help decide the correct answer. I think I'll stick with the cast since that's what I'd do in pure C when faced with a long value headed to a 64-bit destination.

Very good. This sounds more a meta-assembly to me, in my days you would never include asm into C code that way, but things have changed in the last 25 years or so .

Cheers
Eddy

[wnjj]

Originally Posted by routerunner

Very good. This sounds more a meta-assembly to me, in my days you would never include asm into C code that way, but things have changed in the last 25 years or so .

Cheers
Eddy

I hear ya. Nowadays everything is macroed, wrapped, embedded, etc. I have a tough time finding the actual code sometimes. I checked a newer version of this file and see they smartly changed that argument to an int so it automatically scales.