Why would you want to execute the script opcode by opcode? Sure you can do the same thing with an x86 debugger and native code, but why would you wish for the ability here?
I would think it to be a giant waste to be writing your scripts in the as bytecode and that could be the only reason I came up with to require the need to debug bytecode at a time.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Bring ExecuteStep back :)
I thought he was trying to even out time-step sizes when threading scripts. It's inherently difficult because you can't pause in the middle of application functions. There also seems to be a misunderstanding about the suspend stuff. I thought the compiler stuck them in automatically.
Author
Quote: Original post by Rain Dog
Why would you want to execute the script opcode by opcode? Sure you can do the same thing with an x86 debugger and native code, but why would you wish for the ability here?
I would think it to be a giant waste to be writing your scripts in the as bytecode and that could be the only reason I came up with to require the need to debug bytecode at a time.
I don't need that function for debugging purposes. I want to run script threads concurrently with the ability to preempt one thread by another when the scheduler wants, not when the code allows :)
It actually does not matter, whether an atomic execution unit is opcode or anything else, as far as following conditions are satisfied:
1) execution time of an atomic unit is small enough
2) that time is more or less constant
3) thread can be stopped after executing arbitrary atomic unit
Well, SetLineCallback()/ExecuteStep() almost satisfy those, except for the 3), because thread can be only stopped when SUSPEND occurs in the code, and there can be no SUSPENDs in the code at all.
I think I will customize AS a bit, adding that unsafe ExecuteUnit() function, and define BUILD_WITHOUT_LINE_CUES, so script code will contain no SUSPENDs (and thus will be smaller and faster).
Cheers,
RCL
P.S. ASM VM seems to be broken in current release? At least some assert()s that check for offsets do not compile with USE_AS_VM.
The only reason why there would be no SUSPENDs is if someone tampers with your precompiled bytecode (for example by building a customized compiler with the BUILD_WITHOUT_LINE_CUES). You should make sure to add validations that will tell you if the code was produced by your own compiler and not by someone elses. Assuming that you're going to use precompiled bytecode at all, because if not then it will be very difficult for anyone to remove the SUSPENDs (only by hacking the application).
Yes, the ASM VM is temporarily out of order (as noted in the change log). I'll fix it as I release the final version of the library. In either case you won't be able to use the ASM VM for your ExecuteUnit(), since the ASM VM doesn't return for each bytecode.
Yes, the ASM VM is temporarily out of order (as noted in the change log). I'll fix it as I release the final version of the library. In either case you won't be able to use the ASM VM for your ExecuteUnit(), since the ASM VM doesn't return for each bytecode.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
