|
From: Mike G. <mi...@ac...> - 2005-04-14 18:14:55
|
Hi, I have a program that uses the smsw instruction (for the curious, I want to test if FXSAVE is emulated by the processor). Valgrind quits with the following message when it hits this instruction: "disInstr: unhandled instruction bytes: 0x66 0xF 0x1 0xE0". Those instruction bytes are equivalent to "smsw ax" in assembly. Cheers, --Mike |
|
From: Nicholas N. <nj...@cs...> - 2005-04-14 18:53:18
|
On Thu, 14 Apr 2005, Mike Grass wrote: > I have a program that uses the smsw instruction (for the curious, I want to > test if FXSAVE is emulated by the processor). Valgrind quits with the following > message when it hits this instruction: > > "disInstr: unhandled instruction bytes: 0x66 0xF 0x1 0xE0". > > Those instruction bytes are equivalent to "smsw ax" in assembly. What does 'smsw' do? Is it like 'fstsw ax' ? Can you provide the assembly sequence that this is part of? Thanks. N |
|
From: Mike G. <mi...@ac...> - 2005-04-15 20:42:03
|
Nicholas Nethercote wrote: > What does 'smsw' do? Is it like 'fstsw ax' ? > Can you provide the assembly sequence that this is part of? > smsw is similar to fstsw, except that it stores the machine status word (which is part of the control register CR0). I could use 'mov cr0, eax', except I want to get the status word without jumping privilege level. This code is part of an extended cpu identification routine, and is based on Agner Fog's DetectProcessor. The code snippet is as follows: ... smsw ax ; read part of CR0 without violating privilege test al, 4 ; test if FXSAVE is emulated jnz .no_SSE_test ... Thanks, --Mike |
> smsw ax ; read part of CR0 without violating privilege > test al, 4 ; test if FXSAVE is emulated > jnz .no_SSE_test It would be legal for valgrind to "implement" smsw by treating it as a generator of a two-byte random result (the existing contents of the destination). The status revealed by smsw is relevant to user mode only when running on the bare, real hardware. The bits are essentially meaningless for user mode on i586 and later; they have observable meaning only for i486SX (no FP), i386, and i286. -- |
|
From: Jeremy F. <je...@go...> - 2005-04-16 16:36:21
|
John Reiser wrote:
>> smsw ax ; read part of CR0 without violating privilege
>> test al, 4 ; test if FXSAVE is emulated
>> jnz .no_SSE_test
>
>
> It would be legal for valgrind to "implement" smsw by treating it
> as a generator of a two-byte random result (the existing contents
> of the destination). The status revealed by smsw is relevant to
> user mode only when running on the bare, real hardware. The bits
> are essentially meaningless for user mode on i586 and later; they
> have observable meaning only for i486SX (no FP), i386, and i286.
>
Hm, looks like that to me too. Specifically, EM is set and cleared by
the kernel all the time as part of lazy FPU context switching, so what
you're really looking at is whether the process has used an FP/SSE
instruction within this timeslice or not, or perhaps there are no other
FPU-using processes. So I don't think this code does what Mike thinks
it does.
J
|
|
From: Julian S. <js...@ac...> - 2005-04-19 21:43:37
|
All in all this instruction seems sufficiently mutant that it deserves not to be implemented. In all the too-many years I've been doing user-space x86 I've never come across it, so I assume it's hardly a popular one. J > >> smsw ax ; read part of CR0 without violating privilege > >> test al, 4 ; test if FXSAVE is emulated > >> jnz .no_SSE_test > > > > It would be legal for valgrind to "implement" smsw by treating it > > as a generator of a two-byte random result (the existing contents > > of the destination). The status revealed by smsw is relevant to > > user mode only when running on the bare, real hardware. The bits > > are essentially meaningless for user mode on i586 and later; they > > have observable meaning only for i486SX (no FP), i386, and i286. > > Hm, looks like that to me too. Specifically, EM is set and cleared by > the kernel all the time as part of lazy FPU context switching, so what > you're really looking at is whether the process has used an FP/SSE > instruction within this timeslice or not, or perhaps there are no other > FPU-using processes. So I don't think this code does what Mike thinks > it does. |