According to the Intel manuals:
The LOCK prefix can be prepended only to the following instructions
and only to those forms of the instructions where the destination
operand is a memory operand: ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG,
CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG. If
the LOCK prefix is used with one of these instructions and the source
operand is a memory operand, an undefined opcode exception (#UD) will
be generated. An undefined opcode exception will also be generated if
the LOCK prefix is used with any instruction not in the above list.
Checking of the LOCK prefix done in fetchDecode state and not overloads
Bochs's execution.
- it works only on x86 with gcc2.95+
- uses the GCC function atribute "regparm(n)" to declare that certain
functions use the register calling convention
- performance improvement is about 6%
1) fixed the type of "hostPageAddr" and associated typecasts.
2) fixed the type of "pages" and associated typecasts (overloaded variable)
3) patch to cpu.cc to calculate "eipPageBias" correctly in 64 bit mode
1) fixed some errors running 32 bit compat mode. IMPORTANT FIX.
2) added IST processing (uses IST1-IST7 in 64 bit TSS)
3) cosmetic - debugging stuff to console.
a minor optimization. Also in transition from compat mode to 64 bit mode (e.g. interrupt to inner
privelege with mode change), SS may not be properly defined - this avoids other messiness.
* renamed CPU_ID to BX_CPU_ID.
with this new name there is no possibility for name contentions and BX_CPU_ID
definition could be moved out to NEED_CPU_REG_SHORTCUTS block
* returned back `unsigned BX_CPU::which_cpu(void)` function
* added BX_CPU_ID parameter for
BX_INSTR_PHY_READ(a20addr, len);
BX_INSTR_PHY_WRITE(a20addr, len);
now it will be
BX_INSTR_PHY_READ(cpu_id, a20addr, len);
BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
> CPU_ID is defined as
> #define CPU_ID (BX_CPU_THIS_PTR local_apic.get_id())
> This is not true when the APIC name is changed (true in Linux). Please
> change this to:
> #define CPU_ID (BX_CPU_THIS - BX_CPU(0))
The 64 bit variant of MOVNTI was not decoded. The proper fix for this is to work on
fetchdecode64.cc to call a 64 bit variant of SSE instructions or fail it with a
invalid op. A careful check needs to be done with the AMD manuals to determine if
there are any other SSE instructions that have a special 64 bit decoding.
PSRAW_PqQq (MMX)
PSRAD_PqQq (MMX)
PSRAW_PqIb (MMX)
PSRAD_PqIb (MMX)
PSRAW_VdqWdq (SSE)
PSRAD_VdqWdq (SSE)
PSRAW_PdqIb (SSE)
PSRAD_PdqIb (SSE)
When register was shifted by 0 bits the result produced was incorrect.
Now Bochs fully passes MMX test provided by
Hentai Yagi [hentai_yagi@yahoo.com.au] !
sash to run.
1) fixed fetchdecode64.cc to fix the operand size at 64 bits in long mode for moves
to/from CRx
2) minor patches to sse2.cc to fix unimplemented and 64 bit variants of sse2
instructions.
Because source files were added/removed it would require an update
of the windows and macos project files, so I want to wait until after 2.0.
M Makefile.in 1.51 back to 1.50
M cpu.h 1.121 back to 1.120
M fetchdecode.cc 1.37 back to 1.36
M fetchdecode64.cc 1.33 back to 1.32
M sse.cc 1.17 back to 1.16
A sse2.cc 1.27 back to 1.26 (added back)
R sse_move.cc removed
R sse_pfp.cc removed
- to bring these changes back again, all we have to do is
"cvs update -j tmp-before1 -j tmp-after1"
sse.cc -> general SSE stuff and SSE integer (MMX extensions)
sse_move.cc -> memory transfer and shuffle opcodes
sse_pfp.cc -> packed floating point operations
Description/justification:
Endian Host byte order Guest (x86) byte order
======================================================
Little FFFFFFFFEEAAAAAA FFFFFFFFEEAAAAAA
Big AAAAAAEEFFFFFFFF FFFFFFFFEEAAAAAA
F - fraction/mmx
E - exponent
A - aligment
debugger, SMP, and x86-64. A few macros were missing the CPU_ID argument,
and a few passed nonexistent variables to the instrumentation macros.
- I changed CPU_ID into a plain old macro instead of an inline call to a
trivial which_cpu() function, and removed which_cpu().
Modified Files:
cpu/cpu.h cpu/ctrl_xfer64.cc debug/dbg_main.cc
In bx_cpu_c::reset method I set bx_cpu->async_event to 2
so execution in the cpu_loop gets stopped early.
Previously, async_event was set to 0, and with repeatable
instructions, after reset, eip was incremented by the instruction
length, so execution would resume at 0xffffX (X being >0, the current
instruction length).
In halt state I check now for reset with async_event is 2, so
reset works also when the cpu is halted. (update to Peter change)
I hope I fixed this the right way, please report any strange behaviour.
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
stack limits. This is needed for EROS, and probably for L4, as both
rely on this SS fault (and the corresponding GP fault) to trigger the
switch from small address spaces to large address spaces. The
push_16() code was already correct, and I find the inconsistency a bit
odd.
I'm not 100% sure about the push_64() change, so I made the change
with a comment but left it a BX_PANIC() rather than switching it to
BX_INFO. I'll ask Peter momentarily to have a look and let me know.
While I was added, changed the push_16() BX_INFO message to be
consistent with the others -- all now say 'push outside stack limits'.
- Now compiles for plain ia-32
- Fixed some printf formatting for ia32 only.
- Update to latest Win32 DLL
- Added an ICEBP (Undoc 0xF8, INT 01) facility.
- updated to use latest VGA refresh routine
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
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
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
SSE/SSE2 for Stanislav. Also, some method prototypes and
skeletal functions in access.cc for read/write double quadword
features.
Also cleaned up one warning in protect_ctrl.cc for non-64 bit compiles.
There was an unused variable, only used for 64-bit.
This is an interim update to allow others to test.
We have userland code running!!! (up to a point)
Able to start executing "sash" as /sbin/init in userland from linux 64 bit
kernel until it crashes trying to access a null pointer. No kernel panics
though, just a segfault loop.
into inline functions with asm() statements in cpu.h. This cleans
up the *.cc code (which now doesn't have any asm()s in it), and
centralizes the asm() code so constraints can be modified in one
place. This also makes it easier to cover more instructions
with asm()s for more efficient eflags handling.
hack with longjmp() back to cpu.cc main decode loop, and added a
check in there to return control when bx_guard.special_unwind_stack
is set (compiling with debugger enabled only).
If in the debugger you try to execute further instructions
(which you shouldn't), other fields need to be reset I would
think, such as EXT and errorno, and have to make sure ESP/EIP
are corrected properly. Basically, this hack is only good
for examining the current situation of a nasty fault.
