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/>.
