Esteemed GCC developers:
I am writing to request the that the sparc -mflat option be retained in GCC 4.0.
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.
I believe that the uSPARC-IIep is a truly "open-source" processor: the specs for the entire processor are freely downloadable from Sun -- anyone can produce cores with this chip for free. While I'm not a VLSI engineer, I think that everything one needs to go to production on such cores is already freely available from Sun. (So I'm saying that the chip *implementation* is open, not just the instruction set or pin-outs.)
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.
Btw, I think the uSPARC-IIep is also used certain older JavaStations, which can and do run Linux. I'm not sure how many of them there are out there, but Linux seems to be the OS of choice for these boxes. I don't know whether -mflat is used in that environment or not. It certainly seems like it could be, too good effect for performance. (Otherwise nearly every save/restore would involve an interrupt for window overflow and underflow.)
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.)
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.
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.)
Thank you in advance for your consideration of this request.
-- Garrett
