Commit 9422ea5905
introduced support for
resetting the 32x SH2 CPUs from the MD 68k CPU, and it also created a
couple of new issues.
1. SH2::power() tries to allocate from a fixed bump allocator, but that
allocator is only reset from M32X::power(), which is not called in
response to a reset register write. In practice this meant we were
falling back on dynamic allocation, creating performance issues when the
allocation is distant from the ares executable.
2. The code cache could be released out from under a running SH2 libco
thread we switched away from to run the 68k thread.
This change fixes #1 and partially addresses #2, but it doesn't address
the issue of an already executing SH2 code block resuming where it left
off after a reset. I don't currently have a test for this case, so I'll
leave it for a later change.
このコミットが含まれているのは:
コミット
07c320e55a
|
@ -64,10 +64,12 @@ auto SH2::power(bool reset) -> void {
|
|||
cache.power();
|
||||
|
||||
if constexpr(Accuracy::Recompiler) {
|
||||
auto buffer = ares::Memory::FixedAllocator::get().tryAcquire(64_MiB);
|
||||
memory::jitprotect(false);
|
||||
recompiler.allocator.resize(64_MiB, bump_allocator::executable | bump_allocator::zero_fill, buffer);
|
||||
memory::jitprotect(true);
|
||||
if(!reset) {
|
||||
auto buffer = ares::Memory::FixedAllocator::get().tryAcquire(64_MiB);
|
||||
memory::jitprotect(false);
|
||||
recompiler.allocator.resize(64_MiB, bump_allocator::executable | bump_allocator::zero_fill, buffer);
|
||||
memory::jitprotect(true);
|
||||
}
|
||||
recompiler.reset();
|
||||
}
|
||||
}
|
||||
|
|
|
@ -44,7 +44,7 @@ auto M32X::save() -> void {
|
|||
|
||||
auto M32X::power(bool reset) -> void {
|
||||
if constexpr(SH2::Accuracy::Recompiler) {
|
||||
ares::Memory::FixedAllocator::get().release();
|
||||
if(!reset) ares::Memory::FixedAllocator::get().release();
|
||||
}
|
||||
sdram.fill(0);
|
||||
shm.power(reset);
|
||||
|
|
読み込み中…
新しいイシューから参照