correct ioctls

[qemu] / qemu-tech.texi

diff --git a/qemu-tech.texi b/qemu-tech.texi
index 0df2a0b..95d1787 100644 (file)
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -22,7 +22,7 @@ QEMU has two operating modes:
 
 @item 
 Full system emulation. In this mode, QEMU emulates a full system
-(usually a PC), including a processor and various peripherials. It can
+(usually a PC), including a processor and various peripherals. It can
 be used to launch an different Operating System without rebooting the
 PC or to debug system code.
 
@@ -126,7 +126,7 @@ maximum performances.
 
 @itemize
 
-@item Full PowerPC 32 bit emulation, including priviledged instructions, 
+@item Full PowerPC 32 bit emulation, including privileged instructions, 
 FPU and MMU.
 
 @item Can run most PowerPC Linux binaries.
@@ -137,9 +137,32 @@ FPU and MMU.
 
 @itemize
 
-@item SPARC V8 user support, except FPU instructions.
+@item Somewhat complete SPARC V8 emulation, including privileged
+instructions, FPU and MMU. SPARC V9 emulation includes most privileged
+instructions, FPU and I/D MMU, but misses VIS instructions.
 
-@item Can run some SPARC Linux binaries.
+@item Can run some 32-bit SPARC Linux binaries.
+
+@end itemize
+
+Current QEMU limitations:
+
+@itemize 
+
+@item Tagged add/subtract instructions are not supported, but they are
+probably not used.
+
+@item IPC syscalls are missing.
+
+@item 128-bit floating point operations are not supported, though none of the
+real CPUs implement them either. FCMPE[SD] are not correctly
+implemented.  Floating point exception support is untested.
+
+@item Alignment is not enforced at all.
+
+@item Atomic instructions are not correctly implemented.
+
+@item Sparc64 emulators are not usable for anything yet.
 
 @end itemize
 
@@ -167,7 +190,7 @@ interpreter part of the FX!32 Digital Win32 code translator [5]).
 
 TWIN [6] is a Windows API emulator like Wine. It is less accurate than
 Wine but includes a protected mode x86 interpreter to launch x86 Windows
-executables. Such an approach as greater potential because most of the
+executables. Such an approach has greater potential because most of the
 Windows API is executed natively but it is far more difficult to develop
 because all the data structures and function parameters exchanged
 between the API and the x86 code must be converted.