Re: [sdcc-devel] Adding TMS9900 back end

[Oleg E. <ole...@t-...>]

On Tue, 2025-02-11 at 15:51 +0000, Mark Burkley wrote:
> On 08/02/2025 10:25, Philipp Klaus Krause wrote:
> > There is a bit of information about adding a port at
> > https://sourceforge.net/p/sdcc/wiki/Adding%20a%20port/
> Thanks - I've taken a look - very interesting.
> > My main worry here is the large number (16) of large (16 bit) registers
> > in the TMS9900. A Chaitin-style graph coloring register allocator, as
> > used by GCC, is most likely better for that than the register allocators
> > we currently have in SDCC.
> > 
> > Also, I have no idea how much work it would be to get your existing GCC
> > 4.4 backend updated for current GCC, so it is hard for me to compare
> > with the effort of creating a new SDCC port.
> I've taken a look at the backends for stm8 and z80.  There are a few 
> similarities to the GCC insns but it is overall very different and looks 
> like it would be a very significant porting exercise.  Given your 
> comment about the register allocator it sounds like it would be better 
> to stick with the plan to upgrade the latest GCC instead.
> > I haven't looked into the byte orderings yet. But "a few quirks", or a
> > few more, is something you'll find in all SDCC targets.
> Very true!
> 

Register allocation is only one of the many pieces.  SDCC lacks a lot of
other optimizations, but that's what makes it simpler.  If you already have
a working GCC backend, I think it makes more sense to stick with that,
unless you're OK with code quality regressions.

GCC is currently transitioning to the new LRA framework away from the old
reload thing.  Porting an exiting backend to LRA can be trivial or non-
trivial.  It's been an ongoing struggle on SH, but maybe yours is easier.
Some backends like the RX are so simplistic, they require almost no
maintenance.  Others like AVR always seem to be on the hook.  It also
depends how "smart" your backend is (or tries to be).

Best regards,
Oleg Endo