That's only if you do everything through the indexed-X method, not if you let every task use zeropage for whatever purpose. Plus it requires the X register.


ARM can do load/store with [base + index], or [base + index LSL #N], or [base + offset] in a single instruction, and use a 3rd register for the result. A [base + index * N + offset] would typically take 2 instructions, but because you have a bunch of registers, you can often save partial results for reuse later.

True, after some point increasing performance requires increasing complexity.

Generally 6809 is only slightly faster than 6502 at the same frequency because it is slower with memory, has bulky index registers, ... But the 2nd accumulator gives it a lot of advantages over 6502.


http://www.roguelazer.com/2015/02/beating-the-compiler/

_________________
my blog about processors

You know that since the 6802/03/08 and of course the 6809 the crytal oscillators are designed to use a 4x crystal frequency not because they need more clocks but simply because higher frequency crystals was less bulky and cheaper? A 4MHz crystal cause a 1 MHz clock for the 6809 and this causes a cycle time of 1µs. There is no "slower with memory".
Are you talking about accumulator B or are you talking about using accumulators A and B as 16 bit accu D? Then, yes you could achieve 100% gain under rare circumstances. Otherwise nope.

GaBuZoMeu, on this issue I agree with you.

But litwr's point about the 6809 being slow with memory is valid because there are more dead cycles. (I'm referring to bus cycles, so this is independent of any details of the clock generator).

Example:

65xx LDA zero-page takes 3 bus cycles. The 6809 equivalent takes 4 bus cycles. Likewise,
65xx LDA absolute takes 4 bus cycles. The 6809 equivalent takes 5 bus cycles.

cheers,
Jeff

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

Ahh - OK, this was meant with "slow memory". Sorry, I'm not familiar with this term. Thank you

It's possible I misunderstood litwr, but the meaning seems fairly clear. Myself, I'd call it a case of "slow processor" rather than "slow memory."

BTW and FWIW, Hitachi produced its own version of the 6809 -- the enigmatic and legendary 6309. Compared to the Motorola product the 6309 has many *major* improvements. Among these is a drastic reduction in the number of dead cycles.

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

6809 uses BE byte order and this reduces the gain from 16-bit D-accumulator. 6809 ALU is 8 bit and this reduces the gain too. And there are a lot of instructions, for example, ADC, ASL, ..., which have no D-variant. However I have to agree with your point about rare circumstances. IMHO the average gain is about 60-80%.


Thank you very much it is exactly my point.
See results for 6309 in my project pi-spigot - http://forum.6502.org/viewtopic.php?f=2&t=4185 - it shows that 6309 is the best 8-bit processor. However these results maybe inaccurate I used an emulator to get them. And anyway 6502+ would be much better because 6309 has a lot of bulky instructions, can use only 64 KB of memory, ...

_________________
my blog about processors

The pain is nowhere as severe with the 65C816 in native mode.

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

What do you have against PER? I find all sorts of use for that instruction, as it is the basis for developing fully relocatable code.


PEA and PEI are indispensable for creating stack frames prior to calling full reentrant subroutines. Just about all of my 65C816 programs use those instructions, along with more orthodox register pushes.

One of the subtle but important benefits of using PEA or PEI to write parameters to the stack is the registers are not disturbed. In fact, I occasionally use the instruction PEA #0 in a loop to create and initialize ephemeral stack workspace as an alternative to REP #%0010000 -- TSC -- SEC -- SBC #NNNN -- TCS. The latter sequence, while faster in moving the stack pointer if a lot of workspace is needed, doesn't zero out the workspace, which is sometimes a requirement, especially if direct page is temporarily pointed to the workspace as well.

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

...and the 65C816 is better still with 16 bit registers, 24 bit memory addressing, block copy instructions, stack relative addressing, fully relocatable direct page, support for high clock speeds (20 MHz if the rest of the circuit can handle it), etc.

You keep comparing apples (no pun intended) to oranges when you bring the 6800 MPUs into the discussion. The 6502's design was intended to eliminate the two most glaring weaknesses of the 6800, namely the lack of two index registers and the cost per piece (the latter is what influenced Wozniak into choosing the 6502 over the 6800). Obviously the 6502 greatly succeeded in that respect, as the home computer revolution was largely fueled by 6502 systems, not 6800 systems.

Comparison of the 6502 to the 6309 is only partially relevant, again apples to oranges—different MPUs with different intended "audiences." The 65xx family stands on its own, as is abundantly clear when one considers the countless millions and millions of 65xx MPUs that have been and continue to be used. Also, it is safe to say that the 6502 (and derivatives) is one of the most documented microprocessors in history. Only recently has the number of Internet search engine hits on "x86" exceeded the number of hits gotten when searching on "6502."

In my opinion, the 65C816 makes a better starting point for a homebrew computer than the 65C02 (or the much slower 6309), simply because it is a much more capable device, yet still adheres to the 65xx "philosophy" of a friendly bus structure, clean programming model and ready availability. One doesn't have to be concerned about 16 MB addressing to build a basic 65C816 system, as minus the bank latching circuitry, the 65C816 looks like a 65C02 as far as memory and I/O are concerned. It powers up in 65C02 emulation mode, which means it will run almost all 65C02 software without error. Once the programmer gets comfortable with the '816 he can switch to native mode (CLC -- XCE) and tap into the enhanced capabilities. That is how I started with my POC units, and it worked out well for me.

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

The second one, for sure. The first point? Citation needed!


Interesting and unexpected!

Yes. Moreover, BDD, re your statement (below), the 6800-series processor that's been repeatedly referenced is the 6809 -- which came out well after 6502 entered the market. IOW the 6502 wasn't intended to eliminate any weakness of the 6809. (BTW the 6809 has four index registers.)

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

True that.

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

The '816 makes it easier to do 16 bit arithmetic, but if you want to use the full 24 bit address, it's still painful.