From Lambda the Ultimate blog: http://www.uni-koblenz.de/~laemmel/expression/

Yeah, I take it in steps as well. I usually write out the code in unoptimized easy to understand version, then rewrite it from scratch for self modifying version. The emu debugger I use is great though and very accurate.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Coming from AVR, it's almost ironic to call it "Self Modifying Code" at all. I see the 6502 as being a processor with 256 fast registers and 65280 slow registers!
Code, or data... it doesn't matter. It's just 64K that can be used to accomplish a given task.

On the AVR, writing to the Program Memory does have its consequences, since you are dealing with Flash. Slow write times, wear leveling, etc.

I am just a 6502 newb, but in my fresh opinion, "Self Modifying Code" makes absolute sense when you consider how much optimization it offers - both speed and code size. Is it more complex?... garbage in, garbage out!

Brad

Most of the code I write is intended for ROM so self modifying code is not really applicable but I have used it a few times.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

When I was first working with 6502 assembly, I didn't know any better, so, I wondered why anyone would bother using STA ($00),y unless the code was in ROM. I always used STA $0000 and changed the operand bytes to my destination location.

As a matter of principal, I just don't do that anymore.

Once in a while, I think about using it to effectively JSR indirect, but, I never actually end up doing it.

One place where I used self-modifying code extensively was in a graphics library for the PC. Rather than have a conditional to determine the raster op, I had the code hardcoding the raster op using self modification. It sped up the graphics enormously (by eliminating all the branches).

_________________
http://www.finitron.ca

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I've been guilty of using self-modifying code over the years, but am always mindful of the potential booby traps such code can bring. Indeed, modifying an absolute address so as to avoid the time penalty of indirect access is an excellent way to speed up video access. The 65C816 in native mode lessens the value of such a tactic, however, since one can cover a 64K address space with a 16 bit index using something like LDA $00,X.

In the UNIX environment, self-modifying code is not allowed, although it was at one time. An attempt to write into the code segment of a running process causes a memory access violation, followed by a core dump and forced termination of the process.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Self-modification can speed up dispatch points, and I don't think that's a problem.

I also have some round-robin code in one of my projects. Each routine gets a pass per frame or per interrupt, depending on whatever's active. The first instruction of the routine is "BIT nextRoutine" when enabled, which gets self-modded to "JMP nextRoutine" when disabled. I do similar in interrupting AcheronVM. Rerouting flow of control is really low overhead this way, as no checks are involved in the standard case. Changing a single instruction opcode costs exactly the same as setting a variable/flag to a particular value.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Why wouldn't you use a macro that takes parameters instead of self modifying code? It is much cleaner and safer.

A macro is an assembly-time function. Self-modifying code is a run-time function.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I've used loads of self-modifying code in my time, the target platform being the BBC Micro, running code out of RAM.

One example was a sprite routine which ran in the zero page which self-modified plenty of its own operands (the self-modified address being in zp as well, saving another cycle). Here's a snippet of the innermost bit of the loop:


That reads sprite data (from (read+1)), looks up a mask for it in a pre-prepared table, masks the screen background, ORs the data over the masked screen data, and writes it back. I figure that the self-modification there saves 4 cycles per byte, which for this particular game saved up to 4900 cycles per frame from just that, plus other more modest savings elsewhere - not bad!

I also remember using them to self-modify the branch destination when entering an IRQ service routine, so that consecutive timer interrupts would go to different places in the code without needing to explicitly check it.

That inner loop looks pretty intense, Rich! A self-modifying ISR is a cool idea as well, as long as you stay on top of things and don't get out of sync.

Mike B.