Re: i686 quirk for AMD Geode

["H. Peter Anvin" <hpa@zytor.com>]

On 11/11/2009 04:51 PM, Daniel Pittman wrote:
>>
>> Consider SSE3, for example.  Why should the same concept not apply to
>> SSE3 instructions as to CMOV?
> 
> FWIW, the issue of the binary-only flashplayer.so came up later in the thread,
> but to add my few cents:
> 
> When flash 10 was released the binary only 64-bit version generated
> instructions from the LAHF set unconditionally, in part because Windows chose
> to emulate those on the very few x86-64 platforms that didn't do them in
> hardware.
> 
> At that time it would have been very nice from a "user support" point of view
> to be able to add LAHF emulation to support the software.  Yes, it is ugly,
> binary-only code, but it is reasonably popular...
> 
> ...in the end, in fact, popular enough to have at least a couple of people
> I know purchase a new CPU that did implement it, just for flash on Linux.

The main use case for emulation is indeed to support binary-only or
otherwise precompiled software that exposes holes in the instruction
set.  As such, emulation can also be used to "raise the baseline", which
can be a highly desirable thing to do.

My point in all of this is that this is not a static problem, and that
if we're going to do emulation we need to consider the requirements
going forward.  I would *prefer* to have only one interpreter to deal
with when it's broken, and I certainly trust Avi & co to do the right
thing, but I'm certainly willing to entertain technical reasons why it
is not the right thing to do -- *not just now but in the future*.  The
latter is an absolutely critical constraint, though.

Once we have a general enough interpreter framework, we can add new
instructions as needed; it should make it a lot easier to phase in new
instructions while not breaking old legacy machines.

	-hpa