Why doesn't the 6502 have "sty abs,x" and "stx abs,y"?

[Aaendi]

That's always been a headscratcher for me. They have "ldy abs,x" and "ldx abs,y" so you would think they would have a "sty" and "stx" to go with it but they don't, and the opcode number you would expect these instructions to be, both have illegal opcodes, instead of what you would expect.

[BigEd]

I think the answer is the same for all of this sort of question: such an instruction did not earn its place, in the limited space and limited time available. The 6502 had to be small, had to be adequate, and had to be shipped.

Edit: just conceivably, such an instruction might have been attempted, not quite work, and just quietly not be documented. But I think this is unlikely.

[GARTHWILSON]

I wonder if they figured that if you're going to store it that way, it has probably been manipulated in the accumulator anyway, so you'd do STA instead. The fact that it didn't make it into the '816 set either tells you Bill Mensch didn't think it was worthy of displacing something else in the full op code table—not that he had experience writing kernels or compilers for every possible language, but by that time he would have gotten plenty of feedback from others who did. Many have wondered why the (ZP,X) addressing mode is taking space in the op code table as they suppose nobody uses it. Well, in Forth, we use it constantly, and I suspect other languages do too.

[Dr Jefyll]

Aaendi wrote:

They have "ldy abs,x" and "ldx abs,y" so you would think they would have a "sty" and "stx" to go with it but they don't

I don't find this strange, simply because the loads have such great utility for accessing lookup tables. But perhaps that's not the only reason.

-- Jeff

[Aaendi]

https://www.masswerk.at/nowgobang/2021/ ... al-opcodes

From this article it is speculated that the illegal instructions "SHY abs,x" and "SHX abs,y" were glitched versions of "STY abs,x" and "STX abs,y".

[BigDumbDinosaur]

BigEd wrote:

The 6502 had to be small, had to be adequate, and had to be shipped.

...and it had to be cheap.

GARTHWILSON wrote:

Many have wondered why the (ZP,X) addressing mode is taking space in the op code table as they suppose nobody uses it. Well, in Forth, we use it constantly, and I suspect other languages do too.

The serial I/O (SIO) driver in my POC firmware makes extensive use of (<dp>,X).

As there are four SIO channels to be processed, an array of direct page locations is used to point to channel-specific UART registers and circular queues. A surprisingly-succinct loop in the interrupt handler “converses” with the hardware and relatively trivial foreground code interfaces with the caller. A zero-based index is used to select which channel is to be processed. While it could have been done via other methods, using (<dp>,X) proved to be the most economical in terms of code size and execution speed. Plus it will readily scale as I add more SIO channels.

As I work on my lightweight kernel, I am looking at ways to manage having multiple filesystems being mounted (six maximum per disk). Although I have not gotten to the point where I am able to mount a filesystem, I am starting to see where the use of (<dp>,X) to look up mount table data might be the way to go. This would be an area in which the 816's ability to see direct page anywhere in bank $00 would be invaluable, since there will be a lot of direct page usage.

[BigEd]

Aaendi wrote:

https://www.masswerk.at/nowgobang/2021/6502-illegal-opcodes

From this article it is speculated that the illegal instructions "SHY abs,x" and "SHX abs,y" were glitched versions of "STY abs,x" and "STX abs,y".

Nice find!

BigDumbDinosaur wrote:

BigEd wrote:

The 6502 had to be small, had to be adequate, and had to be shipped.

...and it had to be cheap.

I wrote small on purpose - as you know, the cost of a chip is a function (an exponential function) of the area. There are other elements to cost, though: for example cost of testing, cost of packaging. So we gather, for example, that Atari got a reduced pinout 6502 because the packaging would make it cheaper (and as a side effect this reduced-price offering is also reduced-functionality which is helpful in maintaining a price differential. We also gather that Atari experimented with chip-on-board for the cartridge ROMs, as a cost reduction, but that reliability at that time made it a poor choice. Chip-on-board is now rather common, as is bare-die flip-chip, for the same reasons. (Chip on board has the bond wires running from the die to the PCB pads, and the whole thing covered with a blob of epoxy. Bare-die flip-chip does away with the bond wires and the epoxy.)

I believe I read in one of the oral histories that the testing story for the 6502 was pretty rudimentary at first. The simpler the chip, and the better the yield, the more chance of getting away with that, in terms of field return rates.

And so, a simpler chip is a smaller chip, a cheaper chip, and a chip that's earlier to market. (Oh, and it stands a chance of being lower power and running faster.)

You'll note I use the word cost: it bears a relationship to price, which is the customer's side of the bargain.

[Martin_H]

Interesting question. I suppose as others have said it was part of the cost reduction zeitgeist.

From a utility POV I find myself loading x and y, but almost never storing them. Their contents are pretty disposable to me. When I need to save them it's usually on the stack in a subroutine call where I don't want to mess up the state of the calling routine.

Given zero page indirect addressing I've sometimes wondered if you could write 6502 assembly without using X and Y at all. It would be a lot less efficient, but it could probably be done. It might be the basis of a coding challenge.

[BigEd]

I think you can get away with surprisingly little - hence the Turing tarpit, and the one-instruction computers, and various esoteric languages. So, once a CPU design proposal has the very basics, everything else is an improvement - for performance or density or both. And the improving at some point stops, because time is out, or the transistor budget is spent.

I do agree, a mini-challenge in some restricted subset could be very interesting!

[GARTHWILSON]

Martin_H wrote:

Given zero page indirect addressing I've sometimes wondered if you could write 6502 assembly without using X and Y at all. It would be a lot less efficient, but it could probably be done. It might be the basis of a coding challenge.

That's an interesting idea too. The PIC16 has no indexing, and in fact even indirection takes place through an indirect register which you have to load before using, and you use W (the working register, like the 6502's accumulator) to load it. That's for data access. Computed GOTOs and CALLs (like JMP and JSR) are quite a lot messier. It's inefficient, but it shows it can be done. Writing 6502 assembly language without referring to X and Y could be done, and the mess could be hidden inside macros so you don't have to look at the innards every time you use them. Self-modifying code becomes interesting again, as does the whole field of synthesizing instructions the processor doesn't have. I show some of the 65816's stack-related instructions synthesized on the '02 at http://wilsonminesco.com/stacks/816newinst.html . Another topic and article on synthesizing instructions would be interesting.

