This patch fixes two bugs in cuda emulation:
- the CUDA timer is always triggered twice, with current code
- SET_TIME command is supposed to send back a 7 bytes packet
--
J. Mayer [EMAIL PROTECTED]
Never organized
Index: hw/cuda.c
This patch adds little-endian mode support to PPC emulation.
This is needed by OS/2 and Windows NT and some programs like VirtualPC.
This patch have been tested using OS/2 bootloader (thanks to Tero
Kaarlela).
--
J. Mayer [EMAIL PROTECTED]
Never organized
Index: cpu-exec.c
This conversation, below, is very interesting. It is precisely this
part of QEMU that fascinates me and potentially holds the most promise
for performance gains. I have even imagined using a genetic algorithm
to discover optimal block-sizes and instruction re-ordering and
whatnot. This could be
There are some code sequences that are quite common, for example compare
followed by branch. A threaded decoder tends to look like:
... // do some work
load instruction
mask out opcode
address_of_decoder = load decoder_lookupopcode
goto *address_of_decoder
but if you say compare and branch are
hw/vga.c: S3 VGA is deprecated, remove it.
diff -X excl -rduNp qemu.oorig/hw/vga.c qemu/hw/vga.c
--- qemu.oorig/hw/vga.c 2005-02-10 23:00:27.0 +0100
+++ qemu/hw/vga.c 2005-04-18 10:21:45.113278016 +0200
@@ -28,12 +28,8 @@
//#define DEBUG_VGA_MEM
//#define DEBUG_VGA_REG
I was up until 3:00am studying Qemu, and I came to the conclusion
that
it doesn't make sense to try speeding up the output code, at least
not
yet. A peephole optimizer or hand-coded sequences made to handle
common
combinations of instructions would lead to the problems discussed
here:
Christian MICHON wrote:
I did months ago gcc/FDO with a xp/lite installation as a repetitive task :)
I did not improve the timings after all the effort.
could this be down to the tables used to find the
translators/generators? are they constant? is it possible to make them
amenable to
