Re: 6502 illegal opcodes questions

["Michael J. Mahon" <mjmahon@aol.com>]

John Selck wrote:
> Stephen Harris wrote:
>
> > And now you've introduced program bloat, dual code paths, extra 
> > potential for
> > bugs...
>
>
> That's the way you handle low level stuff. All your Windows XP drivers 
> are doing the same, and all the games which support SSE or MMX 
> instructions.

This works only when the behavior of all versions are known, and they
can be differentiated by software tests.

Since it is difficult to predict which undocumented behavior(s) would
be present in a future chip, it cannot, in general, allow for future
chips, except in the special case where the "test" encompasses *exactly*
the behavior that the exploiting code uses (no more, no less).

> Doing it the "one routine works for every condition" way usually means 
> 10 times slower programs.

Oh, come now--even the wildest example given (just the inner loop) was
less than a factor of 2 different.  The vast majority of uses of such
undocumented "features" have negligible effects on any important
measure--they are just hacks, in the worst sense.

Modern programming practice does allow for code (and even algorithms)
tailored to specific processor levels, but only when there is a method
for differentiating implementations that is architectural, and therefore
sanctioned by the manufacturer(s).  Of course, most compilers don't
offer support for this, except in some embedded environments.

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."