Howdy programmers,

Here's a fun little mini programming challenge that you may enjoy.

Your task is to design and implement a highly specific 6502 calling convention.

In your calling convention, all the operands must be 8-bit pointers representing zero-page addresses. The function being called, will ONLY touch zero-page memory to do whatever work it needs to do -- it will NOT touch 16-bit memory.

All functions using your calling convention will have three or fewer operands. You don't need to worry about arbitrary numbers of operands.

For example, one function might take the value that the first operand points to, subtract the value that the second operand points to, and store the result in the location that the third operand points to.

You can use all the 6502 registers, the stack, zero page, main memory, or anything else you want in your calling convention.

For example, one calling convention might be to store the operands in three consecutive zero page locations.

Another calling convention would be to store the first operand in the X register, the second operand in the Y register, and the third operand in a fixed zero page location.

Another might be to store all the operands on the stack.

To demonstrate your calling convention, please show an efficient implementation of an addition function that:

- adds a 16-bit value at a zero-page location pointed to by the first operand;
- to another 16-bit value at another zero-page location pointed to by the second operand;
- and stores the result at a third zero-page location pointed to by the third operand.

The winning proposal is the calling convention that sets up arbitrary operands, and completes the addition function, in the fewest clock cycles.

Another win should also go to the calling convention with the smallest code size.

Thank you very much for playing with me! Looking forward to seeing your brilliancies.

Ground rule questions:

6502 instructions only or are 65C02 instructions allowed?

Is self-modifying code allowed?

It must be shown that a reasonably performant NMOS 6502 solution exists. However, a clever 65C02-only solution is definitely of interest. (The compiler can be told to target a specific 6502 variant.)

For that reason, a 65CE02-only solution, that may or may not use the Z accumulator, is also of interest.

However, a winning entry must show that you can do it cleanly, via documented instructions only, on the original 6502 metal, as per http://archive.6502.org/books/mcs6500_family_programming_manual.pdf .



Same as above. It must be shown that a reasonably performant, non self modifying solution, exists. However, if there is a clever self modifying solution, that is definitely of interest as well. (Some targets will need the executable code to be in ROM. and some will not.)

Any other rules of engagement questions?

This is my entry for fastest NMOS 6502:



Edit: Made faster.

This is my entry for fastest 65C02:



Edit: Made faster.

This is my entry for smallest NMOS 6502:



Edit: revised to benefit Add being called more than once.

Further edit: Made smaller.

This is my entry for smallest self-modifying 6502:



Edit: Allow the code to be outside of the zero page.

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

Not merely the calling convention, but a specific demonstration of its use, so that its speed and size overhead can be fairly benchmarked against other proposals.

Recall that the goal of the exercise is not to leave a result on the stack, but to perform exactly the zero-page addition operation described.

BillG clearly understands the intention of the exercise. I'm curious to see if anyone can come up with a method that works in fewer cycles.

There is no "Z accumulator" in the 65C816. The 65C816's registers are .A, .B, .X, .Y, DB, DP, PB, PC and SP.

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

I certainly don't know if I'm misunderstanding or oversimplifying, but my attempt which does what you seem to describe would be:

If I count correctly (big if), 57 cycles between jmp main and brk, one cycle faster than BillG's fastest NMOS attempt.

[Edit: added "#"s to main, derp]

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Nicely done!

I'll see your cycle and raise (or is that lower) you another...





vs.



vs.



Keep the ideas coming...

Even though it does not meet the requirements of this competition, I think it will be interesting to see how the ADD word compares.

Can you provide that?

Edit: I am guessing that if you are using parallel stacks for low and high bytes, the code may look something like this:



for a total of 40 cycles.

If this is used within FORTH, the cost of a trip through the inner interpreter would have to be added to the total to be fair.

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