> The reason this particular register model is important to me is that I > use GCC on the microSPARC-IIep (actually, a SoC variant produced by > Infineon called the "copernicus") to build firmware for Sun Ray > appliances (ultra-thin client). These SparcV8 processors only have two > register windows, so the -mflat option is required for performance. > (The Sun Ray kernel also doesn't have a handler for register window > over/underflow traps.) The register windows are used exclusively for > entry into the interrupt handler. > > [...] > > Note also that these parts (Copernicus at least) are real, currently > shipping products. This is *not* a legacy product, and active new > development is continuing on this stuff.
OK, there appears to be a real niche. > I do realize (and am very grateful) that GCC is a free project, and that > the needs of the many may outweigh the needs of the few. (I am also > asking my company to make a donation to the FSF in support of GCC, > independent of the decision about -mflat. Whether such a donation is > made or not depends on management though, so I can't promise anything.) Thanks for doing that. > But I also thought it was a real possibility that the GCC team might not > be aware of anyone who had a real requirement for the -mflat option. I > certainly appreciate the value of trimming support for defunct > architectures and such from a product to reduce code size and > complexity. However, in this case such a trim does potentially impact > otherwise happy GCC users. The -mflat support code in the SPARC back-end was identified as an absolescent, untested and unmaintained code. I personally gave it a whirl in the 3.4 timeframe and the testsuite results were abysmal (a few fixes were added as a result, so 3.4.x is supposed to be less broken than earlier compilers). We basically had 0 bugreport in years. Moreover, it was in the way of a major technical transition for the SPARC back-end. It was, therefore, advertised as deprecated in 3.4.x: http://gcc.gnu.org/gcc-3.4/changes.html and its support code was immediately removed when 4.x development started, one year ago. > I'd be grateful if the team could consider reversing the decision on > -mflat. While I can continue to use older versions of GCC, I'd like the > ability to update to new compilers later if possible. (It certainly > seems like some of the new optimizations in GCC 4.0 might be very useful > to us.) Because of the aforementioned technical transition, -mflat cannot be simply reinstated in 4.x. It must be rewritten from scratch. It's definitely too late to do that for 4.0, so the compiler will be released without -mflat support. But it is not too late for the next release cycle, 4.1, whose development just started. There is probably a 6-month window for the -mflat support to be reimplemented in the back-end and be released with 4.1. The amount of work is not overwhelming but, as GCC is a volunteer project, your company might consider hiring someone to do the work if it deems the feature a requirement for 4.1. -- Eric Botcazou
