Jeff, that is a good solution. Next time I need to do this, I will look into that.
Thanks. M On Fri, Nov 5, 2010 at 2:00 PM, Jeff Barber <[email protected]> wrote: > Why don't you just imitate what the boot loader would do? Find the > symbol that indicates the beginning of BSS and the symbol that > indicates the end, find the difference and clear. Then only do that > when your wakeup has decided there's something to do. Linker-dependent > but usually these symbols are accessible or can be made so. > > Jeff > > On Fri, Nov 5, 2010 at 4:51 PM, mat henshall <[email protected]> wrote: >> Simon... >> >> It sounds like you are frustrated that this issue has been raised >> multiple times and doesn't seem to go away! I am sorry to add to the >> 'fire'. In all the important things that could be done/worked on this >> is, I am sure a low priority. >> >> I wanted to bring to your attention a use case where it makes sense to >> turn off compliance with the standard (I believe most compliers allow >> this) ... and I pass on the reasoning from the engineers who made the >> choice... The circumstance they are concerned about is when a very low >> power device wakes up and decides to do nothing.... then not reading, >> not writing not zeroing... dong as little as possible can make a big >> differnece to battery life. Ofcourse, if you need to wake up and get >> on the netowork, all bets are off, and the time taken to zero out is >> irrrelevant. But as the ratio of wake up and do nothing to wake up and >> talk to the radio is often 100000 to 1 or more, it kind of makes >> sense. I believe they measured it. >> >> I have had this discussion with other library writers... and you are >> correct, Ansi C says it should be zero'd... doesn't stop me from >> having to search through the libraries every time there is a version >> increment to see if I need to manually init to zero in these >> applications. >> >> A single function where all the global variables are gathered together >> and zero'd out that can optionally be linked in makes a cleaner >> interface for this odd, but not unknown usecase. >> >> Regards, >> >> mat >> >> On Fri, Nov 5, 2010 at 12:44 PM, Simon Goldschmidt <[email protected]> wrote: >>> Excerpt from the ANSI-C Standard >>> (e.g. http://flash-gordon.me.uk/ansi.c.txt): >>> If an object that has static storage duration is not initialized >>> >>> explicitly, it is initialized implicitly as if every member that has >>> arithmetic type were assigned 0 and every member that has pointer type >>> were assigned a null pointer constant. If an object that has >>> automatic storage duration is not initialized explicitly, its value is >>> indeterminate./65/ >>> >>> As you can see, there's absolutely no portability issue here! Also, there's >>> no performance gain in not zeroing the variables at startup: when they are >>> explicitly initialized by the application, the loader has to load their >>> initial values from flash/ROM to RAM. When relying on zeroing by the loader, >>> you only have to write zeros starting from a defined point, for a defined >>> length. What's faster now, reading AND writing or only writing? >>> Also, if you write an ANSI-C compatible loader/startup code, there's no need >>> to manually collect global variables and initialize them with your own C >>> code. also, static globals can't be collected that way as you can't access >>> them from another file. >>> Finally, we've been having his discussion over and over again, and the ANSI >>> C standard didn't change over the years in that regard. I'm still open for >>> really pressing issues regarding portability, but up to now, I (and other >>> lwIP developers, I guess) haven't been convinced this is such an issue. >>> Simon >>> >>> mat henshall <[email protected]> wrote: >>> >>> Simon, >>> >>> I have hit this problem where an environment by default turns off the >>> initialization of globals for 'efficiency' and expects an application >>> to explicit zero out the globals and statics as needed. For example, I >>> use an ultra low powered wifi chip that has lwIP in ROM and it loads >>> applicaiton code from flash on 'wake up'. TIme is energy, so the less >>> time the chip takes to wake up and see if it really needs to do >>> something and the if not, fall asleep again, the better. Only if you >>> really want to do something might you want to then initialize the >>> various modules etc. >>> >>> When using subsystems and third party libraries, it is always a >>> little error prone and painful to collect all the various globals into >>> a 'init_to_zero' function. It would be more pleasant and robust to >>> have the optional function provided by the library. >>> >>> Mat >>> >>> On Fri, Nov 5, 2010 at 11:53 AM, Simon Goldschmidt <[email protected]> wrote: >>> >>> Hey Piotr, >>> >>> I hate to turn you down on that, but the variables are deliberately not >>> being initialized: when not initialized (and thus implicitly zeroed at >>> startup), they are put into the uninitialized section and no space on >>> disk/in flash is needed. However when they are initialized to NULL, they are >>> put NGO the initialized data section, which is present on disk/in flash, >>> too. >>> >>> As to the portability: the C standard requires non initialized data to be >>> initialized to zero at startup. It is a common error in self-made ports to >>> leave out the zeroing of the uninitialized data section (.bss for gnu bcc). >>> >>> Simon >>> >>> Piotr Piwko <[email protected]> wrote: >>> >>> Hello, >>> >>> I currently implement the LwIP stack under u-boot environment and I >>> >>> have one notice regarding global variables initialization. I think >>> >>> that every global variable which are not static should be initialized >>> >>> by NULL or 0 value. I mean for example: >>> >>> file tcp.c: >>> >>> struct tcp_pcb *tcp_bound_pcbs; >>> >>> union tcp_listen_pcbs_t tcp_listen_pcbs; >>> >>> struct tcp_pcb *tcp_active_pcbs; >>> >>> struct tcp_pcb *tcp_tw_pcbs; >>> >>> file udp.c: >>> >>> struct udp_pcb *udp_pcbs; >>> >>> file netif.c: >>> >>> struct netif *netif_list; >>> >>> struct netif *netif_default; >>> >>> If I leave they uninitialized, after compilation and link operation >>> >>> they will contain random values which causes the system crash during >>> >>> LwIP initialized functions. Assumption that they will be automatically >>> >>> filled by 0 is wrong and non-portable. >>> >>> This modification can really save a lot of time during integration :) >>> >>> Anyway I am impressed with LwIP project. It is very useful part of >>> >>> software. Good job guys! >>> >>> Regards, >>> >>> -- >>> >>> Piotr Piwko >>> >>> http://www.embedded-engineering.pl/ >>> >>> _______________________________________________ >>> >>> lwip-users mailing list >>> >>> [email protected] >>> >>> http://lists.nongnu.org/mailman/listinfo/lwip-users >>> >>> _______________________________________________ >>> >>> lwip-users mailing list >>> >>> [email protected] >>> >>> http://lists.nongnu.org/mailman/listinfo/lwip-users >>> >>> >>> >>> >>> -- >>> >>> Mat Henshall >>> Founder and CEO, Square Connect, Inc. >>> San Jose, CA >>> www.squareconnect.com >>> cell: 650.814.7585 >>> >>> _______________________________________________ >>> lwip-users mailing list >>> [email protected] >>> http://lists.nongnu.org/mailman/listinfo/lwip-users >>> >>> _______________________________________________ >>> lwip-users mailing list >>> [email protected] >>> http://lists.nongnu.org/mailman/listinfo/lwip-users >>> >> >> >> >> -- >> >> Mat Henshall >> Founder and CEO, Square Connect, Inc. >> San Jose, CA >> www.squareconnect.com >> cell: 650.814.7585 >> >> _______________________________________________ >> lwip-users mailing list >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/lwip-users >> > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > -- Mat Henshall Founder and CEO, Square Connect, Inc. San Jose, CA www.squareconnect.com cell: 650.814.7585 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
