to cache the CPU context pointer to a register and thus rendering generated
code CPU context independent. Not useful to SheepShaver, but it is for
another project for threads emulation on plain x86-32.
Note: AltiVec performance may drop a little on x86 but this will be restored
(and even improved) in the future.
set to 0 until generated code is optimized enough (current slow down factor
is 3x vs. previous core, expectations are about 50% slower FP code).
The main benefit is exception bits are accurate. All glibc test-fenv,
test-arith{,f}, test-double, test-float pass on ppc, and mostly on x86_64
with gcc 4.0.1. Yes, this is also compiler dependent.
FIXME: find a real Mac application that depends on precise FPSCR bits... I
think I don't want to care optimizing yet until someone shows me a real world
application.
if you have changed the depth since boot (seems to be something strange
with the parameters that I still haven't worked out). If this happens,
we now put a suggested workaround in the warning message.
68k or MacOS code, so they don't need to be a termination point. i.e. don't
split into two basic blocks and thus avoid a full hash search.
Also add missing NQD_unknown_hook NativeOp from previous commit.
This reduces the number of Screen_fault_handler() calls by 80%. i.e. VOSF
is now viable on this turtle MacOS X. Besides, since there is no buffer
comparison, idle sleep can really be effective. SheepShaver in idle mode
on my PBG4 now goes below 8% of CPU resources instead of 70-80% with
bounding boxes based video refreshes.
Caveat: if your program doesn't use standard MacOS routines that call NQD,
then you can expect slower (visual) performance. However, I do think the
new default behavior (VOSF+NQD) is the most common.
This does not improve graphics performance but helps CPU because it reduces
the number of bytes transfered to actual screen. I saw an improvement by up
to 26% in frameskip 4 800x600x16 but also a hit by 3% with frameskip 0.
The next step is to use NQD bounding boxes to help detecting dirty areas.
So far, this is the best I can do without VOSF working (MacOS X performance
bugs -- pitifully slow Mach syscalls)
- Properly handle migration from "screenmodes" and "windowmodes" to "screen"
- Fix has_mode() logic to really test for actual mode availability. i.e.
no longer start in large screen mode if user specified a max size.