|
This page describes some of the internals of GXemul.
In reality, a lot of things need to be handled. Before each instruction is executed, the emulator checks to see if any interrupts are asserted which are not masked away. If so, then an INT exception is generated. Exceptions cause the program counter to be set to a specific value, and some of the system coprocessor's registers to be set to values signifying what kind of exception it was (an interrupt exception in this case).
Reading instructions from memory is done through a TLB, a translation lookaside buffer. The TLB on MIPS is software controlled, which means that the program running inside the emulator (for example an operating system kernel) has to take care of manually updating the TLB. Some memory addresses are translated into physical addresses directly, some are translated into valid physical addresses via the TLB, and some memory references are not valid. Invalid memory references cause exceptions.
After an instruction has been read from memory, the emulator checks which opcode it contains and executes the instruction. Executing an instruction usually involves reading some register and writing some register, or perhaps a load from memory (or a store to memory). The program counter is increased for every instruction.
Some memory references point to physical addresses which are not in the normal RAM address space. They may point to hardware devices. If that is the case, then loads and stores are converted into calls to a device access function. The device access function is then responsible for handling these reads and writes. For example, a graphical framebuffer device may put a pixel on the screen when a value is written to it, or a serial controller device may output a character to stdout when written to.
Mode a is very slow. On a 2.8 GHz Intel Xeon host the resulting emulated machine is rougly equal to a 7 MHz R3000 (or a 3.5 MHz R4000). The actual performance varies a lot, maybe between 5 and 10 million instructions per second, depending on workload.
Mode b ("bintrans") is still to be considered experimental, but gives higher performance than mode a. It translates MIPS machine code into machine code that can be executed on the host machine on-the-fly. The translation itself obviously takes some time, but this is usually made up for by the fact that the translated code chunks are executed multiple times. To run the emulator with binary translation enabled, just add -b to the command line.
Only small pieces of MIPS machine code are translated, usually the size of a function, or less. There is no "intermediate representation" code, so all translations are done directly from MIPS to host machine code.
The default bintrans cache size is 16 MB, but you can change this by adding -DDEFAULT_BINTRANS_SIZE_IN_MB=xx to your CFLAGS environment variable before running the configure script, or by using the bintrans_size() configuration file option when running the emulator.
By default, an emulated OS running under DECstation emulation which listens to interrupts from the mc146818 clock will get interrupts that are close to the host's clock. That is, if the emulated OS says it wants 100 interrupts per second, it will get approximately 100 interrupts per real second.
There is however a -I option, which sets the number of emulated cycles per seconds to a fixed value. Let's say you wish to make the emulated OS think it is running on a 40 MHz DECstation, and not a 7 MHz one, then you can add -I 40000000 to the command line. This will not make the emulation faster, of course. It might even make it seem slower; for example, if NetBSD/pmax waits 2 seconds for SCSI devices to settle during bootup, those 2 seconds will take 2*40000000 cycles (which will take more time than 2*7000000).
The -I option is also necessary if you want to run deterministic experiments, if a mc146818 device is present.
Some emulators make claims such as "x times slowdown," but in the case of GXemul, the host is often not a MIPS-based machine, and hence comparing one MIPS instruction to a host instruction doesn't work. Performance depends on a lot of factors, including (but not limited to) host architecture, host speed, which compiler and compiler flags were used to build GXemul, what the workload is, and so on. For example, if an emulated operating system tries to read a block from disk, from its point of view the read was instantaneous (no waiting). So 1 MIPS in an emulated OS might have taken more than one million instructions on a real machine. Because of this, imho it is best to measure performance as the actual (real-world) time it takes to perform a task with the emulator.
As far as I have understood it, there seems to be two different ways to go:
or
Since I have choosen the second kind of implementation, I have to write support explicitly for any kind of network protocol that should be supported. As of 2004-07-09, the following has been implemented and seems to work under at least NetBSD/pmax and OpenBSD/pmax under DECstation 5000/200 emulation (-E dec -e 3max):
Inside emulated NetBSD or OpenBSD, running the following commands should configure the emulated NIC:
# ifconfig le0 10.0.0.1 # route add default 10.0.0.254 add net default: gateway 10.0.0.254If you want nameserver lookups to work, you need a valid /etc/resolv.conf as well:
# echo nameserver 129.16.1.3 > /etc/resolv.conf(But replace 129.16.1.3 with the actual real-world IP address of your nearest nameserver.)
Now, host lookups should work:
# host -a www.netbsd.org Trying null domain rcode = 0 (Success), ancount=2 The following answer is not authoritative: The following answer is not verified as authentic by the server: www.netbsd.org 86400 IN AAAA 2001:4f8:4:7:290:27ff:feab:19a7 www.netbsd.org 86400 IN A 204.152.184.116 For authoritative answers, see: netbsd.org 83627 IN NS uucp-gw-2.pa.dec.com netbsd.org 83627 IN NS ns.netbsd.org netbsd.org 83627 IN NS adns1.berkeley.edu netbsd.org 83627 IN NS adns2.berkeley.edu netbsd.org 83627 IN NS uucp-gw-1.pa.dec.com Additional information: ns.netbsd.org 83627 IN A 204.152.184.164 uucp-gw-1.pa.dec.com 172799 IN A 204.123.2.18 uucp-gw-2.pa.dec.com 172799 IN A 204.123.2.19To transfer files via UDP, you can use the tftp program.
# tftp 12.34.56.78 tftp> get filename Received XXXXXX bytes in X.X seconds tftp> quit #or, to do it non-interactively (with ugly output):
# echo get filename | tftp 12.34.56.78 tftp> Received XXXXXX bytes in X.X seconds tftp> #This, of course, requires that you have put the file filename in the root directory of the tftp server (12.34.56.78).
It is also possible to run NFS via UDP. This is very useful if you want to share entire directory trees between the emulated environment and another machine. These instruction will work for FreeBSD, if you are running something else, use your imagination to modify them:
/tftpboot -mapall=nobody -ro 123.11.22.33where 123.11.22.33 is the IP address of the machine running the emulator process, as seen from the outside world.
# portmap # nfsd -u <--- u for UDP # mountd -n
# mount -o ro,-r=1024,-w=1024,-U,-3 my.server.com:/tftpboot /mnt or # mount my.server.com:/tftpboot /mntIf you don't supply the read and write sizes, there is a risk that the default values are too large. The emulator currently does not handle fragmentation/defragmentation of outgoing packets, so going above the ethernet frame size (1518) is a very bad idea. Incoming packets (reading from nfs) should work, though, for example during an NFS install.
TCP is implemented to some extent, but should not be considered to be stable yet. It is enough to let NetBSD/pmax and OpenBSD/pmax install via ftp, though.
NOTE: 2005-02-26: I'm currently rewriting the device registry subsystem.
(I'll be using the name 'foo' as the name of the device in all these examples. This is pseudo code, it might need some modification to actually compile and run.)
Each device should have the following:
/* * devinit_foo(): */ int devinit_foo(struct devinit *devinit) { struct foo_data *d = malloc(sizeof(struct foo_data)); if (d == NULL) { fprintf(stderr, "out of memory\n"); exit(1); } memset(d, 0, sizeof(struct foon_data)); /* * Set up stuff here, for example fill d with useful * data. devinit contains settings like address, irq_nr, * and other things. * * ... */ memory_device_register(devinit->machine->memory, devinit->name, devinit->addr, DEV_FOO_LENGTH, dev_foo_access, (void *)d, MEM_DEFAULT, NULL); /* This should only be here if the device has a tick function: */ machine_add_tickfunction(machine, dev_foo_tick, d, FOO_TICKSHIFT); /* Return 1 if the device was successfully added. */ return 1; }
struct foo_data { int irq_nr; /* ... */ }
#define FOO_TICKSHIFT 10 void dev_foo_tick(struct cpu *cpu, void *extra) { struct foo_data *d = (struct foo_data *) extra; if (.....) cpu_interrupt(cpu, d->irq_nr); else cpu_interrupt_ack(cpu, d->irq_nr); }
int dev_foo_access(struct cpu *cpu, struct memory *mem, uint64_t relative_addr, unsigned char *data, size_t len, int writeflag, void *extra) { struct foo_data *d = extra; uint64_t idata = 0, odata = 0; idata = memory_readmax64(cpu, data, len); switch (relative_addr) { /* .... */ } if (writeflag == MEM_READ) memory_writemax64(cpu, data, len, odata); /* Perhaps interrupts need to be asserted or deasserted: */ dev_foo_tick(cpu, extra); /* Return successfully. */ return 1; }
The return value of the access function has until 20040702 been a true/false value; 1 for success, or 0 for device access failure. A device access failure (on MIPS) will result in a DBE exception.
Some devices are converted to support arbitrary memory latency values. The return value is the number of cycles that the read or write access took. A value of 1 means one cycle, a value of 10 means 10 cycles. Negative values are used for device access failures, and the absolute value of the value is then the number of cycles; a value of -5 means that the access failed, and took 5 cycles.
To be compatible with pre-20040702 devices, a return value of 0 is treated by the caller (in src/memory.c) as a value of -1.
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.