Author Topic: Questions about Self Modifying Code  (Read 5802 times)

0 Members and 1 Guest are viewing this topic.

Offline Yeong

  • Not a bridge
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3739
  • Rating: +278/-12
  • Survivor of Apocalypse
    • View Profile
Questions about Self Modifying Code
« on: October 11, 2011, 06:01:22 pm »
question lists
1: How does it work?
2:How do I use it?
3: Can I see the example(code) of it?
Sig wipe!

Offline shmibs

  • しらす丼
  • Administrator
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2132
  • Rating: +281/-3
  • try to be ok, ok?
    • View Profile
    • shmibbles.me
Re: Questions about Self Modifying Code
« Reply #1 on: October 11, 2011, 06:20:37 pm »
self modifying code is code that writes back over parts of itself during execution so that, when those parts are executed later on, they will do different things, or, when that data is accessed later (such as a high score) it will hold a different result. if you are running a program with asm() then it will always be a permanent change, so if someone wants a clean copy it will need to be obtained elsewhere. if you are running under mirage, the code is copied to a temp program during runtime, but i believe writeback is automatic, so the end result is a permanent change as well, although there will be more garbage collects involved. i'm also fairly certain that doors makes writeback optional, so the self modifying could be used as temporary storage should you run out of free RAM that won't necessarily be copied back later.

i don't know much about exactly how it's used because i've never had to myself, but in axe i believe one easy way to go about it is to use Zeroes() [which was changed to a new name in the latest release, but i don't remember that either] to tack empty bytes onto the end of your code and then write directly to those.

other people will probably be more helpful.

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Questions about Self Modifying Code
« Reply #2 on: October 11, 2011, 06:24:49 pm »
question lists
1: How does it work?
2:How do I use it?
3: Can I see the example(code) of it?

1) Code that modifies itself while it's running is called "Self-modifying code."

2) You modify the code, then you change PC to point to the modified code. However, there are very few situations in which SMC is the only way to write a program. I would highly recommend avoiding it if at all possible, especially if you're working with Axe rather than ASM.

3) Cue calc84...
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline Yeong

  • Not a bridge
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3739
  • Rating: +278/-12
  • Survivor of Apocalypse
    • View Profile
Re: Questions about Self Modifying Code
« Reply #3 on: October 11, 2011, 06:25:58 pm »
What I want to do is write some minigames in axe, store it into appvar, and call it out from another axe program.
Sig wipe!

Offline thepenguin77

  • z80 Assembly Master
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1594
  • Rating: +823/-5
  • The game in my avatar is bit.ly/p0zPWu
    • View Profile
Re: Questions about Self Modifying Code
« Reply #4 on: October 11, 2011, 06:58:35 pm »
Just to clear things up. SMC is purely changing your code on the fly to do things more efficiently. You would typically want to do this in very time sensitive sections that get executed thousands of times per second. (i.e. bullet/enemy collision checks) The general idea is to setup the code with some "fairly constants", like the x/y of the enemy you are going to check against all 50 bullets, so that rather than pulling the x/y coordinates out of memory for all 50 bullets, they are hard coded into the routine.

What does this mean for axe? Unless you know asm very well, and understand Axe to the level that you could compile programs yourself, you should not touch SMC.


Now, what you are trying to do with copying your routines into appvars and using them later will not work in Axe. There are two reasons for this: 1) You can't execute the appVar where it lies because it is probably in the $C000 range and will insta-crash your calculator. 2) Axe code meant to be run at a certain memory address in the calculator and from a certain program. When compiling, Axe has to hard code in locations for it's internal routines (like ClrDraw) so that it can call them without crashing. And not only that, but the actual code itself has to call itself which means it has to be run from a very specific address in memory. If you just copy the back end off an axe program off and store it in an appvar. The only way to make it function would be to copy it back to the exact same spot in the exact same program.

If you copy it back to any other address (any of the other 32,767 addresses) or in any other program (even a recompiled version might not work) the routine is going to crash.


What can you do? Really, your only option for something like this is just to make your minigames into separate axe programs and have your main program call them. Or, you could always just put all the minigames into the same file ;D
« Last Edit: October 11, 2011, 07:00:02 pm by thepenguin77 »
zStart v1.3.013 9-20-2013 
All of my utilities
TI-Connect Help
You can build a statue out of either 1'x1' blocks or 12'x12' blocks. The 1'x1' blocks will take a lot longer, but the final product is worth it.
       -Runer112

Offline shmibs

  • しらす丼
  • Administrator
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2132
  • Rating: +281/-3
  • try to be ok, ok?
    • View Profile
    • shmibbles.me
Re: Questions about Self Modifying Code
« Reply #5 on: October 12, 2011, 01:57:16 am »
wouldn't it be possible to create the program, then use something to copy it over to an appvar and then, during runtime, create a new one full of 0's and copy it over? it seems a bit impractical, but i guess it prevents the user from accidentally running just the subroutine program...

Offline ralphdspam

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 841
  • Rating: +38/-1
  • My name is actually Matt.
    • View Profile
