--- trunk/doc/technical.html 2007/10/08 16:18:31 11
+++ trunk/doc/technical.html 2007/10/08 16:18:38 12
@@ -1,16 +1,16 @@
-
Regression tests
@@ -94,7 +94,7 @@
different kinds of emulation, so these might change in the future.)
- - MIPS
+ - MIPS:
There are two emulation modes. The most important one is an
implementation of a dynamic binary translator.
(Compared to real binary translators, though, GXemul's bintrans
@@ -105,26 +105,13 @@
works. It can be forcefully used by using the -B command
line option.)
-
- ARM
- This mode does not really work yet, but will use
- dynamic translation, but not binary translation. Stay tuned. :-)
-
-
- URISC
- Simple interpretation, one instruction at a time. There is probably
- no other way to emulate URISC, because it relies too heavily
- on self-modifying code.
-
-
- POWER/PowerPC
- This emulation mode is very much unfinished, but still enabled by
- default. So far it uses plain interpretation, where an instruction
- is read from emulated memory, and interpreted one at a time.
- Slow. Not very interesting.
-
-
- x86
- Although too unstable and non-working to be enabled by default,
- there is some code for emulating x86 machines. It simply reads
- one instruction at a time from emulated memory, and executes it.
- This is as slow as it gets. Not very interesting.
+ - All other modes:
+ These are under development, using a new dynamic translation
+ system. This system does not use host-specific backends.
+ Speed is slower than real binary translation, but faster than
+ traditional interpretation, and with some tricks it will hopefully
+ still give reasonable speed. These modes don't really work yet,
+ and are not enabled by default in the stable release.
@@ -132,7 +119,6 @@
-
Networking
@@ -343,7 +329,7 @@
Emulation of hardware devices
-Each file in the device/ directory is responsible for one
+Each file in the src/device/ directory is responsible for one
hardware device. These are used from src/machine.c, when
initializing which hardware a particular machine model will be using, or
when adding devices to a machine using the device() command in
@@ -474,76 +460,6 @@
-
-
-
Regression tests
-
-In order to make sure that the emulator actually works like it is supposed
-to, it must be tested. For this purpose, there is a simple regression
-testing framework in the tests/ directory.
-
-
-NOTE: The regression testing framework is basically just a skeleton so far.
-Regression tests are very good to have. However, the fact that complete
-operating systems can run in the emulator indicate that the emulation is
-probably not too incorrect. This makes it less of a priority to write
-regression tests.
-
-
-To run all the regression tests, type make regtest. Each assembly
-language file matching the pattern test_*.S will be compiled and
-linked into a 64-bit MIPS ELF (using a gcc cross compiler), and run in the
-emulator. If everything goes well, you should see something like this:
-
-
- $ make regtest
- cd tests; make run_tests; cd ..
- gcc33 -Wall -fomit-frame-pointer -fmove-all-movables -fpeephole -O2
- -mcpu=ev5 -I/usr/X11R6/include -lm -L/usr/X11R6/lib -lX11 do_tests.c
- -o do_tests
- do_tests.c: In function `main':
- do_tests.c:173: warning: unused variable `s'
- /var/tmp//ccFOupvD.o: In function `do_tests':
- /var/tmp//ccFOupvD.o(.text+0x3a8): warning: tmpnam() possibly used
- unsafely; consider using mkstemp()
- mips64-unknown-elf-gcc -g -O3 -fno-builtin -fschedule-insns -mips64
- -mabi=64 test_common.c -c -o test_common.o
- ./do_tests "mips64-unknown-elf-gcc -g -O3 -fno-builtin -fschedule-insns
- -mips64 -mabi=64" "mips64-unknown-elf-as -mabi=64 -mips64"
- "mips64-unknown-elf-ld -Ttext 0xa800000000030000 -e main
- --oformat=elf64-bigmips" "../gxemul"
-
- Starting tests:
- test_addu.S (-a)
- test_addu.S (-a -b)
- test_clo_clz.S (-a)
- test_clo_clz.S (-a -b)
- ..
- test_unaligned.S (-a)
- test_unaligned.S (-a -b)
-
- Done. (12 tests done)
- PASS: 12
- FAIL: 0
-
- ----------------
-
- All tests OK
-
- ----------------
-
-
-
-Each test writes output to stdout, and there is a test_*.good for
-each .S file which contains the wanted output. If the actual
-output matches the .good file, then the test passes, otherwise it
-fails.
-
-
-Read tests/README for more information.
-
-
-