Daedalus-Lkb v0.07b-Lkb3-to-Lkb4 Patch

posted in Emulator News by outsider on Aug 25th, 2001

Daedalus-Lkb is a modified version written by Lkb, of the Nintendo 64 emulator Daedalus. Here's the following changes: In practice:
  • Speed is improved, noticeably
  • GoldenEye tested and still works Minor changes:
  • Memory regions allocated with VirtualAlloc instead of new (ensures page alignment, automatically zeroes memory and is more efficient for large memory areas)
  • Bounds checking in memory routines now only done if DAEDALUS_RELEASE_BUILD
  • Memory tables and registers declared in a different way to align them on 4096-byte boundaries Major changes:
  • "New" memory address resolution system: instead of indirectly calling functions, it reads a pointer from an additional table and adds the MIPS address. If the result is signed (above 0x80000000, in kernel space) it falls back to the old system, otherwise the address is already computed without any function call and with only 4 instructions except register loading (MOV, SHR, ADD mem, JS)
  • Added another dynarec buffer in the last virtual 64 MBs of the main one - it is used to store code reached by conditional branches that must be predicted as not taken
  • Modified SR_Emit_L?, SR_Emit_S?, ReadAddress, WriteAddress, WriteValue, EPILOGUE and the ESI/ESP caching code to use/generate code for the new memory system Note:
  • I realized that it hasn't been a very smart idea to add "ADDED/MODIFIED by Lkb - GCC support" notices everywhere, so I removed them and this patch assumes they are removed (for i in *.c *.cpp *.h *.inl; do sed -e '/BY Lkb.*GCC support$/d' $i temp-sed; mv -f temp-sed $i; done) - backup first. Problems/Bugs:
  • The SR_Emit_ReadWriteAddress function, that implements dynarec for the new memory system, is really ugly beacuse it outputs directly x86 opcode numbers and takes 10 parameters Possible improvements:
  • Currently, TLB address resolution still goes thru a function call; it would be better to alter the pointer table every time the TLB is changed, so that TLB accesses would have the same performance of ordinary RAM/ROM accesses
  • It might be possible to slightly rearrange instructions in SR_Emit_ReadWriteAddress to improve parallelism
  • Currently a 32-bit displacement is used to jump to infrequently used code: a 8-bit or 16-bit one could be faster but would introduce a lot of design problems Other thoughts:
  • GCC: I have written some code to use GCC to compile dynamically generated C code. However, while it works, it has a lot of compile-time overhead and the speed is similar to the already existing dynarec so I've decided to drop the idea. Get it from the Nintendo 64 Emulators page.