Re: [PIC] Learning C

This all seems rather more complicated than simply comparing SPH and SPL to
a fixed value which is determined by breakpointing just before the
comparison.
(Atmel AVR)

On Tue, Nov 19, 2024 at 4:45 AM Isaac Marino Bavaresco <
[email protected]> wrote:

> > and then
> > to verify that the top values never change.
>
> I think I made a mistake, the test should be:
>
>      if( sp < (uint32_t)&_sstack + SAFETY_MARGIN )
>
>
> I also noticed an interesting thing, the compiler is extremely clever,
> it detects that we are testing for stack overflow and put this code even
> before allocating the local variables.
>
>
> Cheers,
>
> Isaac
>
>
> > 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
>
-- 
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
https://mailman.mit.edu/mailman/listinfo/piclist