[vlc-devel] [PATCHv2 2/3] deinterlace: x86: add external asm emms function

[Janne Grunau]

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
> >itself.  
> >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
> >complete 
> >picture is processed. This patch doesn't change any of that. It adds
> >the 
> >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.

Janne