a control panel, but now we're calling it a text configuration interface.
Modified:
.bochsrc Makefile.in bochs.h main.cc cpu/Makefile.in
debug/Makefile.in disasm/Makefile.in fpu/Makefile.in
gui/Makefile.in iodev/Makefile.in memory/Makefile.in
"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
instead of winmm being a part of GUI_LINK_OPTS_WIN32 only, it is
placed in @DEVICE_LINE_OPTS@ so that it will be used for sdl, rfb, wx,
etc.
- solve compile problems when building bximage, niclist, and any other
console based program. The compile flags returned by wx-config and
sdl-config did strange things to these console programs, for example
redefining main to SDL_main. Because I wanted to use the
configure-generated CFLAGS to compile the programs, but I wanted to
avoid including GUI specific compile options, I split up the configure's
@CFLAGS@ variable into @CFLAGS@ and @GUI_CFLAGS@, and split
@CXXFLAGS@ into @CXXFLAGS@ and @GUI_CXXFLAGS@. All programs in the
Bochs binary will use both, but the console programs will just use
@CFLAGS@ or @CXXFLAGS@.
- gui/Makefile.in, I no longer use the gui specific CFLAGS variables,
SDL_CFLAGS and WX_CXXFLAGS. These values are included in CFLAGS and
CXXFLAGS now.
- modified: configure.in, configure, all Makefile.in's
to bitfields. bxInstruction_c is now 24 bytes, including 4 for
the memory addr resolution function pointer, and 4 for the
execution function pointer (16 + 4 + 4).
Coded more accessors, to abstract access from most code.
with accessors. Had to touch a number of files to update the
access using the new accessors.
Moved rm_addr to the CPU structure, to slim down bxInstruction_c
and to prevent future instruction caching from getting sprayed
with writes to individual rm_addr fields. There only needs to
be one. Though need to deal with instructions which have
static non-modrm addresses, but which are using rm_addr since
that will change.
bxInstruction_c is down to about 40 bytes now. Trying to
get down to 24 bytes.
use accessors. This lets me work on compressing the
size of fetch-decode structure (now called bxInstruction_c).
I've reduced it down to about 76 bytes. We should be able
to do much better soon. I needed the abstraction of the
accessors, so I have a lot of freedom to re-arrange things
without making massive future changes.
Lost a few percent of performance in these mods, but my
main focus was to get the abstraction.
which were generated with gcc -MM to the end of each Makefile.in
so that make understands which files depend on which. Basically,
everything depends on bochs.h, which depends on everything, which
is not ideal.
in an output format similar to gdb (when you do info all-registers).
Also, if you do "info all" you get the CPU registers and the FPU
registers.
- added bx_cpu_c method called fpu_print_regs, which is implemented
in wmFPUemu_glue.cc
in BRANCH-smp-bochs revisions.
- The general task was to make multiple CPU's which communicate
through their APICs. So instead of BX_CPU and BX_MEM, we now have
BX_CPU(x) and BX_MEM(y). For an SMP simulation you have several
processors in a shared memory space, so there might be processors
BX_CPU(0..3) but only one memory space BX_MEM(0). For cosimulation,
you could have BX_CPU(0) with BX_MEM(0), then BX_CPU(1) with
BX_MEM(1). WARNING: Cosimulation is almost certainly broken by the
SMP changes.
- to simulate multiple CPUs, you have to give each CPU time to execute
in turn. This is currently implemented using debugger guards. The
cpu loop steps one CPU for a few instructions, then steps the
next CPU for a few instructions, etc.
- there is some limited support in the debugger for two CPUs, for
example printing information from each CPU when single stepping.
To see the commit logs for this use either cvsweb or
cvs update -r BRANCH-io-cleanup and then 'cvs log' the various files.
In general this provides a generic interface for logging.
logfunctions:: is a class that is inherited by some classes, and also
. allocated as a standalone global called 'genlog'. All logging uses
. one of the ::info(), ::error(), ::ldebug(), ::panic() methods of this
. class through 'BX_INFO(), BX_ERROR(), BX_DEBUG(), BX_PANIC()' macros
. respectively.
.
. An example usage:
. BX_INFO(("Hello, World!\n"));
iofunctions:: is a class that is allocated once by default, and assigned
as the iofunction of each logfunctions instance. It is this class that
maintains the file descriptor and other output related code, at this
point using vfprintf(). At some future point, someone may choose to
write a gui 'console' for bochs to which messages would be redirected
simply by assigning a different iofunction class to the various logfunctions
objects.
More cleanup is coming, but this works for now. If you want to see alot
of debugging output, in main.cc, change onoff[LOGLEV_DEBUG]=0 to =1.
Comments, bugs, flames, to me: todd@fries.net
compile warnings with or without it on Linux, so it seems no longer
necessary. It may have been introduced to cope with the fabs symbol
conflict, which was already removed in rev1.3 of fpu_etc.c.
unfortunately is the same as the C library function fabs. Many
compilers seem to use the static one with no complaint, but others
don't like it. Just rename fabs, to eliminate the potential
conflict.
For compilers (such as Microsoft VC++) which don't allow "LL" after a
constant to make it 64-bit, this patch declares all such constants as
BX_CONST64(value). Then in config.in, a switch called
BX_64BIT_CONSTANTS_USE_LL controls whether the macro puts the
LL's in or not. Configure sets the macro, if you're on a platform
that can run such things.
- put /*comments symbols*/ around any chars after #endif. Other compilers
do not get it.
- fix cases in which a pointer is cast to a 32-bit int, then back to a
pointer. This breaks on a machine with 64-bit pointers. Examples:
FPU_sub arg 2 and FPU_div arg 2. The int->ptr->int conversions are
now done more safely by macros REGNO2PTR and PTR2INT.
- use GCC_ATTRIBUTE macro instead of __attribute__. For compilers that
do not support __attribute__, the macro can be defined to be nothing.
- in fpu_entry.c, arg1 of FPU_load_int32 is (s32*), but the calls to
it cast their data to (u32*).
- if compiler does NOT inline functions in poly.h, the "extern inline"
setting caused duplicate symbols to be created. Changed them to
"static inline" so that the mul_32_32 from different .c files do not
conflict.
- implemented setcc so that it doesn't use curly brackets inside parens
- comment out sigcontext structure definition, which conflicts with
non-linux or non-intel operating systems. It's not used by bochs anyway.
