Let me clarify: The *only* difference between task and naked is that, if you
apply it to a function that requires allocation of stack space for local
variables, task will allocate that space and naked will generate an error (I
did introduce this behavior change: in the past, naked would "work" for
definitions of "work" that include silently overwriting arbitrary portions
of the stack). See the history at
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg03043.html.
"task" does not mean "noreturn"; that's a different attribute which is part
of base GCC (and which is still not correctly handled in mspgcc; I didn't
fix 3257192 as I'd meant to and have re-opened it).
For pre-emptive task switching, an interrupt with both "task" and "hosted"
attributes will do what you want. On CPUX devices, use "pushm" in an asm
statement to save all registers. There are also now built-ins to manipulate
the stack register.
I was going to say use __builtin_frame_address() to figure out where the
return address is, but it appears mspgcc has always initialized the frame
pointer register to be the value of the stack pointer AFTER the prologue's
finished pushing all call-saved registers and allocating local variables,
which is incompatible with standard usage and makes it completely useless
for figuring out where the return address is in anything except a naked
function.
Since support for _builtin_frame_address is new, maybe I'll fix that (though
that means I'll have to touch gdb and DWARF2 as well). If the frame address
had its more common meaning, the existing semantics of "naked" would be
obviously wrong and "task" would never have been needed. (Not that any of
the function attribute names are particularly evocative.)
At this rate, 20-bit support will get merged in sometime in 2015.
Peter
On Wed, Mar 30, 2011 at 2:20 AM, Peter Jansen <pwjan...@yahoo.com> wrote:
> Hi Peter,
>
> >For problem 1, the commit comments imply my attempt to orthogonalize the
> >attributes went too far: critical and reentrant can't be combined with
> naked
> >because they require prologue/epilogue code, but I thought they might be
> useful
>
>
> >on an interrupt without realizing I'd already disallowed that combination
> too.
>
>
> >I'll look into remove that restriction (SF 3257021).
>
> Yes it was no problem to remove the restriction.
>
> >FWIW, "naked" is a rather poorly defined construct, as the original
> >implementation would allow you to write code that would silently overwrite
> parts
> >
> >
> >of the stack. "task" (documented only in the mailing list archives) is
> >equivalent to naked except that it allocates a stack frame when the
> function
> >requires one, and is what main() will be given when I deal with 3207046.
>
> The FreeRTOS example I'm using does not use 'task', but I agree that 'task'
> is
> useful for functions that don't return.
>
> >I'm curious, though, why your interrupt routine needs control of the order
> of
> >register saves. Does FreeRTOS inspect the stack to extract register
> values for
>
>
> >some reason?
>
> FreeRTOS task switches through a pre-emptive interrupt. So manipulates the
> return address on the stack to switch tasks. This also means that all
> registers
> must be saved. Some way of saving all regs would be nice(tm).
>
> >For problem 2 my sole suggestion is to use msp430-objdump to display the
> >interrupt vector, and check that all values are valid and don't end up at
> >zero. (Unless you end up at zero as a consequence of hitting your naked
> ISR,
> >in which case maybe I had some other reason in mind for ruling out that
> >combination. In general, it's rather dangerous to assume that you can
> know what
> >
> >
> >the compiler did to your code well enough to generate correct prologue and
> >epilogue code.)
>
> I still have to look into what is going on.
>
> Peter
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
