Sort of, but not quite. XBA swaps the halves of the 816's 16 bit accumulator C -- ie, swaps 8 bits from accumulator A with 8 bits from accumulator B. I think André meant swapping the 4 bit halves of an 8 bit accumulator.

I have to admit I like this idea. But I suspect it won't do much in terms of a useful speedup of existing code. Sweet 16 was used to shrink the memory footprint when a task wasn't especially performance-critical, isn't that right? But writing new Sweet 16 code to run natively in hardware.... that would be cool (and fast!)

-- Jeff

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

Another thing that was done on some 6502 variant, and which I always liked as an extension, was the addition of a Z index register whose default value was 0. Many of the new opcodes corresponded with existing ones, so STZ did exactly that, and the zp-indirect instructions like LDA (zp) became LDA (zp),Z. Always seemed like a smart way of getting some extra mileage out of a limited number of opcodes, while retaining backward compatibility.

ASR - yes, that would've been nice. Also ADD and SUB (without taking C as input) would've been great, and while we're at it (taking inspiration from the ARM), RSB and RSC for reverse subtract [with carry] would've saved the whole horrible sequence of:or, slightly more cleverly:RSB #0 would of course provide a nice 2 cycle 2's complement operation.

That's what I made INV for - the two's complement. You could
But looking at that it doesn't save very much...

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/

Unsigned. I had noticed that I had sequences of Branches to do just that, branch on greater (where BCS is basically greater or equal) or branch on less or equal (where BCC is basically branch on less).

Forgive my ignorance, but isn't signed the same as unsigned, as long as V is NOT set?

As has been asked in another post in this thread, yes, that exchanges the two nibbles in a single byte. Due to the extended nature of my 65k, of course there are SWP.W to exchange the bytes in a word, SWP.L to exchange the WORDs in a LONG, and SWP.Q to exchange the LONGs in a QUAD (64 bit).

"EOR #$FF" is the one's complement, not the two's complement. I made this to easily do a reverse substraction as mentioned in another post here. But in fact, replacing

with

