|
From: <sv...@va...> - 2005-04-06 10:27:16
|
Author: sewardj
Date: 2005-04-06 11:27:11 +0100 (Wed, 06 Apr 2005)
New Revision: 1124
Modified:
trunk/priv/guest-x86/toIR.c
Log:
Comment-only changes
Modified: trunk/priv/guest-x86/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/guest-x86/toIR.c 2005-04-06 01:45:44 UTC (rev 1123)
+++ trunk/priv/guest-x86/toIR.c 2005-04-06 10:27:11 UTC (rev 1124)
@@ -34,7 +34,7 @@
*/
=20
/* TODO:
- SBB reg with itself
+ SBB reg with itself (copy from amd64 front end)
=20
check flag settings for cmpxchg
FUCOMI(P): what happens to A and S flags? Currently are forced
@@ -64,7 +64,7 @@
zeroes all the FP registers. It should leave the registers
unchanged.
=20
- RDTSC returns zero, always.
+ RDTSC returns one, always.
=20
SAHF should cause eflags[1] =3D=3D 1, and in fact it produces 0. As
per Intel docs this bit has no meaning anyway. Since PUSHF is the
@@ -80,6 +80,21 @@
translate x86 code for execution on a 64-bit host.
*/
=20
+/* Performance holes:
+
+ - fcom ; fstsw %ax ; sahf
+ sahf does not update the O flag (sigh) and so O needs to
+ be computed. This is done expensively; it would be better
+ to have a calculate_eflags_o helper.
+
+ - emwarns; some FP codes can generate huge numbers of these
+ if the fpucw is changed in an inner loop. It would be
+ better for the guest state to have an emwarn-enable reg
+ which can be set zero or nonzero. If it is zero, emwarns
+ are not flagged, and instead control just flows all the
+ way through bbs as usual.
+*/
+
/* Translates x86 code to IR. */
=20
#include "libvex_basictypes.h"
|