17 Oct
2003
17 Oct
'03
5:23 a.m.
From: "Jim Battle"
<frustum(a)pacbell.net>
Dwight K. Elvey wrote:
...
Hi
I should have mentioned the issues with instruction caches
and pipelines. After all, our K8 is heavy into this. I was
thinking more in terms of small micros or even in the case
where there is a well defined cache that can be used to advantage.
Anytime one does something out of the ordinary, one needs
to make it clear all of the restrictions and such of how
it is to be used. One of the examples of how a known cache
can be to advantage is like the adsp2100 works. It has a 6
instruction cache so that it can do things like over write
the current instructions in memory for an overlay while
running the loader code from the cache. It does need the
interrupts disabled but this can be handy for something
like a flash update.
Dwight
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.