does not help much - I should probably investigate the reverse substract as well (in addition to ADD and SUB that don't use the carry)

Parity flag is a good point. I currently just don't have a status register bit left... My 65k can have up to 64 bit values - the routine would still be very short, but log(64) is still getting larger, so I thought it in order to do this.

a per-register stack is a neat idea, but what do you do if it overflows?

I though doing these opcodes to make model/family-independent interrupt routines. A later 650x0 could have more registers, and this PLL/PSH would simply be extended to pull/push them from/onto the stack.
This would not necessarily be used for calling subroutines - here I would use the registers for parameters and return values anyway, and selectively save those on the stack that are needed.

I don't intend to make it as inefficient as the 65816 one. I was more thinking of one cycle per byte (or even less with a wider memory interface).

No, but those can be used for handling pointers to parameters on the stack.

I wonder how that would work, swap two bytes in two clock cycles. I can only see this with two memory banks read in parallel and written back in parallel.
Anyway, the plan is to have two cycles per byte maximum (maybe less with wider memory interfaces)


Admittedly HBS/HBC are "imagined", but could possibly come in handy to shorten an integer multiply/division routine.
BSW I would find useful for computing the swapped addresses in a fast fourier transform (although then it would probably better be used on an index register).
Those would either be read memory -> do operation -> store in AC, or AC -> operation -> AC. Don't think a R/M/W would be useful here though.
If no bit is set/cleared on HBS/HBC respectively, the carry bit could be set for example. Haven't thought about that yet I have to admit.

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/

I think I even have (had?) that on a todo list somewhere

For this I wanted to invent "quick" opcodes that contain a number from 1 to 8 in the opcode and work on Y or X, like


Hm, interesting idea. Never thought of it before. But then it seems I probably haven't really needed it.

As you have to compute values just read into a new address (indirect indexed addressing modes), there will always be "dead" cycles on the core. But for example I was able to hide the 65816 dead cycles in my computer if the CPU was fast enough to still provide the address lines even though the "dead" cycle was in the beginning of Phi1 - however, the clock factor needed IIRC was about 1:8 or 1:10.

Yeah, that would be a real dream...

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/

A couple of points:

On FGPA, multiply is cheap. The multipliers are already there, whether you use them or not. The argument that they use up a lot of silicon area applies to the era of the 6502 rather more strongly than to the era of the 250k gate FPGA. (But division remains difficult.)

If you supply bitcount, parity is cheap. The converse isn't true! Whether bitcount is worth bothering with is another question, but again, on FPGA we don't pay for silicon (within reason), we pay for lines of code and we pay if clock speed is affected.

Final point: beware of wish-list features which trim one or two bytes or clock cycles. These thoughts probably come from experience with 1MHz or 2MHz systems with 64k memory. If a project is delivering a CPU which runs at 25MHz with a 32bit address space, the baseline performance should already be a lot higher and the memory pressure a lot lower. Time might be better spent on increasing clock speed, or making a smarter SDRAM interface which will speed up all programs, instead of adding or tweaking a few special-case instructions. (Of course, some instructions are worth the effort, and others are not.)

Cheers
Ed

Thinking a little more about this - how much extra logic would've been necessary to achieve this, other than some extra lines on the PLA to implement the opcodes? It's just that, as far as I can tell, the 6502 already knows how to do adds and subtracts without using the carry as input, because CMP is just a SBC operation with C=1, and left shifts are implemented as N+N, which means that ASL is just an ADC with C=0.

I would take almost no logic, but it would take a large chunk of opcode space, which may be better used for something else.

That's what I figured, but the original 6502 had plenty of spare opcode space. Why were ASL/ROL and LSR/ROR afforded the luxury of having versions which ignored the carry or used the carry, while ADC and SBC were not. Arguably, addition and subtraction are a more basic and common operation than multiplication/division by 2.

Probably because it only takes 1 instruction to clear/set the carry flag, and it would take multiple instructions to simulate a ROR with ASR, or the other way around, which would be very annoying if you had to do multiple shifts in a row. Also, the shift/rotate instruction only have 5 addressing modes, and the ADC/SBC have 8. And while there's plenty of spare opcode space, I suspect the designers wanted to have the option of using it for something they thought was more useful.

In my 65k I have an "LEA" load effective address into the E register with all addressing modes, and then some of the new opcodes only get like immediate and E-indirect:

would do a direct rotate of the address that is stored in E. That helps not cluttering up the opcode space.

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/

I noticed it only a few times, typically in large nested loops. However most of my work was time critical, which was part of the reason to write assembly code in the first place. I remember compiler authors also back then said their compilers created better code than hand crafted assembly. My employers disagreed and I was brought in on many a project to squeeze that extra bit of oumph out of the code or shave off memory or bandwidth requirements. The 6502, in my view, was very appealing for coding and lent itself to ultra high density code.


I did all sorts of projects, data compression, image compression, map and navigation systems and more. It was amazing what you could fit into 32 KB memory. And the 6502 delivered every time. Unfortunately I don't have any of that code. If we had a substantial code corpus we could do some statistical analysis on what new instructions could gain us in terms of memory and cycle savings.

Is anyone from WDC on this forum? It would be interesting to hear their views on what this discussion is bringing up. Implementing a LPX instruction should be trivial to them.

The idea was that for LPX the X-register sets the flag. part of my thinking of writing "++Y" rather than "Y++" was to indicate that Y is incremented first, in other words before X is decremented.


Leaving Y unknown is easy, convenient but in my view also untidy. Considering a common trick of the trade is to reply on a known state of a register for further work, it would be counter productive to leave big unknowns around. I would prefer that Y was incremented every time X was decremented.


Um, well, changing two registers at a time is common, like X-register and processor status. What I suggests here is, strictly speaking, changing 3 registers. It would be an unusual case but the benefit would be significantly increased code density and an opportunity for cycle saving.

Actually SWEET16 is already in use, in the Apple II. And a search on the net shows that a few assemblers also support this syntax. This means that use and infrastructure is already in place, moreover it also means that SWEET16 is a proven concept.

I would propose some minor tweaks, say SWEET17 (she grew up, right?), by synchronising the A, X and Y registers with SWEET16 registers on entry and exit:


Going from 6502 to SWEET17 provides, in my view, a clear path for scaling up in width.

_________________
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?