[FFmpeg-devel] [PATCH] read_time() for SPARC

[Måns Rullgård]

Michael Kostylev <michael.kostylev at gmail.com> writes:

> On Fri Sep 10 09:47:34 2010
> M?ns Rullg?rd wrote:
>
>>>>>>> if the only issue left is the sometimes unneeded stx instruction
>>>>>>> then i approve the patch with this. If there are other issues they
>>>>>>> of course have to be fixed first
>>>>>>
>>>>>>Apparently the ifdef test in the patch is not reliable.
>>>>>
>>>>> Redone.
>>>>>
>>>>> Michael
>>>>>
>>>>> +#ifndef AVUTIL_SPARC_TIMER_H
>>>>> +#define AVUTIL_SPARC_TIMER_H
>>>>> +
>>>>> +#if defined(__arch64__) || defined(__sparc_v9__)
>>>>
>>>>I'm still not convinced this is right:
>>>
>>> There is an issue with -m32 on Solaris.
>>
>>I don't understand.
>
> As mentioned, __sparc_v9__ is never defined there.

That does not make __sparc_v9__ alone a sufficient condition for using
64-bit registers.

>>>>$ sparc-unknown-linux-gnu-gcc -m32 -mcpu=v9 -mno-v8plus -dM -E -xc /dev/null | grep -E 'arch|sparc'
>>>>#define sparc 1
>>>>#define __sparc__ 1
>>>>#define __sparc 1
>>>>#define __sparc_v9__ 1
>>>
>>> This is as right as xor rax,rax in an i386 binary built with -march=core2.
>>
>>Yes, that instruction would be invalid there.  In a pure 32-bit
>>environment, you can't use the high half of 64-bit registers, even if
>>they are physically present.  Consider what happens on a context switch.
>
> An ancient kernel will not preserve the sse registers as well. Anyway, there
> is no such problem on Sparc. Anything else?

A 32-bit kernel on Sparc will only preserve the low 32 bits of the
registers.  How could it possibly do otherwise?  Or is such a system
impossible for some reason?

-- 
M?ns Rullg?rd
mans at mansr.com