Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #25450
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: g++ on Cortex-M with no dynamic memory |
| Date | 2016-11-08 02:31 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <nvs610$vep$1@dont-email.me> (permalink) |
| References | (3 earlier) <gdednX9BUNITNb3FnZ2dnUU7-IudnZ2d@giganews.com> <5820bc64$0$1739$e4fe514c@newszilla.xs4all.nl> <7lq12c5tdg01as2mmm1qnfnb52d32r5jba@4ax.com> <nvqqrd$hhf$1@dont-email.me> <kc132clolt74fqmms83orohe68t68j5s77@4ax.com> |
On 11/8/2016 1:57 AM, upsidedown@downunder.com wrote:
>>>> // using free must cause a linker error
>>>> void free( void * p ){
>>>> void if_you_see_this_you_are_using_free_or_delete();
>>>> if_you_see_this_you_are_using_free_or_delete();
>>>> }
>>>
>>> free() is a no-no, I disable it after the first millisecond and let
>>> the program run for 10-40 years.
>>
>> So, all of your objects are persistent? (e.g., no "temporary/transient"
>> tasks that come and go -- instantiating then releasing their stacks, etc.)
>
> The nice thing about stacks is that the worst case stack allocation
> can be determined statically. Even if recursion is used, the worst
> case allocation as long as you have a strict limit to the recursion
> depth.
>
> The problem with heaps is the fragmentation of the heap in a long
> running system. It might seem running OK for the first year, but will
> it run for the next ten years ?
That depends on how that memory is physically implemented.
E.g., slip a VMM under it and issues change (albeit at the
granularity of pages)
Also, it assumes your memory allocation strategy is fixed and
not under the control of the memory system's clients -- who
*know* how the memory is likely to be used (allocated AND
released).
[IMO, that's the problem with most allocators: one arena and
one black-box allocation strategy.]
E.g., folks have no problem dealing with "buffer pools"
("partitions", etc.) -- and PREFER them to "dynamic
memory allocation". But, isn't this just a special case
of dynamic memory allocation? One chosen where all
requests are of a size determined a priori?
If, for example, I implemented malloc() to allocate pools in exactly
those same sizes, I could replace your "buffer_alloc()" with
"malloc()" and your code would perform identically!
> One can not test a system for 10 years
> and then release it. With properly designed systems, running it for a
> few months should be enough. If it is going to fail in the far future,
> it will fail during the early test period (infant mortality).
If I allocate task stacks from an arena that I, BY CONVENTION,
manage as a set of "stack sized units" -- or, that is backed
by a set of VMM pages that correspond efficiently with
submultiples of stack sizes -- then I can allocate and free in
damn near any order for all eternity without ever worrying
about fragmentation.
[It's just "buffer pools" at a different level in the
implementation!]
"Don't run with scissors" is unnecessarily pessimistic.
>> How would you, for example, build a set of cascaded menus? In
>> artificially introduced function layers?
>
> What prevents using a stack based allocation system ?
Why force them to be auto variables in (layered) *function* stack frames
when you can use an (intrinsic) stacking allocation strategy on a heap?
(because that is the very essence of the user interface!)
I.e., there are characteristics of the application of which the DEVELOPER
is aware -- that a compiler nor stdlib writer will *never* be aware.
Why tie the developers' hands needlessly? Are the standard libraries
THAT intimidating that you can't "look under the hood" and FIX them
to behave in a more opportune manner? To provide guarantees that
SOME PARTICULAR IMPLEMENTATION doesn't?
[Preface each function's name with "my_" if you're afraid someone
won't understand that there are differences]
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
g++ on Cortex-M with no dynamic memory Dave Nadler <drn@nadler.com> - 2016-11-05 14:09 -0700
Re: g++ on Cortex-M with no dynamic memory antispam@math.uni.wroc.pl - 2016-11-07 02:55 +0000
Re: g++ on Cortex-M with no dynamic memory Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-07 07:52 +0000
Re: g++ on Cortex-M with no dynamic memory Wouter van Ooijen <wouter@voti.nl> - 2016-11-07 09:11 +0100
Re: g++ on Cortex-M with no dynamic memory Tim Wescott <tim@seemywebsite.com> - 2016-11-07 10:08 -0600
Re: g++ on Cortex-M with no dynamic memory David Brown <david.brown@hesbynett.no> - 2016-11-07 10:02 +0100
Re: g++ on Cortex-M with no dynamic memory Dave Nadler <drn@nadler.com> - 2016-11-08 12:01 -0800
Re: g++ on Cortex-M with no dynamic memory Dave Nadler <drn@nadler.com> - 2016-11-07 04:13 -0800
Re: g++ on Cortex-M with no dynamic memory Tim Wescott <tim@seemywebsite.com> - 2016-11-07 10:15 -0600
Re: g++ on Cortex-M with no dynamic memory Wouter van Ooijen <wouter@voti.nl> - 2016-11-07 18:39 +0100
Re: g++ on Cortex-M with no dynamic memory Tim Wescott <seemywebsite@myfooter.really> - 2016-11-07 11:59 -0600
Re: g++ on Cortex-M with no dynamic memory Wouter van Ooijen <wouter@voti.nl> - 2016-11-07 19:40 +0100
Re: g++ on Cortex-M with no dynamic memory Dave Nadler <drn@nadler.com> - 2016-11-08 11:59 -0800
Re: g++ on Cortex-M with no dynamic memory Wouter van Ooijen <wouter@voti.nl> - 2016-11-08 23:30 +0100
Re: g++ on Cortex-M with no dynamic memory David Brown <david.brown@hesbynett.no> - 2016-11-09 09:23 +0100
Re: g++ on Cortex-M with no dynamic memory Wouter van Ooijen <wouter@voti.nl> - 2016-11-10 07:34 +0100
Re: g++ on Cortex-M with no dynamic memory David Brown <david.brown@hesbynett.no> - 2016-11-10 10:43 +0100
Re: g++ on Cortex-M with no dynamic memory Dave Nadler <drn@nadler.com> - 2016-11-11 16:53 -0800
Re: g++ on Cortex-M with no dynamic memory David Brown <david.brown@hesbynett.no> - 2016-11-12 14:21 +0100
Re: g++ on Cortex-M with no dynamic memory Jack <jack4747@gmail.com> - 2016-11-21 04:08 -0800
Re: g++ on Cortex-M with no dynamic memory upsidedown@downunder.com - 2016-11-07 23:01 +0200
Re: g++ on Cortex-M with no dynamic memory Don Y <blockedofcourse@foo.invalid> - 2016-11-07 14:14 -0700
Re: g++ on Cortex-M with no dynamic memory upsidedown@downunder.com - 2016-11-08 10:57 +0200
Re: g++ on Cortex-M with no dynamic memory Don Y <blockedofcourse@foo.invalid> - 2016-11-08 02:31 -0700
Re: g++ on Cortex-M with no dynamic memory upsidedown@downunder.com - 2016-11-08 13:52 +0200
Re: g++ on Cortex-M with no dynamic memory Dimiter_Popoff <dp@tgi-sci.com> - 2016-11-08 15:11 +0200
Re: g++ on Cortex-M with no dynamic memory Don Y <blockedofcourse@foo.invalid> - 2016-11-08 08:01 -0700
Re: g++ on Cortex-M with no dynamic memory Dimiter_Popoff <dp@tgi-sci.com> - 2016-11-09 08:26 +0200
Re: g++ on Cortex-M with no dynamic memory Don Y <blockedofcourse@foo.invalid> - 2016-11-09 00:55 -0700
Re: g++ on Cortex-M with no dynamic memory Dimiter_Popoff <dp@tgi-sci.com> - 2016-11-10 10:27 +0200
Re: g++ on Cortex-M with no dynamic memory Don Y <blockedofcourse@foo.invalid> - 2016-11-10 02:40 -0700
Re: g++ on Cortex-M with no dynamic memory Don Y <blockedofcourse@foo.invalid> - 2016-11-08 06:58 -0700
Re: g++ on Cortex-M with no dynamic memory Wouter van Ooijen <wouter@voti.nl> - 2016-11-07 23:01 +0100
Re: g++ on Cortex-M with no dynamic memory Dave Nadler <drn@nadler.com> - 2016-11-08 11:38 -0800
Re: g++ on Cortex-M with no dynamic memory Tim Wescott <tim@seemywebsite.com> - 2016-11-07 20:02 -0600
Re: g++ on Cortex-M with no dynamic memory upsidedown@downunder.com - 2016-11-07 22:56 +0200
Re: g++ on Cortex-M with no dynamic memory Don Y <blockedofcourse@foo.invalid> - 2016-11-07 14:11 -0700
Re: g++ on Cortex-M with no dynamic memory David Brown <david.brown@hesbynett.no> - 2016-11-08 10:37 +0100
Re: g++ on Cortex-M with no dynamic memory upsidedown@downunder.com - 2016-11-08 13:38 +0200
Re: g++ on Cortex-M with no dynamic memory David Brown <david.brown@hesbynett.no> - 2016-11-08 13:32 +0100
Re: g++ on Cortex-M with no dynamic memory Don Y <blockedofcourse@foo.invalid> - 2016-11-08 07:09 -0700
Re: g++ on Cortex-M with no dynamic memory Wouter van Ooijen <wouter@voti.nl> - 2016-11-07 08:10 +0100
csiph-web