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

Michael Niedermayer michaelni
Fri Sep 10 14:03:14 CEST 2010


On Fri, Sep 10, 2010 at 01:05:08PM +0100, M?ns Rullg?rd wrote:
> 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?

that could be just stored in rom or returned by an instruction or there could
be enough reserved space in previous cpu generations

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100910/73580910/attachment.pgp>



More information about the ffmpeg-devel mailing list