Editing Motorola 6809 (section)

===6809===
While the 6502 began to take over the 6800's market, [[Intel]] was experiencing the same problem when the upstart [[Zilog Z80]] began to steal sales from the [[Intel 8080]]. Both Motorola and Intel began new design cycles to leapfrog those designs. Intel responded by quickly introducing a small but practical upgrade of the 8080 as the [[Intel 8085|8085]], which made it less expensive to use and more competitive with the Z80. They also began to design a series of 16-bit processors, which emerged as the [[Intel 8086]] in 1978. Motorola also began the design of a similar high-end design, in the MACSS project,<ref>{{cite web |url=http://www.decadecounter.com/vta/articleview.php?item=415 |website=The Vintage Technology Association |title=Motorola 68000 |date=17 May 2007 |access-date=2 February 2021 |archive-date=3 August 2020 |archive-url=https://web.archive.org/web/20200803205727/http://www.decadecounter.com/vta/articleview.php?item=415 |url-status=usurped }}</ref> but did not initially consider an improved 8-bit design. But when they polled their existing 6800 customers, they found that many were not willing to pay for a 16-bit design for their simple needs. This led to the decision to produce a greatly improved but compatible 8-bit design that became the 6809.<ref name="byte197901_6809">{{cite magazine |magazine=[[Byte (magazine)|BYTE]] |date=January 1979  |first1= Terry |last1=Ritter |first2=Joel |last2=Boney |title=The 6809, Part 1: Design Philosophy |pages=14–42 |url=https://archive.org/details/byte-magazine-1979-01/page/n15 |volume=4 |issue=1}}</ref>{{rp|pages=20,26}}

Analysis of 6800 code demonstrated that loads and stores were the vast majority of all the time in CPU terms, accounting for 39% of all the operations in the code they examined. In contrast, mathematical operations were relatively rare, only 2.8% of the code. However, a careful examination of the loads and stores noted that many of these were being combined with adds and subtracts, revealing that a significant amount of those math operations were being performed on 16-bit values. This led to the decision to include basic 16-bit mathematics in the new design: load, store, add, and subtract. Similarly, increments and decrements accounted for only 6.1% of the code, but these almost always occurred within loops where each one was performed many times. This led to the addition of post-incrementing and pre-decrementing modes using the [[index register]]s.<ref name="byte197901_6809"/>{{rp|pages=26}}

The main goal for the new design was to support [[position-independent code]]. Motorola's market was mostly [[embedded system]]s and similar single-purpose systems, which often ran programs that were very similar to those on other platforms. Development for these systems often took the form of collecting a series of pre-rolled [[subroutine]]s and combining them together. However, as [[assembly language]] is generally written starting at a [[base address]], combining pre-written modules normally required a lengthy process of changing [[Constant (computer programming)|constants]] (or equates) that pointed to key locations in the code.<ref name="byte197901_6809"/>{{rp|pages=20,24}}

Motorola's idea was to eliminate this task and make the building-block concept much more practical. System integrators would simply combine off-the-shelf code in ROMs to handle common tasks. Libraries of common routines like [[floating point]] arithmetic, graphics primitives, [[LZ77 and LZ78|Lempel-Ziv compression]], and so forth would be available to license, combine together along with custom code, and burn to ROM.<ref name="byte197901_6809"/>{{rp|pages=20,24}}{{efn|Other examples are matrix arithmetic, Huffman encoding/decoding, statistical functions, string searching (e.g. by the [[Boyer–Moore string-search algorithm|Boyer-Moore algorithm]]) and tree structure management. A larger example is found in Motorola's 6809 programming manual, which contains the full listing of ''assist09'', a so-called [[Resident monitor|monitor]], a miniature operating system intended to be burned in ROM.<ref name="motorola_mc6809_programming_manual">{{cite book |url= https://archive.org/details/bitsavers_motorola68_13419254 |title=MC6809-MC6809E Microprocessor Programming Manual |publisher=Motorola |date=May 1983 |access-date=13 May 2024}}</ref>{{rp|pages=B.1}}}}

In previous processor designs, including the 6800, there was a mix of ways to refer to memory locations. Some of these were relative to the current location in memory or to a value in an index register, while others were absolute, a 16-bit value that referred to a physical location in memory. The former style allows code to be moved because the address it references will move along with the code. The absolute locations do not; code that uses this style of addressing will have to be recompiled if it moves. To address this, the 6809 filled out its instruction opcodes so that there were more instances of relative addressing where possible.<ref name="motorola_mc6809_programming_manual"/>{{rp|pages=1.2}}

As an example, the 6800 includes an 8-bit direct [[addressing mode]] used to make code smaller and faster; instead of a memory address having 16 bits and thus requiring two bytes to specify, commonly used variables could be located within a 256-byte window (called the "direct page" on the 6800 or "[[zero page]]" on the 6502 because of its location at the bottom of memory) and accessed with an 8-bit address.  The downside was competition for valuable direct page addresses.  The 6809 added a new 8-bit DP register, allowing direct page addressing to refer to any part of memory as long as the DP register is changed to point to its new location.<ref name="motorola_mc6809_programming_manual"/>{{rp|pages=1.2}}

A second category of data was constant data stored in ROM such as strings and lookup tables.  To solve the problem of easily referring to such data while remaining position independent, the 6809 added a variety of new addressing modes. Among these was program-counter-relative addressing which allowed any memory location to be referred to by its location relative to the instruction. Moving this code to a new location in memory would have no effect on the addresses. Additionally, the [[Call stack|stack]] was more widely used, so that a program in ROM could set aside a block of memory in RAM, set the SP to be the base of the block, and then refer to data within it using relative values.<ref name="motorola_mc6809_programming_manual"/>{{rp|pages=2.1-2.4}}

To aid this type of access, the 6809 renamed the SP to U for "user", and added a second stack pointer, S, for "system".<ref name="motorola_mc6809_programming_manual"/>{{rp|pages=1.3}} The idea was user programs would use U while the CPU itself would use S to store data during [[subroutine|subroutine calls]]. This allowed system code to be easily called by changing S without affecting any other running program. For instance, a program calling a floating-point routine in ROM would place its data on the U stack and then call the routine, which could then perform the calculations using data on its own private stack pointed to by S, and then return, leaving the U stack untouched.<ref name="motorola_mc6809_programming_manual"/>{{rp|pages=1.3}}

Another reason for the expanded stack access was to support [[reentrant (subroutine)|reentrant]] code, code that can be called from various different programs concurrently without concern for coordination between them, or that can recursively call itself.<ref name="byte197901_6809"/>{{rp|pages=30}} This makes the construction of [[operating system]]s much easier; the operating system had its own stack, and the processor could quickly switch between a user application and the operating system simply by changing which stack pointer it was using. This also makes servicing [[interrupt]]s much easier for the same reason.<ref name="motorola_mc6809_programming_manual"/>{{rp|loc=4}} The 6809 adds a fast [[interrupt request]] (FIRQ) interrupt that saves only the program counter and condition code register before calling the interrupt code, whereas the IRQ interrupt saves all registers, taking additional cycles, then more to [[stack unwinding|unwind the stack]] on exit.<ref name="motorola_mc6809_programming_manual"/>{{rp|pages=1.9}}

The 6809 included one of the earliest dedicated hardware multipliers.<ref name="byte197901_6809"/>{{rp|pages=36}} It takes 8-bit numbers in the A and B accumulators and produces a 16-bit result in A:B, known collectively as D.<ref name="motorola_mc6809_programming_manual"/>{{rp|pages=1.1}}