removal of -mflat in GCC 4.0 (sparc)

[Garrett D'Amore]

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