[vlc-devel] [PATCHv2 2/3] deinterlace: x86: add external asm emms function
janne-vlc at jannau.net
Tue Dec 6 20:43:53 CET 2016
On 2016-11-28 13:31:27 +0200, Rémi Denis-Courmont wrote:
> On November 28, 2016 12:16:38 AM GMT+02:00, Janne Grunau <janne-vlc at jannau.net> wrote:
> >On 2016-11-27 23:40:01 +0200, Rémi Denis-Courmont wrote:
> >> AFAICT, if the calling code does not rely on UB, then this function
> >> should have no useful effects. So something is very wrong here,
> >> even if this patch proper does not strictly speaking rely on UB.
> >It is out of scope of the C spec. The function is required to handled
> >defined behavior of x86 CPUs (explictly the implementation details of
> >the mmx/3dnow mm registers). The state of the FPU register file has to
> >be restored after using mm registers. So this function has the side
> >effect of cleaning up certain side effects of the earlier call to asm
> >functions which clobber the fpu register file.
> >It would of course be nicer if the function could do the cleanup
> >But since all the deinterlace asm functions handle only a single output
> >line it is optimized away to do the cleanup only once after the
> >picture is processed. This patch doesn't change any of that. It adds
> >external asm to replace several inline asm functions doing the same.
> Err... This is very much in scope of the hypothetical applicable
> architecture-specific ABI specification which ought to define the C
> calling convention.
> I am no authority on x86, but I can hardly conceive a calling
> convention where this function would make sense of its own.
the emms instruction has the global/CPU 'side effect' of restoring the
state of the fpu register file after using mmx instructions. So we call
the this function/instruction entirely for the side effect. I don't see
what would forbid 'void func(void)' with side effects. There are
sequence points between the functions clobbering the fpu register file
status and vlcpriv_emms_ext_asm.
More information about the vlc-devel