[quake3-bugzilla] [Bug 4977] x86 qvm improvements
bugzilla-daemon at icculus.org
bugzilla-daemon at icculus.org
Tue May 10 05:49:46 EDT 2011
https://bugzilla.icculus.org/show_bug.cgi?id=4977
--- Comment #12 from Thilo Schulz <arny at ats.s.bawue.de> 2011-05-10 05:49:43 EDT ---
(In reply to comment #11)
> As I can see stack pointer can be modified even often than actual data
> reads/writes so its better to put checks for load/store/arg instructions IMO
Look at my code in vm_x86_64.c that I added to revision 1969, specifically the
macros STACK_PUSH() and STACK_POP() and OPSTACKCHECK()
The opStack is modified every time you execute push, pop, etc.
And every time the opStack is pushed/popped we need to check whether the stack
pointer (edi in your case) is still pointing to an address inside the VM.
Here's a VM that writes to memory locations where it shouldn't:
code
CNSTP4 805306368
CNSTP4 0
JUMPV
make it into a QVM with:
$ q3asm -o ui.qvm segfault.asm
Copy ui.qvm to baseq3/vm/
and segfault
> Also found that optimizer is very sensible to jused[] array - my fixed version
> already rejected few load/store const-optimizations (because of jump labels)
> that was possible with untouched code
Does this new patch fix these issues, and can we expect old mods will still
work with your code?
> So I'm thinking - maybe its better to disable optimizations completely for
> vq3-qvms? VM_MAGIC_VER2 sure fixing that issue but it
If you want to do that, then what's the point of your patches?
> - modern CPUs is fast enough to handle that :)
Yes, there's not much effect on framerate, because the heavy-duty stuff happens
in the renderer, not the gamecode. Even with the additional checks every time
the opStack is increased/decreased there's hardly any impact on the FPS for the
vm_x86_64.c
--
Configure bugmail: https://bugzilla.icculus.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the quake3-bugzilla
mailing list