Re: [PIC] Learning C
Isaac Marino Bavaresco <[email protected]>
| Newsgroups | gmane.comp.hardware.microcontrollers.pic |
|---|---|
| Message-ID | <[email protected]> |
> and then
> to verify that the top values never change.
That is not 100% guaranteed, because that area could be allocated to an
array that is never fully used.
It is very common to have lots of unused "holes" in the stack. I know
that because I use RTOSes a lot and often check the stacks of the tasks.
The safest way is checking the stack pointer itself. e.g. (for ARM):
#define SAFETY_MARGIN 128
extern uint32_t _sstack;
uint32_t sp;
asm volatile( "mov %0,sp" : "=r"(sp) );
if( sp < _sstack + SAFETY_MARGIN )
{ /* Do something... */ };
Cheers,
Isaac
Em 19/11/2024 03:54, Forrest Christian (List Account) escreveu:
> So my point really was to point out that being able to determine the status
> of the stack is really implementation defined behavior, and assuming that
> the address of an auto variable is on the stack isn't guaranteed.
>
> As a result one needs to read the compiler manual once you start getting
> into this level of design. In some architectures all auto variables go on
> the stack. In others there is basically no stack and the compiler
> implements it statically. Some architectures have a single stack pointer
> register one can read, others have multiple pointers for different
> functions. All change how you determine the current stack pointer, if one
> even exists.
>
> In the context of detecting an overflow at runtime, one strategy that is
> used is to initialize the stack memory to a known non-zero value and then
> to verify that the top values never change. If they do, you know that
> something has overwritten them probably due to a stack overflow which can
> be handled appropriately.
>
> On Mon, Nov 18, 2024, 11:57 AM smplx <[email protected]> wrote:
>
>> Hi Forrest,
>> Thank you for that, I really appriciate you taking the time to explain!
>>
>> I didn't know XC8 used a static stack. XCSB did this back in 2002
>> (http://xcprod.com/titan/license.html). I guess XC8 caught up. Now all we
>> need to do is wait for compiler aware multitasking (you know, where we get
>> multiple copies of functions so they can be used concurrently in different
>> tasks) and builtin efficient comms between tasks.
>>
>> The one thing I REALLY hate is when people claim to produce a C compiler
>> and "Oh, BTW it doesn't do this and that - but it is C". Come on if it
>> isn't 100% C then call it something else - I did :-)
>>
>> Yes I really do understand the implications of a static stack but the
>> poster I was replying to wanted to know how he could perform a sanity
>> check on the stack. If your software is generating a static stack then
>> there is ABSOLUTELY no need for a sanity check and it would be impossible
>> for the software to overflow the stack without the compiler detecting it.
>>
>> FYI if you really want the compiler to generate space on the stack OR FAIL
>> then there is always "alloc", recursive functions, pointer to functions,
>> seperate compilation units... blah blah blah... I'm sure you could come up
>> with something than will ALWAY work for portable C code.
>>
>> Really Really Friendly Regards :-)
>> Sergio Masci
>>
>>
>> On Mon, 18 Nov 2024, Forrest Christian (List Account) wrote:
>>
>>> The C standard doesn't mention where automatic duration variables (like x
>>> in your example) will be stored. It leaves that 100% up to the
>> compiler.
>>> It could be on the stack, or it could be some static allocation, or it
>>> could be a register, or somewhere else.
>>>
>>> A good example is XC8, and other compilers for the 8 bit PICs. It does
>>> what it calls static stack allocation. How it works is somewhat easy to
>>> explain:
>>>
>>> Every auto variable that won't fit in a register is assigned a specific
>>> memory address which never changes for a particular build of the code.
>>> Because XC8 is aware of the call tree, it is able to assign these
>> variables
>>> in a way that variables that are never "active" at the same time can
>> share
>>> the same memory space. For example, all library functions that use a
>>> temporary variable and then return can use the exact same space for those
>>> variables. On the other hand, an auto variable which exists in main()
>>> will need to be assigned a dedicated space which is not reused.
>>>
>>> This also simplifies the output code. Instead of having to deal with the
>>> stack pointer, the functions can then just go after the memory directly.
>>> This does cause problems for functions which are called by interrupt
>>> routines and as such, the compiler will duplicate functions which are
>> used
>>> by the main program and interrupts, compiling each to their own set of
>>> variables. XC8 or one of the other compilers I've used will emit a
>> warning
>>> when it does that. I'll usually use that as an excuse to look at the
>>> called function and determine if it can be eliminated from the interrupt
>> in
>>> some way that improves the code.
>>>
>>> One other note is that "statically compiled stacks" like this don't
>> support
>>> recursion as it's impossible to tell the call depth. As a result, either
>>> the compiler will fail the compile with an error, or in some cases the
>>> compiler will do a dynamic stack just for the recursive functions.
>>> Looking at the XC8 compiler docs it looks like on larger PICs with better
>>> support for a stack it supports this mixed methodology.
>>>
>>> Note that this whole issue is one of the reasons why the AVR crowd used
>> to
>>> point at their core and said it was better for C, since it has better
>> stack
>>> support and also has other features which are more useful for C such as
>> (if
>>> I recall correctly) more data registers to store temporary values in.
>>>
>>> One final note: Any C complier which compiles for hardware with a very
>>> restricted or non-existent stack is going to have to support some sort of
>>> method for having auto variables not being on the stack. Even if that
>>> support is to tell the programmer that they need to fix this (or worse,
>>> produce a broken executable).
>>>
>>> On Mon, Nov 18, 2024, 4:01 AM smplx <[email protected]> wrote:
>>>
>>>> Hi Forrest,
>>>> I am intrigued by what you say. Could you please point me at any
>> specific
>>>> embedded C compilers that do this.
>>>>
>>>> Friendly Regards
>>>> Sergio Masci
>>>>
>>>> On Sun, 17 Nov 2024, Forrest Christian (List Account) wrote:
>>>>
>>>>> With many embedded compilers, x may or may not be on the stack, as the
>>>>> compiler will, in some cases, use non-stack memory for local
>> variables.
>>>>> This is especially true on smaller microcontrollers with limited stack
>>>>> space.
>>>>>
>>>>> One would need to read the compiler manual to determine if x will
>> always
>>>> be
>>>>> on the stack, whether there is a way to force x to be on the stack,
>> or
>>>> if
>>>>> there is a compiler specific way to get the stack pointer.
>>>>>
>>>>> On Sat, Nov 16, 2024, 4:09 AM smplx <[email protected]> wrote:
>>>>>
>>>>>> write a function:
>>>>>>
>>>>>> void * get_stack_ptr(void)
>>>>>> {
>>>>>> int x;
>>>>>>
>>>>>> return &x;
>>>>>> }
>>>>>>
>>>>>> This will return the address of the local variable x which will be on
>>>> the
>>>>>> stack.
>>>>>>
>>>>>> use it as:
>>>>>>
>>>>>> if ((unsigned long)get_stack_ptr() == (unsigned
>>>> long)fixed_value+N)
>>>>>> // where N is a constant TBD (around +/- 4 to 12)
>>>>>>
>>>>>>
>>>>>> On Fri, 15 Nov 2024, David VanHorn wrote:
>>>>>>
>>>>>>> Same here. I can work with c fairly well, but some things seem
>>>> unusually
>>>>>>> difficult in c. Like comparing the current value of the stack
>> pointer
>>>>>> to a
>>>>>>> fixed value ( used in my sanity check routine) I assume there is a
>>>> way
>>>>>> to
>>>>>>> get there.
>>>>>>>
>>>>>>> On Sun, Nov 10, 2024, 11:34 AM David C Brown <[email protected]>
>>>> wrote:
>>>>>>>> Although I enjoy programming in Assembler, the fact that so many
>>>>>> libraries
>>>>>>>> abd code examples are in C I think that the time has come for me
>> to
>>>>>> learn
>>>>>>>> that language.
>>>>>>>>
>>>>>>>> Any advice on how to do that would be welcomed, be it a book or
>>>> online
>>>>>>>> resources.
>>>>>>>> I am a competent programmer having programmed in with Forth,
>>>> Fortran.
>>>>>>>> \Pascal, Visual basic
>>>>>>>> __________________________________________
>>>>>>>> David C Brown
>>>>>>>> 43 Bings Road
>>>>>>>> Whaley Bridge
>>>>>>>> High Peak Phone: 01663 733236
>>>>>>>> Derbyshire eMail: [email protected]
>>>>>>>> SK23 7ND web: www.bings-knowle.co.uk/dcb
>>>>>>>> <http://www.jb.man.ac.uk/~dcb>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Sent from my etch-a-sketch*
>>>>>>>> --
>>>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>>>>>> View/change your membership options at
>>>>>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>>>>>>
>>>>>>> --
>>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>>>>> View/change your membership options at
>>>>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>>>> --
>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>>>> View/change your membership options at
>>>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>>>>
>>>>> --
>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>>> View/change your membership options at
>>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>> --
>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>> View/change your membership options at
>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>>
>>> --
>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>> View/change your membership options at
>>> https://mailman.mit.edu/mailman/listinfo/piclist
>> --
>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>> View/change your membership options at
>> https://mailman.mit.edu/mailman/listinfo/piclist
>>
--
O software antivírus Avast realizou uma checagem de vírus neste e-mail.
www.avast.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
https://mailman.mit.edu/mailman/listinfo/piclist