Saturday, March 8, 2014

Finished Up Support for the Hitachi 6309 CPU

I've added Hitachi 6309 support to my disassembler, monitor interrupt handlers, and monitor client. So I'm now able to switch over my 6809 test app to use the 6309's "native" mode, which is something like 15-30% faster. I can single step over 6309 code sequences and display/modify the extra registers (E/F/V). I verified my disassembler by using the a09 6809/6309 cross assembler to assemble a bunch of test 6309 code, disassemble it, then diff the results vs. the original code. Lomont's 6309 Reference and The 6309 Book are the best references I've found.

The 6309 is amazingly powerful for its time. You've got some 32-bit ops, fast CPU memory transfers, hardware division/multiplication, various register to register ops, and two more 16-bit regs to play with over the 6809 (W and V, although V is limited to exchanges/transfers). W is hybrid register, useful as a pointer or general purpose register. I've written a good deal of real mode (16-bit segmented) 8086/80286 assembly back in the day, and I really like the feel of 6309 assembly.


Unfortunately, the assembler used by gcc6809 (as6809) doesn't support the 6309. The gcc6809 package comes with a 6309 assembler (as6309), but it doesn't compile out of the box. I got it to compile but it's very clear that whoever worked on it never finished it. I made a quick stab at fixing up as6309 but to be honest the C code in there is like assembly code (with unfathomable 2-3 letter variable names and obfuscated program flow), and I don't have time to get into it for a hobby project.

So for now, I'm using the a09 assembler (which does support 6309) to create position independent code (at address 0) contained in simple .bin files which I convert to as09 assembly source files. The .s files contain nothing but ".byte 0xXX" statements and the symbols. To get the symbols I manually place a small symbol table at the end of the .bin file that is automatically located and parsed using a custom command line tool which converts the a09 assembled .bin file to .s assembly files:

                code
                org     $0

;------------------------------------------------------------------------------
; void _math_muli_16_16_32(int16 left_value, int16 right_value, int32 *pResult)
;------------------------------------------------------------------------------

; x - int16 left value
; stack: 
; 2,3 - int16 right value
; 4,5 - int32* result_ptr 

_math_muli_16_16_32:

right_val = 2
result_ptr = 4

tfr x,d
muld right_val, s
stq [result_ptr, s]
rts

;------------------------------------------------------------------------------
; Define public symbols, processed by cc3monitor -a09 <src_filename.bin>
;------------------------------------------------------------------------------

fcb 0x12, 0x35, 0xFF, 0xF0

fcc "_math_muli_16_16_32$"
fcw _math_muli_16_16_32

This gets converted to an .s file which the gcc6809 tool chain likes:

.module asmhelpers
.area .text
.globl _math_muli_16_16_32
_math_muli_16_16_32:
.byte 0x1F
.byte 0x10
.byte 0x11
.byte 0xAF
.byte 0x62
.byte 0x10
.byte 0xED
.byte 0xF8
.byte 0x4
.byte 0x39

This is a cheesy hack but works fine (for a hobby project).

2 comments:

  1. Nice! I lived with the same as09 assembler 'hack' technique to support the hd6309 instructions until I discovered the lwtools suite, at http://lwtools.projects.l-w.ca/

    The 6809 and 6309 instructions are supported. I just completed and submitted support for srec and ihex output options for lwasm which will appear in the next release, I'm told. If you look in the /extras directory of the source snapshot, you'll find a patch for gcc6809 to target lwasm as the backend. I'm not running a CoCo, so I've not tried this myself.

    -tom

    ReplyDelete
  2. Limitations live only in our minds. But if we use our imaginations, our possibilities become limitless. –Jamie Paolinetti

    For more info visit: leisure

    ReplyDelete