On 03/05/13 10:06, Chung-Ju Wu wrote: > 2013/5/3 Chung-Ju Wu <jasonw...@gmail.com>: >> >> Or do you think 'naked' is still useful for some other cases in mips porting? >> You can implement it and submit the patch to gcc-patc...@gcc.gnu.org >> and I believe the mips maintainers are willing to have review with you. :) >> > > Oops~ I just noticed that the mips maintainer Richard Sandiford > already had some thought about 'naked' attribute. > > Refer to: > http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html >
I've only used gcc on mips for a couple of small programs, and haven't needed "naked". But I've used it occasionally on other targets, and I'm with Mark Mitchell on this one. "naked" is not often useful - but when it /is/ useful, it can be very useful. In some cases you might want to use it for interrupts, if the normal interrupt framing is not suitable (on some platforms it is not quite optimal). You might want to use it in conjunction with writing a RTOS. Personally, I've used "naked" when I want to write pure assembly code and don't want extra stack frames or "return" codes. I don't want to write stand-alone assembly files (I've written mountains of them in the past, and hope they stay in the past). I am happier using the very nice flexible gcc inline assembly syntax. I am happier having all my code in C files - it fits my build process well. So some people use "naked" on some targets. Other people who don't like it, don't have to use it. But in the interests of compatibility, maintainability, code re-use (within gcc), ease of use, code re-use by users across different platforms, ease of learning, simpler documentation, and a dozen other good reasons - there should always be an aim to make attributes consistent across targets. I can well understand that some attributes will not be implemented on some targets - they are perhaps not appropriate, or there simply has not been anyone with the time to do the work. But - speaking purely as a user - it is hard to understand why a feature like "naked" would not be available on all targets. Equally, it is hard to comprehend why attributes for interrupt functions are called "interrupt" on one target, "interupt_handler" on another, and "exception_handler" on a third - and why "interrupt" will re-enable interrupts on some targets but not others. Surely it would be a good thing all round if these sorts of this were - where practically possible - consistent across targets?