Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #25471

Re: g++ on Cortex-M with no dynamic memory

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>

Show all headers | View raw


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


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