ALPP 02-07 -- A Note on Byte Widening and Scratch Registers on the 6800, 6801, and 6809

A Note on Byte Widening and Scratch Registers
on the 6800, 6801, and 6809

(Title Page/Index)

 

I briefly mentioned, in the introduction to byte arithmetic chapter on the 6800, 6801, and 6809, the necessity of expanding byte data to 16-bit to use the 6801 and 6809's ADDD and SUBD instructions. I gave a more concrete example of byte widening in the 68000's chapter on byte arithmetic that we just finished.

In the 68000, the data registers are plenty wide enough. All we need to do, in the case of unsigned byte widening, is to make sure that, before we load the byte, enough of the register is cleared out to hold the target width.

In the case of signed byte widening for the 68000, we can use the sign-EXTend instruction after loading the byte value, which we will take a look at later.

(Other 16-bit and wider CPUs have load instructions that automatically sign-extend or zero-extend registers on load, instead.)

Let's look at how we can widen a byte on the 6800.

Hmm? What? The 6800 doesn't have a 16-bit add, you say?

Well, yeah, but, (mutter, mumble, ...) actually, when we cleared A out before we used ADCA #0 and SBCA #0, we were effectively performing a byte widening. We just used an immediate zero byte as the high byte of the widened source.

Why are you looking at me like that?

Sigh. Okay, remember, add with carry (ADC) allows us to expand the width of the ADD instruction. So we can synthesize a sixteen-bit add quite easily:

NLFT	FDB	132	; 132 in two bytes, high byte zero
NRT	FDB	188	; 188 in two bytes, high byte zero
RES	RMB	2	; 2-byte result
	...
	LDAB	NLFT+1	; Get the left low byte.
	LDAA	NLFT	; Get the left high byte.
	ADDB	NRT+1	; Add the right low byte.
	ADCA	NRT	; Add the right high byte.
	STAB	RES+1	; Store the result low byte.
	STAA	RES	; Store the result high byte.

And there's your 16-bit add. Just takes 6 instructions. >:-)

Comparing that to the 6801 and 6809, same declarations as above:

NLFT	FDB	132	; 132 in two bytes, high byte zero
NRT	FDB	188	; 188 in two bytes, high byte zero
RES	RMB	2	; 2-byte result
	...
	LDD	NLFT	; Get the left 16-bit word.
	ADDD	NRT	; Add the right 16-bit word.
	STD	RES	; Store the result 16-bit word.

3 instructions.

Okay, it takes a few more than 6 on the 6800 if we need to get the flags perfectly right, but we don't usually need to get the flags perfect for addition. Hardly ever, really. The Carry is correct, and so is the Negative. The Zero only reflects the high byte, which is wrong, but we have ways to handle that. So we're good for most purposes on the 6800 -- for addition. 

