self modified code in Assembler

ganeshptrk · New User Joined: 04 Apr 2007 Posts: 17 Location: Chennai

Can anyone tell me what is "Self-Modified" code in Assembler. this was one of the interview questions.

Thanks
Ganesh

Phrzby Phil · Posted: Fri Jul 06, 2007 5:27 pm

Since an assembler program has access to all of its memory, it can change the value of instructions as well as data. While there might be very special reasons for doing so in extreme cases, the executed program at this point will not match the original program, so tracing, debugging, etc., will be seriously compromised.

Anyone got a good example of when this is a good technique?

ganeshptrk · New User Joined: 04 Apr 2007 Posts: 17 Location: Chennai

Can you give me an example instruction for this please...?

Cheers
Ganesh

dick scherrer · Posted: Sun Jul 08, 2007 6:18 am

Hello,

There is no particular single instruction - the 2 "straight" instructions i've seen the most used to self-modify code is a MVI or an MVC (Move Immediate or Move Character).

Another is building an instruction to EXecute on the fly.

What typically happens is that the programmer creates an instruction on the fly, modifies one or more parameter(s) of an instruction, or forces an ungraceful abend at some point where they wanted an abend. The last case is very seldom used anymore (from what i see these days) - the debugging tools are such that this is not as handy as it once might have been.

Another technique that was used due to limited memory was to "set aside" a bit of memory called transient areas. Code that was not even in the main assembly/link would be brought in at run time as needed. This way the total executable size was reduced and the dozens or hundreds of transient modules were run from the transient areas.

Phil - one place i was, this was often used for a first-time switch. The code was such that the first time thru, the code modified itself to branch the one-time logic.

There was also code that set bits whose content wasn't known at assembly time, so the actual instruction was created and EX'ed at run-time.

With nearly unlimited memory and better programming practices, i'd recommend against self-modifying code as a practice (execpt where it really does make sense).

One of the worst times i ever had was trying to figure out what was going on in a program that modified branches all over the place. When i asked how the code got that way (it did not look like it was designed, but just kinda happened), i was told that the author had the habit of forcing the code to go where he wanted it when there were problems rather than fixing the problems. The author no longer worked there and there were several of his time-bombs that had to be dealt with.

Microchip · Posted: Wed Mar 05, 2008 1:57 am

I can think of only ONE good, and acceptable use of self-modifying code: a first-time thru process.

MAINLINE EQU *
NOP NOT1st Do following only first time thru
MVI *-3,X'F0' Turn on the above NOP
WTO ' Hello, world! I am here!'
Not1st EQU *

Bill O'Boyle · Posted: Sun Mar 09, 2008 12:04 am

What Dick has said is very true and I've experienced this in many of the systems which I've maintained.

Manually inserting the length of Operand-1 into the next instruction, such as an MVC, CLC and/or an XC will someday, rear its ugly head, leaving the poor slob who has to fix the problem, scratching their own (been there, done that, got the tee shirt).

To reemphasize, an EX should ALWAYS be used to do this and many times when it's not, I find it was either the lifting of previously written bad code, a matter of convenience or just outright laziness on the part of the programmer.

So, DON'T MODIFY INSTRUCTIONS, UNLESS YOU USE APPROVED AND DOCUMENTED METHODS!

OK, I'm done....

Regards,

Bill