On 7/14/2023 7:12 AM, Nicolas George wrote:
James Almer (12023-07-13):
Curious that they pull git snapshots of this package for Debian testing. For
others they seem to stick to tagged releases.
I do not understand what you mean. *I* pulled my work tree to the head
to fix a bug in the OpenGL device, it was the first time since Testing
was unfrozen, and I noticed it fails to build.
I mean that for pretty much every other package, Debian Unstable/Testing
sticks to tagged releases. But for this one they pull git snapshots
every other day.
If they did what the do for every other package, they'd have waited
until binutils 2.41 was tagged.
This definitely sounds like a regression in binutils, so other than
reporting it upstream, i don't see much more we can do.
It could also be a case where we have been using a slightly invalid and
unsupported construct. My knowledge of assembly stopped at the 386, so I
cannot tell which one it is, but I think the likeliness are balanced.
Somebody more skilled will look at it, hopefully.
I'm not an expert, but i learned a bit of inline asm when i was porting
some of it to nasm syntax.
> static inline uint32_t NEG_USR32(uint32_t a, int8_t s){
> __asm__ ("shrl %1, %0\n\t"
Nothing to say here, it's just shr.
> : "+r" (a)
r means the first operand, %0, needs to be a register. The + means it's
both input and output, meaning the value at the time of entering this
block is not to be ignored/discarded, and the value at the time of
leaving the block needs to be in a.
> : "ic" ((uint8_t)(-s))
i means this operand can be an immediate value, and c means it can also
be the rcx/ecx/cx/cl register.
According to https://www.felixcloutier.com/x86/sal:sar:shl:shr this is
indeed correct.
> );
> return a;
> }
This is most likely a bug in the assembler. The "Error: operand type
mismatch for 'shr'" error message makes me think it may be trying to use
a register other than CL for the second operand.
That said, i don't know if this asm block is needed at all, seeing how
the generic C implementation is
define NEG_USR32(a,s) (((uint32_t)(a))>>(32-(s)))
Which the compiler can surely convert into whatever is most optimized
for the target. The BMI2 instruction set added shrx, which accepts any
register as second operand, for example.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