If we need to test for zero results, we can check that Carry is clear first, then OR the result low and high bytes together. If carry was set, we know the result was $10000 or greater, so, non-zero. ORing the low and high bytes together will leave non-zero if either was non-zero, so that completes the test. (I can make it sound simple, right? It's simple here because we have two copies of the result, one in memory and one in the accumulators. There is more to this, but I don't want to get too distracted. We'll come back to it.)

And in another point of fact, because loads and stores don't affect the carry flag, we could do all that math in 6 instructions just using a single accumulator instead of using both.

So, let's take that as a jumping-off point, declare the values we're adding as bytes again, and expand before adding. We'll start by declaring a byte of scratch RAM,  preferably in the direct page:

SCRTCH	RMB	1	; preferably in DP
	...
NLFT	FCB	132	; 132 in one byte
NRT	FCB	188	; 188 in one byte
RES	RMB	2	; 2-byte result
	...
	CLRA		; A high byte of zero
	STAA	SCRTCH	; Another high byte of zero
	LDAB	NLFT	; Get the left byte.
	ADDB	NRT	; Add the right byte.
	ADCA	SCRTCH	; Add the widening bytes.
	STAB	RES+1	; Store the result low byte.
	STAA	RES	; Store the result high byte.

So, do you believe me now?

Let's look at that on the 6801 (and 6809, by translating LDAB to LDB):

SCRTCH	RMB	2	; preferably in DP
	...
NLFT	FCB	132	; 132 in one byte
NRT	FCB	188	; 188 in one byte
RES	RMB	2	; 2-byte result
	...
	CLRA		; A high byte of zero
	LDAB	NRT
	STD	SCRTCH	; widened 16-bit word
	LDAB	NLFT	; Get the left byte, A still clear.
	ADDD	SCRTCH	; Add the widened 16-bit word.
	STD	RES	; Store the result high byte.

Because the D register operators need 16-bit operands, widening for the 6801 and 6809 requires two bytes of scratch RAM instead of one -- unless you're doing the math one byte at  a time, in which case you can still use the immediate zero argument to ADC as the source.

The above sources are slightly incomplete, so you might need to edit them a little to check what I am saying. Not much, but a little.

Subtraction is pretty similar, although we do care more about the flags after subtraction. 

By widening before we add or subtract, the addition and subtraction sequences can be made quite parallel. You might want to simply substitute SUBtract for ADD and SuBtract with Carry for ADd with Carry in the above code to see what happens.

I keep trying to go a bit further on the flags and such, but that is a distraction.

One thing that I need to make clear before we go, where the 68000 with lots of accumulator-equivalet data registers shows how natural byte widening is, having only one 16-bit accumulator makes byte widening on the 6801 and 6809 use scratch registers.

And I'm thinking we can now, after you've played with the subtraction code, move forward to doing proper 16-bit arithmetic. 

>:->

(Title Page/Index)

 

ALPP 02-06 -- Introduction to Byte Arithmetic on the 68000

Introduction to Byte Arithmetic
on the 68000

(Title Page/Index)

 

If you haven't already worked through the introduction to byte arithmetic on the 6800, 6801, and 6809, you should. I explained the byte math there, so I'm going to focus on 68000 code here, and on the differences between the 68000 code and the 6800/6801/6809 code. 

I'm going to show three different versions for the 68000. The first version follows, as closely as possible, the 6800/6801/6809 code. 

But to reduce the back-and-forth between the editor, the assembler, and the debugger, and to reduce the number of files to edit, I'm putting the addition and subtraction code together into a single file:

	OPT LIST,SYMTAB	; Options we want for the stand-alone assembler.
	MACHINE MC68000	; because there are a lot the assembler can do.
	OPT DEBUG	; We want labels for debugging.
	OUTPUT
***********************************************************************
* Adding and subtracting two 8-bit numbers in memory
* and storing them in memory,
* transliterating the 6800 code --
*
	EVEN
ENTRY	JMP	ADDM8


* The constants and result storage for the additions:

NL1	DC.B	34	; just an arbitrary small number
NR1	DC.B	66	; another arbitrary small number
C1	DS.B	1	; To hold one bit of carry from the sum.
R1	DS.B	1	; To hold the eight bit sum.

NL2	DC.B	132	; Somewhat larger arbitrary number
NR2	DC.B	188	; And another
C2	DS.B	1	; carry from 2nd sum
R2	DS.B	1	; 2nd sum


* I could have coordinated these better,
* But I'll rename the constants for the subtractions 
* to ML1, ML2, and ML3:

ML1	DC.B	66	; just an arbitrary small number
MR1	DC.B	34	; another arbitrary small number
RH1	DS.B	1	; To hold borrow/sign byte from the difference.
RL1	DS.B	1	; To hold the eight bit difference.

ML2	DC.B	132	; Somewhat larger arbitrary number
MR2	DC.B	188	; And another
RH2	DS.B	1	; borrow/sign from 2nd difference
RL2	DS.B	1	; 2nd difference

ML3	DC.B	34	; just an arbitrary small number
MR3	DC.B	66	; another arbitrary small number
RH3	DS.B	1	; To hold borrow/sign byte from the difference.
RL3	DS.B	1	; To hold the eight bit difference.



	EVEN
ADDM8	CLR.B	D6	; clear a register for the carry bit
	MOVE.B	NL1,D7	; Get the augend (left side addend).
	ADD.B	NR1,D7	; Add the addend (right side addend).
* 8-bit result is safely in D7.
	ROXL.B	#1,D6	; Recover the eXtend carry bit.
	MOVE.B	D6,C1	; Save it away.
	MOVE.B	D7,R1	; Save the sum itself.
*
	CLR.B	D6	; 2nd carry bit
	MOVE.B	NL2,D7	; 2nd augend (left side addend)
	ADD.B	NR2,D7	; 2nd addend (right side addend)
	MOVE.B	D7,R2	; 2nd sum, 8 bits
* MOVE does not alter X bit, carry eXtend still safe.
	ROXL.B	#1,D6	; 2nd carry bit
	MOVE.B	D6,C2	; Save it away.
* Could also use the ADDX.B with D5 pre-cleared method
* used in the subtraction examples below.
*
	NOP
	NOP


SUBM8	CLR.B	D5	; Need a constant zero. (No SUBX #0,Dn.)
	CLR.B	D6	; clear register D6 for the borrow/sign extension
	MOVE.B	ML1,D7	; Get the minuend (left side).
	SUB.B	MR1,D7	; Subtact the subtrahend (right side).
* Result is safely in D7.
	SUBX.B	D5,D6	; Recover the eXtend borrow bit, sign extended.
	MOVE.B	D6,RH1	; Save high byte away.
	MOVE.B	D7,RL1	; Save the difference low byte.
*
	CLR.B	D5	; should still be clear, actually.
	CLR.B	D6	; 2nd sign extension
	MOVE.B	ML2,RL2	; 2nd minuend to memory, just because we can
	MOVE.B	MR2,D7	; 2nd subtrahend in register
	SUB.B	D7,RL2	; 8-bit result safely saved away
	SUBX.B	D5,D6	; 2nd borrow, sign extended
	MOVE.B	D6,RH2	; Save high byte away.
*
	CLR.B	D5	; Again, should still be clear.
	CLR.B	D6	; 3rd borrow bit
	MOVE.B	ML3,D7	; 3rd minuend (left side)
	SUB.B	MR3,D7	; 3rd subtrahend (right side)
	MOVE.B	D7,RL3	; Save 8-bit result away
* MOVE does not alter X bit, borrow eXtend still safe.
	SUBX.B	D5,D6	; 3rd borrow, sign extended.
	MOVE.B	D6,RH3	; Save it away.
*
	NOP
	NOP

The comments pretty much explain what I've done with the variable names, also pretty much what is going on in the code. 

Go ahead and open up a second browser window with the 6800/6801/6809 code and compare.

You can see that we can use memory and registers in much the same way as on the 8-bit processors, with some odd exceptions. 

You'll note that having lots of data registers gives us more options in how to organize our code. In some places, I deliberately altered some steps to show that. But, in other places, I was forced to make some changes because of those odd exceptions. 

Other than having lots of registers, specific things to pay attention to:

(1) Rotating bits into memory is limited to 16-bit wide memory targets. We can't rotate only 8 bit targets in memory. But we can rotate 8-bit targets in a data register, so we do that. 

Speaking of rotating, rotates and shifts on the 68000 do not use the Carry flag!

They use the eXtended carry flag, thus, we have the mnemonic, ROXL.

Why not ROL? 

Lemme 'splain!

Rotating through carry is actually a 9-bit rotate.

That's 8 bits in the target plus the carry (on the 6800, etc.) or the eXtended carry (on the 68000). 

So you don't really have an 8-bit rotate on the 6800/6801/6809. 

Fortunately, 9 bit rotates is what is most common, but, if 9 bits is too many, you have to short-circuit the carry with some odd logic that I'm not going to show yet. 

The 68000 gives you true 8-bit rotates -- and 16-bit and 32-bit -- without going through the (eXtended) carry, and ROtate Left by 8/16/32 bits (without going through the eXtended carry) is what ROL and ROR mean on the 68000.

Erk. Lot's of explanation we didn't think we wanted just here, but keep it in mind. It'll come in useful later. Or, perhaps, it's a waste of micro-instructions in the 68000 CPU, but that's something to think about later.

Anyway, that's part of what's behind the differences in the bit rotation code.

(Why split the carry function into Carry and eXtended carry? 

SHHHH! 

You're not supposed to ask that. 

Heh. Yet.)

(2) The Carry flag is cleared by MOVEs. The eXtended carry flag is not. This allows some variation in execution order with the X flag, which can come in handy sometimes. It also forces execution order sometimes.

(3) Instead of ADd with Carry (ADC) and SuBtract with Carry (SBC), the 68000 has ADD with eXtend and SUBtract with eXtend, ADDX and SUBX.

... aaaaand ...

Where other instructions on the 68000 are really flexible as to where the source or target are, the ADDX, SUBX, and CMPX instructions are not.

You can ADDX, SUBX, or CMPX two registers. Not memory-to-register, not register-to-memory. Or you can ADDX or SUBX memory-to-memory in auto-increment mode. And you can CMPX memory-to-memory in auto-decrement mode.

No immediate mode operands. No ADDX #0.

ARRRGGGGGGHHHHHHH!!!!!!     WHY?!?!?!?!?!?

Sigh. There is reason to this madness, sort-of. Maybe just madness. We'll come back to this.

For now, it can be made to work by using another register to hold the zero.

Yes, that RISC trick.

Well, a partial response to the madness is due here. The 68000 design project began about the time certain departments within IBM were just digging into the 801 processor. Patterson would not go on sabbatical to DEC for a couple of years yet. Not just Motorola, everybody was exploring unknown territory, going boldly where no man (in history) had gone before. Motorola made some mistakes. We all made mistakes -- and are now living with the consequences.

RISC isn't the Holy Grail, anyway.

Guys like me will daydream about what might have been, but daydreaming has limits. 

We can work with less-than-optimal. With some care, we can get pretty close to the what should have been, and that's why I'm writing this tutorial.

Let me step off the soap box, and we'll take a look at some nifty gadgetry in the 68000 that provides an alternate way of doing this. But first, copy the code to a text file, save it, maybe as arithm8.s or something, and assemble it with something like

$ vasmm68k_mot -Ftos -no-opt -o ARITHM8.PRG -L arithm8.lst arithm8.s

Get Hatari running, go through the 

CTRL-Z, CD to the target emulated directory, ALT-BREAK, set the "b pc = TEXT :once" breakpoint, (c)ontinue 

protocol and use the debugger to (s)tep through the code, showing (r)egister and (m)emory contents as appropriate.  

The final results in memory should be

> m TEXT 20
00013D10: 4e f9 00 01 3d 2a 22 42 00 64 84 bc 01 40 42 22   N...=*"B.d...@B"
00013D20: 00 20 84 bc ff c8 22 42 ff e0 42 06 1e 39 00 01   . ...."B..B..9..

Well, the actual address of TEXT should be (may be?) different, but the contents should be there. Showing the results you want in red (after the numbers we added and subtracted in blue):

4e f9 00 01 3d 2a 22 42 00 64 84 bc 01 40 42 22
00 20 84 bc ff c8 22 42 ff e0 42 06 1e 39 00 01

And you'll notice that I'm so focused I didn't include exit code. That's okay, just (q)uit when you're done.

Okay, that nifty gadgetry I promised:

	OPT LIST,SYMTAB	; Options we want for the stand-alone assembler.
	MACHINE MC68000	; because there are a lot the assembler can do.
	OPT DEBUG	; We want labels for debugging.
	OUTPUT
***********************************************************************
* Adding and subtracting two 8-bit numbers in memory
* and storing them in memory,
* Using the Set conditional instruction to capture the Carry/borrow bit
* instead of the eXtended carry/borrow bit 
*
	EVEN
ENTRY	JMP	ADDM8


* The constants and result storage for the additions:

NL1	DC.B	34	; just an arbitrary small number
NR1	DC.B	66	; another arbitrary small number
C1	DS.B	1	; To hold one bit of carry from the sum.
R1	DS.B	1	; To hold the eight bit sum.

NL2	DC.B	132	; Somewhat larger arbitrary number
NR2	DC.B	188	; And another
C2	DS.B	1	; carry from 2nd sum
R2	DS.B	1	; 2nd sum


* I could have coordinated these better,
* But I'll rename the constants for the subtractions 
* to ML1, ML2, and ML3:

ML1	DC.B	66	; just an arbitrary small number
MR1	DC.B	34	; another arbitrary small number
RH1	DS.B	1	; To hold one bit of borrow from the difference.
RL1	DS.B	1	; To hold the eight bit difference.

ML2	DC.B	132	; Somewhat larger arbitrary number
MR2	DC.B	188	; And another
RH2	DS.B	1	; borrow from 2nd difference
RL2	DS.B	1	; 2nd difference

ML3	DC.B	34	; just an arbitrary small number
MR3	DC.B	66	; another arbitrary small number
RH3	DS.B	1	; To hold one bit of borrow from the difference.
RL3	DS.B	1	; To hold the eight bit difference.



	EVEN
ADDM8	CLR.B	C1	; clear memory for the carry bit/sign byte
	MOVE.B	NL1,D7	; Get the augend (left side addend).
	ADD.B	NR1,D7	; Add the addend (right side addend).
* Result is safely in D7, carry in C,
* But a MOVE will destroy the Carry in C.
	SCS	C1	; Recover the Carry bit.
	AND.B	#1,C1	; Mask off the unnecessary bits.
	MOVE.B	D7,R1	; Save the 8-bit sum itself.
*
	CLR.B	C2	; memory for 2nd carry bit/sign byte
	MOVE.B	NL2,R2	; 2nd augend to result memory
	MOVE.B	NR2,D7	; 2nd addend to a register
	ADD.B	D7,R2	; 8-bit result safely stored
* A MOVE will destroy the Carry in C.
	SCS	C2	; 2nd carry bit
	AND.B	#1,C2	; Mask off the unnecessary bits.
*
	NOP
	NOP


SUBM8	CLR.B	RH1	; memory for 1st borrow/sign byte
	MOVE.B	ML1,D7	; Get the 1st minuend (left side).
	SUB.B	MR1,D7	; Subtact the 1st subtrahend (right side).
* Result is safely in D7, borrow in C,
* But a MOVE will destroy the borrow in C.
	SCS	RH1	; 1st sign byte/borrow, DO NOT MASK!
	MOVE.B	D7,RL1	; Save the result low byte.
*
	CLR.B	RH2	; 2nd borrow/sign extension
	MOVE.B	ML2,RL2	; 2nd minuend (left side) to memory
	MOVE.B	MR2,D7	; 2nd subtrahend (right side)
	SUB.B	D7,RL2	; 2nd result safely stored.
* A MOVE will destroy the borrow in C.
	SCS	RH2	; 2nd borrow, sign extended
*
	CLR.B	D6	; 3rd borrow/sign byte in register
	MOVE.B	ML3,D7	; 3rd minuend (left side)
	SUB.B	MR3,D7	; 3rd subtrahend (right side)
	SCS	D6	; Get sign/borrow in regiser
* A MOVE will destroy the borrow in C.
	MOVE.B	D7,RL3	; Save 3rd difference, low byte.
	MOVE.B	D6,RH3	; Save sign/borrow away.
*
	NOP
	NOP

(1) Set conditionally is an interesting instruction. You can set a byte to all 1s on the specified condition. It does not text eXtended carry, but it does test Carry. So you can use Set Carry Set (SCS) immediately after an ADD or SUBtract or such, but if you do a MOVE, the Carry is gone.

(2) After an ADD, since we only want the borrow/carry from the high bit of the byte, all 1s from a SCS is too many 1s. So we can mask all but the bottom 1 out with AND immediate 1.

(3) AND is one of several instructions that can operate directly on memory, so if the target of SCS is in memory, we can mask the target directly. 

Note that it takes more time to mask something in memory, because the processor has to read it out of memory into an hidden latch to work on it, then write it back. This is true of any operator that works directly on memory, including the Set conditionally operators. So there are trade-offs.

(3) After a SUBtract, SCS setting all ones on borrow is actually what we want, since all 1s is how we know it's negative. So there's no need to mask after a subtract.

(4) ADD and SUBtract are also operators that can work directly on memory. Again, they take more time operating on memory than they do operating on registers.

Oddly enough, for as nifty as this Set conditionally and operate-directly-on-memory gadgetry is nifty, it turns out not to be very exciting. But that is not necessarily bad. 

After stepping through and watching the registers and memory, make one final check to see that the values store are correct as in the first example, com;pare below: 

00013D10: 4e f9 00 01 3d 2a 22 42 00 64 84 bc 01 40 42 22   N...=*"B.d...@B"
00013D20: 00 20 84 bc ff c8 22 42 ff e0 42 39 00 01 3d 18   . ...."B..B9..=.

Not that the instructions following the results are different from the first example, as they should be. Showing the results in red again:

4e f9 00 01 3d 2a 22 42 00 64 84 bc 01 40 42 22
00 20 84 bc ff c8 22 42 ff e0 42 39 00 01 3d 18

Finally, thinking about the 6801 and 6809's double accumulator instructions, the 68000 has the ability to do both 16-bit and 32-bit math and loads and stores.

But it has no easy way to concatenate the least significant bytes of two registers similar to the 6801/6809 double accumulator instructions. Well, okay, it's not that hard, I guess, but it's harder than just being able to STD.

And there are restrictions, such as 16-bit and 32-bit operands in memory have to be 16-bit aligned. (Some of the later processors in the family relax this requirement.)

To see how that will play out on the 68000, here's some code:

	OPT LIST,SYMTAB	; Options we want for the stand-alone assembler.
	MACHINE MC68000	; because there are a lot the assembler can do.
	OPT DEBUG	; We want labels for debugging.
	OUTPUT
***********************************************************************
* Adding and subtracting two 8-bit numbers in memory
* and storing them in memory,
* Using 68000's 16-bit arithmetic --
*
	EVEN
ENTRY	JMP	ADDM8
* Instructions are always on even boundaries, 
* and use an even number of bytes.

* Remember that the 68000 requires 16-bit and 32-bit accesses 
* to be on 2-byte even boundaries.

* The constants for the additions:

NL1	DC.B	34	; just an arbitrary small number
NR1	DC.B	66	; another arbitrary small number
	EVEN
NSUM1	DS.W	1	; 2 bytes to hold carry/sign and 8-bit sum
NDH1	EQU	NSUM1	; carry/sign byte
NDL1	EQU	NSUM1+1	; 8-bit sum

NL2	DC.B	132	; Somewhat larger arbitrary number
NR2	DC.B	188	; And another
	EVEN
NSUM2	DS.W	1	; carry/sign and 8-bit sum
NDH2	EQU	NSUM2	; carry/sign byte
NDL2	EQU	NSUM2+1	; 8-bit sum


* I could have coordinated these better,
* But I'll rename the constants for the subtractions 
* to ML1, ML2, and ML3:

ML1	DC.B	66	; just an arbitrary small number
MR1	DC.B	34	; another arbitrary small number
	EVEN
MDIFF1	DS.W	1	; borrow/sign and 8-bit differenc
MDH1	EQU	MDIFF1	; To hold borrow/sign from the difference.
MDL1	EQU	MDIFF1+1	; To hold the eight bit difference.

ML2	DC.B	132	; Somewhat larger arbitrary number
MR2	DC.B	188	; And another
	EVEN
MDIFF2	DS.W	1	; borrow/sign and 8-bit differenc
MDH2	EQU	MDIFF2	; borrow/sign from 2nd difference
MDL2	EQU	MDIFF2+1	; 2nd difference

ML3	DC.B	34	; just an arbitrary small number
MR3	DC.B	66	; another arbitrary small number
	EVEN
MDIFF3	DS.W	1	; borrow/sign and 8-bit differenc
MDH3	EQU	MDIFF3	; To hold borrow/sign from 3r difference.
MDL3	EQU	MDIFF3+1	; 3rd eight bit difference.



	EVEN
ADDM8	CLR.W	D6	; Prepare left side for 16-bit math.
	MOVE.B	NL1,D6	; Get the augend (left side addend).
	CLR.W	D7	; Prepare right side for 16-bit math.
	MOVE.B	NR1,D7	; Get the addend (right side addend).
	ADD.W	D7,D6	; Add right into left.
* Result is safely in D6, including carry.
	MOVE.W	D6,NSUM1	; Save the 8-bit sum along with the carry/sign.
*
	CLR.W	D6	; Prepare left side for 16-bit math.
	CLR.W	D7	; Prepare right side for 16-bit math.
	MOVE.B	NL2,D6	; Get the augend (left side addend).
	MOVE.B	NR2,D7	; Get the addend (right side addend).
	ADD.W	D7,D6	; Add right into left.
* Result is safely in D6, including carry.
	MOVE.W	D6,NSUM2	; Save the 8-bit sum along with the carry/sign.
*
	NOP
	NOP

SUBM8	CLR.W	D6	; Prepare left side for 16-bit math.
	MOVE.B	ML1,D6	; Get the minuend (left side).
	CLR.W	D7	; Prepare right side for 16-bit math.
	MOVE.B	MR1,D7	; Get the subtrahend (right side).
	SUB.W	D7,D6	; Subtract right from left.
* Result is safely in D6, including carry.
	MOVE.W	D6,MDIFF1	; Save the 8-bit sum along with the carry/sign.
*
	CLR.W	D6	; Prepare left side for 16-bit math.
	CLR.W	D7	; Prepare right side for 16-bit math.
	MOVE.B	ML2,D6	; Get the minuend (left side).
	MOVE.B	MR2,D7	; Get the subtrahend (right side).
	SUB.W	D7,D6	; Subtract right from left.
* Result is safely in D6, including carry.
	MOVE.W	D6,MDIFF2	; Save the 8-bit sum along with the carry/sign.
*
	CLR.W	D6	; Prepare left side for 16-bit math.
	MOVE.B	ML3,D6	; Get the minuend (left side).
	CLR.W	D7	; Prepare right side for 16-bit math.
	MOVE.B	MR3,D7	; Get the subtrahend (right side).
	SUB.W	D7,D6	; Subtract right from left.
* Result is safely in D6, including carry.
	MOVE.W	D6,MDIFF3	; Save the 8-bit sum along with the carry/sign.
*
	NOP
	NOP

Check the results:

00013D10: 4e f9 00 01 3d 2a 22 42 00 64 84 bc 01 40 42 22   N...=*"B.d...@B"
00013D20: 00 20 84 bc ff c8 22 42 ff e0 42 46 1c 39 00 01   . ...."B..BF.9..

The sums and differences in red:

4e f9 00 01 3d 2a 22 42 00 64 84 bc 01 40 42 22
00 20 84 bc ff c8 22 42 ff e0 42 46 1c 39 00 01

The comments do tell a lot about what is happening, but they are a little terse.

Knowing what the code looks like, I can say that all the EVEN directives in there are unnecessary. But I put them in for emphasis, and just in case I do something strange with the code later when I've forgotten a lot about it. And for anyone else who needs to read the code.

I hope the data declarations and allocations are clear enough. Unlike high-level languages, assembler can't enforce the intended access widths and boundaries. The best we can do is provide labels where access is intended, with comments about the intended width. Trailing equates can help when you intend alternate access points and widths.

Why am I using 16-bit addition and subtraction here, when the 6800, etc. code did not?

If we use byte addition and subtraction, we end up with the carry/borrow in the flags, but not in the register. That means we have to have instructions to bring it in, which we have already seen. We're trying to avoid that.

Well, there's an approach I haven't mentioned, using branches, but I am deliberately avoiding that. It looks like this:

	...
ADDM8	MOVE.B	NL1,D7	; Get the augend (left side addend).
	ADD.B	NR1,D7	; Add the addend (right side addend).
	BCC.S	ADDM8NC
	OR.W	#$0100,D7	; set bit 8
	BRA.S	ADDM8M
ADDM8NC	AND.W	#$FEFF,D7	; clear bit 8
ADDM8M	AND.W	#$01FF,D7	; clear the rest
	MOVE.W	D7,NSUM1	; Save the 8-bit sum along with the carry/sign.
	...
SUBM8	MOVE.B	ML1,D7	; Get the minuend (left side).
	SUB.B	MR1,D7	; Subtract the subtrahend (right side).
	BCC.S	SUBM8NB
	OR.W	#$FF00,D7	; set the borrow/sign
	BRA.S	SUBM8M
SUBM8NB	AND.W	#$00FF,D7	; clear the borrow/sign
SUBM8M	MOVE.W	D7,MDIFF1	; Save the 8-bit sum along with the carry/sign.
	...

For the addition code, the 68000 Bit Set (BSET) and Bit Clear (BCLR) instructions could also be used, but you still have to mask off the remaining bits with the final AND.W, because you don't know what they were when you started.

And I am deliberately avoiding mentioning that, you understand.

:-/

If you're wondering, it's good to avoid branches if it doesn't cost too much to do so.

Back to the file we were working on -- because we are going to use word arithmetic to do byte math, we need to clear the lower 16 bits of the registers we are using. Otherwise, we don't know what's up there in the higher order byte, and it's likely to be stuff that trashes our results.

We can clear both words and then load both words, or we can clear and load and clear and load. Either way.

We clear them because the bytes are unsigned. If the were signed, we could use the EXT.W instruction to sign-extend them after loading, instead.

This is a pattern on the 68000 -- for extending unsigned data that will be widened, you clear the width you need before loading the data. For extending signed data, you load and then sign EXTend the data.

After that, I hope it's all straightforward. Do the math in 16-bit width, store the result in 16-bit width. Subtracting at the wider width takes care of the high byte for you. 

Does this feel like the approach we should have been looking at from the start? I hope so.

By the way, RISC CPUs use this approach pretty much exclusively. It's part of the concept of RISC.

While we're talking about it, how would we go about expanding the 8-bit operands to use 16-bit math on the 6809?  Maybe we should take a quick look at that next.

(Title Page/Index)

 

ALPP 02-05 -- Introduction to Byte Arithmetic on the 6800, 6801, and 6809

Introduction to Byte Arithmetic
on the 6800, 6801, and 6809

(Title Page/Index)

 

In the last four chapters, we reused the Hello World example to introduce and demonstrate the use of a separate parameter stack, first, synthesizing the parameter stack in software on the 6800, and 6801, then using the advanced addressing capabilities of the 6809 and  68000 to directly implement the parameter stack using the CPU's own instructions.

It may have been a little deep. 

It's okay. It just gets deeper. But in this chapter, we're going to relax a bit and get a better feel for some of the fundamentals of arithmetic on digital logic processors. 

8-bit CPUs generally work on data in 8-bit bytes. (Other size bytes have existed.)

Just as a reminder, the word "byte" is a pun. This is bite-sized data, so to speak. But you knew that. You also knew that there are other byte sizes than 8 bits, right? 

The 6800, 6801, and 6809 all have 8-bit bytes. So do the members of the 68000 family, although their natural integer width is 16 or 32 bits. They address memory in 8-bit bytes.

Eight bits (binary digits) in a latch yield 256 discrete values. These values can represent, among many other things, up to 256 states in a control system, up to 256 characters (as in ASCII or EBCDIC text) in a small character set, or small integers. One common thing to have them represent is the unsigned small integers 0 to 255_ten. 

Eight bits could also represent signed small integers, such as -128_ten to +127_ten, or -127_ten to -0 and +0 to +127_ten, but we'll set signed integers aside for a moment. (Sort-of. Just a moment.)

Let's take a closer look at adding small unsigned integers. 

One question that arises when you know you can only represent numbers from 0 to 255 is what happens when you go over 255?

What happens when you go over nine in a column when adding decimal (base ten) numbers by hand? Let's see if we can remember:

 34
+66
---
???

First column adds up to ten. Write down your zero, carry your one to the next column:

 1  (carries)
 34
+66
---
__0

Nine and the carried one makes ten in the second column, write down the zero, carry the one:

11  (carries)
 34
+66
---
_00

And so forth.

11  (carries)
 34
+66
---
100

Let's replay that in hexadecimal:

 22
+42
---
???

Two and two is four, no carry:

 0  (carries)
 22
+42
---
__4

Two and four is six, no carry:

00  (carries)
 22
+42
---
_64

Interesting. 64_sixteen is 100_ten. I wonder what 64_ten is in hexadecimal. :)

How would this sum look in binary?

 00100010
+01000010
---------
?????????

       0  (carries)
 00100010
+01000010
---------
________0


      10  (carries)
 00100010
+01000010
---------
_______00


     010  (carries)
 00100010
+01000010
---------
______100


    0010  (carries)
 00100010
+01000010
---------
_____0100

... and a few more uninteresting columns without carries until we get:

00000010  (carries)
 00100010
+01000010
---------
_01100100

Bit serial CPUs actually do that one bit at a time. But none of the processors we are working with are bit serial. The 8-bit processors all do eight bits in parallel. And the 68000 does sixteen bits in parallel.

So, what happens when you get a carry from the highest bit in a byte?

Consider a byte to be a column in base 256, and it is plain. You get a carry to the next byte.

Just like carries from column to column in base ten never exceed 1, and carries from column to column in hexadecimal never exceed 1, carries from column to column in binary never exceed 1, and carries in base 256 never exceed 1. 

So, when you go over 255 in unsigned byte additions in a CPU, you have a carry, of course. And the CPU, if it's a 6800, 6801, or 6809, records it in the (C)arry flag. 

There are other ways to do this, but most 8-bit CPUs do it this way.

So let's look at some code. 

We've done 8-bit additions before, using immediate constants. This time, we'll separate the numbers from the code and put them in global constants and variables (even though I've said global constants and variables are not what we generally want to do). Also, I'll be showing several different approaches, rather than just showing you some "optimal" subroutine. And we'll do something so we don't lose the Carry flag:

* Add two 8-bit numbers in memory and store them in memory:
*
ENTRY	JMP	ADDM8
*
NL1	FCB	34	; just an arbitrary small number
NR1	FCB	66	; another arbitrary small number
C1	RMB	1	; To hold one bit of carry from the sum.
R1	RMB	1	; To hold the eight bit sum.
*
NL2	FCB	132	; Somewhat larger arbitrary number
NR2	FCB	188	; And another
C2	RMB	1	; carry from 2nd sum
R2	RMB	1	; 2nd sum
*
*
ADDM8	CLR	C1	; clear storage for the carry bit
	LDAB	NL1	; Get the augend (left side addend).
	ADDB	NR1	; Add the addend (right side addend).
* Result is safely in B.
	ROL	C1	; Save the carry bit away.
	STAB	R1	; Save the sum itself.
*
	CLR	C2	; 2nd carry bit
	LDAB	NL2	; 2nd augend (left side addend)
	ADDB	NR2	; 2nd addend (right side addend)
	STAB	R2	; 2nd sum, 8 bits
* ST and LD do not alter C, carry still safe.
	ROL	C2	; 2nd carry bit
	NOP
	NOP

Assemble that and step through it on EXORsim running a 6800 instance:

$ ./exor --mon
Load facts file 'facts'
'exbug.bin' loaded.
  EXBUG-1.1 detected
'mdos.dsk' opened for drive 0 (double sided)

OSLOAD...

Hit Ctrl-C for simulator command line.  Starting simulation...

>         0 A=00 B=00 X=0000 SP=00FF ------          0020: B6 E8 00 LDA E800                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% a 2000
2000: * Add two 8-bit numbers in memory and store them in memory:
2000: *
2000: ENTRY	JMP	ADDM8
2003: *
2003: NL1	FCB	34	; just an arbitrary small number
2004: NR1	FCB	66	; another arbitrary small number
2005: C1	RMB	1	; To hold one bit of carry from the sum.
2006: R1	RMB	1	; To hold the eight bit sum.
2007: *
2007: NL2	FCB	132	; Somewhat larger arbitrary number
2008: NR2	FCB	188	; And another
2009: C2	RMB	1	; carry from 2nd sum
200a: R2	RMB	1	; 2nd sum
200b: *
200b: *
200b: ADDM8	CLR	C1	; clear storage for the carry bit
Address at 2001 set to 200B
200e: 	LDAB	NL1	; Get the augend (left side addend).
2011: 	ADDB	NR1	; Add the addend (right side addend).
2014: * Result is safely in B.
2014: 	ROL	C1	; Save the carry bit away.
2017: 	STAB	R1	; Save the sum itself.
201a: *
201a: 	CLR	C2	; 2nd carry bit
201d: 	LDAB	NL2	; 2nd augend (left side addend)
2020: 	ADDB	NR2	; 2nd addend (right side addend)
2023: 	STAB	R2	; 2nd sum, 8 bits
2026: * ST and LD do not alter C, carry still safe.
2026: 	ROL	C2	; 2nd carry bit
2029: 	NOP
202a: 	NOP
202b: 
% u 2000
2000: 7E 20 0B            JMP $200B
2003: 22 42               BHI $2047
2005: 00                  ???
2006: 00                  ???
2007: 84 BC               ANDA #$BC
2009: 00                  ???
200A: 00                  ???
200B: 7F 20 05            CLR $2005
200E: F6 20 03            LDB $2003
2011: FB 20 04            ADDB $2004
2014: 79 20 05            ROL $2005
2017: F7 20 06            STB $2006
201A: 7F 20 09            CLR $2009
201D: F6 20 07            LDB $2007
2020: FB 20 08            ADDB $2008
2023: F7 20 0A            STB $200A
2026: 79 20 09            ROL $2009
2029: 01                  NOP
202A: 01                  NOP
202B: 00                  ???
202C: 00                  ???
202D: 00                  ???
% s 2000

          0 A=00 B=00 X=0000 SP=00FF ------ ENTRY    2000: 7E 20 0B JMP 200B  EA=200B(ADDM8) 
>         1 A=00 B=00 X=0000 SP=00FF ------ ADDM8    200B: 7F 20 05 CLR 2005                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          1 A=00 B=00 X=0000 SP=00FF ------ ADDM8    200B: 7F 20 05 CLR 2005  EA=2005(C1)    
>         2 A=00 B=00 X=0000 SP=00FF ---Z--          200E: F6 20 03 LDB 2003                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          2 A=00 B=00 X=0000 SP=00FF ---Z--          200E: F6 20 03 LDB 2003  EA=2003(NL1) D=22 
>         3 A=00 B=22 X=0000 SP=00FF ------          2011: FB 20 04 ADDB 2004                

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          3 A=00 B=22 X=0000 SP=00FF ------          2011: FB 20 04 ADDB 2004 EA=2004(NR1) D=42 
>         4 A=00 B=64 X=0000 SP=00FF ------          2014: 79 20 05 ROL 2005                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          4 A=00 B=64 X=0000 SP=00FF ------          2014: 79 20 05 ROL 2005  EA=2005(C1)    
>         5 A=00 B=64 X=0000 SP=00FF ---Z--          2017: F7 20 06 STB 2006                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          5 A=00 B=64 X=0000 SP=00FF ---Z--          2017: F7 20 06 STB 2006  EA=2006(R1) D=64 
>         6 A=00 B=64 X=0000 SP=00FF ------          201A: 7F 20 09 CLR 2009                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          6 A=00 B=64 X=0000 SP=00FF ------          201A: 7F 20 09 CLR 2009  EA=2009(C2)    
>         7 A=00 B=64 X=0000 SP=00FF ---Z--          201D: F6 20 07 LDB 2007                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          7 A=00 B=64 X=0000 SP=00FF ---Z--          201D: F6 20 07 LDB 2007  EA=2007(NL2) D=84 
>         8 A=00 B=84 X=0000 SP=00FF --N---          2020: FB 20 08 ADDB 2008                

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          8 A=00 B=84 X=0000 SP=00FF --N---          2020: FB 20 08 ADDB 2008 EA=2008(NR2) D=BC 
>         9 A=00 B=40 X=0000 SP=00FF H---VC          2023: F7 20 0A STB 200A                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

          9 A=00 B=40 X=0000 SP=00FF H---VC          2023: F7 20 0A STB 200A  EA=200A(R2) D=40 
>        10 A=00 B=40 X=0000 SP=00FF H----C          2026: 79 20 09 ROL 2009                 

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% s

         10 A=00 B=40 X=0000 SP=00FF H----C          2026: 79 20 09 ROL 2009  EA=2009(C2)    
>        11 A=00 B=40 X=0000 SP=00FF H-----          2029: 01       NOP                      

6800 Monitor: Ctrl-C to exit, 'c' to continue, or type 'help'
% d 2000 10
2000: 7E 20 0B 22 42 00 64 84  BC 01 40 7F 20 05 F6 20 ~ ."B.d...@. .. 
%

In the first case, we didn't have a carry from the byte addition. Or, rather, the carry was 0, and the ROL instruction recovered the 0 carry.

 We see here that the ROL instruction on the 6800, 6801, and 6809 can be used to move (rotate) the carry bit into a register or a byte of memory.  

If you want, do it again on EXORsim6801, but it should do essentially the same thing. Since you're only looking at the values of registers while stepping through the code, there is no need to bother with either getting the terminal emulator's attention or with pausing at the end for this code on the 6801. You won't need to add the code to do that. Same code. Same execution.

Another way to capture the carry is to use the ADd with Carry instruction, adding the carry and an immediate zero to the zero in a cleared accumulator like this:

	CLRA	; 2nd carry bit
	LDAB	NL2	; 2nd augend (left side addend)
	ADDB	NR2	; 2nd addend (right side addend)
	STAB	R2	; 2nd sum, 8 bits
* ST and LD do not alter C, carry still safe.
	ADCA	#0	; 0 in A plus carry bit
	STAA	C2	; 2nd carry bit

I'm going to emphasize the comments in the above code -- LoaDs and STores do not affect the Carry flag on 680X CPUs. We can store the 8-bit result first and capture the carry after if we want.

Just for completeness, the 6801 and the 6809 will allow you to treat the carry byte and the 8-bit sum byte as a single 16-bit integer result, as well:

	...
NL1	FCB	34	; just an arbitrary small number
NR1	FCB	66	; another arbitrary small number
RES1	RMB 2	; 2-byte result
C1	EQU	RES1	; To look at the carry from the sum.
R1	EQU	RES1+1	; To look at the the eight bit sum.
	...
	CLRA	; clear storage for the carry bit
	LDAB	NL1	; Get the augend (left side addend).
	ADDB	NR1	; Add the addend (right side addend).
	ADCA	#0	; Save the carry bit away.
	STD	RES1	; Save the 9 bit result in 16 bits.

Note the STore Double accumulator at the end, instead of storing each accumulator separately.

I intentionally put the carry byte below the sum byte in memory to allow them to be treated together as a single 16-bit integer. This is the byte order the 6800, 6801, and 6809 use, most significant byte first. (68000, too.)

Using three labels, RES1 for the 16-bit result, and C1 and R1 for the separate halves of the result, helps make it clear which half of the integer you're looking at even if you forget which order they are in.

Now, if you want, you can try the above two variations. (I recommend it.) And when you're done playing with that on the 6800, edit the LDAB and LDAA instructions to LDB and LDA, and the STAB and STAA instructions to STB and STA, and assemble the code on a 6809 instance and step through it there as well. It will execute this code exactly the same except for timing (which you won't notice in the emulator), but it will give you a chance to practice and notice more about what goes on.

(You may be wondering whether it wouldn't be possible to do the math on the 6801 and 6809 using the 16-bit ADD Double and SUB Double accumulator instructions. It can be done, but you need more byte of memory because the ADDD and SUBD instructions want a 16-bit addend as well as the 16-bit augend.)

If you get really ambitious, you might use the (m)emory change command to change the constants that are getting added and step through again with different values, without editing the source code and re-assemlbing.

(Are the op-codes output for the source code on this also all the same on the 6809? You might want to check. 8-*)

It will run the same on all three.

So, what about subtraction?

Let's review how subtraction works when we do it on paper:

 66
-34
---
???

First column, difference is 2, no borrow.

 0     (borrow)
 66
-34
---
__2

Second column, difference is 3, no borrow.

00     (borrow)
 66
-34
---
_32

And we're done. That wasn't interesting -- at least, not obviously so. Let's look at something that generates a borrow.

 62
-34
---
???

First column, 2 minus 4 is minus 2. So we'll borrow a 1 from the next column over, subtracting 1 from that and adding 10 to this:

  -1       (borrow)
   6 12
  -3  4
  --  -
  __  8

Take the borrow from 6, that's 5.

 0-1     (borrow)
  65 12
  -3  4
  --  -
  _2  8

5 minus 3 is 2, no borrow generated, difference is 28.

What we did was use ten's complement math in the column that needed a borrow. We borrowed from the next column over because a 1 in that column is a 10 in this column, and we remembered to take the borrowed 1 away when we moved to the next column over.

We can do the same thing in hexadecimal (sixteen's complement), but that would be a distraction. 

We can also do the same thing in binary. This is called two's complement, and is very useful.

Of the two above differences, 66 minus 34 is the more interesting in binary:

 01000010  (66ten)
-00100010  (34ten)
---------
 ????????

Okay, the first (bit) column on the right, 0 minus 0 is 0. Not particularly ineresting:

       0   (borrow) 
 01000010  (66ten)
-00100010  (34ten)
---------
 _______0

But things don't get really interesting until the 6th bit:

   00000   (borrow) 
 01000010
-00100010
---------
 ___00000

Can't take 1 from 0, so we borrow from the next column over:

 -1    00000   (borrow) 
 01 10 00010  (10two == 2ten)
-00  1 00010
---  - -----
 __  1 00000

1 from 2 is 1. And,

   -1    00000   (borrow) 
 0  1 10 00010  (10two == 2ten)
-0  0  1 00010
--  -  - -----
 _  0  1 00000

In the next column, take the borrow from 1 and that's 0, and 0 - 0 is 0. And the next column, 0 - 0 is 0. Which gives us

   -1    00000   (borrow) 
 0  1 10 00010  (10two == 2ten)
-0  0  1 00010
--  -  - -----
 0  0  1 00000

00100000_two, which is 32_ten. If you haven't already, you might want to get paper and pencil out and make up some binary problems and work them out by hand, to prove to yourself that this works, and is essentially the same thing you're familiar with in base-ten math, but in base two.

What happens if we take a larger number from a smaller? Let's flip 66 - 34 over and see what we can see:

 34
-66
---
???

Because we've already done this and just flipped it over, we know that the answer is -32. That's the way we usually work by hand when we have a large number to take from a small number. And things have actually been done this way in some computers in the past.

But we're deliberately going to see what happens when the borrow runs off the left edge of the numbers.

You definitely want to be following along with pencil and paper on this one. Leave some room to the left when you write it down: 

First column, 4 minus 6 is ...

-1        (borrow)
 3 14
-6  6
--  -
__  8

Gotta borrow. 14 - 6 is 8. 

Second column, (1-) + 3 - 6 is ...

-1 -1     (borrow)
  312 14
-   6  6
--  -  -
__  6  8

Remember to scratch out the used borrow. Gotta borrow again. 12 - 6 is 6.

But now what? We've got a borrow hanging off the left, and nothing to borrow it from. 

Let's invent an infinity of 0s out there. Well, not an infinity, but one or two: 

 -1  -1     (borrow)
 00 312 14
-00   6  6
---   -  -
___   6  8

Apply the borrows and ...

-1  -1  -1  -1     (borrow)
 0 010 010 312 14
-0   0   0   6  6
--   -   -   -  -
__   9   9   6  8

Again, ten's complement. 

Subtract 9968 from 10000, and we get 32. And, somehow, we just know that the leftmost 9 in the result really means we have to subtract from an appropriate power of ten and call the result negative.

Yeah, it's a stretch, but we do crazy things like this in computers because it makes the mechanical adders easier to build. (Early digital computers actually worked in decimal, or in decimal coded binary, or in bi-quinary, because it was easier for many of those involved to intuit at the time.)

Two's complement for binary is especially convenient. Try it on the above problem. Fill the result out to eight bits by continually borrowing a 1 from the next left column and you should get 

11100000

Or you could fill it out to sixteen bits and get 

1111111111100000

And maybe you can intuit that the 1 on the left could be seen like a minus sign.

But how do we know that these numbers are not 224_ten and 65504_ten?

Unfortunately, unless we remember where the numbers came from, we don't. 

In other words, when we are working with integers in computers that use two's complement signed integers, we have to remember (and remind ourselves) whether the particular number we are working with is supposed to be a two's complement signed number or an unsigned number. Yes, it's a bother, but it's necessary.

(... on signed and unsigned integers. -- We're not looking at fixed-point or floating point numbers here, but you have to remember what you're looking at with those, as well.)

Okay, having seen how this works, let's look at some code.

After the subtraction, we could use the ROtate Left instruction to just capture the carry/borrow as we did with addition, but the SuBtract with Borrow Carry instruction can do a little more for us. So we'll use that, instead. (It's the same Carry flag that we used in the addition routines, but it records the borrow after a subtraction. Yes, it works.) 

You'll be pleasantly surprised at how subtracting zero and a borrow from zero plays out:

* Subtract two 8-bit numbers in memory and store them in memory:
*
ENTRY	JMP	SUBM8
*
NL1	FCB	66	; just an arbitrary small number
NR1	FCB	34	; another arbitrary small number
RH1	RMB	1	; To hold one bit of carry from the sum.
RL1	RMB	1	; To hold the eight bit sum.
*
NL2	FCB	132	; Somewhat larger arbitrary number
NR2	FCB	188	; And another
RH2	RMB	1	; carry from 2nd sum
RL2	RMB	1	; 2nd sum
*
NL3	FCB	34	; just an arbitrary small number
NR3	FCB	66	; a larger arbitrary small number
RH3	RMB	1	; To hold one bit of carry from the sum.
RL3	RMB	1	; To hold the eight bit sum.
*
*
SUBM8	CLRA		; clear accumulator A for the carry/sign extension
	LDAB	NL1	; Get the minuend (left side).
	SUBB	NR1	; Subtact the subtrahend (right side).
* Result is safely in B.
	SBCA	#0	; Recover the carry bit, sign extended.
	STAA	RH1	; Save high byte away. 
	STAB	RL1	; Save the difference low byte.
*
	CLRA		; 2nd sign extension
	LDAB	NL2	; 2nd minuend (left side)
	SUBB	NR2	; 2nd subtrahend (right side)
	SBCA	#0	; 2nd carry, sign extended
	STAB	RL2	; Save 2nd difference, low byte.
	STAA	RH2	; Save high byte away.
*
	CLRA		; 3rd carry bit
	LDAB	NL3	; 3rd minuend (left side)
	SUBB	NR3	; 3rd subtrahend (right side)
	STAB	RL3	; Save 3rd difference, low byte.
* ST and LD do not alter C, carry still safe.
	SBCA	#0	; 3rd carry, sign extended.
	STAA	RH3	; Save it away.
	NOP
	NOP

Assemble that and step through it on the 6800, and on the 6801 if you want. Then edit the LD and ST instructions for the 6809 and assemble it and step through it there, as well. Here's the result at the end, (d)umped out:

% d 2000 10
2000: 7E 20 0F 42 22 00 20 84  BC FF C8 22 42 FF E0 4F ~ .B". ...."B..O

Repeating that line in mark-up-able HTML so I can mark the results in red without depending on your browser to read <span> tags buried in pre-formatted text:

2000: 7E 20 0F 42 22 00 20 84 BC FF C8 22 42 FF E0 4F

We now expect the result for the first subtraction: 

42_sixteen - 22_sixteen == 20_sixteen 

(That's 

66_ten - 34_ten == 32_ten

 right?)

The results for the second and third have a borrow from the most significant bit, and by subtracting the borrow instead of rotating it in, we end up with minus one in the stored high byte. 

0 - 1 = -1

As we've seen, in signed two's complement arithmetic, a byte (or other size integer) full of 1s is -1. Subtracting 0 and the borrow from 0 does this for us quite nicely!

If you're wondering whether it's possible to use the ADD Double (ADDD) and SUBtract Double (SUBD) instructions on the 6801 and 6809, yes, sort-of. But it requires an extra couple of bytes of memory because both sides, the minuend and the subtrahend, want a 16-bit operand, so we have to expand both operands.

Keep this in mind for the 68000, though.

Let's look at how that works one more time from a bit more of a high-level view:

First, let's do the math in base ten:

132_ten - 188_ten == -56_ten
34_ten - 66_ten == -32_ten

One more than the largest number in 8 bits is 256. If we add those results (adding negative numbers) to 256, we get 

256_ten + (-56_ten) == 200_ten => C8_sixteen
256_ten + (-32_ten) == 224_ten => E0_sixteen

And the byte full of 1s is FF_sixteen, which explains the results stored away, $FFC8 and $FFE0.

Okay, break out the hexadecimal calculator again. Enter those numbers and do the math in hexadecimal and decimal. Maybe even binary.

If you're not seeing it, switch to hexadecimal base and enter -1. Then switch to binary. You should have a readout full of 1s somewhere in there.

Now switch to decimal and enter -56, then switch to hexadecimal and then binary and watch the bit patterns. Remember, using the four bits at a time conversion to hexadecimal, 

1100 1000_two == C8_sixteen

When you've figured out what's being displayed where, and are satisfied that the bit patterns match what I'm telling you, clear the display, switch to decimal, and enter -32, then, again, switch to hexadecimal and binary and remember that

1110 0000_two == E0_sixteen

We'll get more satisfaction about this once we have enough assembly language to build a calculator that does integer math in various bases, but I hope we've gotten enough satisfaction to move on. 

Go ahead and play with it a bit more, and then let's look at this in 68000 assembler. 

(Title Page/Index)

 

 

 

 

ALPP 02-XX -- Introduction to Address Math on the 6800, 6801, 6809, and 68000

This attempt at a chapter went sideways. Keeping it for the records.
Go here, instead: https://joels-programming-fun.blogspot.com/2024/09/alpp-02-05-introduction-to-byte-arithmetic-6800-6801-6809.html

Introduction to Address Math
on the 6800, 6801, 6809, and 68000

(Title Page/Index)

 

In the last chapter, we saw how the 68000 provides similar advanced addressing features to the 6809's.

Now we want to take an introductory look at general address math on all four processors.

Why do you need to do address math?

We've seen one of the use cases, allocating and deallocating space on the stacks. It's also necessary when allocating and deallocating space for variables and other stuff that needs to stick around between calls to various routines.

It's also useful when accessing distinct fields within structured variables and other objects, and when linking such objects together.

The 6800 doesn't have much in the way of address math. INX and DEX are about it. So you have to use the more general integer math, which only comes in byte size on the 6800.

So you have to synthesize the general math, along with some specific useful cases of general math. That's what we'll look at first.

You've noticed by now that there is a carry bit in the 6800's processor state. It's the least significant bit of the state flags, which is convenient when trying to find out its state. But we don't need to know that for combining two 8-bit adds to make a 16-bit add, because we have the ADd Carry instruction that adds the carry bit leftover from the last operation in along with its specified operands.

ADD and ADC are binary operands. Binary operands on 680X and 680XX family CPUs specify one accumulator or register as both a source and a target, and one memory operand as the second source -- thus, in the case of ADD and ADC, add something in memory to a register.

So you can use the Carry bit to chain the addition of bytes together, pretty much the way you use the carry bit in ordinary arithmetic to chain columns together. 

(If you want, you can consider the addition to be to numbers in base 256, and think of each byte as a column. If that does anything for you. If not, forget I mentioned it.)

Here's how to add two 16-bit numbers on the 6800 when both are in memory, either in the direct page or in the extended absolute addressing area:

* Add two 16-bit numbers in memory and store them in memory:
*
ENTRY	JMP	ADDM16
*
N1	FDB	57738	; just an arbitrary number
N2	FDB	17715	; another arbitrary number
RES	RMB	3	; Enough room to hold a carry from the high bytes.
*
ADDM16	LDAB	N1+1	; do the low byte (right columns) first.
	ADDB	N2+1	; Sets the Carry flag if the result is too big to fit.
	STAB	RES+2	; LoaD and STore do not affect the Carry flag.
	LDAA	N1	; Now do the high bytes (left columns).
	ADCA	N2	; ADd in the Carry from the low bytes as well.
	STAA	RES+1	; Save the high byte away.
	LDAB	#0	; CLR would clear the carry.
	ROLB		; Move the carry in
	STAB	RES	; Save the carry in the low bit of the highest byte.
	NOP
	NOP

This is not the way we usually do this, but it is useful for stepping through and watching the columns get added together. 

There is no real reason for using A for the high byte. B could be used instead and, other than that, the code would not change. Using B only would have the potential advantage of preserving A.

This code would work as is on the 6801 and 6809, with the proviso that you would use LDA for LDAA and STA for STAA on the 6809. But, of course, it could be done 16 bits at once on both:

* Add two 16-bit numbers in memory and store them in memory:
*
ENTRY	JMP	ADDM16
*
N1	FDB	57738	; just an arbitrary number
N2	FDB	17715	; another arbitrary number
RES	RMB	3	; Enough room to hold a carry from the high bytes.
*
ADDM16	LDD	N1	; Both bytes at once
	ADDD	N2	; Sets the Carry flag if the result is too big to fit.
	STD	RES+1	; LoaD and STore do not affect the Carry flag.
	LDAB	#0	; CLR would clear the carry.
	ROLB		; Move the carry in
	STAB	RES	; Save the carry in the low bit of the highest byte.
	NOP
	NOP

... using STA instead of STAA at the end for the 6809 code.

As a reader challenge, work the 6809 code out. (Hardly worth calling a challenge, but do it anyway.)

And, especially if you don't feel comfortable that you know what's happening, take the time to play with the code

On the 68000, of course we can do it a byte at a time or 16 bits at once, or ... 

Wait a minute. 

If we do it a byte at a time or even 16 bits at once, things get a little weird with the 68000. It's intended as a 16-bit/32-bit processor, and it kind of shows in places, particularly when using 24-bit results and other odd sizes.

In the 68000, the Carry function is split up between the X flag, used for eXtending multiple precision additions and subtractions, and the C flag, used for testing and branching. Instead of ADC and SBC, there is ADDX and SUBX, and ADDX and SUBX operate only on registers or in predecrement mode on numeric strings in memory. (Interestingly, the 68000 adds a CMPM instruction, to operate only in postincrement mode on numeric strings in memory.)

And then there is the even address requirements for the 68000. If you store or load by 16 bits or 32, you have to access memory on an even (divisible by 2) boundary.

Sounds wonky?

Yes and no. Let's look at what that means for the 16+1 bit math from above:

* Add two 16-bit numbers in memory and store them in memory:
* Both of these are messy because we are doing odd addresses.

Fix these***

*
ENTRY	JMP	ADDM16W
*
	EVEN
N1	DC.W	57738	; just an arbitrary number
N2	DC.W	17715	; another arbitrary number
RES	DS.B	3	; Enough room to hold a carry from the high bytes.
*
	EVEN
ADDM16W	CLR.B	D6	; pre-clear the carry byte
	MOVE.W	N1,D7	; One 16 bit word at a time
	ADD.W	N2,D7	; Sets the Carry and eXtend flags on carry.
	ROXL.B	#1,D6	; Save the eXtended carry in X first
	MOVE.B	D6,RES	; and move it into place (rotate on memory is word only).
	MOVE.B	D7,RES+2	; Save result low byte. Does not affect the X flag.
	ASR.W	#8,D7	; bring the high byte down
	MOVE.B	D7,RES+1	; because we can't save a 16-bit word to an odd address
	NOP
	NOP
	CLR.W	RES	; clear the result so we can do it again.
	CLR.B	RES+2
ADDM16	LEA	RES+3,A3	; point one beyond RES, same as MOVE #RES+3,A3
	LEA	N2+2,A2		; point one beyond N2, same as MOVE #N2+2,A2
	MOVE.B	-(A2),-(A3)	; copy low byte
	MOVE.B	-(A2),-(A3)	; copy high byte
	ADDQ.L	#2,A3		; back up on RES (100% sure clears X)
	LEA	N1+2,A2		; Actually, it was already there
	CLR.B	D7		; pre-clear the carry byte
	ADDX.B	-(A2),-(A3)	; add low bytes directly in memory
	ADDX.B	-(A2),-(A3)	; and high bytes directly in memory
	ROXL.B	#1,D7		; Save the eXtended carry in X
	MOVE.B	D7,-(A3)	; and move it into place (rotate on memory is word only).
	NOP
	NOP

So it takes more instructions than we want to think it would take -- because of the odd alignment issues. 

(FWIW, certain later members of the 680X0 family relax the alignment require about memory access, but the instruction set does not get dressed-out to fill in certain gaps for byte-level operands. So with those processors, we could improve the number of instructions a little, but not completely to the degree the 6809 allows. I won't look at those CPUs at this point, we have more important things to do.)

But, wait! (There's more ...)

Addresses on a 68000 are not 16 bit. 

Well, unless your runtime is only using a 64 K page within the total memory space or something like that. But that's a story for another time.

And, addresses don't use the carry bit. It's modular math. They just wrap around.

(Wraparound is useful when adding negative offsets, but requires some care in pointer comparison.) 

Hmm.  The 6800 and 6801 code is easy enough to read through and remove the part extracting and saving the carry, but the 68000 code needs another look.

* Add two 16-bit numbers in memory and store them in memory:
* Much less messy with even addresses.
*
ENTRY	JMP	ADDM16W
*
	EVEN
N1	DC.W	57738	; just an arbitrary number
N2	DC.W	17715	; another arbitrary number
RES	DS.B	2	; No carry, keep it aligned
*
	EVEN
ADDM16W	CLR.B	D6	; pre-clear the carry byte
	MOVE.W	N1,D7	; One 16 bit word at a time
	ADD.W	N2,D7	; Add it.
	MOVE.W	D7,RES	; and store the result non-destructively.
	NOP
	NOP
	CLR.W	RES	; clear the result so we can do it again.
ADDM16B	LEA	RES+2,A3	; point one beyond RES, same as MOVE #RES+3,A3
	LEA	N2+2,A2		; point one beyond N2, same as MOVE #N2+2,A2
	MOVE.W	-(A2),-(A3)	; copy all at once
	ADDQ.L	#2,A3		; back up on RES, probably (100% sure) clears X
	LEA	N1+2,A2		; Actually, it was already there
* All this setup just so we can do this,
* one byte at a time to show how to chain adds on the 68000:
	ADDX.B	-(A2),-(A3)	; add low bytes directly in memory
	ADDX.B	-(A2),-(A3)	; and high bytes directly in memory
* Yes, ADDX can be done .W and .L widths, as well.
	NOP
	NOP

 

 

 

(Title Page/Index)

 

 

ALPP 02-04 -- Foothold! (Split Stacks ... barely on the Beach) -- 68000

Foothold!
(Split Stacks ... barely on the Beach)
68000

(Title Page/Index)

 

In the last chapter, we took a bit of a closer look at how to use many of the 6809's key improvements over the 6800 and 6801. In this chapter, we'll look at using similar features in the 68000.

Again, you may want to compare the code in separate browser windows or even on separate monitors.

Where the 6809 gives us either two 8-bit accumulators or one 16-bit accumulator, the 68000 gives us a monstrous eight -- D0 ~ D7. Where the 6809 gives us four or five generally indexable registers -- X, Y, U, S, and PC, the 68000 gives us eight or ten -- A0 ~ A6, system and user A7, and PC.

Anyway, let's take a look at how OUTC can change on the 68000. Somewhat randomly, I am choosing to use A6 as the the parameter stack pointer. OUTC can use the 68000's pop equivalent instructions:

* In these examples, we'll assume that items on the parameter stack
* are full natural width (NATWID bytes), as a simplifying assumption.
OUTC	MOVEM.L	(A6)+,D7	; Get the character, all 32 bits
	AND.W	#$00FF,D7		; clear character high byte.
	MOVEM.W	D7,-(A7)	; Put it where bconout wants it, on the A7 stack.
	MOVE.W	#devscrkbd,-(A7)	; push the device number
	MOVE.W	#bconout,-(A7)		; push the BIOS routine selector
	TRAP	#BIOSTRAP		; call into the BIOS
	ADDQ.L	#6,A7			; deallocate the BIOS parameters when done
	RTS

Note that this looks like a lot more code than the 6809 code, but most of that is for the BIOS call. Where the call into the monitor ROM on the 6809 was one instruction, the BIOS call here is four, including the final deallocation. Also, in the 6809 monitor code, we did not need to clear the high byte, and here we do. 

So it would be essentially the same number of instructions if we were comparing like calls with like.

We could clear the high byte after we move it where bconout expects it:

OUTC	MOVEM.L	(A6)+,D7		; Get the character, all 32 bits.
	MOVEM.W	D7,-(A7)	; Put 16 bits of it where bconout wants it.
	CLR.B	(A7)	; Clear the high byte on the A7 stack.
	MOVE.W	#devscrkbd,-(A7)	; push the device number
	MOVE.W	#bconout,-(A7)		; push the BIOS routine selector
	TRAP	#BIOSTRAP		; call into the BIOS
	ADDQ.L	#6,A7			; deallocate the BIOS parameters when done
	RTS

Or we could clear D7 before we get just the byte:

* We can handle the parameter stack directly.
OUTC	CLR.W	D7		; clear the high byte for the character.
	MOVE.B	NATWID-1(A6),D7	; Get the character.
	ADDQ.L	#NATWID,A6	; drop it from parameter stack.
	MOVEM.W	D7,-(A7)	; Put it where bconout wants it, on the A7 stack.
	MOVE.W	#devscrkbd,-(A7)	; push the device number
	MOVE.W	#bconout,-(A7)		; push the BIOS routine selector
	TRAP	#BIOSTRAP		; call into the BIOS
	ADDQ.L	#6,A7			; deallocate the BIOS parameters when done
	RTS

What if we even want to preserve D7? (We probably don't, but ...):

OUTC	LEA	NATWID/2(A6),A6	; get the high 16 bits out of the way
	MOVE.W	(A6)+,-(A7)	; move the character from one stack to the other
	CLR.B	(A7)		; clear character high byte, as bconout wants it.
	MOVE.W	#devscrkbd,-(A7)	; push the device number
	MOVE.W	#bconout,-(A7)		; push the BIOS routine selector
	TRAP	#BIOSTRAP		; call into the BIOS
	ADDQ.L	#6,A7			; deallocate the BIOS parameters when done
	RTS

When you want to adjust an address or other value by small amounts, the ADDQ instruction is usually the Quickest. Think of it as INC by anything from 1 to 8. 

Load Effective Address using constant offset also works, similar to the 6809.

Again, we have PC relative source addresses to help keep the code easy to move from place to place. Here, too, the assembler figures out the offset from the label, so you use the label in the source code, but the offset is assembled to the object code.

Again, if you haven't already, open up separate browser windows for the introduction to split stacks on the 6809 so you can compare.

Of course, we don't need any equivalent to the PPUSHD and PPOPD routines. I've used the MOVEM instruction in the above examples, to let you know MOVEM is there. Also, MOVEM does not alter the CPU processor state flags, like a straight MOVE would. But a straight MOVE with auto-increment or -decrement can be used if you only have one register to push or pop.

MOVEM, like the 6809 PSH and PUL, can move Multiple registers with a single instruction.

One word of warning about using MOVEM as the default POP instruction -- Even though it doesn't affect the flags, it does sign-extend 16-bit values loaded into data registers. So you'll need to keep that in mind.

The 68000 routine to set up the stack pointers looks a lot like the 6809 routine::

INISTKS	LEA	PSTKBAS(PC),A6	; Set up the parameter stack
	MOVEM.L	(A7),A0		; 68000 lets us do this -- return address in A0
	MOVE.L	A7,D7		; Save what the monitor gave us.
	LEA	SSTKBAS(PC),A7	; Move to our own stack
	MOVEM.L	D7,-(A7)	; Save monitor's stack pointer on ours
	JMP	(A0)	; return via A0

When we're done, we can restore the monitor's stack pointer with a simple load:

DONE	MOVEM.L	(A7),A7		; restore the BIOS stack pointer

Let's look at the complete code to test character output:

	OPT LIST,SYMTAB	; Options we want for the stand-alone assembler.
	MACHINE MC68000	; because there are a lot the assembler can do.
	OPT DEBUG	; We want labels for debugging.
	OUTPUT
***********************************************************************

*
NATWID	EQU	4	; 4 bytes in the CPU's natural integer


BIOSTRAP	EQU	13
bconout		EQU	3
devscrkbd	EQU	2


	EVEN	
ENTRY	JMP	START
	EVEN
* No need for PSP in 68000 --
* A6 will be our parameter stack pointer
*
* No need for SSAVE, either. We will keep SSAVE in an unused register.
*
SSTKLIM	DS.L	16	; 16 levels of call, max
* 68000 is pre-dec (decrement before store) push
SSTKBAS	DS.L	1	; a little bumper space
PSTKLIM	DS.L	16*2	; 16 levels of call at two parameters per call
PSTKBAS	DS.L	1	; bumper space -- parameter stack is pre-dec
* (But this example only uses two levels.)


* MOVEM is the designated PUSH/POP for the 68000, sort-of.
* Usually it is used to save and restore multiple registers in one instruction.
* It can also be used to avoid messing with the processor state flags.
* We're using it to bring it to yor attention.
* Otherwise, for only one register, you will usually use a normal MOVE.
* Unless you want to preserve flags.
INISTKS	LEA	PSTKBAS(PC),A6	; Set up the parameter stack
	MOVEM.L	(A7),A0		; 68000 lets us do this -- return address in A0
	MOVE.L	A7,D7		; Save what the monitor gave us.
	LEA	SSTKBAS(PC),A7	; Move to our own stack
	MOVEM.L	D7,-(A7)	; Save monitor's stack pointer on ours
	JMP	(A0)	; return via A0

* No need for PPOPD or PPUSHD in 68000 code.

* We can handle the parameter stack directly.
* In this example, we'll assume that items on the parameter stack
* are full natural width (NATWID bytes), as a simplifying assumption.
OUTC	CLR.W	D7		; clear the high byte for the character.
	MOVE.B	NATWID-1(A6),D7	; Get the character.
	ADDQ.L	#NATWID,A6	; drop it from parameter stack.
	MOVEM.W	D7,-(A7)	; Put it where bconout wants it, on the A7 stack.
	MOVE.W	#devscrkbd,-(A7)	; push the device number
	MOVE.W	#bconout,-(A7)		; push the BIOS routine selector
	TRAP	#BIOSTRAP		; call into the BIOS
	ADDQ.L	#6,A7			; deallocate the BIOS parameters when done
	RTS
	
*
START	BSR.W	INISTKS		; 68000 lets us do medium range relative branches
*
	MOVE.L	#'H',-(A6)	; push character to be output at natural width
	BSR.W	OUTC
*
DONE	MOVEM.L	(A7),A7		; restore the BIOS stack pointer
	NOP
	NOP
* One way to return to the OS or other calling program
	clr.w	-(sp)	; there should be enough room on the caller's stack
	trap	#1		;	quick exit

And that's it. 

Here again, line buffering requires you to (c)ontinue the code through the return to the TOS command line, to see the character output.

Save the code as something like "out_H_2s.s" in the directory where you're doing the 68000 Atari ST work and use vasm to assemble it, using a command something like

$ vasmm68k_mot -Ftos -no-opt -o OUT_H_2s.PRG -L out_H_2s.lst out_H_2s.s

Refer back to Hello World for 68000 example in the H68000's Hello World chapter if you don't remember how to invoke the debugger, set breakpoints, and run it.

Unlike the 6800/6801 and 6809, the 68000 has an exception to break on undefined op-codes. But you don't want to depend on garbage in memory being undefined op-codes, so do set breakpoints.

And now, again, really straightforward (once you've seen the above), the string output test routine:

* First 68000 Foothold on the split stack beach,
* by Joel Matthew Rees September 2024, Copyright 2024 -- All rights reserved.
*
	OPT LIST,SYMTAB	; Options we want for the stand-alone assembler.
	MACHINE MC68000	; because there are a lot the assembler can do.
	OPT DEBUG	; We want labels for debugging.
	OUTPUT
***********************************************************************

* We will not be using these:
*GEMDOSTRAP	EQU	1
*GEMprintstr	EQU	9	; PRINT LINE in some docs

BIOSTRAP	EQU	13
bconout		EQU	3
devscrkbd	EQU	2

LF	EQU	$0A	; line feed
CR	EQU	$0D	; carriage return
NUL	EQU	0

* Opinions may vary about the natural integer.
NATWID	EQU	4	; 4 bytes in the CPU's natural integer

	EVEN	
ENTRY	BRA.W	START

* No need for PSP in 68000 --
* A6 will be our parameter stack pointer
*
* No need for SSAVE, either. We will keep SSAVE in an unused register.
*
SSTKLIM	DS.L	16	; 16 levels of call, max
* 68000 is pre-dec (decrement before store) push
SSTKBAS	DS.L	1	; a little bumper space
PSTKLIM	DS.L	16*2	; 16 levels of call at two parameters per call
PSTKBAS	DS.L	1	; bumper space -- parameter stack is pre-dec
* (But this example doesn't use half of that number of levels.)
*
HELLO	DC.B	CR,LF	; Put message at beginning of line
	DC.B	"SEKAI YO, YAI!"	; Whatever the user wants here.
	DC.B	CR,LF,NUL	; Put the debugger's output on a new line.

* MOVEM is the designated PUSH/POP for the 68000, sort-of.
* Usually it is used to save and restore multiple registers in one instruction.
* It can also be used to avoid messing with the processor state flags.
* We're using it to bring it to yor attention.
* Otherwise, for only one register, you will usually use a normal MOVE.
* Unless you want to preserve flags.
	EVEN
INISTKS	LEA	PSTKBAS(PC),A6	; Set up the parameter stack
	MOVEM.L	(A7),A0		; 68000 lets us do this -- return address in A0
	MOVE.L	A7,D7		; Save what the monitor gave us.
	LEA	SSTKBAS(PC),A7	; Move to our own stack
	MOVEM.L	D7,-(A7)	; Save monitor's stack pointer on ours
	JMP	(A0)	; return via A0

* No need for PPOPD or PPUSHD in 68000 code.

* We can handle the parameter stack directly.
* In this example, we'll assume that items on the parameter stack
* are full natural width (NATWID bytes), as a simplifying assumption.
OUTC	CLR.W	D7		; clear character high byte.
	MOVE.B	NATWID-1(A6),D7	; Get the character, high byte cleared
	ADDQ.L	#NATWID,A6	; drop it from parameter stack.
	BSR.S	OUTCV		; Can't just fall through if we're going to share.
	RTS
*
* Return from TRAP is RTE,not RTS,
* therefore, this must be called as a subroutine, not just jumped to.
* Common hook: call with the character on A7 stack. 
* This bit of glue calls the BIOS.
OUTCV	MOVE.W	D7,-(A7)	; Push the character on A7 where bconout wants it.
	MOVE.W	#devscrkbd,-(A7)	; push the device number
	MOVE.W	#bconout,-(A7)		; push the BIOS routine selector
	TRAP	#BIOSTRAP		; call into the BIOS
	ADDQ.L	#6,A7			; deallocate the BIOS parameters when done
	RTS

*
* And we can handle the parameter stack directly here, too.
* A3 is preserved by Hatari BIOS.
OUTS	MOVEM.L	(A6)+,A3	; get the string pointer
OUTSL	CLR.W	D7		; Prepare the high byte.
	MOVE.B	(A3)+,D7	; get the byte, update the pointer
	BEQ.S	OUTDN		; if NUL, leave before pushing the character.
	BSR.S	OUTCV	; use the same call OUTC uses.
	BRA.S	OUTSL	; next character
OUTDN	RTS
*
* All the newlines we need are in the string.


*
START	BSR.W	INISTKS		; 68000 lets us do medium range relative branches
*
	LEA	HELLO(PC),A0	; push address of string to be output
	MOVEM.L	A0,-(A6)	; A0 is not preserved by Hatari BIOS, by the way.
	BSR.W	OUTS		; put it on the screen,
DONE	MOVE.L	(A7),A7		; restore previous user stack pointer
	NOP
	NOP
* One way to return to the OS or other calling program
	clr.w	-(sp)	; there should be enough room on the caller's stack
	trap	#1		;	quick exit

Note again, all the uses of the auto-increment index mode, not just in the string output. 

Note also the choices of index registers. 

In particular, I got trapped in forgetting that A0 is volatile across BIOS calls and had to debug some code before putting it up here. Can't use it and expect it to be there after a BIOS call, but we can use it for scratch calculations and temporarily holding addresses when we don't call a subroutine between setting it and using it. (This is information in the Atari manuals.)

Also note that we don't put a few BIOS parameters on the A7 stack and then jump into a subroutine that puts more on the A7 stack, because that would require moving return addresses out of the way. I got bitten by this, trying to push the character on A7 before calling OUTCV and pushing the BIOS call selectors on A7. (Remember what I said about using just one stack?)

And the 68000 also makes it is quite easy to have OUTS call OUTC rather than the common code subroutine, like this:

OUTS	MOVEM.L	(A6)+,A3	; get the string pointer
OUTSL	CLR.L	D7		; Prepare the high byte.
	MOVE.B	(A3)+,D7	; get the byte, update the pointer
	BEQ.S	OUTDN		; if NUL, leave before pushing the character.
	MOVE.L	D7,-(A6)	; push it on the parameter stack.
	BSR.S	OUTC	; use OUTC itself.
	BRA.S	OUTSL	; next character
OUTDN	RTS

Here we can get a peek at one of the differences between the 6809 and the 68000. 

Concatenating low bytes and high bytes is easy on the 6809. Not so easy on the 68000 -- so much so that when you need to clear the higher part of an integer on the 68000, it's generally best to clear a free register before loading the lower part of the integer.

Like the 6809, it takes just a little extra code to call OUTC rather than the common subroutine, but, like the 6809, it can make it easier to manage character output related code, and, like the 6809, separating the common code into a shorter subroutine may be useful.

Which way do I recommend? It depends, and I'll tell you more about that as we go.

Again, lightly tested, should work for you. Play with the code a little while we're here. And think about checking whether the stacks are in balance.

After you've played with it a bit, let's start looking at doing integer arithmetic at byte level on the three 8-bit processors.

 

(Title Page/Index)

 

 

ALPP 02-03 -- Foothold! (Split Stacks ... barely on the Beach) -- 6809

Foothold!
(Split Stacks ... barely on the Beach)
6809

(Title Page/Index)

 

The differences we saw between the 6800 and the 6801 were relatively minor, but not unimportant. The very small advances in the 6801 make it significantly easier to keep the CPU responsive and stable while handling interrupts and other kinds of concurrency.

And now we finally get a look at some of the important differences between the 6800 / 6801, and the 6809. It may be a little mind-boggling. You really want to open up separate browser windows and compare the code for each, preferably on separate monitors. 

Even if you don't quite follow what's going on, compare the code. The more times you see this from different points of view, the easier it gets.

Again, as I have said, one major purpose of the split stack is to separate return addresses from parameters and local variables, producing somewhat more robust, less difficult to debug code. 

And, I'm going to repeat myself (again?), you probably won't believe me yet, but the split stack also simplifies and streamlines the call interface for the subroutines and procedures you write. 

Let's start taking a look at why. 

The 6809 includes the same ability to concatenate A and B that the 6801 has. (Historically, the 6809's design actually came first.)

The 6809 also gives us two more index registers, or four, depending on how you count, adding Y and U to X and S. Where in the 6800/6801, only X can take an offset and be used as a general index register, all four, plus PC, can take an offset in the 6809. Additionally, U also specifically supports pushes and pops, and we shall be using it instead of PSP for the parameter stack. 

(We'll talk about the 6809's partially indexable DP and how to use it well later.)

Enough sales talk, let's take a look at how OUTC can change on the 6809.

OUTC will use the 6809's pop instruction (PULU) for U:

* Walks on contents of B.
OUTC	PULU	D	; Get the character, 
	TFR	B,A	; Put it where XOUTCH wants it.
	JSR	XOUTCH	; output via monitor ROM
	RTS

Or we could do two PULU A instructions and preserve B.

* Does not Walk on B.
OUTC	PULU	A	; Get the high byte out of the way, 
	PULU	A	; Get the character where XOUTCH wants it.
	JSR	XOUTCH	; output via monitor ROM
	RTS

But the 6809 also provides a way to access the U stack directly:

* Preserves B.
OUTC	LDA	1,U	; Get the character in A where XOUTCH wants it.
	LEAU	2,U	; Got it in A, now drop it from the stack.
	JSR	XOUTCH	; output via monitor ROM
	RTS

What if we even want to preserve A? (We probably don't, but ...):

OUTC	PSHS	A	; Save A
	LDA	1,U	; Get the character in A where XOUTCH wants it.
	LEAU	2,U	; Got it in A, now drop it from the stack.
	JSR	XOUTCH	; output via monitor ROM
	PULS	A,PC	; Pop and return in one instruction.

Load Effective Address shows up again, this time replacing a separate INCrement instruction for U, or, rather, replacing what would have been two INU instructions if the 6809 had them. 

For source registers other than PC, LEA adds the signed offset to the specified index register, in this case +2 to U.

For PC relative source addresses (which we will see again below), the assembler figures out the offset from the label, so you use the label in the source code, but the offset is assembled to the object code.

(If you have a macro assembler, you can define INU as LEAU 1,U, but that's rather wasteful if you use it more than once in a row.)

And there are several other interesting ways we could do this.

Again, if you haven't already, open up separate browser windows for the introduction to split stacks on the 6800 and the 6801 so you can compare.

Note that X is not used, no need to push and pop it, it's preserved. 

Note also that PPUSHD and PPOPD simply go away (along with PPUSHX and PPOPX), replaced by the 6809's more flexible PSHU and PULU instructions.

The 6809 gives us some really wonderful options for setting up the stack pointers. Not only can we pop the return address directly to X like we can on the 6801, but we can save the monitor's stack pointer on our own stack, eliminating yet another global variable:

INISTKS	LEAU	PSTKBAS,PCR	; Set up the parameter stack
	PULS	X	; 6809 lets us do this -- return address in X
	TFR	S,Y	; Save what the monitor gave us.
	LEAS	SSTKBAS,PCR	; Move to our own stack
	PSHS	Y	; Save monitor's stack pointer on ours
	JMP	,X	; return via X

When we're done, we can restore the monitor's stack pointer with a simple load:

DONE	LDS	,S	; restore the monitor stack pointer

Let's look at the complete code to test character output:

* Essential control codes
LF	EQU	$0A	; line feed
CR	EQU	$0D	; carriage return
* Essential monitor ROM routines
XOUTCH	EQU	$F018
*
NATWID	EQU	2	; 2 bytes in the CPU's natural integer
*
*
* Blank line will end assembly.
	ORG	$80	; MDOS and EXbug docs say it should be okay here.
ENTRY	JMP	START
	NOP		; Just want even addressed pointers for no reason.
* No need for PSP in 6809 --
* U will be our parameter stack pointer,
* And we will save S on our own stack.
*
	ORG	$2000	; MDOS says this is a good place for user stuff
NOENTRY	JMP	START
	RMB	2	; a little bumper space
SSTKLIM	RMB	32	; 16 levels of call, max
* 6809 is pre-dec (decrement before store) push
SSTKBAS	RMB	2	; a little bumper space
PSTKLIM	RMB	64	; 16 levels of call at two parameters per call
PSTKBAS	RMB	2	; bumper space -- parameter stack is pre-dec
* (But this example only uses two levels.)
*
*
INISTKS	LEAU	PSTKBAS,PCR	; Set up the parameter stack
	PULS	X	; 6809 lets us do this -- return address in X
	TFR	S,Y	; Save what the monitor gave us.
	LEAS	SSTKBAS,PCR	; Move to our own stack
	PSHS	Y	; Save monitor's stack pointer on ours
	JMP	,X	; return via X
*
* No need for PPOPD or PPUSHD in 6809 code.
*
* We can handle the parameter stack directly.
* Preserves B.
OUTC	LDA	1,U	; Get the character in A where XOUTCH wants it.
	LEAU	2,U	; Got it in A, now drop it from the stack.
	JSR	XOUTCH	; output via monitor ROM
	RTS
*
*
START	LBSR	INISTKS
*
	LDD	#'H
	PSHU	D
	LBSR	OUTC	; 6809 lets us do long relative branches
*
DONE	LDS	,S	; restore the monitor stack pointer
	NOP
	NOP		; landing pad

And that's it.

Change back to the directory for JHAllen's unmodified EXORsim and run an instance of EXORsim 6809, assemble the source, set a breakpoint at the landing pad NOPs, and run it. (Refer back to Hello World for 6809 in the 8-bit Hello World chapter if you don't remember how to do this.) 

Do set the breakpoint. 

EXORsim is nice enough to break on undefined opcodes, but, with the 6809, zero is a defined opcode -- the direct-page form of the NEGate instruction. So it won't stop, It will wander off and will eventually start executing the monitor or something and end up jumping into MDOS or something, which will be confusing.

Be aware, the actual 6800 is not nice enough to break on undefined opcodes. So if you were getting lazy about breakpoints on the 6800 and 6801, remember you can't do that on real hardware.

This is so short that I almost want to do the 68000 code here in the same chapter and be done with it. But I want you to be able to compare the 68000 code to the 6809 code side-by-side, so we'll keep that separate.

So, it's time to look at the string routines?

Really straightforward.

* First 6809 Foothold on the split stack beach,
* by Joel Matthew Rees September 2024, Copyright 2024 -- All rights reserved.
*
* Essential control codes
LF	EQU	$0A	; line feed
CR	EQU	$0D	; carriage return
NUL	EQU	0
*
* Essential monitor ROM routines
XOUTCH	EQU	$F018
*
NATWID	EQU	2	; 2 bytes in the CPU's natural integer
*
*
* Blank line will end assembly.
	ORG	$80	; MDOS and EXbug docs say it should be okay here.
ENTRY	JMP	START
	NOP		; Just want even addressed pointers for no reason.
* We will save S on our own stack.
*
*
	ORG	$2000	; MDOS says this is a good place for usr stuff
NOENTRY	JMP	START
	RMB	2	; a little bumper space
SSTKLIM	RMB	32	; 16 levels of call, max
* 6809 is pre-dec (decrement before store) push
SSTKBAS	RMB	2	; a little bumper space
PSTKLIM	RMB	64	; 16 levels of call at two parameters per call
PSTKBAS	RMB	2	; bumper space -- parameter stack is pre-dec
*
*
HELLO	FCB	CR,LF	; Put message at beginning of line
	FCC	"Ashi-ba ga dekita!"	; Whatever the user wants here.
	FCB	CR,LF,NUL	; Put the debugger's output on a new line.
*
*
INISTKS	LEAU	PSTKBAS,PCR	; Set up the parameter stack
	PULS	X	; 6809 lets us do this -- return address in X
	TFR	S,Y	; Save what the monitor gave us.
	LEAS	SSTKBAS,PCR	; Move to our own stack
	PSHS	Y	; Save monitor's stack pointer on ours
	JMP	,X	; return via X
*
*
* No need for PPOPD, PPUSHD, PPOPX, or PPUSHX in 6809 code.
*
* We can handle the parameter stack directly.
* Preserves B.
OUTC	LDA	1,U	; Get the character in A where XOUTCH wants it.
	LEAU	2,U	; Got it in A, now drop it from the stack.
	BSR	OUTCV	; output via monitor ROM
	RTS
*
OUTCV	JMP	XOUTCH	; common hook
*
* And we can handle the parameter stack directly here, too.
OUTS	PULU	X	; get the string pointer
OUTSL	LDA	,X+	; get the byte, update the pointer
	BEQ	OUTDN	; if NUL, leave
	BSR	OUTCV	; use the same call OUTC uses.
	BRA	OUTSL	; next character
OUTDN	RTS
*
* All the newlines we need are in the string.
*
*
START	LBSR	INISTKS
*
	LEAX	HELLO,PCR
	PSHU	X
	LBSR	OUTS	; Our string has its own CR/LF this time around.
*
DONE	LDS	,S	; restore the monitor stack pointer
	NOP
	NOP		; landing pad

Note the use of the auto-increment index mode in the string output routine. 

Before we leave, I think I should point out something I briefly mentioned in the 6800 and 6801 code examples. It is quite easy to have OUTS call OUTC, like this:

OUTS	PULU	X	; get the string pointer
OUTSL	LDA	,X+	; get the byte, update the pointer
	BEQ	OUTDN	; if NUL, leave
	PSHU	A	; push the low byte of the character
	CLR	,-U	; push the high byte of zero for OUTC
	BSR	OUTC	; use OUTC itself.
	BRA	OUTSL	; next character
OUTDN	RTS

We can't just CLeaR B and PuSH D on U, because that will be in the wrong byte order. But the predecrement mode CLR works nicely for putting the high byte of zero in the right place.

We do need to be careful to check that the stack remains balanced after the parameter pushing and popping, particular since it can be a little distracting that it's happening in a loop.

You can see that takes a bit of extra code and ends up pushing and popping a little redundantly. 

On the 6800 and 6801, that's going to be a full call and return penalty to let PPUSHD and PPOPD handle it. On the 6809, it's not nearly as much of a penalty, since the 6809 provides the extra stack, PSHU, PULU, and the predecrement addressing modes. But it's still redundant code that takes room in the object and takes cycles to execute.

On the other hand, having OUTS call OUTC allows all character output issues to be taken care of in OUTC.

As a compromise, I'm having both OUTS and OUTC call OUTCV. 

(You might think a branch would work instead of a call, stealing the monitor's RTS, and, indeed, it should work, it often does, and it has been done in existing, functioning code. But there's a certain lack of clarity in doing so, and I have other things I want you to be thinking about.)

Again, lightly tested, should work for you. Play with the code a little while we're here. And think about how to make sure the stacks have stayed in balance.

(A note, while we're looking at it: From early code examples from Motorola and even the CPU's order of saving registers on interrupt, it appears that the original intent in the design of the 6800 might have been that A would be the low byte and B the overflow -- high -- byte, when used together -- and that, for some reason, that intent was inverted in the 6801 and 6809. That may be the reason the monitor looks for the character in A instead of B.)

After you're done playing a bit, let's move on to getting this foothold on the 68000.

(Title Page/Index)