On Sun, Apr 11, 2021 at 8:04 AM David Brown <david.br...@hesbynett.no> wrote: > > On 11/04/2021 16:37, Richard Kenner via Gcc wrote: > >> I guess my point is that the direction in which a project *does* go is not > >> always the direction in which it *should* go. > > > > I agree. And depending on people's "political" views, that can either be > > an advantage or disadvantage of the free software development model. > > > >> To give just one small practical example, I'm told (by people who are more > >> familiar with GCC internals than I) that it is not feasible with today's > >> GCC to port to backends which have a small number of registers. > > > > [Finally, a technical discussion in this thread!] > > > > It never really has been. Maybe it's not even possible now (I don't > > know), but if you tried it in the past the results would never have > > been very good. Almost all multi-backend systems operate by having > > very large numbers of expressions at all levels, which you gradually > > lower to actual registers. This works quite well if you have enough > > registers to hold the high-usage expressions in them, but when you > > have high register pressure, the model breaks down completely. > > Although the situation may well have gotten worse in recent versions > > that I'm not familiar with, I'd say that GCC was probably doing a > > *better* job with a small number of registers in more recent versions > > than in older ones: "reload" was particularly bad when there was high > > register pressure. > > > > When your main constraint is register pressure, in order to get > > high-quality results, I think you almost have to change the entire > > philosophy of compilation, to the point I think where you have an > > almost entirely different compilation chain for such machines. > > > > Low register count cpu designs have been out of fashion for quite some > time now (perhaps precisely because they are not a good fit for common > compiler strategies). They are mostly found in older families, such as > the 8-bit CISC designs in older microcontrollers (8051, PIC, COP8, 6502, > etc.). And you are absolutely right that you need a different way of > thinking in order to get the best out of such chips - low register count > is only one aspect. Other issues are few or no flexible pointer > registers, no "SP + offset" addressing modes for efficient parameters or > stack frames, banked ram and code blocks, and multiple separate address > spaces. Good toolchains for such devices need to work in a very > different way, and typically encompass compilation, assembling and > linking in one "omniscient" build so that variables, parameters, etc., > can be placed statically in ways that minimise banking and maximise > reuse, based on lifetime analysis of the whole program. > > This would be a massively different way of working from how gcc does > things now, and given that such devices are very much on the decline > (when 32-bit ARM microcontrollers can be bought for 30 cents, smaller > and cheaper cpu cores are rarely the right choice for a new design), it > would not make sense to spend the effort supporting them in gcc. There > is, after all, quite a solid GPL'ed compiler toolchain for such devices > at <http://sdcc.sourceforge.net/>.
I think it depends on your goals. In the past I've ported GCC to a Harvard architecture system with six registers. I agree that the code quality was not the highest possible. But the port worked fine, and for this process performance was not an issue. (As you suggest, I tend to think that for most people who choose a processor with a small number of registers, performance is not an issue. Where performance matters a lot, spend the money for a real processor, or at least use a RISC/V.) Ian
