16 Oct
2003
16 Oct
'03
5:05 p.m.
Dwight K. Elvey wrote:
...
In any case, I never understood the stigma of using
self
modifying code. It does require careful documentation if
it is expected to be maintained. There is no reason why
it can't be as robust as any other code if done properly.
I suspect it was used as a sales talk when someone was
trying to pitch their version of code to be better than
someone else's. Such things as overlays would qualify as
more risky uses of self modifying code but that is done
without mention.
Obvious drawbacks --
doesn't work if you ROM the code
indeterminate behavior on certain chips that have instruction caches.
the data cache snoops and invalidates the write address, but the
instruction cache doesn't snoop and so requires an explicit flush (eg,
the i860).
even if the icache snoops the write, it can have a performance impact
depending how often the code is modified since it can result in a full
instruction pipe flush.
even without caches, there can be a race between the data being written
and the instruction fetch path. some self modifying code that works
reliably on a 386 may not work on a 486.
in an interrupt driven environment, such code is unlikely to be
reentrant/thread safe/interrupt safe.
it is harder to maintain.
but, I agree, sometimes a coder has to do what a coder has to do.