Re: Questions about Self Modifying Code
« Reply #6 on: October 12, 2011, 02:07:09 am »
wouldn't it be possible to create the program, then use something to copy it over to an appvar and then, during runtime, create a new one full of 0's and copy it over? it seems a bit impractical, but i guess it prevents the user from accidentally running just the subroutine program...
It would be hard to do because some of the z80's commands use absolute addressing.  The appvar has a dynamic address, allowing for multiple appvars.  Simply put, Axe code from an appvar would jump to weird places in memory.

In all practicality, it is near impossible in Axe, and probably will always be. 

What can you do? Really, your only option for something like this is just to make your minigames into separate axe programs and have your main program call them. Or, you could always just put all the minigames into the same file ;D
I couldn't word it better.  :)
ld a, 0
ld a, a

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Questions about Self Modifying Code
« Reply #7 on: October 12, 2011, 02:16:51 am »
If the program that is turning the appvar into a program is an application, this gets incredibly easier, and in fact might just be a BCALL or two away.  I do not remember the specifics, but you should be able to run programs from an application no problem.

Offline ralphdspam

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 841
  • Rating: +38/-1
  • My name is actually Matt.
    • View Profile
Re: Questions about Self Modifying Code
« Reply #8 on: October 12, 2011, 02:21:06 am »
If the program that is turning the appvar into a program is an application, this gets incredibly easier, and in fact might just be a BCALL or two away.  I do not remember the specifics, but you should be able to run programs from an application no problem.
Oh, that's true.  I didn't realize that.  All you have to do is copy the appvar into $9d95 and change the page in $4000 to the system bcall page.  Then again, if you have an app's worth of memory, you might as well put all of the minigames into that app.
« Last Edit: October 12, 2011, 02:21:30 am by ralphdspam »
ld a, 0
ld a, a

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Questions about Self Modifying Code
« Reply #9 on: October 12, 2011, 02:22:12 am »
Well for this topic I'm assuming an unlimited number of archived minigames :P

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Questions about Self Modifying Code
« Reply #10 on: October 12, 2011, 02:33:40 am »
Self modifying code for the purpose of speed optimization is not practical in Axe because by definition, you are modifying at the instruction level.  Since Axe does not deal with assembly instructions directly in its syntax, you would have no idea what instructions to change.  Instead what you want is self modifying code at the language level.

Suppose you have some long complicated routines:
Code: [Select]
:A+(B*C)-D->E

Lets say sometimes, you need to use * between B and C and other times you need a + and other times you need a - and occasionally you need a /.  So instead of writing 4 routines with an if statement to pick between them, you would like to self modify the code so you avoid if statements all together for "faster" code. (May or may not actually be faster in Axe) But from a high level programming point of view, you can imagine that modifying the code directly avoids having to make an extra check against one or more if statements.

The good news is that you actually CAN do this.  This is what lambdas were meant for and why they're so powerful.  The code can be written like this instead:
Code: [Select]
:A+(Z)(B,C)-D->E

:λ(r1*r2)->Z
:λ(r1+r2)->Z
:λ(r1-r2)->Z
:λ(r1/r2)->Z

Using any of the lambdas once modifies the code so that all future calls to the big routine will use the new operation until you set it something else.  You can use the same method for even more complicated things:

Code: [Select]
:(Z)(5,6,Pic1)

:LOr->Z
:LXor->Z
:LOff->Z

:Lbl Or
:Pt-On(r1,r2,r3)
:Return
:Lbl LXor
:Pt-Change(r1,r2,r3)
:Return
:Lbl LOff
:Pt-Off(r1,r2,r3)
:Return

So yes there is a way to sort of do self modifying code in Axe, but other than making it easier to code, it doesn't really optimize anything since SMC optimizations can really only come from the instruction level.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Questions about Self Modifying Code
« Reply #11 on: October 12, 2011, 03:07:13 am »
Quigibo, thanks for explaining Lambdas to me. I can really see how they might be used now.

Anyway, yeongJIN_COOL, while the others are right, I do remember wanting to learn SMC for myself. I still maintain that you don't need it for your current project. There's very little good information available on it because it's such a difficult/specialized technique*. The basic situation where SMC is used is those cases where you have code that is largely repetitive. It occasionally turns out that it's actually more efficient to write new code in where the old code differs than to use two different blocks of code. The whole thing hinges on the fact that code and data are exactly the same thing at the machine level. When you write to memory, you're potentially writing valid code, even if it will never be executed.

The basic cycle of SMC is

1: Execute
2: Write new code to the existing code in (1)
3: Goto (1)

Now, SMC is very dangerous because if you set a single bit in the code improperly, you may cause a complete program crash and also because it can be very difficult to follow the flow of a self modifying program, leading to bugs if you're not careful.

Basically, avoid SMC like the plague unless there's some problem that cannot be reasonably solved without it or you have near-complete access to/understanding of the assembly level source. When you have to use it, spend a lot of time making sure that the SMC is *absolutely* correct before writing anything else. Bad SMC can have some incredibly strange behavior.

* I spent quite awhile on Google reading comments about how "you shouldn't use SMC" before I gave up and asked Calc84. Now I use it in Khavi to solve the difficult problem of not knowing where in memory the interpreter threads will be located at any time before runtime. Windows uses a very similar method to get programs to run at places in memory that they weren't compiled to run at.
« Last Edit: October 12, 2011, 03:10:53 am by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