Prev: Why a file system required in an embedded Device
Next: PHY initialization
From: D Yuniskis on 25 Feb 2010 00:00
Hi Dimiter,

Didi wrote:
> On Feb 24, 10:21 pm, D Yuniskis <not.going.to...(a)seen.com> wrote:
>
>> Any "static" allocation algorithm has to make assumptions
>> about how memory will be used.
>
> I was referring to dynamic allocate, whether paged or not,

Yes, sorry, I think we are cross-communicating.
By "static" I meant the algorithm used *in* malloc.
I.e., if it DOESN'T CHANGE (which was the goal of
my "selector" function), then the way that it allocates
remains constant (static) throughout its use.

I.e., it will always use the same heuristics to allocate
a block of size N (which is the only parameter that it
can receive from the "application")

> DPS uses static allocate on boot time for pieces which will
> never be released (there is a setup.syst file, one can
> install device drivers using it so they get stuck together
> on a .l basis rather than being cluster aligned etc.).

But, you can only do a static allocation (using C's concept
of static vs. dynamic) if you know the sizes of those items.
If they can vary in size, then you rely on malloc (sbrk, etc.)
to set aside the memory that they require.

> Then DPS also has an area of "BAT translated" memory, one
> needs it in MMU systems to place IRQ handlers in it so an
> IRQ does not cause a page fault (so the DSI exception
> can run without masking IRQ). Now this is also statically
> allocated, default or via setup.syst.

This is "wired down" memory (not pageable)

> But all that static allocate - which DPS does by simply
> adding to the heap before calling it a boot and allocating
> the entire so far taken heap in the CAT (Cluster Allocation Table).
>
>> ... OTOH, the programmer
>> *knows* (or, *should* know) how he *will* be using memory.
>> I am advocating letting the user bias malloc's allocation
>> strategy based on his (the programmer's) knowledge of
>> how he will be using that memory.
>
> I now get some of your point. Of course this is so. I did not get
> what exactly you were after because I don't use C (I regard it
> as being "write only" and generally a waste of my time) and
> so when programming I have access to all of the allocate
> facilities (I use VPA, Virtual Processor Assembly, which
> I based on 68k assembly and took forward, meanwhile quite
> a distance forward; I have yet to encounter someone matching my
> efficiency using some other language :-) ).

Some of us have to write things that others will maintain :>

>> In one of the applications I am working on currently,
>> crt0 builds the "system heap". My "init" task then
>> allocates blocks of memory for use by the RTOS. These
>> contain static data structures, etc. Some are small,
>> some are large. THEY WILL NEVER BE FREED.
>>
>> Interspersed among these allocations, there are often
>> numerous other allocations (which *will* be freed,
>> typically).
>>
>> A naive malloc will treat all of these the same -- since
>> the only information that it has at its disposal is the
>> *size* of the request
>
> Well if the language would allow to pass malloc not just
> the requested size but also some more info it could choose
> which system facility to use - if I get what you are after.

Yes. The classic malloc(3) has a very narrowly defined
interface. Of course, how it works "behind the scenes"
is up for grabs -- so long as it implements the functionality
advertised.

I am suggesting a different malloc (call it something else)
and features that would be helpful in such a malloc with
particular emphasis on how it could be applied to
providing some degree of determinism that a "classic"
malloc implementation can't (note my initial comments
regarding how quasi-deterministic implementations of
malloc are inefficient in their handling of memory *and*
that c.a.e type applications tend to be concerned with
needless waste in that area)

> E.g. give me that much memory but guarantee it will be
> contiguous - one needs this for buffers used by say DMA;
> or allocate that much memory at this fixed address - one may
> need this and well, may be denied it :-); etc. etc.

Yes. One could change the selector to accept a va_list
and, for some of the selectors, that list could include
arguments like "make the allocated region adjoin the
region containing *this* address, etc."

> But I am not sure I get exactly what you are after since
> I have long since decided I will not let HLL restrictions
> stand in my way, life is too short :-).
From: Didi on 25 Feb 2010 04:10
Hi Don,

> On Feb 25, 7:00 am, D Yuniskis <not.going.to...(a)seen.com> wrote:
> > Then DPS also has an area of "BAT translated" memory, one
> > needs it in MMU systems to place IRQ handlers in it so an
> > IRQ does not cause a page fault (so the DSI exception
> > can run without masking IRQ). Now this is also statically
> > allocated, default or via setup.syst.
>
> This is "wired down" memory (not pageable)

Aha, thanks for the name (I did not know it).

Not having many more ideas to contribute I guess the following
triggered some more or less related output from me:

> ...
> I am suggesting a different malloc (call it something else)

In DPS, it is called allocm (LOL). Actually it is allocm$,
but the $ is just to make the call name difficult to duplicate.

It is - just looked it up - the very first DPS call I have written
all these years ago :-). You pass in D2 the amount of memory
you want, you get in A1 the address of the piece you got
and in D1 the actual size (which will obviously be cluster
aligned).

Oh well, I guess I mentioned what flavours of it I have
done over the years, not sure if they relate to a C function
(I guess they do if one implements a compiler for DPS which
I have not done yet).
Another related detail is the way memory gets deallocated.
The allocm$ leaves it to the application to deallocate upon
exit or forced kill; it can choose to leave the piece allocated
(say, having installed some device driver or object descriptor).
Then I also have the allmr$ - allocate registered - which will be
deallocated by the system upon task kill.
And then I remember chasing a bug at the dawn of DPS which was
occasionally crashing me - I was deallocating the task's system
stack a little too early upon kill - and the system being without
a MMU (a proud 68340 with 1M RAM...)tolerated that as long as
no other task got that too early deallocated - and still in
use - piece of memory.... :-).

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/a191901ec63cfdb9?dmode=source
From: D Yuniskis on 25 Feb 2010 14:59
Hi Dimiter,

Didi wrote:

[attributions elided]

>> I am suggesting a different malloc (call it something else)
>
> In DPS, it is called allocm (LOL). Actually it is allocm$,
> but the $ is just to make the call name difficult to duplicate.

Like prepending "_" in C, etc.

> Another related detail is the way memory gets deallocated.
> The allocm$ leaves it to the application to deallocate upon
> exit or forced kill; it can choose to leave the piece allocated
> (say, having installed some device driver or object descriptor).
> Then I also have the allmr$ - allocate registered - which will be
> deallocated by the system upon task kill.

I've taken very different approaches over the years (and,
varying based on project needs/resources, etc.)

Currently, I am leaving much to the application -- e.g.,
I don't protect heaps with dedicated mutexes (since that
makes the call more non-deterministic and often isn't needed
as the application *knows* how/when it is using the dynamic
store). But, I *do* "clean up" after a task terminates
as it is relatively easy to do (if the task has been given
its own private heap -- I *don't* track per task requests
made on the system heap!).

> And then I remember chasing a bug at the dawn of DPS which was
> occasionally crashing me - I was deallocating the task's system
> stack a little too early upon kill - and the system being without
> a MMU (a proud 68340 with 1M RAM...)tolerated that as long as
> no other task got that too early deallocated - and still in
> use - piece of memory.... :-).

This was a common bug in early uses of realloc()...
First  |  Prev  | 
Pages: 1 2 3
Prev: Why a file system required in an embedded Device
Next: PHY initialization