Well, no you don't. That's purely a design decision, and I would consider it one of the brilliant innovations in the 6502 that it doesn't save the entire register file when responding to an interrupt.

Apparently I'm not alone in this; the designers of the 6809 liked the idea enough that they added a second maskable interrupt, FIRQ, that worked in the same way.

_________________
Curt J. Sampson - github.com/0cjs

Indeed, its such a good idea that ARM and x86 behave essentially the same way: they save (via one method or another) only those registers that must be saved, and leave the ISR itself to save any others that it needs to use. Of course, in practice, you'll need to save at least one or two general purpose registers or your ISR is unlikely to be able to do anything useful (in the case of 6502, I would say at least the accumulator and one index register), but you as the programmer get to decide what resources you need and what the trade-off is versus the required interrupt servicing delay. For example, I doubt that any ARM ISR actually saves all 14 general purpose registers since for the types of jobs you should be doing in an ISR that would be pointless: I've seen entire ARM software packages that never touch some of the registers at all, let alone in an ISR, because there just aren't that many variables that need to be loaded into the CPU at any given moment. Now that I think about it, if you have some spare registers that you're not otherwise using, that'd be a really good way to speed up your ISR: just have it use those registers that the rest of the software doesn't use, that way you never have to worry about saving and restoring them at all (unless you need the ISR to be re-entrant).

All that being said, in the specific case of the 6502 architecture I feel like it would be nice if the interrupt process saved and restored the accumulator for you because there is essentially no way of doing anything useful without it and it would save a couple of cycles per interrupt. I vaguely remember reading somewhere that it was originally intended that it would but the necessary circuitry wouldn't fit or some such.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Yup -- I had an MSP430 project that worked that way. Honestly, it was so easy it felt a little creepy... The failure to save/restore any reg's left me feeling as if I'd broken the rules!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Actually, the NMOS 6502 does have number of instructions that neither read nor change registers. These include INC/DEC in direct or extended address modes (oops...I think I mean "zero page" and "absolute" there—too much 6800 on my brain at the moment), and shift instructions on memory locations (which affect the flags, but those are automatically saved and restored). So with some careful hardware design you could probably do at least checks of what needs to be done during the interrupt without needing to save any registers.

And of course the Rockwell 65C02 adds SMB/RMB/BBR bit manipulation and test instructions that extend one's abilities to do the above kind of stuff.

_________________
Curt J. Sampson - github.com/0cjs

I have been playing with my toy Pascal compilers. This is some of the generated code...

For the 6502:



For the 8080:



And for the 6800:



There is no optimization at this time other than some simple things which can be done while parsing.

Obvious opportunities for



are



for the 6800

and



for the 8080.

Would a 32 bit evolution of 65816 stay accumulator based?

In one sense, that question has already been answered by the 65832, and the answer was "yes". You could take the fate of that design as an indication that this was the wrong answer. The industry as a whole as taken a totally different route, and for good reasons. A respectable number of general purpose registers is pretty much essential if you want to make a competitive processor for desktop computers at any point past the early 1980s.

Would an evolution of the 6502 with a respectable number of general purpose registers still be a '6502'? That depends on what you think the essence of the 6502 is. If the essential factor is the ability to run 6502 binaries without modification (or without too much), then yes. If you want it to still feel like a 6502 in some vague way that gives us oldies all the nostalgia, then probably no.

My (very slowly progressing) 65020 project is almost binary compatible; I think there was only one change I needed to get Microsoft BASIC running. It has 12 almost but not quite general purpose registers. And it does not feel like a 6502. Part of that is deliberate - I wanted something that could have been an alternative to the 68000, and although still losing, still put up a decent fight against the ARM. Compatibility has forced a few quirks, but on the whole it feels like the awkward younger sibling of the ARM, MIPS and PowerPC.

Hmmm, intriguing! I'll be interested to hear more about this project, whenever you feel ready. Among other challenges, you have the question of instruction encoding. The fact you're addressing more registers while preserving (almost) binary compatibility makes me suspect you're using prefix bytes... but I could be wrong; other solutions exist.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I've given each byte an extra 8 bits that the 6502 didn't know about, and arranged the instruction set so that if these new bits are all 0 it behaves like a 6502. So it sort of is using prefix bytes, only everything, including operands, gets them. Some of the extra bits are used to select different registers (there are 4 of each of A, X, and Y). Two of them control the data width (8, 16 or 32 bit operations). One is used to choose a variant of the instruction: ADC becomes ADD without carry. Two byte addresses, which the 6502 thought were only 16 bit, now have 32 bits.

There's an old and not very good description at http://c640.blogspot.com/2018/06/the-65020.html, and some example code at http://c640.blogspot.com/2018/07/some-65020-code.html. I'm currently working on the user manual for the processor, so maybe you'll get to see a better description sometime this year. I should be working on a testbed for the ALU, but motivation for VHDL coding is very hard to find.

If we move the ZP to registers - http://anycpu.org/forum/viewtopic.php?f ... 5890#p5833 - we can get only 2 cycles which matches timings of the best processors.

_________________
my blog about processors