[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6502 illegal opcodes questions
Rainer Buchty wrote:
In article <d4CdnR_y__CUmfXZnZ2dnUVZ_s-dnZ2d@comcast.com>,
"Michael J. Mahon" <mjmahon@aol.com> writes:
|> True, but the decoding in the 6502 is handled by a kind of PLA, so
|> it would likely not be very expensive (in real estate) to trap or
|> NOP the invalid combinations.
You are too today-centric.
Back in the 1970s even that "likely not very expensive" decision raised
the costs significantly and introduced complexity to the chip which was
unnecessary from a technical and marketing point of view.
|> If I had been designing the 6502,
|> I likely would have made the same choice.
Probably everyone would have. Leaving out the illegal opcode traps or
mapping them to NOP did no harm, implementing them would just raise
costs.
|> (But as a coder, I would have regarded undefined ops as a curiosity,
|> not as an opportunity to save a few cycles at the expense of future
|> utility.)
If a platform stays identical over a long-enough period of time
then why not starting to squeeze the last out of it by using undocumented
behavior. After all, the use of such undocumented behavior in the end
led to enhanced capabilities, even the chip designers didn't envision
in the first place.
I suspect that we don't disagree very much about this. But note that
the 6502 was not such a platform. Being relatively successful, it went
on through multiple generations of implementation, and unintended
behaviors are not, in general, maintained in subsequent implementations.
Although early experimenters could not have predicted the course of the
architecture's evolution, it was still common culture, since the 1950s,
not to "exploit" accidental, and therefore unsupported, "instructions"
that might exist in particular computer implementations. The problems
in maintenance and upgrading that this caused were well known.
Commercial computing recognized the significant advantages of creating
an object code-compatible line of machines, with scalable performance,
by the end of the 1950s, and major computer lines were designed with
this in mind by the early 1960s.
It has often been noted that the microprocessor community apparently
needed to rediscover all the lessons already learned by the mainframe
computer culture, but two decades later. A general presumption that
"things will always be as they are now" is one misconception that it
took people a while to correct.
I'm especially thinking about all the fancy stuff coders did with the
C64's video chip, which like the original 6502 (and the hereon based 6510)
is a hardwired design.
As it turned out, the presumption that these were immutable chips was
correct.
As I stated earlier, if you have good reason to believe that you are
programming for an end-of-the-line system, then you are free to do
anything that works. But I consider this a pessimistic assumption
unless the platform has really fossilized--as the platforms we are
celebrating here have.
And back then noone really thought about future utility. Maybe apart from
the Apple II those machines were pretty much integrated & rather unexpandable
boxes -- even more, in the early homecomputer and video game market there was
no sense for a "family concept" where software from the old machine would just
run on its next generation successor, cause that most likely was an entirely
new box.
Think of Atari 400/800 vs. 600/800XL, Commodore VIC20 vs. C64, Sinclair ZX81
vs. Spectrum just to name a few.
No one is praiseworthy for not thinking about future utility!
It seems hard to imagine now that--almost 20 years after commercial
computers had all moved to scalable, compatible lines to leverage
code investments--the idea that this might be at least as valuable
in the microcomputer marketplace did not influence design decisions.
Until the Mac, all of Apple's computers were designed with application
compatibility with previous machines in mind. Of course, the same has
been true since in the Mac line, and in the entire PC line (after a few
early not-quite-clone dead ends).
I suppose I must fault the undisciplined early coders for participating
in the newest, most radical advance in computing without a real vision
of what success would mean. The lesson was already clear for anyone
who was paying attention. (Note that I have no problem whatever with
someone *using* undocumented features themselves--the problem is when
code that uses such features is released for wider use.)
-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."