Comparative software analysis of the MC6809 microprocessor M F Smith presents a software study of three 8-bit microprocessors, comparing the performance of Motorola's 6809 with the 6800 and Zilog's Z80

One way of comparing one microprocessor with another is to run a standard program on each of them. Then, by look- ing at various parameters, for example, length of program and execution time, it is possible to evaluate their relative performances. The study makes the conclusion that the newer 6809 is quantitively superior to the older ZSO and 6800, but, in the author's opinion, still has some failings. The article shows both a useful comparison and a useful, and relatively simple, method for comparing microprocessor performance.

The MC6809 microprocessor was introduced by Motorola in 1978 as an upgrade to the MC6800 processor. The major

1. design goals of the architects were

• position independent object code • improved stack and index operations • indirect addressing modes • more efficient object code (speed and size) • consistent and uniform instruction set • suitability for high level language implementation

The resulting microprocessor is a device which seems to meet these goals well. In practical terms, the MC6809 is not a disappointment and the architects' theory seems to coincide well with practice. The author presents below a comparative software analysis of the MC6809 with the Motorola MC6802 and the Zilog Z80 in a practical appli- cation of a well-known program.

C O M P A R A T I V E S T U D Y

It is unfortunate that any comparativ e study of micro- processors which is aimed at ROM-based applications must take assembler programming heavily into account. High level languages still have not been realized which are totally suited for many small (1-2 kbyte) ROM-based micro- processor applications. In general, the deficiencies of the high level languages available 2,3 appear to be that: • many are not suitable for real-time programming • many will not produce programs which can be placed

in ROM • the size of the object or run time programs may be

excessive • low level programming techniques, such as bit/byte

manipulation, are often less intelligible when expressed in some high level language

A benchmark should, therefore, be selected which reflects the intended application and programming language of the

Department of Computer Science, University of Reading, White- knights, Reading, Berks RG6 2AH, UK

microprocessor. For many 'conventional' microprocessor applications, this may imply assembler programming and control of devices at the bit and byte level. Program size and software maintenance may be more important con- siderations than high performance, position independency, 'number crunching' capability or suitability for high level languages.

The program employed for the comparative analysis of the MC6809 is a 16-bit binary to ASCII assembler routine which should be well-known to MC6800 programmers 4 The program (called BINDEC) was rewritten to meet certain standards and to improve clarity for the compara- tive study. This is a suitable routine for purposes of com- parison because:

• it employs a well-known algorithm, is used frequently in real applications and reflects relatively conventional programming techniques

• extensive index register manipulations are required, including a double precision table and a character buffer

• 16-bit arithmetic is needed, as well as byte manipulations

• it is moderately difficult to make reentrant and relocatable

C R I T E R I A FOR E V A L U A T I O N

Some factors of software performance can be evaluated quantitatively by analysis and suitable benchmark programs. Quantitative factors which are important to most microprocessor applications are (in considered order of importance for 'conventional', ROM-based applications):

• length of source programs • size of object code • reentrancy • facilities for passage of parameters • ability to create local variables, when required • speed of execution • relocatability of object programs

Certain aspects of software evaluation are subjective in the sense that they cannot be proved directly or vary with applications and individual programmers. Important subjective factors are (in considered order of importance):

• orthogonal instruction set-evidenced by regularity, consistent modes of operation for all instructions and lack of special cases

• improved software reliability by reducing the possibility of programming errors - e.g. inconsistent flag setting, easily confused modes of operation, possibility of unstacking incorrectly, etc

vol 5 no 9 november 1 9 8 1 0141-9331/81/090401-04 $02.00 © 1981 IPC Business Press 401

• completeness o f the inst ruct ion set for the intended app l i ca t i on -e .g , power fu l index ing modes, suf f ic ient number o f registers, good stack operat ions, comple te data movemen t instruct ions and adequate log ica l /ar i thmet ica l capabi l i t ies

• overal l ease o f use - ref lect ing all o f the factors above

plus read ib i l i ty , c o m m o n a l i t y w i th o ther assemblers, consistency o f ins t ruct ion usage by d i f fe ren t program- mers, ease o f learn ing/remember ing, logical mnemonics and (very subject ive) the general ' feel ' o f the inst ruct ion set

RESULTS

The Z80 (Figure l ) and MC6800 (Figure 2) versions of the binary to ASCII routine, called BINDEC in the study, were written, assembled and tested using a HP64000 system. The MC6809 version (Figure 3) was written and assembled on the HP64000 but was tested using a Percom single- board MC6809 computer. Each version of BINDEC was

