Re: [sdcc-devel] Adding TMS9900 back end

[Mark B. <ma...@bu...>]

On 12/02/2025 01:00, Oleg Endo wrote:
> 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.
Agree.  Unfortunately regressions would be an issue.  The compiler users 
are picky about code size and speed given their apps run on 
retro-computers with limited space.  Generally everything is compiled 
with -O2 optimisation.  Even getting GCC to emit well optimised code has 
been a challenge.
> 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).
The backend isn't particularly smart.  It just has some workarounds for 
some issues I've had, which are mostly due to GCC's assumption that it 
can use 8-bit instructions to access the lower byte of a 16-bit value, 
which isn't the case for the 9900.

The version of GCC I'm using at the moment is very old (4.4.0). I have a 
side project to update it to 13.2 which did take quite a bit of work 
since the condition code handling completely changed. But it's emitting 
working code now in most cases.  Sounds like I should just keep going 
with that initiative.  I'm hoping the move to GCC 14 or even 15 will be 
easier once I have a stable version on 13.  I see LRA is the default 
since GCC 7 and I didn't do anything to select reload so hopefully the 
condition code rework I've done is most of what I need to do there.  The 
9900 regs are orthogonal so I maybe that makes it less problematic.

Thanks

Mark