Starting convergence to new lazy flags scheme by Darek Mihocka (www.emulators.com). The new flags code is still being validated and perfected but I try to minimize the diff between 2 versionS
Averything that required cpu.h include now has it explicitly and there are a lot of files not dependant by CPU at all which will compile a lot faster now ...
1. Review and commit patch
[ 896733 ] Lazy flags, for more instructions, only 1 src op
May be partially, but I hope to get all ideas from patch in
2. Get Bochs speedup after lazy flags optimization
3. Most important for me: improve correctness of emulation by handling several
undocumented EFLAGS modifications. And finally pass
UFLAGS - Undefined Flags Test v 3.0
Copyright (C) Potemkin's Hackers Group (PHG) 1989,1995
The test still fails on > 50% of its checks.
For a whole lot of configure options, I put #if...#endif around code that
is specific to the option, even in files which are normally only compiled
when the option is on. This allows me to create a MS Visual C++ 6.0
workspace that supports many of these options. The workspace will basically
compile every file all the time, but the code for disabled options will
be commented out by the #if...#endif.
This may one day lead to simplification of the Makefiles and configure
scripts, but for the moment I'm leaving Makefiles and configure scripts
alone.
Affected options:
BX_SUPPORT_APIC (cpu/apic.cc)
BX_SUPPORT_X86_64 (cpu/*64.cc)
BX_DEBUGGER (debug/*)
BX_DISASM (disasm/*)
BX_WITH_nameofgui (gui/*)
BX_SUPPORT_CDROM (iodev/cdrom.cc)
BX_NE2K_SUPPORT (iodev/eth*.cc, iodev/ne2k.cc)
BX_SUPPORT_APIC (iodev/ioapic.cc)
BX_IODEBUG_SUPPORT (iodev/iodebug.cc)
BX_PCI_SUPPORT (iodev/pci*.cc)
BX_SUPPORT_SB16 (iodev/sb*.cc)
Modified Files:
cpu/apic.cc cpu/arith64.cc cpu/ctrl_xfer64.cc
cpu/data_xfer64.cc cpu/fetchdecode64.cc cpu/logical64.cc
cpu/mult64.cc cpu/resolve64.cc cpu/shift64.cc cpu/stack64.cc
debug/Makefile.in debug/crc.cc debug/dbg_main.cc debug/lexer.l
debug/linux.cc debug/parser.c debug/parser.y
disasm/dis_decode.cc disasm/dis_groups.cc gui/amigaos.cc
gui/beos.cc gui/carbon.cc gui/macintosh.cc gui/rfb.cc
gui/sdl.cc gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc
gui/wxmain.cc gui/x.cc iodev/cdrom.cc iodev/eth.cc
iodev/eth_arpback.cc iodev/eth_fbsd.cc iodev/eth_linux.cc
iodev/eth_null.cc iodev/eth_packetmaker.cc iodev/eth_tap.cc
iodev/eth_tuntap.cc iodev/eth_win32.cc iodev/ioapic.cc
iodev/iodebug.cc iodev/ne2k.cc iodev/pci.cc iodev/pci2isa.cc
iodev/sb16.cc iodev/soundlnx.cc iodev/soundwin.cc
there to offer a way to substitute more efficient code
to do the RMW cases. At the moment, they just map to
the normal functions.
Sorry, restored the previous version ...
"bx_bool" which is always defined as Bit32u on all platforms. In Carbon
specific code, Boolean is still used because the Carbon header files
define it to unsigned char.
- this fixes bug [ 623152 ] MacOSX: Triple Exception Booting win95.
The bug was that some code in Bochs depends on Boolean to be a
32 bit value. (This should be fixed, but I don't know all the places
where it needs to be fixed yet.) Because Carbon defined Boolean as
an unsigned char, Bochs just followed along and used the unsigned char
definition to avoid compile problems. This exposed the dependency
on 32 bit Boolean on MacOS X only and led to major simulation problems,
that could only be reproduced and debugged on that platform.
- On the mailing list we debated whether to make all Booleans into "bool" or
our own type. I chose bx_bool for several reasons.
1. Unlike C++'s bool, we can guarantee that bx_bool is the same size on all
platforms, which makes it much less likely to have more platform-specific
simulation differences in the future. (I spent hours on a borrowed
MacOSX machine chasing bug 618388 before discovering that different sized
Booleans were the problem, and I don't want to repeat that.)
2. We still have at least one dependency on 32 bit Booleans which must be
fixed some time, but I don't want to risk introducing new bugs into the
simulation just before the 2.0 release.
Modified Files:
bochs.h config.h.in gdbstub.cc logio.cc main.cc pc_system.cc
pc_system.h plugin.cc plugin.h bios/rombios.c cpu/apic.cc
cpu/arith16.cc cpu/arith32.cc cpu/arith64.cc cpu/arith8.cc
cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer16.cc cpu/ctrl_xfer32.cc
cpu/ctrl_xfer64.cc cpu/data_xfer16.cc cpu/data_xfer32.cc
cpu/data_xfer64.cc cpu/debugstuff.cc cpu/exception.cc
cpu/fetchdecode.cc cpu/flag_ctrl_pro.cc cpu/init.cc
cpu/io_pro.cc cpu/lazy_flags.cc cpu/lazy_flags.h cpu/mult16.cc
cpu/mult32.cc cpu/mult64.cc cpu/mult8.cc cpu/paging.cc
cpu/proc_ctrl.cc cpu/segment_ctrl_pro.cc cpu/stack_pro.cc
cpu/tasking.cc debug/dbg_main.cc debug/debug.h debug/sim2.cc
disasm/dis_decode.cc disasm/disasm.h doc/docbook/Makefile
docs-html/cosimulation.html fpu/wmFPUemu_glue.cc
gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/gui.cc gui/gui.h
gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc
gui/rfb.cc gui/sdl.cc gui/siminterface.cc gui/siminterface.h
gui/term.cc gui/win32.cc gui/wx.cc gui/wxmain.cc gui/wxmain.h
gui/x.cc instrument/example0/instrument.cc
instrument/example0/instrument.h
instrument/example1/instrument.cc
instrument/example1/instrument.h
instrument/stubs/instrument.cc instrument/stubs/instrument.h
iodev/cdrom.cc iodev/cdrom.h iodev/cdrom_osx.cc iodev/cmos.cc
iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_arpback.cc
iodev/eth_packetmaker.cc iodev/eth_packetmaker.h
iodev/floppy.cc iodev/floppy.h iodev/guest2host.h
iodev/harddrv.cc iodev/harddrv.h iodev/ioapic.cc
iodev/ioapic.h iodev/iodebug.cc iodev/iodev.h
iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.h
iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pic.h
iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h
iodev/sb16.cc iodev/sb16.h iodev/serial.cc iodev/serial.h
iodev/vga.cc iodev/vga.h memory/memory.h memory/misc_mem.cc
use getB_CF() etc. getB_CF() and friends are only for a relatively
small number of cases where a true boolean/binary number (0 or 1) is required
rather than 0 or non-0 as is returned by get_CF().
