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

Måns Rullgård mans
Fri Sep 10 14:05:08 CEST 2010


Michael Niedermayer <michaelni at gmx.at> writes:

> On Fri, Sep 10, 2010 at 10:46:45AM +0100, M?ns Rullg?rd wrote:
> [...]
>> >>>>$ 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?
>
> i dont know about sparc but a cpu surely could provide means to save and
> restore future registers. that could be by instructions that just do the
> save and restore or by a function in rom of teh cpu somewhere that one can
> call
> id even say a well designed cpu should do that unless the additional
> complexity is an issue

How would you manage the unknown amount of memory required for this?

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



More information about the ffmpeg-devel mailing list