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.
