Re: Counting Elements?

Re: Counting Elements?

[Robert A Duff]

Freejack <freejack@nowhere.net> writes:

> I've been fiddling with Storage Pools. I can get the Allocate procedure to
> allocate from an mmap() region quite easily. I can access it, play with
> it, and do all the naughty stuff you're not supposed to be doing with Ada.

;-)

Ada doesn't _prevent_ low-level stuff.  It just allows you to isolate it
so the "naughty" stuff doesn't pollute the higher-level stuff.
Ada is actually a better language than C for programming close
to the metal (IMHO).

> However I'm a little confused about a couple
> things. Storage_Count depends on Storage_Offset, which depends on
> Storage_Element, which depends on Storage_Unit(On GNAT Linux 32bit,
> Storage_Unit is 8).
> So, if I understand it correctly a 32bit Integer would be measured this
> way ...
> 
> type Integer32 is array (Storage_Offset range 1..4) of
> aliased Storage_Element;

Yes.  The size passed to Allocate is in "storage elements",
which most people, on most machines, call "bytes".
Except in the embedded world, storage elements are usually 8 bits
in size.  Storage_Unit is just the size (in bits) of a Storage_Element;
that is:

    Storage_Element'Size = Storage_Unit

Ada measures most sizes in bits.  The size passed to Allocate is an
exception.

Note that the compiler automatically calculates this size.
So if you say "new Integer" it will pass 4 to Allocate,
which should allocate 4 storage elements, and return the address.

> I gotta make sure I understand this correctly so I can pass the right
> Sizes to my Region allocators before calling mmap().
> 
> Also, while I can call munmap() directly from anywhere, my overidden
> Deallocate procedure doesn't seem to be using it.(At least from what I see
> using strace and my debugger. Rather than dumping the memory back to the
> system at the end of a block(declare, subprogram, etc...)like I assumed
> it's suppose to, it looks like it just keeps reusing the same memory over
> and over again. I assumed that Deallocate is called whenever the access
> type to the pool goes out of scope. Is this true? Or do I have to pass the
> access pointer to a Finalize procedure? My goal is to basically dump the
> entire allocated area immediately back to the Host System as soon as the
> access goes out of scope.

I think you're confused.  Allocate is called for each "new".  Deallocate
is called for each call to an instance of Unchecked_Deallocation.

I think what you want is something like this:

    Initialize of your pool type should call mmap.

    Finalize of your pool type should call munmap.

    Allocate should allocate small pieces out of the mmap'ed area.

    Deallocate should free those small pieces, allowing them
    to be reused by future allocates.

Finalize, not Deallocate, is called when one of your pool objects goes
out of scope.  (Storage pools are derived from Limited_Controlled,
so they have the normal Initialize/Finalize features of all
controlled types.)

Maybe I'm confused about what you're trying to accomplish.
If so, you should post some example code that uses your
storage pool, and explain what you want it to do.

To debug, I suggest putting print-out statements in those four routines,
rather than messing around with strace or the debugger.

> Except for all that, everything else is working smoothly.
> 
> Currently I'm working on a downward growing Parameter stack Region(for
> starters). Think Forth style stacks. Anyone have a use for something like
> that?

I think you should post a package spec with comments explaining what it
does in more detail.

- Bob