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?


Reply via email to