|
From: Dirk M. <dm...@gm...> - 2004-01-26 18:28:57
|
On Monday 26 January 2004 10:40, Jeremy Fitzhardinge wrote: > > emulating has to check before calling cpuid(0x80000001) if it is in fact > > a AMD CPU. If they don't, well, they get undefined behaviour anyway. > No, because other vendors can use 0x80000001 for other purposes. Intel > has this reserved, for example. intel cleans all bits. > Just clearing the bit means you could > be clearing some other feature flag for another vendor. Yes, as I said, one could check first if its an athlon cpu. However, thats not what your patch did. > > Correct. IMHO, we should only expose those which exist at all on the > > original host cpu. So basically we have to blacklist a few extensions > > which we don't support. > But that makes no sense. At any point, one of the currently reserved > bits could come into use, and a piece of software will try to use > instructions which are associated with that bit - requiring an upgrade > to Valgrind to make any progress at all. Its not as if valgrind would be a package that requires more than 5 minutes to download, configure, compile and install. When you use such a ultra new CPU you're going to get a lot more trouble with your kernel, your libc and your other runtime environment anyway. > After all, Valgrind's intent is not to emulate your actual host CPU, but > the common useful subset of ia32 implementation - which your host CPU > happens to be one of. Is this true? I wonder why we keep adding new instructions then. we could just claim to not support cpuid and only implement 386 instructions, not any of the "fancy" stuff newer processors do. Look, there were good reasons for implementing SSE: for example because of DRI drivers that use SSE without checking for it (NVIDIA being a good example). There was no way to suppress SSE support, and it was often requested since almost every second computer uses those NVIDIA drivers nowadays. > > euhm? when does invoking the cpuid instruction change the CPU behavior? > > Got an example for that? > It doesn't, but it does indicate CPU behavioural changes. The only ones > which user-mode programs care about are instruction-set extensions. Oh, how do you know what all possible user-mode programs care about? Is there some secret source of CPUID wisdom I don't know about yet? For the single reason that the old code did not expose any problem in any existing application that we know of I ask you to consider changing the code back to a blacklisting behavior. If you don't want to fix the cpuid masking to be athlon specific,then thats fine, I can do that. > Yes, I agree. But that isn't part of the feature bitmasks. Really? I wonder why I can read about such processor specific information then in the documentation of cpuid on sandpile.org. > Instruction set changes do affect the emulation. All the others are a > big "don't care". It's trivial to copy them through. Great. Then why did you break the "copy through" bit ? Thats the point I'm complaining about the whole time ! Dirk |