[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