Table 1. Quantatit ive results of the comparison of the program B I N D E C written for the Z80, the MC6800 and the MC6809. The f i rst figures for the MC6800 are fo r extended mode addressing, the second for direct addressing

MC6809 Z80 MC6800

S o u r c e lines 23 36 " 3 7 / 3 7

(1.00) (1.57) (1.61)

Object size 50 63 68/62 bytes (1.00) (1.26) (1.36/1.24)

RAM bytes 0 0 5/5

Reentrant Yes Yes No /no

Relocatable Yes No No /no

wr i t ten so as to take advantage of the indiv idual processors' characteristics, consistent w i th reasonable programming

LOCATION OBJECT CODE LINE SOURCE LINE

1 "SBO0" 2 ; 3 ) 4 5 6 7 ; S 9 ;

0000 10 RESULT RHB 0001 11 BEST X RHB 0003 12 TABLE_X RHB

13 14

0005 36 15 BINDEC PSHA 0006 37 16 PSHB

17 0007 DFOt 18 STX BEST X 0009 CE0039 19 LDX ICONST O00C 7FO000 20 NEXT 10 CLR RESULT O00F EO01 21 SUS_16 SUB B 1~X 0011 A200 22 SBC A O,X 0013 2505 23 BCS ADD_I 6 0015 7C0000 24 INC RESULT 0018 20F5 25 BRA SUB_16

26 O01A EB01 27 ADD_16 ADD B t,X 001C ASO0 28 ADC A O,X

29 O01E 36 30 PSH A O01F DF03 31 STX TABLE X 0021 DE01 32 LDX BEST X 0023 9600 33 LDA A RESULT 0025 8B30 34 ADD A 4130H 0027 A700 35 STA A O,X

36 0029 OB 37 INX O02A DF01 38 STX DEST_X 002C 32 39 PUL A

40 ; 002D DE03 41 LDX TABLE X O02F OE 42 INX 0030 OS 43 IHX 0031 BC0043 44 CPX 0034 26D6 45 SNE

46 ; 0036 33 47 PULB 0037 32 4S PULA 0038 39 49 RTS

50 51

0039 2710 52 CONST FDB 10000 O03B 03ES 53 FDB 1000 O03D 0 0 6 4 5 4 FDS 100 O03F O00A 55 FDS 10 0041 0 0 0 1 5 6 FDB 1 0043 57 CONST ENDI

EPPOPS m 0

Figure 1. Listing for BINDEC running on the Z80 microprocessor

B I N D E C 0 2

CONVERT AsS TO ASCII STRING POINTED TO BY X

A;B ARE RETURN UNDISTURBED~ X"X+5 ROUTINE IS NOT REENTRANT OR RELOCATABL~

1 NUHBER OF SUCCESSFUL SUBTRACTIONS 2 TENPORARY DESTINATION FOR X 2 POINTER TO CONSTANTS

DIRECT

SAVE REGISTERS

STORE POINTER FOR RESULTS POINT TO CONSTANT8 FOR SU]BTRACTION CLEAR THE COUNT FOR SUBTRACTIONS NOW SUBTRACT THE BINARY NURSER FROH THE 16 BIT VALUE IN THE TABLE UNTIL IT UNDERFLOMB DIDN'T THIS TlffiE SO COUNT CONTINUE UNTIL THERE I~ UNDERFLOW

RESTORE VALUE BECAUSE IT WENT TOO FAR MHEN UNDERFLOM OCCURRED

SAVE A (HSB) TENPORARZLY STORE THE TAm.E POINTER GET THE POINTER TO THE RESULT SUFFER GET THE NUNBER OF SUBTRACTIONS HAKE IT INTO AN ASCII CHARACTER AND HOVE IT INTO THE RESULT BUFFER

HOVE THE RESULT POINTER UP ONE AND SAVE IT BACK FOR THE NEXT TIRE RESTORE THE A REGISTER (HSB)

GET THE TABLE POINTER BACK HOVE IT TMO BYT1E8 TO THE NEXT ENTRY (1/10 OF LAST)

)CONST_ENB CHECK IF THIS IS THE END NEXT 10 IF HOT, CONTINUE

RESTORE REGISTERS

402 microprocessors and microsystems

LOCATION OB3ECT CODE LINE SOURCE LINE

1 "Z80" 2 ~ B I N D E C Z 8 0 3 ; 4 ; CONVERT HL TO ASCI I STRING 5 ; POINTED TO BY IX 6 ; 7 ; ALL REGISTERS ARE RETURNED UNDISTURBED S ; ROUTINE IS REENTRANT BUT NOT RELOCATABLE ? ;

