What if independent MOS Technology had survived?

[Arlet]

GARTHWILSON wrote:

You don't need to. You just change the stack pointer X when you switch tasks. The system stores the last value for the application, and restores it when it lets it run again. The applications don't have to care where their stack range is.

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.

Quote:

Quote:

It's easier, yes, but it does waste an awful lot of cycles and it's not even very compact either.

Each separate operation is one or more instructions. I'm sure any RISC would require quite a few instructions to do the example you gave too.

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.

[Arlet]

Quote:

Or actually, I think it comes back to how hard it is to write in assembly language for most modern processors.

True, after some point increasing performance requires increasing complexity.

[litwr]

GARTHWILSON wrote:

Quote:

I have some tests with 6809 (2 accumulators) - they show that 2 accumulators may give even more than 100% speed boost.

Someone pointed out in another topic that the 6809 was not significantly faster than the '02 at a given clock rate. (Additionally, the 6809 was limited to very slow clock rates.)

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.

Quote:

I'd say that speaks very poorly of the programmer! Or actually, I think it comes back to how hard it is to write in assembly language for most modern processors.

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

[GaBuZoMeu]

litwr wrote:

... at the same frequency because it is slower with memory

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".

litwr wrote:

But the 2nd accumulator gives it a lot of advantages over 6502.

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.

[Dr Jefyll]

GaBuZoMeu wrote:

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

[GaBuZoMeu]

Dr Jefyll wrote:

GaBuZoMeu wrote:

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 is 3 bus cycles. The 6809 equivalent takes 4 bus cycles. Likewise,
  65xx LDA absolute is 4 bus cycles. The 6809 equivalent takes 5 bus cycles.

cheers,
Jeff

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

[Dr Jefyll]

GaBuZoMeu wrote:

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.

[litwr]

GaBuZoMeu wrote:

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.

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%.

Dr Jefyll wrote:

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).

Thank you very much it is exactly my point.
See results for 6309 in my project pi-spigot - 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, ...

[BigDumbDinosaur]

Arlet wrote:

And while it's true that you don't need to load/unload the pointers in zeropage, it is quite painful to do pointer arithmetic, such as [B+N*X+offset] addressing, that's typically used in higher level languages. Anybody who disagrees is invited to write a 6502 version of my memory allocation challenge.

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

[BigDumbDinosaur]

litwr wrote:

BTW I don't like 65816 PER instruction.

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.

Quote:

PEI and PEA are just extenders to PUSH.

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.

[BigDumbDinosaur]

litwr wrote:

And anyway 6502+ would be much better because 6309 has a lot of bulky instructions, can use only 64 KB of memory, ...

...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.

[BigEd]

BigDumbDinosaur wrote:

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 second one, for sure. The first point? Citation needed!

Quote:

Only recently has the number of Internet search engine hits on "x86" exceeded the number of hits gotten when searching on "6502."

Interesting and unexpected!

[Dr Jefyll]

BigEd wrote:

Citation needed!

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.)

BigDumbDinosaur wrote:

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

[BigDumbDinosaur]

Dr Jefyll wrote:

BigEd wrote:

Citation needed!

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.)

True that.

[Arlet]

BigDumbDinosaur wrote:

Arlet wrote:

And while it's true that you don't need to load/unload the pointers in zeropage, it is quite painful to do pointer arithmetic, such as [B+N*X+offset] addressing, that's typically used in higher level languages. Anybody who disagrees is invited to write a 6502 version of my memory allocation challenge.

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

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.