[BruceRMcF]

Aaendi wrote:

That's always been a headscratcher for me. They have "ldy abs,x" and "ldx abs,y" so you would think they would have a "sty" and "stx" to go with it but they don't, and the opcode number you would expect these instructions to be, both have illegal opcodes, instead of what you would expect.

Note that the "illegal opcodes" are just whatever accidentally happens ... they are not really "illegal", but more precisely unintentional opcodes ... the opcode execution is designed to execute the designed operations, and in the original design, no transistors were added to do the job of regulating what happened when some other code was encountered where an opcode belonged. It was just a side-effect of how the circuitry designed to execute the intended opcodes happened to act when an unintended opcode was encountered.

So in the NMOS 6502, if they were not attempting to implement an operation, of COURSE there would be an "illegal opcode" where you would "expect" that operation to be, unless they elected to use that opcode for some OTHER operation.

AFAIU, by the time of the design of the 65C02, with transistors relatively cheaper and with an intention to extend the instruction set, they went to the trouble of making all unintended opcodes into co-ops.

[Aaendi]

BruceRMcF wrote:

Aaendi wrote:

That's always been a headscratcher for me. They have "ldy abs,x" and "ldx abs,y" so you would think they would have a "sty" and "stx" to go with it but they don't, and the opcode number you would expect these instructions to be, both have illegal opcodes, instead of what you would expect.

Note that the "illegal opcodes" are just whatever accidentally happens ... they are not really "illegal", but more precisely unintentional opcodes ... the opcode execution is designed to execute the designed operations, and in the original design, no transistors were added to do the job of regulating what happened when some other code was encountered where an opcode belonged. It was just a side-effect of how the circuitry designed to execute the intended opcodes happened to act when an unintended opcode was encountered.

So in the NMOS 6502, if they were not attempting to implement an operation, of COURSE there would be an "illegal opcode" where you would "expect" that operation to be, unless they elected to use that opcode for some OTHER operation.

AFAIU, by the time of the design of the 65C02, with transistors relatively cheaper and with an intention to extend the instruction set, they went to the trouble of making all unintended opcodes into co-ops.

Later CPUs like ARM were able to reduce transistor count by making there be a pattern to the opcodes. From https://llx.com/Neil/a2/opcodes.html it appears that the 6502 team atleast tried to make there be some kind of a pattern, but later on started diverging from the pattern. The page I linked earlier about illegal opcodes said that the STX abs,y and STY abs,x almost worked, the issue was that the high byte of the absolute address somehow got ANDed with the value being stored.

https://github.com/davidmjc/6502/blob/master/bd.png

Here is diagram I found of the 6502. I wonder if the fact that the accumulator has two output buses, whereas X and Y only have one, has something to do with it. Like they had to do a round about way of doing STX dp,y and STY dp,x that didn't cleanly lead to STX abs,y and STY abs,x working simply by changing the addressing mode.

I just thought of a theory just typing this. Maybe when it's doing STA abs,x and STA dp,x, it normally puts A into the data output register in the first cycle, while bringing X or Y to the ALU input register. To avoid bus conflicts, instead of latching X and Y on the first cycle, they change it to the second cycle of STX dp,y and STY dp,x instead, but since STX abs,y and STY abs,x take 2 cycles to load the address, it has a bus conflict, and the 6502 developers didn't want to spend extra transistors on yet another work around, or giving X and Y an output on the second bus.

[BigEd]

You can learn a lot by running a short program of your choice on the visual6502 model - at least some of the undocumented instructions will do as silicon does. Hoglet looked into this...

Which is to say, you don't need to puzzle out from external behaviour, if you care to look at the internal behaviour.