I found the code generators for libfirm/cparser a lot easier to follow than gcc.
On Thu, Nov 12, 2020, 08:07 Philipp Klaus Krause <p...@spth.de> wrote: > Am 11.11.20 um 23:50 schrieb Bill Gaylord: > > Yes. I have no special purpose registers that you can directly access. > > The stack top register you have to use an instruction to actually look > > at or change. > > > > I can link to my horrible google sheets for my Instruction set if that > > helps at all. But basically all arithmetic logic types of instructions > > work directly on registers and can not touch the ram. You have to load > > and store from ram into the registers to access anything. > > > > I am not sure if SDCC is the best choice here: > > * You have many fully interchangeable registers. For this scenario, > Chaitin-style graph-coloring register allocators tend to be the best > choice in terms of compiler runtime vs. code quality. > * AFAIK, GCC and LLVM have Chaitin-style graph-coloring register > allocators. SDCC doesn't. > * SDCC has two registzer allocators: A linear range scan (used for > mcs51, ds390, pic14, pic16), which is fast, but doesn't generate very > good code, and the "new allocator" used for the other ports (by default, > some ports have an option to switch to the linear range scan one instead > to reduce compilation time). > * SDCC's "new allocator" can be optimal, and can deal even with highly > non-orthogonal architectures. Where there are many registers, it tends > to get slow. But it works quite well for the 9 8-bit registers used by > the z80. It has never been tried on more registers. > The allocator could be improved to be faster where registers are > interchangeable, but that has never been implemented (as the > architectures it is currently used for are non-orthogonal). > > I suspect that GCC would be the best match for your architecture. The > GCC avr port has shown that GCC can deal well with 8-bit architectures > that have many interchangeable registers. But GCC has a steep learning > curve. LLVM also might work well, but it tends to change interfaces > often, so there is quite some maintenance effort required to keep a port > current with LLVM. > > SDCC is still an option - its learning curve is less steep than that of > GCC, and interfaces are more stable than those of LLVM. But you'll have > to choose one of SDCC's register allocators (or implement a > Chaiting-style one, but that would be extra effort required). The linear > scan allocator will be fast, but give worse results than Chaitin. The > "new allocator" will be slow. It might give better results than Chaitin, > but we don't have data for that many registers. > > Philipp > > > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user >
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
