6502.org

If actual hardware works as my simulator does, that may actually be useful.

If the code is written: control is passed to $1234 the first time through. Subsequent times, the code at $105 looks like

Good one, Mike! And $0134 is correct.

That's because the cycle which fetches ADL of the JSR destination occurs before the return address gets pushed to stack, and the cycle which fetches ADH of the JSR destination occurs after.

-- Jeff

Simulators, unless you've been very careful with what operations happen on which cycles, are more likely to be misleading in this case.

On the NMOS 6502 and 65C02, JSR works like this:

1. Fetch opcode
2. Fetch target address low byte
3. (internal operation)
4. Write PC high byte
5. Write PC low byte
6. Fetch target address high byte

The low byte of the target address will be fetched correctly, but by the time it fetches the high byte it has been overwritten by the high byte of PC. The target address will be (if I haven't messed up) $0134.

Instructions that push to the stack (like PHA and JSR) write the value first, then decrement S. Instructions that pull (like PLA and RTS) increment S first, then read the value.

The 65816 works differently, if its datasheet is correct. It fetches the full target address before writing the old PC, so it should go to $1234.

Nice puzzle. Here's visual6502 confirming:
http://visual6502.org/JSSim/expert.html ... 0&d=4c0001

Whoa, well spotted, John! And the datasheet seems adamant on this point, as there's a specific note included: "different order from N6502"

Also I notice the Absolute Indexed Indirect mode uses a different order once again, with the stack push cycles occurring consecutively and very early indeed.

-- Jeff

Are there any other race condition traps in the 6502 instruction set?

It may be interesting to determine how the various processors deal with the jsr/call instruction being overwritten by the return address.

For starters, the x86 has a prefetch queue and will be immune. No need to test it.

The 9900 does not have a hardware stack; it uses a "branch and link" method for invoking a subroutine. It has a number of other land mines because its registers, aka the workspace, may be positioned anywhere in the address space by loading the Workspace Pointer.

The AVR is Harvard architecture and also immune - separate data and program memory.

I cannot single step the 6809 but will try to come up with test code to catch the possibilities.

I seem to recall the documentation for the 6800 and the 8080 going into detail with cycle by cycle descriptions of instructions. I'll go read the fine manuals...

For the 6809, I wrote: Then I sprinkled landing pads at the likely places to display a message: $1234, $0107, $0134 and $1207.

It jsred to $1234.

The 8080 Family User's Manual says that the target address is fetched before the return address is pushed.

I just modified mine to properly handle this.

Which is the chicken and which is the egg?

The 6502 pushes the return address - 1 with rts correcting it later. Does jsr work this way to save cycles or transistors or both?

I'm not really a hardware guy, but my thinking is that it was done this way to keep the internal state machine as small as reasonably possible. If jmp abs takes only three cycles, then jsr abs should theoretically need only five, and rts only three. Theoretically ...

I believe it's to avoid the need for a temporary register. At the time of pushing PC, the value of PC is the one we observe. In order to push the actual return address, JSR would need to be able to read both opcode bytes before doing the stack pushes - and there's nowhere on-chip for those bytes to be stored. As it is, the stack register gets briefly reused to store the first operand, which is possible because the stack value needs to take a round trip through the ALU to be decremented.

You can see this visual6502:
http://visual6502.org/JSSim/expert.html ... 5&steps=20

I have gotten several more results for my Mandelbrot project: the 65816, TMS9995, R800, etc were added. The 65816 shows approximately 2 times better performance than the 6502 at the same frequency. My results also shows that the 68020 was only ≈30% slower than the ARM on 16-bit calculations.
This benchmark generates pictures and someone can say that they show us Xmas firs in horizontal and other positions.

Mike Douglas just posted the following to the FLEX Users Group mailing list:

I have created two versions of the "Byte Sieve" benchmark to run on the SWTPC 6800 and one to run on an 8080 machine (Altair 8800). This benchmark was first published in the Sep 1981 issue of BYTE magazine. The test was designed to allow comparison between different languages/compilers on a given machine, and to compare between machines given the same language/compiler.

For the first 6800 version, I took the C language version of the benchmark and pretended I was a mediocre compiler and generated a 6800 assembly source file. For the second 6800 version, I optimized the code as a good assembly language programmer would do. Here are the results on a SWTPC 6800 computer (1 MHz):

"C" version: 28.25 seconds
Optimized assembly version: 11.85 seconds

As expected, a well written assembly language version is substantially faster than a non-optimized compiled program.

Through a wide variety of tests in the past, I have found the 8080 at 2 MHz and the 6800 at 1 MHz to be closely on par with each other. However, for this Sieve benchmark, which uses a lot of array/indexed operations, the extra 16 bit registers of the 8080 clearly provide an advantage:

Optimized assembly version: 8.18 seconds

You can find the 6800 versions of the Sieve benchmark here:
https://deramp.com/downloads/swtpc/soft ... Benchmark/

The 8080 version is here:
https://deramp.com/downloads/altair/sof ... ellaneous/

Mike D

Previously, I wrote: Motorola claimed the 6809 was "source code" compatible with the 6800. That is not entirely true.

There are some obscure differences in the way a few instructions affected the condition codes. Motorola documented those.

What I did not go into with the above quote and Motorola never mentioned in their documentation is that some 6800 instructions grew in size when assembled for the 6809. This may cause marginal relative branch instructions to go "out of range." Maybe the Motorola assembler automatically replaced the branch with a long branch or a jump and conditional branches with the long form or a jump and the opposite branch. Or maybe not. The FLEX 6809 assembler does not and generates an out of range error; the source code must be manually adjusted.