Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #25471
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: g++ on Cortex-M with no dynamic memory |
| Date | 2016-11-10 10:27 +0200 |
| Organization | TGI |
| Message-ID | <o01b01$aqs$1@dont-email.me> (permalink) |
| References | (9 earlier) <rie32ctjgqqako7kj3mrpv1rrb5v4i6a6p@4ax.com> <nvsisc$ari$1@dont-email.me> <nvspc2$2ft$1@dont-email.me> <nvufh2$jvg$1@dont-email.me> <nvuknn$22q$1@dont-email.me> |
On 09.11.2016 г. 09:55, Don Y wrote: > On 11/8/2016 11:26 PM, Dimiter_Popoff wrote: >>>>> If rotating fans and rotating disk can't be used, the only alternative >>>>> is a Flash disk with limited number of write cycles. >>>> >>>> While generally so VM does not necessarily need to swap memory. >>>> If your physical memory is say 64M and your logical space is set to >>>> say 1G _and_ you know the 64M will never be all used up, the benefit >>>> of the VM is that fragmentation will be much less of a problem. >>> >>> It also lets you "write protect" memory, trap on writes to >>> memory that shouldn't be written, trap on writes to memory >>> that *should* be written, provide protected address spaces, >>> share memory with different processes (and in different places), >>> move large blocks of memory in constant time, etc. >> >> All of the protection etc., of course. When I write something new >> to run under dps many of the mistakes I make are captured by the >> "attempted access to non-allocated space, press CR to kill task" :-). > > Yes, handy at debug time but also handy for (VERY) long-lived > processes; "CAN'T HAPPEN" had really better NOT happen! Hi Don, in my experience long-lived tasks (months) just do not fail. It appears that if some piece of code survives a day or so chances are it is pretty stable and "bug free" (to the extent it will not fail at all). Which is not to say your scenario is not thinkable of course, just how things are with me. Where I do see failures is when doing new things, e.g. a user using some relatively new feature. Had this recently during a demo - user being me. Right click on a button crashed the task, got that "attempted access to non-allocated space" message. The buttons had been there for a few years... had never seen that. The cause turned out to be a non-initialized pointer of sorts; had lay dormant (pointing to some allocated piece to be read to no further consequences, what was read was irrelevant) until some other global system change or whatever woke it up. Good thing the entire demo was a shiny plug-and-play affair (with a HPGe detector people are used to anything but that) so I could just laugh the bug off. > > Most VMM operations happen without the developer's knowledge, > in my case. The OS takes care of keeping track of all the > magic so the developer sees a "clean" interface free of > hazzards, etc. Well if the developer has to allocate memory he has to say so, no way around that. I can't think of a cleaner and simpler way than have him say "give me that much" and in return "here you are, at this address, that much, rounded up a little". The developer (even if this is me) just does not think of physical memory at this level, just of logical. Then if you write at a higher level - e.g. write a dps shell script - allocate/deallocate is completely hidden. You "make" an object which requests memory from its "container" object, logs that so it will deallocate upon "remove" etc. It is a highly sophisticated/interconnected piece of underlying code really. > Its tricky to provide these hooks without EXPOSING them > (which would require a more sophisticated class of developer!) I just do not think of the limitations of the user. If I can learn to do something he/she also can (if not he is just messing with things he is not suppose to mess with. If something is too much for me to process in the time I want to spend on a given task it will be for someone else, too; so I just pack things into higher and higher level as needed, thus reducing the level of competence one needs to have involved in the task at hand. I.e. if I want to make some search utility I just write a dps script, I do not use my knowledge on allocate/deallocate, vpa language etc. Generally I think the assumption that a user is too stupid to be handed this or that so we have to stupefy the product is a bad approach, I have never seen anything useful come out of it (I don't think this is what you mean but it brought the association, it is one of my red buttons I suppose). Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
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