ALPP 02-35 -- Tentative Op-code Map of RK0801 CPU (Extension of M6801)

One final bit of treasure from the bottom of the pool.

  Tentative Op-code Map of
RK0801 CPU
(Extension of 6801)

(Title Page/Index)

 

This is a tentative op-code map of extensions to the 6801 CPU that I think would make it significantly more efficient without blowing the semiconductor real estate (gates) budget for an 8-bit CPU core, from some older ideas I've had for a while (direct page unaries and SBX) and some new ideas suggested by the addressing math and stack frame examples: 

New in this map:

• SBX: Subtract B from X corollary to existing ABX. This optimizes small-to-medium allocations where size is not known at compile/assemble time, also helps when following relative links around.
  (Adding an op-code to add D to X might be another possibility, but would require sign-extending into A.)
  
• Add signed Immediate byte to X and S, ADIX/ADIS. This optimizes small-to-medium stack and other allocations where size is known at compile/assemble time.
  (Add and Subtract unsigned byte immediate is an option, but requires more op-codes in the very tight primary op-code table. Add 16-bit immediate is yet another option, but is less efficient with code size, enough so as to make the most common case, add plus or minus 2, meaningless.)
  (Considered dropping INX/DEX and INS/DES, but that de-optimizes byte string operations.)
  
• Direct-page versions of unary/read-modify-write byte instructions,
  • NEG (NEGate byte),
    
  • COM (bit COMplement byte),
    
  • LSR (Logical Shift Right byte),
    
  • ROR (ROtate Right byte through carry)
    
  • ASR (Arithmetic Shift Right byte, copying sign),
  • ROL (ROtate Left byte through carry),
  • DEC (DECrement byte),
  • INC (INCrement byte),
  • TST (TeST byte),
  • CLR (CLeaR byte).
    

  (These are, really, more appropriate in direct-page mode than in extended mode, to provide effective pseudo-registers.)
  (Also, it might be useful to provide address function code outputs that distinguish between direct page and extended mode, providing an effective separate address space for pseudo-registers and I/O, with all addressing modes enabled on it.)
  

• 16-bit read/modify/write  instructions:
  
  • DINC, (Double-byte INCrement)
    (including INCD, INCrement Double accumulator),
  • DDEC (Double-byte DECrement)
    (including DECD, DECrement Double accumulator),
  • DASL (Double-byte Arithmetic Shift Left)
    (including ASLD, Arithmetic Shift Left Double accumulator),
    
  • DLSR (Double-byte Logical Shift Right)
    (including LSRD, Logical Shift Right Double accumulator).
    

  (DASL and DLSR are moved from their position in the 6801 map to the corresponding position in the new 16-bit ranks.)
  (16-bit increment and decrement in the direct page will be especially helpful for software stacks.)
  

• JMP to direct-page target (not in 6801 op-codes).

Adding the FDIV and IDIV instructions that the 68HC11 has would be fun, but would likely shoot the gates budget. Likewise, adding the 68HC11's bit testing and manipulation instructions or an additional stack register would require using pre-bytes, and I don't want to do that, either.

Instead of moving the op-codes around, the missing op-codes could be squeezed into empty codes in the 6801 map, but that would require gates that could be used for something else. 

Using a pre-byte and putting the direct page op-codes in a second op-code map would partially erase the advantage of direct-page op-codes.

Left half of the op-code table:

Mnemonic
	UNARY		BRANCH		UNARY
	**ACCA	**INH	REL	INH	**ACCB	*Dir	Ind	Ext
	0	1	2	3	4	5	6	7
0	NEG	***CBA	BRA	TSX	NEG	NEG
1		NOP	BRN	[INS]	INCD	*DINC
2		***SBA	BHI	PULA	DECD	*DDEC
3	COM	***ABA	BLS	PULB	COM	COM
4	LSR	***TAB	BCC	[DES]	LSR	LSR
5		***TBA	BCS	TXS	**ASLD	*DASL
6	ROR	TAP	BNE	PSHA	ROR	ROR
7	ASR	TPA	BEQ	PSHB	ASR	ASR
8	ASL	[INX]	BVC	PULX	ASL	ASL
9	ROL	[DEX]	BVS	RTS	ROL	ROL
A	DEC	CLV	BPL	ABX	DEC	DEC
B		SEV	BMI	RTI	***LSRD	*DLSR
C	INC	CLC	BGE	PSHX	INC	INC
D	TST	SEC	BLT	MUL	TST	TST
E	***DAA	CLI	BGT	WAI	*SBX	*JMP
F	CLR	SEI	BLE	SWI	CLR	CLR
	*Not in 6801					*No JMP dp in 6801
	**Moved in 2801
	***Both row and column moved.

Right half of the op-code table:

Mnemonic
	BINARY
	ACCA				ACCB
	Imm	Dir	Ind	Ext	Imm	Dir	Ind	Ext
	8	9	A	B	C	D	E	F
0	SUB
1	CMP
2	SBC
3	SUBD				ADDD
4	AND
5	BIT
6	LDA
7		STA				STA
8	EOR
9	ADC
A	ORA
B	ADD
C	CPX				LDD
D	BSR	JSR				STD
E	LDS				LDX
F	*~ADIS	STS			*~ADIX	STX
	*Not in 6801
	*~ADIS and ADIX are signed byte constant

Expanding the address map via segment registers or widened address registers is tempting, but I'm thinking to simply be satisfied with two additional address function outputs to allow distinction between

• code space (PC relative),
• return address stack space (S relative),
• direct page space (DP mode),
• general data (everything else).
  

Four address spaces won't really even double available address space because of issues in indexing and hard space separation, but it will make it possible to reach or somewhat exceed full 64 K  addressing.

On the other hand, it would not be hard to give the '0801 widened X and PC and maybe S, or segment registers for two, three or all four of the above address spaces or something similar. If segment registers, I would want to use either full-width segment registers, or have the segment registers offset a full byte. None of that 4-bit offset wamby-pamby.

Further extensions, such as a second stack and widened address registers, and the Y register, bit operators, and IDIV and FDIV from the 'HC11, would warrant another part number, say 2801, the "2" indicating two stacks. 

Or a second 16-bit accumulator, such as the 6309 has, would make it a 16-bit CPU, so maybe 21601. But borrowing from the 6309 tends to point to the idea that, beyond a certain point, we'd want to move up to an extended derivative of the 6809.

Well, I don't think I have anything more for this rabbit hole at this moment, so you can return to the irregularly scheduled assembly language tutorial, continuing with getting numbers output.

(Title Page/Index)