[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6502 illegal opcodes questions
John Selck wrote:
Michael J. Mahon wrote:
John Selck wrote:
Huh? They did move forward. 6510 -> 8500 -> 8502. And also, I don't
think it's any kind of problem for Commodore to use customized CPUs
since they owned MOS, the owners and producers of 6502 tech back then :)
And these new processors preserved the undefined opcode behavior?
If so, they are almost certainly *not* new processor designs.
Same opcodes but faster clockspeed. Also, CBM switched from NMOS to HMOS.
So this was an algorithmic rework of the original design for a new
process, not a new logical design.
3) Slow-as-hell 8 Bit platforms don't have a proper abstraction layer
for any of their hardware, no matter if sound, graphics, timers,
ports or CPU.
Nonsense. The "abstraction" we are discussing is the published
documentation for the processor/system. What it documents is the
abstraction that future implementations will preserve. What it
doesn't document will generally not be preserved.
What about the bugs in the decimal mode? They were fixed on later
processor designs, this also renders the CPUs incompatible for some
programs.
Processor bugs (or "errata") are cases where the implementation does not
behave as the documentation says that it should. The decimal bugs in
the original 6502 were not part of its documentation, and therefore
should not be depended upon. (Of course, in the presence of the bug,
code cannot depend on the documented *correct* behavior either; it must
be written to "work around" the bug without depending on undocumented
behavior.)
Errata are always a special case. The designers always hope that code
that runs correctly on the original, buggy processor will still run
correctly on a fixed processor. In other words, they hope that no
one has written code that *depends* on buggy behavior.
To summarize, code written to the specifications of a processor will
work correctly on all implementations, *except* where an implementation
is faulty. Code written to work around a fault can still be written
to the specifications, but avoiding the faulty case(s).
On the other hand, code written to *require* faulty behavior to run does
not conform to the specification, and may not run correctly on a later
implementation of the processor.
Compatibility is always with the specification--not with undocumented
and possibly faulty behavior exhibited by a particular implementation.
Such a specification describes the abstraction known as the processor
"instruction set architecture" (ISA).
-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."