[Coco] Assembler modifications and a super 6309 processor
lost at l-w.ca
Tue Sep 8 13:55:20 EDT 2009
jdaggett at gate.net wrote:
> Not really being a programmer in C/C++ and since most assemblers are programmed in
> C/C++, how difficult would it be to modify the more common used assemblers for 6309
> for new instructions?
I suppose I qualify as a software guru in this instance, what with
having written an assembler for 6x09.
For a table-driven assembler, which most are, it should be relatively
trivial to add new instructions. This is especially the case if the new
instructions already leverage existing addressing modes since that means
no new operand parsing modes would be required. This would be the case
when fleshing out the capabilities of the extra registers in the 6309.
Completely new instructions with no equivalent in the existing
instruction set are no harder except there may need to be some
additional parsing work for the assembler to grok the operand.
As a matter of fact, it seems to me that it is actually easier to add
instructions to assemblers than it is to the CPUs themselves.
On the subject of new instructions, let me throw out a "pie in the sky"
A "test and set" instruction would cool. That way one could do an atomic
"test and set" operation without having to disable interrupts. This is a
required capability for mutexes and so on. In single processor systems,
one only needs to disable interrupts, load the value, set the value,
then enable interrupts, then test the original value loaded (about 6
instructions on a 6809). Once you throw in multiple processors, it
becomes more critical but in that case, the bus has to be locked for the
duration of the instruction so the other CPU cannot access the same
memory location between the read and write operations. That makes it
more complex and probably not worth implementing.
Maybe even add a SET instruction to compliment CLR, although OIM can be
used to accomplish the same thing.
If you're adding instructions to the CPU, it might be cool to also add
arithmetic and logical operations on the 16 bit pointer registers (and
not just the register to register modes). Possibly even some additional
32 bit math instructions, though that might require adding another
register or two which could be difficult.
Something else I've found lacking in the 6309 is a means to stack the
entire register set in the same order as interrupts do in native mode.
Maybe a PSH/PUL variant with a 16 bit register bitmap or a PSHrALL and
PULrALL type instruction? (It takes 3 instructions to do it currently,
totalling 6 bytes and a further 3 instructions at 6 bytes to remove the
registers from the stack.)
I agree with improved DIV instructions - they would be useful. I also
think improved BCD support would be cool, although that may be
achievable easily enough by setting the half-carry flag correctly after
all 8 bit add/sub operations and adding a DAA variant for each 8 bit
register. Of course, direct BCD support would also be cool.
> I was looking through the 6309 Technical Guide by Chet Simpson and was insterested
> by Alan Dekok's notes:
> He stated:
> " The W,E, and F registers do not have the full immediate addressing
> mode capabilities that D,A, and B do. SBC, AND, BIT, EOR, ADC, OR
> with E,F,W are available only in register-register mode. LSR, ROR,
> ROL are available for W but not for E,F. ASR, ASL, LSL, NEG do not
> exist at all for W,E,F."
> Adding the Immediate Mode for instructions like SBC, AND, EOR, OR and ADC for the
> the E, F, and W registers is rather easy. Would it be worth the effort to undertake this? I
> can put all those all on page three of the opcode map and they would have the same
> opcodes as their page one instructions. The $11 page code would just switch target
> register acted on. Real simple to do.
> Also how hard would it to be to add several new commands. I was thinking two like in the
> HC11, BRCLR and BRSET. Test a bit in memory and branch if set or cleared. Good for
> testing memory mapped I/O ports.
> I also remember some conversations before about the DIV instructions and a few were
> not impressed with the way the 6309 implements them. I was thinking along the lines of
> implementing division like the HC11, with IDIV and FDIV. That is Integer and Fractional
> division (16 bit). That will be a bit more detailed but division is nothing more that shift and
> subtract. Even thought of adding BCD ADD and BCD Subtract instructions.
> just some curious thoughts on how to improve an already good processor.
> Coco mailing list
> Coco at maltedmedia.com
lost at l-w.ca
More information about the Coco