On Tue, Jul 10, 2012 at 10:47 PM, Георгий Охохонин <oxoxo...@gmail.com> wrote: > Hello dear mspgcc users! > > Can somebody tell me, what does the attribute 'task' mean?
The best description of task right now outside the source is probably http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg03043.html Apparently "task" was added after the manual was written and the manual wasn't updated. Other function attributes are documented at http://mspgcc.sourceforge.net/manual/x877.html which is mostly right. See http://mspgcc.git.sourceforge.net/git/gitweb.cgi?p=mspgcc/gcc;a=blob;f=gcc/config/msp430/msp430-function.c;h=52ab756894062b3db73e95911849a889070a358a;hb=HEAD#l418 for the corresponding source code. > And what could mean this warning: frame allocation destroys caller register > due to 'task' [-Wattributes]? What "naked" does is skip the function prolog (save caller registers, allocate a stack frame for local variables) and epilog (pop the local stack frame, restore registers, return to caller). "task" differs from "naked" in that it will allocate space on the stack for any local variables. It still won't save caller registers, and doesn't execute a return instruction. A frame pointer is needed when there are places within the function where gcc needs to know the value of the stack pointer on entry (for example, to access parameters passed on the stack), but for whatever reason can't figure it out by subtracting a constant value from the current stack pointer. gcc stores this frame pointer in register r4 on entry to the stack. Normally, the caller's value for r4 would have been saved in the function prolog, and restored in the epilog. For "naked" and "task" functions, this isn't done, so what gcc's telling you is that it's generated code that will destroy the caller's frame pointer. This is probably a serious problem, and you will have to look at the source code and assembly code generated for the task function to determine what might be causing the need for a frame pointer, and try to eliminate it. Generally, a "task" function should do nothing but save registers and switch context to a different thread. If the cause is https://sourceforge.net/tracker/?func=detail&aid=3458330&group_id=42303&atid=432701, you'll have to use another solution to changing the stack pointer, because as I think about it that's probably not a bug. An example of doing RTOS task switching using current mspgcc is in the FreeRTOS-mspgcc repository at https://github.com/pabigot/freertos-mspgcc/blob/master/Source/portable/GCC/MSP430/port.c. Peter > > Thank you. > > -- > George. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
