Omnimaga
Calculator Community => Other Calculators => Topic started by: calcdude84se on June 11, 2010, 01:58:45 pm
-
I was just curious. How often do you use SMC (self-modifying code) in your ASM programs?
Feel free to list why or how you use it too.
-
I use it quite often in my graphics routines. Sometimes I just modify immediate values, other times I will modify the actual instructions being executed (for example, rotating A by any amount can be done in 4 instructions or less). Other than graphics, I don't use much SMC because most of my major projects are now APPs.
-
I don't program in Asm enough to use it (so I'm not voting yet), but I think I'd use it often when I need speed. :D
-
Yeah, SMC is mainly for speed gains impossible with normal techniques. It is also useful as a tool to prevent people from understanding your programs. :P
Also for forcing instructions to have more options than normal (bit, set, and res, for example)
-
It can also be useful if you want to keep your game in one file, even when using save/load options built in the game
-
It can also be useful if you want to keep your game in one file, even when using save/load options built in the game
Though, that's not really self-modifying code, it's modifying data.
-
Yeah true, just saying, though as it still involves modifying the program file.
-
Mmm i like programs that use SMC for highscores ^^ It makes the appvar space less cluttered :P
-
^++
-
My main worry about appvars is that we're more prone to accidentally delete it or lose it in a RAM clear, and I'm not too fond of the idea of archving my appvars everytime I exit my game, especially if the appvar is very large
-
That makes sense, especially if it is large. Obstacle Snake will automatically archive the appvar if it was archived when it was opened. However, SMC is nice because most gamers archive their games to begin with and you don't have to worry about it getting screwed up (with a couple exceptions).
-
Hey, the results kind of look like a bell curve. :P
Not surprising, at any rate.
Yeah, when I said SMC, I wasn't referring to saving data w/in the program itself. The only thing I don't like about that technique (it is, for the most part, good, like others have said) is that I have to have write-back for archived programs turned on. (I try not to use my archive too much, but the programmers are against me! :P)
-
yeah that can be annoying with all Garbage Collections, especially if you got an old 83+ x.x
-
I will only start using SMC when I need speed.
Not using SMC keeps compatibility with APPS and is much more reusable code for other projects (like OSes or other APPS).
I see some confusion between SMC (Self Modifying Code) and write-back on Omnimaga forums. Not only on this topic. I will try to differentiate them.
SMC is when code will simply modify some other code.
Only possible when the code is in RAM so it is easily changed like normal data. The modified code is temporary. (true for 99% of cases) So very rarely if ever SMC needs write-back for the program to work as expected.
Write-back is writing the "copy" back to the "original" program.
This happens because the assembly programs you run is not the original but a copy in a address equated as userMem (address $9D95). For example, in the end of the program data resides the save game data. In order to the program work as expected and your precious progress be kept you need some additional code (it finds out the position of the original program and copies the data back to it) or a shell with write-back option that does the job for the coder.
Note that SMC and write-back are independent. But generally data needs write-back and SMC do not.
If I made a mistake or was not clear, please point out, no one is perfect.
EDIT: bonus example
Mmm i like programs that use SMC for highscores ^^ It makes the appvar space less cluttered :P
It is correctly write-back and not self modifying code. You are modifying some data of a highscore, not code and you need that is copied back to the original program.
(curiously you can hard code high score data into code but is very rare and not the best way to store this kind of data)
EDIT: Oh, but if you are talking about Axe Parser, it is possible you are using both SMC and write-back.
-
I occasionally use it. Sometimes, its for speed considerations, sometimes for size, other times for simplicity. Its not too difficult to copy small code segments from apps into ram and then execute them there so compatibility is usually not an issue. One smc I really like to use is modifying (ix+0) and change the 0 to other values to really quickly read and write to the nth element of a list without using any extra registers. I did this in Pyoro for the "closest block" algorithm.
-
Thanks for the clarification Galandros! :D
userMem (address $95D5 if memory serves well).
It's $9D95. :)
-
I will only start using SMC when I need speed.
Not using SMC keeps compatibility with APPS and is much more reusable code for other projects (like OSes or other APPS).
I see some confusion between SMC (Self Modifying Code) and write-back on Omnimaga forums. Not only on this topic. I will try to differentiate them.
SMC is when code will simply modify some other code.
Only possible when the code is in RAM so it is easily changed like normal data. The modified code is temporary. (true for 99% of cases) So very rarely if ever SMC needs write-back for the program to work as expected.
Write-back is writing the "copy" back to the "original" program.
This happens because the assembly programs you run is not the original but a copy in a address equated as userMem (address $95D5 if memory serves well). For example, in the end of the program data resides the save game data. In order to the program work as expected and your precious progress be kept you need some additional code (it finds out the position of the original program and copies the data back to it) or a shell with write-back option that does the job for the coder.
Note that SMC and write-back are independent. But generally data needs write-back and SMC do not.
If I made a mistake or was not clear, please point out, no one is perfect.
EDIT: bonus example
Mmm i like programs that use SMC for highscores ^^ It makes the appvar space less cluttered :P
It is correctly write-back and not self modifying code. You are modifying some data of a highscore, not code and you need that is copied back to the original program.
(curiously you can hard code high score data into code but is very rare and not the best way to store this kind of data)
EDIT: Oh, but if you are talking about Axe Parser, it is possible you are using both SMC and write-back.
aAH thanks for the carification Galandros ^^
-
I very rarely use SMC, because it spoils readability. If I can get a decent speed, memory or code elegance advantage, I consider using it, but even then I write it in 'normal code ' first, for the sake of debugging.
-
Thanks for the clarification Galandros! :D
userMem (address $95D5 if memory serves well).
It's $9D95. :)
aAH thanks for the carification Galandros ^^
Edited the post. I was doing from memory and I did not have the time to check it.
Thank you both. It is good to know that it was clarifying. ^^ I hope BuilderBoy got it, too.
Maybe we can link the post for other time or even make a topic with only it, if it is needed.
I occasionally use it. Sometimes, its for speed considerations, sometimes for size, other times for simplicity. Its not too difficult to copy small code segments from apps into ram and then execute them there so compatibility is usually not an issue. One smc I really like to use is modifying (ix+0) and change the 0 to other values to really quickly read and write to the nth element of a list without using any extra registers. I did this in Pyoro for the "closest block" algorithm.
That is a use I haven't seen often for SMC. And is really useful.
I documented quite some examples SMC here: http://wikiti.brandonw.net/index.php?title=Z80_Optimization#Self_Modifying_Code
I will add that one too.
-
Quigibo, I must have missed that example. Changing the offset is a really cool idea. Nice job! ;D
-
Yeah, I use the (ix+nn) trick sometimes in my variable-height masked sprite routines
-
Yeah, I use the (ix+nn) trick sometimes in my variable-height masked sprite routines
Yeah, that is the smaller and faster way in size to have in count the variable height.
Not using SMC in this case is much harder to code.