In another thread, barrym95838 wrote:
barrym95838 wrote:
The 6809 designers
had P.I. code directly in mind when they designed it
To which I wrote:
BillG wrote:
I have written one 6809 program using PIC and it was no walk in the park, piece of cake or bed of roses.
That program is the resident part of a system extension to add command recall, aka history, to FLEX. The 6800 and 6502 versions use a relocation bitmap similar to how MOVCPM worked on an 8080 - assemble the code at two addresses a multiple of 256 bytes apart; the bytes which differed needed to be adjusted to relocate the code. But the code can only be placed at addresses differing from the original location by entire pages.
I thought that PIC would allow me to put the code anywhere and not waste up to a page of memory. It did, but one programming idiom was not easy to implement.
In absolute 6800 code, I can write:
Code:
cpx #TheEnd
to compare register X with the address of the end of a data structure.
In PIC 6809 code I
cannot write:
Code:
cmpx #TheEnd,PCR
I can write:
Code:
leay TheEnd,PCR
to load the address into a register, but I cannot easily compare it with another register. I had to push it onto the stack and compare it there:
Code:
leay TheEnd,PCR
pshs Y
cmpx ,S++
which is substantially larger and slower.
If only Motorola had given me four "compare effective address" instructions: ceax, ceay, ceau and ceas...
To which BigEd wrote:
BigEd wrote:
That doesn't seem so bad - you found an idiom which works and you could wrap it in a macro.
To which I wrote:
BillG wrote:
The initial intended target of the 6809 version of the program is a Peripheral Technologies PT69-5 single board computer.
It is based on a 6809 processor running at 2 MHz. Unlike the 6502, evolution of the 6809 stopped when Motorola moved on to bigger things, the 680x0 family. FLEX on a 6809 officially supports up to 56 KBytes of RAM. I specifically chose to target the PT69-5 because it has an additional 4 KBytes, much of which is otherwise unused; my code and the history buffer resides there so that the amount of memory available for program use remained the same.
Instead of that push and compare sequence in my last post, I ended up doing the load effective address and storing the result in a variable during program initialization then comparing pointers against that later - much smaller and faster. The point is that position independent code on the 6809 does not come free though it is easier than on most other architectures.
To which Dr Jefyll wrote:
Dr Jefyll wrote:
BillG wrote:
Unlike the 6502, evolution of the 6809 stopped when Motorola moved on to bigger things
Maybe
Motorola moved on, but there's definitely some further-evolved 6809 DNA out there.
Back in the day, Hitachi out-6809ed Motorola by an embarrassing margin with their backward compatible
6309. "To the 6809 specifications, it adds higher clock rates, enhanced features, new instructions, and additional registers. Most of the new instructions were added to support the additional registers, as well as up to 32-bit math, hardware division, bit manipulations, and block transfers."
Also noteworthy are the MC9S12 and HCS12 series. These guys have "only" three stackpointer/index regs (U got turfed) but otherwise seem very 6809-like. Unfortunately this resemblance includes the 6809's very high prevalence of dead cycles, but on the plus side the MC9S12 and HCS12 are in current production by NXP and presumably clock a great deal faster.
-- Jeff
The Hitachi 6309 is to the 6809 as the 65816 is to the 6502. The addition of more instructions, registers and addressing modes along with a "native" mode. Even though it put its resources into the 68000 and not in further evolving the 6809, Motorola applied legal pressure to keep Hitachi from documenting the "improvements" they made. It took the hacker community to do that.
The evolution of the Motorola 8-bit line is more like
6800 --> 6801 --> HC11 --> HC12 --> HC16
|
+--> 6809
Unfortunately, when they went to the 6809, Motorola dropped many of the efficient inherent instructions in favor of generalized versions. Among those lost were TAB, TBA, ABA, SBA, CBA, INX, DEX, PSHA, PSHB, PULA, PULB. The generalized instructions were bigger and slower. Some dropped instructions were not replaced; the recommended workarounds were seriously inefficient in some cases.
One of the 6809 designers later wrote a master's thesis looking back on the design decisions:
https://www.cs.utexas.edu/ftp/techreports/tr81-206a.pdfInteresting reading. He said that adding the direct page register was a mistake. I disagree; though I have not used that capability, it did not apparently cost much to implement.
To add to what I previously said:
BillG wrote:
If only Motorola had given me four "compare effective address" instructions: ceax, ceay, ceau and ceas...
I would also add lead to load into and cead to compare with the combined accumulator D. It would have been really nice to be able to do things like:
Code:
cead 7,X
ceax D,Y
Login
Register
FAQ
Search
