qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qemu-timer: Don't use RDTSC on 386s and 486s


From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH] qemu-timer: Don't use RDTSC on 386s and 486s
Date: Fri, 23 Nov 2012 16:19:34 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Peter Maydell wrote:
> On 23 November 2012 15:17, Peter Maydell <address@hidden> wrote:
> > On 23 November 2012 15:15, Paolo Bonzini <address@hidden> wrote:
> >> You should at least test __i686__ too:
> >>
> >> $ gcc -m32 -dM -E -x c /dev/null |grep __i
> >> #define __i686 1
> >> #define __i686__ 1
> >> #define __i386 1
> >> #define __i386__ 1
> >
> > Yuck. I had assumed gcc would define everything from i386
> > on up when building for later cores.
> 
> ...and there's an enormous list of x86 cores too. This bites
> us already -- if you use '-march=native' to get "best for my
> cpu" then on a Core2, say, it will define __i386__ and __core2__
> but not __i686__, so TCG won't use cmov :-(
> 
> Anybody got any good ideas for how to say "is this at least
> a 586/686?" in a way that won't fail for any newly introduced
> x86 core types?

Fwiw, cmov doesn't work on some VIA "686" class CPUs.

Shouldn't TCG decide whether to use cmov at runtime anyway, using
cpuid?  For dynamically generated code it would seem not very
expensive to do that.

Looking at GCC source, it has an internal flag to say whether the
target has cmov, but doesn't expose it in preprocessor conditionals.

-- Jamie



reply via email to

[Prev in Thread] Current Thread [Next in Thread]