0000 F5 10 DINDEC PUSH AF 0001 DDE5 11 PUSH IX 0003 FDE5 12 PUSH IY 0005 E5 13 PUSH HL 0006 D5 14 PUSH DE 0007 C5 15 PUSH BC

16 ; 0008 FD210035 17 LD IY ~CONST O00C 0605 18 LD B~5

19 ; O00E AF 20 NEXT_tO XOR A O00F 37 21 SUB_16 SCF 0010 3F 22 CCF 0011 FD5601 23 LD D ~ { I Y + I ] 0014 FD5EO0 24 LD E~ [ IY+O] 0017 ED52 25 SBC HL ~ DE 0019 3803 26 3R C~ADD 16 O01B 3C 27 INC A 001C 18F1 28 3R SUB_16

29 $ O01E 19 30 ADD_16 ADD HL~DE O01F C630 31 ADD A,30H 0021 DD7700 32 LD [ IX+O]~A 0024 DO23 33 INC IX 0026 FD23 34 INC IY 0028 FD23 35 INC IY O02A 10E2 36 D.I"NZ NEXT_t 0

37 ; 002C C1 38 POP DC O02D Dl 39 POP DE O02E E1 40 POP HL O02F FDEt 41 POP IY 0031 ODE1 42 POP IX 0033 F1 43 POP AF 0034 C9 44 RET

45 0035 2710 46 CONST DEFW 10000 0037 03E8 47 DEFW 1000 0039 0064 48 DEFW 100 003B O00A 49 DEFW 10 O03D 0001 50 DEFW 1

;SAVE ALL REGISTERS

;POINT TO CONVERSION TABLE ;FIVE DIGITS TO CONVERT

;CLEAR RESULT IN REG A )CLEAR CARRY

;LOAD CONSTANT VALUE ;INTO DE ;NL=HL-DE ;UNTIL UNDERFLOMS ELSE ;ADD TO RESULT ;AND CONTINUE

~RESTORE UNDERFLOW ;RAKE ASCI I RESULT ;PUT INTO RESULT BUFFER ;MOVE ASCII DIGIT POINTER ;ROVE CONSTANT TABLE POINTER ;DOUBLE INCREMENT ;DO FIVE TINES

;RESTORE ALL REGISTERS

EPPOPS a 0

Fiqure 3. Listing for BINDEC running on the MC6809 microprocessor

practice (i.e., no selfmodifying code and restoration of registers).

The Z80 comes out of the comparison fairly well in quantitative terms. Its version of BINDEC (Table 1 ) is reentrant and requires no RAM (Figure 1 ). The large number of registers is seen to be very useful in this respect. Stacking all of the registers, however, adds considerably to the source length and unstacking in the correct order is sensitive to error. Transfer to the alternative register set would have destroyed reentrancy and is a rather irregular instruction.

The lack of orthogonality of the Z80 instruction set becomes apparent (Figure 1, lines 23-24) in that 16-bit operations cannot be indexed, nor can DE be loaded directly from memory. Use of the DJNZ instruction fixes B as the loop counter; had BC been used as an index, instead of IY, the object code might have been consid- erably shorter. The use of XOR A as a clear instruction is common practice in Z80 programming, but is undesirable from the point of understanding the program. Similar comments might be made for the need for a carry set/ complement sequence to clear the carry before doing a 16-bit subtraction (Figure 1, lines 20-25). This is necessary because there is no 16-bit subtraction without carry (although there are 16-bit adds with and without

carry). Multiple precision 8-bit arithmetic probably is more practical, in both quantitative and subjective respects, than the existing 16-bit instructions which are available in the Z80.

The MC6800 does not do particularly well in the quantitative comparison (Table 1 ). The program (Figure 2) require s RAM, is not reentrant and is not relocatable. The lack of a second index register, or even PSHX/PULX instructions, is the greatest failing of the MC6800. The need to save the index is detrimental to understanding the pro- gram, as well as increasing source and object size.

The strong point of the MC6800 is its clean, simple and fairly orthogonal instruction set and uniform treatment of flags. The MC6800 is somewhat better than the Z80 in modes of operation since most instructions allow immed- iate operands and direct memory addressing. Unfortun- ately, BINDEC does not demonstrate these normally useful features.

Comparison of the three versions of BINDEC (Table 1) shows that the MC6809 is quantitatively superior to both the X80 and the MC6800. Source code length is nearly half that of the two older processors and the object size is considerably smaller. The routine for the MC6809 is both reentrant and relocatable, while in the Z80 the routine is not relocatable and in the MC6800 it is neither.

vol 5 no 9 november 1981 403

LOCATION OB3ECT CODE LINE

1 2 3 4 5 6 7 8 9

1o 0000 36 36 11 0002 31 8D0o19 12

