I made a macro for my preferred version of the multiply representing a good balance of speed vs. size. Its size is 58 bytes for 32 by 32 and includes clearing the high bytes of the product. It was tested in Kowalski and executes in 1483-2699 cycles for a 32 bits by 32 bits multiply. The 27 byte ...

Worth noting.

This kind of discussion happens all the time.

Isn't it interesting that after 41 or so years, people still find fun in implementing MUL, and finding ways to optimize.

I find this amusing as well. Not just with 6502 code, but 8/16-bit computers in general. I still come across forum posts were people argue over which 8-bit is best. Atari or ...

I've been following this discussion and have to say it's been interesting.

That said, if you really want to see an improvement in performance as well as a reduction in code size , try writing the multiply algorithm for the 65C816 running in 16 bit native mode. :D You will be pleasantly amazed at ...

jsii, just a suggestion for your 6502 toolbox if you haven't found it yet, and since reference to cycle counts are popping up in the thread.

Kowalski's 6502 Simulator.
It has a built in assembler and lots of debugging features, including cycle counting.

You'll find a version with recent bug fixes ...

Isn't it interesting that after 41 or so years, people still find fun in implementing MUL, and finding ways to optimize. Yup! :) And sometimes the "optimization" involves upgrading the code to eliminate incorrect results ! :shock: :P If anyone's interested, see Garth's thread (below).

UM ...

Isn't it interesting that after 41 or so years, people still find fun in implementing MUL, and finding ways to optimize. Similar, I think, to the posts we see from time to time on a new Forth NEXT primitive, or a new sort function, or in the other thread, DEX2HEX. The 6502 is simple and constrained ...

Hostility has bitten us here in the past, several times, regrettably. It is somewhat difficult to "feel the tone" of a participant in plain text, especially in the case of English being a second or even third language for some of us.
Quite true.

I am very comfortable here, and I think that it's ...

> "you guys"

Not a good idea to generalise - there are hundreds of people here on the forum, and even if you got into some kind of disagreement with half a dozen, it needn't mean that you have figured out the hive mind. There is no hive mind! Hive mind? It's not 'the borg' here, or is it? "You ...

I still say there must be better ways to do this yet both in terms of byte count and speed. 21 bytes? Cheers. You may not have noticed, but shorter code contradicts faster code because of the overhead the additional loops have over linear code. Not necessarily.

Of course this is not true for ...

If you're going to cheat, why not move the LDX #$09 out of the function, too? Further, if you inline this, you can get rid of the RTS (and everything else; the actual length of the subroutine becomes 0...) I hear that bile is good around the liver. Anyway, I'm not sure what you mean by 'cheat', by ...

I still say there must be better ways to do this yet both in terms of byte count and speed. 21 bytes? Cheers.

If you're going to cheat, why not move the LDX #$09 out of the function, too? Further, if you inline this, you can get rid of the RTS (and everything else; the actual length of the subroutine becomes 0...) I hear that bile is good around the liver. Anyway, I'm not sure what you mean by 'cheat', by ...

25 bytes.


;=================================================================
;=================================================================
;=================================================================
;32bit multiply and 'variable bit' multiply -- CT32X04 -- 2017, jsii
;(not ...