Hello
The 68hc11 support by GCC is not very good and is limited to an old
release, so there is no more support for it, and last time I tried, I
found it quite heavy and rigid in structure. It requires additional RAM
mapped pseudo-registers, which facilitate gcc code generation but these
are a burden in many embedded cases. GDB and binutils still have full
support.
This CPU is quite annoying because of its lack of stack or pc relative
modes. It has the TSX and TXS opcodes to access SP, but this is
inefficient. Memory mapped local variables would be better, keeping the
stack for the rare reentrant code that need it. Using Y as SP is another
possibility, but the generated code looses quite a bit of compacity
because the Y-based opcodes need a prefix.
The culmination of this effort could be support for the 6809, because
even if that one is theoretically supported by several gcc based
toolchains, support is clumsy and documentation/chains are very
scattered across the internet. you find patches for several gcc
versions, but no single good "source tree" to download and build easily.
A 6809 SDCC would likely be much better in general quality, code
quality, and compacity.
(I have written simulators for the 68hc11 and 6809).
All the 68xx CPUs are variations on a similar base, so they could all be
supported with code generation options?
It's difficult for me to be a project leader of any kind but I can help
with some testing.
I should be getting a Epson HX-20 in 2026, so it would be fun to use
sdcc to write code on it :)
Sebastien
On 12/7/25 2:26 PM, Philipp Klaus Krause wrote:
Am 07.12.25 um 13:12 schrieb tcfkat--- via Sdcc-user:
I would very much welcome support for MC680x. The Hitachi HD6303
clone has an extended instruction set, so perhaps that could be
supported as well. Original Motorola has 59 illegal or better unused
opcodes, while Hitachi has only 26. (I started a long time ago
writing a MC6800 simulator, but never finished.)
I agree, though I don't think the HD6301/HD6303 additions over the
MC6801 (10 additional opcodes, or so I think) matter that much, AFAIK
they are mostly just about bitwise operations on memory operands. But
combined with the timing differences an extra port would be worth it.
As far as I can see, we have instruction sets:
MC6800 ⊊ MC6801 ⊊ HD6301.
That could be three ports (possibly named mc6800 mc6801 hd6301 or
similar), that would then share most of the code.
I don't know how much time I'd find to contribute, but I think I could
do some or most of the work on code generation and register allocation.
But first, we need assembler and simulator support for at least one of
the three architecture variants each.
Philipp
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