13 0006 6F 84 14 ogoB A3 A4 15 O00A 25 04 16 O00C 6C 84 17 O00E 20 F8 18

19 o010 E3 AI 20 0012 36 02 21 0014 Ab 84 22 0016 SB 30 23 0018 A7 BO 24 O01A 37 02 25

26 001C 69 A4 27 O01E 2A E6 28

29 0020 37 36 30 0022 39 31

32 33

0023 2710 34 0025 03E8 35 0027 0064 36 0029 O00A 37 O02B 0001 38 O02D FF 39

Errors= 0

Figure 3.

SOURCE LINE

"6809"

BINDEC PSNU LEAY

NEXT 10 CLR SUBTRACT SUBD

8CS INC BRA

ADDITION ADg9 PSHU LgA ADDA STA PULU

TST BPL

P ULU RTS

CONSTANTS FDB FDB FDB FDB FDB

CONSTANTS END FCB

B I N D E C 0 9

CONVERT A:B (9 ) TO ASCI I STRING POINTED TO BY X

ALL REGISTERS ARE RETURNED UNDISTURBED ROUTINE I 8 RE-ENTRANT ~ND RE-LOC&TABLE

X , Y , ~ , B CONBTANTB,PCR

O,X ,Y ADDITION ,X SUBTRACT

~Y++ A ,X 030H ~X+ A

,Y NEXT10

A,B,X,Y

10000 r i o 0 100 10 1 255

Listing for BINDEC running on the MC6809 microprocessor

;SAQE REGISTERS USED ;POINT TO CONSTANTS

;CLEAR COUNT [0, sets assembler] ;SUSTRACT TABLE VALUE ;AND RESTORE IF UNDIERFLOW ;ELSE INCREMENT THECOUNT ;AND KEEP SUBTR&CTING

;RESTORE UNDERFLOW ;SAVE A TEMPORARILY ;PICK UP THE COUNT ;MJM(E TO ASCII NUNBER ;SAVE AND INX ;RESTORE A

;CHECK AT TABLE END ;KEEP GOING IF NOT

;ELSE RESTORE REGISTERS ;AND RETURN

The subjective aspects of the MC6809 appear favourable, in most respects. The instruction set is more orthogonal than either of the other two microprocessors and is much 'cleaner' in eliminating special cases of instructions and simplifying the set of instructions. The indexing modes are elegant, simple and extremely powerful. The auto incre- ment/decrement modes are particularly useful. The 16-bit addition and subtraction instructions are an improvement over multiple precision operations or irregular 16-bit in- structions. The monolithic register push/pull instruction not only shortens the source and object, but ensures that registers will be restored in the proper order.

CONCLUSIONS

In spite of the overall excellence of the MC6809, there are still a few failings. Some of these have been carried over from the MC6800. Those noticed are:

• some lack of orthogonality in the 16-bit instructions - e.g. no carry arithmetic instructions (ADCD), no 16-bit shifts, no logical D instructions, etc. Lack of carry instructions preclude using ADDD/SUBD to implement multiple precision arithmetic

• the use of the concatenated A:B registers as the D reg- ister is poor. This can lead to circuitous programming, as in BINDEC (Figure 3, lines 21-25) where A must be pushed to allow the ASCII value to be created. Worse still, this is a source of potential programming error

• use of the MC6800 immediate mode syntax (#pref ix) which is not easily distinguishable from a memory oper- ation. This is the most consistent error made by this

author when programming the MC6800 • the MC6809 is short of registers. A separate D register

and a third index register would have added considerably to the device. Many routines require an input buffer, a table pointer and an output buffer - using the U stack is possible, but lacks the desired straightforwardness.

These failings are minor in the face of the advantages of the MC6809. The two index registers, two stacks and complete stacking operations give the sort of 'register power' missing in the MC6800. The utilitarian, largely orthogonal instruc- tion set is more complete, yet simpler than that of the Z80. When these features are combined with the powerful index- ing modes available and with the more attractive subjective factors, this device appears superior to both the Z80 and the MC6800 - even for low level ROM-based applications which do not exploit the more exotic features of the MC6809.

R E F E R E N C E S

1 Ritter, T and Boney, J 'A microprocessor for the revolu- tion: the 6809' Byte (January 1979) pp 14-42

2 Cherlin, M 'High-level languages for microcomputers' Mini-Micro Systems (April 1980) pp 89-110

3 Caudill, P 'Using assembly coding to optimize high-level language programs' Electronics (1 February 1979) pp 121-124

4 'PGM5 binary to decimal conversion routine' M6800 Microprocessor Programming Manual Motorola, USA (1976) p 10

404 microprocessors and microsystems