The 6502 was a nice processor to program but looking around the alternatives of the time (Z80, 6809 etc) there were a few things I missed. Interestingly the clever double width accumulator of the 6809 or the similar 16 bit registers of Z80 were not one of them. Rather the DJNZ was something I would have liked. Inner loops could never get tight enough so something that decremented X or Y and branched, preferably with a backward bias, in a single instruction was something I wanted. If anyone is about to improve the 6502 instruction set I'd like to hear your view on such end-of-loop instructions.

Steve Wozniak created SWEET16 that I had thought would provide the necessary 16 bit functionality and also a transition to a 16 bit processor. So why was SWEET16 never implemented in hardware? Like the 6502 it was elegant, orthogonal and required no prefix codes. It seems to me like a lost opportunity.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hello, Alienthe! It is an interesting idea. Loops account for a high proportion of the execution time for most programs, so speeding up the critical loops is usually worth the effort -- an optimization almost as reliable as boosting clock speed. Loops can be unrolled, of course, but that's a bit OT. I can certainly see the appeal of a DJNZ equivalent for 6500 family.

One caveat is that it has to be more than just a convenience for producing pretty code. IOW I'd want to be certain there's a bottom line saving in clock cycles. (Did the Z80's DJNZ live up to this?) At 5 cycles, the DEY BNE sequence is already pretty fast, even though not as sexy as a single instruction equivalent. In the spirit of discussion, what would be the costs and benefits of separately optimizing the DEY instruction and the BNE instruction? The overall payoff would be broader...

cheers
Jeff

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

I could've done with a 2 cycle instruction to swap the top and bottom 4 bits of the accumulator (SWap Nybble?). Would've saved on sequences like which could just have become
I guess it would've been a whole new special path in the random control logic, as it's not remotely like any other kind of operation, so I can see why it wasn't there.

SWEET16 was launched as part of Apple II back in 1977, the 65816 was launched late in 1984. These 7 years represent, in my view, a lost opportunity. SWEET16, while not as capable as 65816, would have been simple to implement due to orthogonality and a well structured ISA and instruction code design, as one would indeed expect from the Woz. Moreover the SWEET16 is more "spacious" having more registers, while the 65816 adds no new general purpose registers.


I remember many benchmark discussions back in the day but I never was really sure how the speed really differed.

Collapsing multiple instructions into one, esp. with something like incrementing or decrementing has its caveats. For example Motorola got it wrong in the 68000 where the postincrement/predecrement of index registers was broken when for example a bus error ABORTed the opcode. Collapsing dec/inc and branch should be fine in this respect though.

However, if you start combining INX with BNE, you could also combine INX with BEQ, and INY instead of INX and maybe even a memory location, and other branches.... You quickly clutter your opcode space.

Here is a set of opcodes I defined for my 65002: http://www.6502.org/users/andre/65k/specsprog.html

BLT - Branch Less Than (C=0 or Z=1)
BGT - Branch Greater Than (C=1 and Z=0)
RDL - Rotate Direct Left (rotate without carry, i.e. bit 7 is directly moved to bit 0)
RDR - Rotate Direct Right (rotate without carry)
ASR - arithmetic shift right (shift in the sign from the left)
SWP - swap upper and lower nibble
INV - two's complement
BCN - bit count, compute number of 1-bits
SXY - swap X and Y
PSH - push all registers (in a 6502 that would be AC, XR, YR, more in a 65002)
PLL - pull all registers (in a 6502 that would be AC, XR, YR, more in a 65002)
FIL - fill a memory area with a byte value
ADS - add value to stack pointer
SBS - substract value from stack pointer
MVN/MVP - move a memory area (see 65816)
HBS - determine bit number of highest bit that is set (like log2)
HBC - determine bit number of highest bit that is clear
BSW - bit swap - exchange bit 7 with bit 0, bit 6 with bit 1, etc

(Not all of them are already on the web page though).
INX/INY can be done in a single cycle in the 65002, so there is not much penalty of not combining them.

André

Edit: added ASR which I had forgot

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I've got some notes on Z80 vs 6502 which I wanted to put into some order for a coherent post about what happened with chess machines... But here are some raw clippings:

The fridge (Judd) reckons a roughly 3:1 clock speed comparability
http://www.ffd2.com/fridge/speccy/score
and has good architectural comparison
(The implication is that 4MHz z80 wins versus 1MHz 6502, but not against 2MHz 6502.)

The hpmuseum queens benchmark comes out at 2.8:1
http://www.hpmuseum.org/cgi-sys/cgiwrap ... ead=120687
       -  Z80      283 msec
       -  6502     100 msec
       -  68000    220 msec

There are some cycle count comparisons in the slightly excited
http://www.alfonsomartone.itb.it/aunlzr.html

In this thread
https://groups.google.com/forum/#!msg/a ... I1im1b2DsJ
william H ivey says he found a 1MHz 6502 to be more performant than a 4MHz z80

That thread and another page both say that z80 is good for floating point. The other page says it's because of the large register set - so less memory bandwidth needed.
http://www.andreadrian.de/oldcpu/Z80_nu ... ncher.html

Well, syntactic sugar always has an appeal. My value proposition here is actually more real than that:
1: Loops never get tight enough.
2: The BNE is (nearly) symmetric as to the maximum distance of branching forward or backward and it gets inelegant if you have to branch more than 128 away from present address. An instruction as proposed here would lend itself to a backward bias, with branches -192 to +64, perhaps even -224 to +32, saving ugly branches plus JMP.
3: BNE is 2 cycles if branch not taken, 3 if taken. The proposal here is to assume branch is taken and optimise for that, shaving off another cycle.
4: DEX + BNE is in sum 3 bytes and 5 cycles, while a LPX (just to give it a name) would be 2 bytes and 3 cycles, perhaps 2 cycles (see point 3).
5: It overcomes the lack of post/pre decrementing index registers during load/store, as found in many other processors, and does so without adding more combinatorials to the existing already substantial number of addressing modes.

LPX (=DEX; BNE) might even be combined as LPX ++Y (=INY; DEX; BNE) allowing fast reversal. Simultaneous decrementing both X and Y seems less useful.

All in all I believe the benefits are substantial. As for the cost it requires 2 (perhaps 4) new opcodes: LPX, LPY, LPX ++Y, LPY ++X with corresponding logic. Considering decrementing and branching logic already are in place I guess the added logic would not be that great.

To speed things up you might prepare branch if register is not 1 and then run the decrement in parallel, retiring the updated value while the branch is taking place.

I was never comfortable about comparing with Z80 so I cannot comment much on the timing issues for Z80. Still, I believe these looping instructions are sexy, draped in leather and crack the whip over Z80, as it should...

I quite agree. A clean structure is to me one of the attractions of the 6502 (and also the SWEET16). For looping purposes I was only thinking of decrementing and a BNE with backward bias. There are some obvious variations outlined in my earlier reply.

Incidentally the DSP65300 has a zero overhead loop function. It is fast, elegant and clever but regrettable requires a fair bit of logic and a flag in the processor status.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm eager to hear of them!

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

My first reaction is: what sets the status register flags? The change in Y or the change in X?

Presumably the answer is the change in X. Okay, but what am I going to know about the state of Y (ie., the value it holds) after the loop terminates? In the general case, presumably nothing.

My second reaction is: oh, this adds to the complexity of trying to visualize just what the instruction really does. Every other instruction changes just one register at a time; this would be un-orthogonal to them. Oh, my poor head!

I do pity myself quite easily.

Signed or unsigned comparison? As things stand now signed comparisons are always a tricky thing on the 6502. You have to use that mysterious V-flag if you want to do signed. It's difficult enough to grasp what's going on that a lot of people stay away from it. Perhaps explicitly signed comparison, subtraction and addition instruction branch instrctions would be helpful as well.



I like these. They can be synthesized already by interspersing CMP immediates among ROL/ROR sequences, but they're occasionally nice to have.



This would be extremely handy. This might be the best addition of them all.



I dunno. It's easy enough already to do "EOR #$FF". I don't know that I want to do this often enough to make it worthwhile as a separate instruction. Is there some address mode other than accumulator where this is useful?



This would take a (very) short routine to duplicate, and the answer would come in log(N) time. Or a big lookup table and constant time. Is there enough need to make it a separate instruction? I can see that it would be handy if you wanted to do parity checks, but beyond that I'm stumped. If parity is all it's good for, why not just a parity status flag?



Mmm. Maybe. All I can think of is setting up registers prior to subroutine (or OS) calls, but it might be handy at that.



So the other day I was thinking "What if each register had its own dedicated on-chip stack space?" Ie, N registers, N stacks And then I thought "What would that possibly be good for?" And then I thought "Interrupts!". I was thinking the processor would do it automatically upon recognizing an interrupt, so an ISR could start out trashing any register it wanted. RTI would restore them all. If each stack was 8- or 16-deep, you could even deal with re-entrant interrupts. The stacks would not be user-accessible, just places to stash register values during interrupts.

But an instruction to do it would be just as useful. The idea of multiple dedicated stacks would of course be to minimize response time to an interrupt. I don't think these would be as useful for calling subroutines, mainly because of the difficulty of returning results in registers (if the callee did PSH at the start then PLL at the end would trash anything you put in them...unless maybe the caller did PSH? Then after the callee returns, save any results passed in registers before the caller does PLL...might work. Okay, I like it)



Again a short subroutine. Is the speed advantage (one or two cycles per byte?) worth it?



Fun. I like these, although playing with stack pointer is not for novices.



I never liked this instruction much. Kind of ugly. The coolest answer to this in the 6502 world I ever saw were the Commodore RAM expanders. That REC chip could do transfers and fills at a byte per clock cycle, and swap two bytes in two clock cycles.



How is the result returned, BTW? What if no bit is set? If bits are numbered 7..0 then zero is not an answer to that. I guess I'm having trouble seeing how useful they'd be, ie., what problem do they solve?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The 65C816's XBA instruction does that on the accumulator.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!