GNAT and Memory Maps?

GNAT and Memory Maps?

[Freejack]

I've been picking through the GNAT docs (and Ada docs in general) in an
attempt to figure out how/if and when/why the Ada compiler might choose to
use an mmap system call in deference to a malloc/calloc or alloca call.

Basically, I'm doing some low level routines and I need explicit control
over what pages are swapped and when. ( mmap() mlock() munlock() and
munmap() are the usual C functions for handling this.)

I'm using Linux at the moment, and I could just as easily use the native C
library (glibc). However, I want to handle this entirely in Ada. I'm using
the No_Run_Time Pragma.

Note: I'm also a Forther, so the idea of explicit memory and device
handling doesnt frighten me. ;->

(Hmmm...now theres an experiment to try sometime. A Subroutine Threaded
Forth VM in Ada.)

Any references would be appreciated.

Freejack

Re: GNAT and Memory Maps?

[Freejack]

Oh, I forgot to mention, I'm familiar with the FLORIST Posix bindings.
But I'm looking for a way around them.

Freejack

Re: GNAT and Memory Maps?

[Ludovic Brenta]

Freejack <Freejack@nomail.com> writes:

> I've been picking through the GNAT docs (and Ada docs in general) in an
> attempt to figure out how/if and when/why the Ada compiler might choose to
> use an mmap system call in deference to a malloc/calloc or alloca call.
> 
> Basically, I'm doing some low level routines and I need explicit control
> over what pages are swapped and when. ( mmap() mlock() munlock() and
> munmap() are the usual C functions for handling this.)
> 
> I'm using Linux at the moment, and I could just as easily use the native C
> library (glibc). However, I want to handle this entirely in Ada. I'm using
> the No_Run_Time Pragma.
> 
> Note: I'm also a Forther, so the idea of explicit memory and device
> handling doesnt frighten me. ;->
> 
> (Hmmm...now theres an experiment to try sometime. A Subroutine Threaded
> Forth VM in Ada.)


My first idea is to use your own storage pool; see ARM 13.11 for
information on storage pools. However, I'm not sure this approach
works with pagma No_Run_Time.

By the way, I came across a post by Robert Dewar where he said
No_Run_Time is obsolete.  Here is the URL:

http://gcc.gnu.org/ml/gcc/2002-11/msg00321.html

What is your situation?  Are you writing a Linux kernel module in Ada?
(that's the only reason I can think of to use No_Run_Time) In this
case, I'm not sure you can use glibc either.

-- 
Ludovic Brenta.

Re: GNAT and Memory Maps?

[Simon Wright]

Freejack <Freejack@nomail.com> writes:

> I've been picking through the GNAT docs (and Ada docs in general) in
> an attempt to figure out how/if and when/why the Ada compiler might
> choose to use an mmap system call in deference to a malloc/calloc or
> alloca call.

I would be very surprised if GNAT ever chose to use mmap -- how would
it know which file to map?

> Basically, I'm doing some low level routines and I need explicit
> control over what pages are swapped and when. ( mmap() mlock()
> munlock() and munmap() are the usual C functions for handling this.)

These functions are (C bindings to) system calls; so at some point
there is going to be a software interrupt (int-something on Intel). I
don't see what advantage you'll get by rewriting the C bindings?

> I'm using Linux at the moment, and I could just as easily use the
> native C library (glibc). However, I want to handle this entirely in
> Ada. I'm using the No_Run_Time Pragma.

I suspect you can still link against the C libraries with No_Run_Time.


Someone suggested use of a storage pool, but (a) I doubt that's
compatible with No_Run_Time, (b) storage pools are about supporting
multiple allocations, if you want to "mmap these 16#40000# bytes which
I will treat as a data structure like _that_" storage pools seem
irrelevant.

Re: GNAT and Memory Maps?

[Florian Weimer]

Freejack <Freejack@nomail.com> writes:

> I've been picking through the GNAT docs (and Ada docs in general) in an
> attempt to figure out how/if and when/why the Ada compiler might choose to
> use an mmap system call in deference to a malloc/calloc or alloca call.

At least the publicly available GNAT versions completely rely on the
system's C run-time library for memory management.  They do not go
below the malloc()/free() level.

Re: GNAT and Memory Maps?

[Freejack]

On Sat, 05 Jul 2003 09:10:36 -0400, Ludovic Brenta wrote:
 
> My first idea is to use your own storage pool; see ARM 13.11 for
> information on storage pools. However, I'm not sure this approach works
> with pagma No_Run_Time.
> 
> By the way, I came across a post by Robert Dewar where he said
> No_Run_Time is obsolete.  Here is the URL:
> 
> http://gcc.gnu.org/ml/gcc/2002-11/msg00321.html
> 
> What is your situation?  Are you writing a Linux kernel module in Ada?
> (that's the only reason I can think of to use No_Run_Time) In this case,
> I'm not sure you can use glibc either.

My initial development platform is a customized Debian Linux x86
installation. I'm using it for developing a prototype application.(Which
will eventually be released as OSS, but I'm keeping it under wraps for
the moment.)

Basically, were a team of three people. We have an experimental logic
board with four Ignite Processors (Patriot Scientific Corps.) wired in
parallel. The Ignite Processors werent designed to be used in this way(at
least that's how our hardware junky explained it to me.) But we found
that it was very workable.
The other two are CS/CE students. I'll be going back into a CE program
once the bills are paid up. This is a summertime project. At least for
now.

The initial software is designed to run in an essentially embedded
environment, with very little Operating System support. Perhaps an
exokernel at the most.
However, the intent is to keep the software-logic portable, so that it
can be run on a regular server (i.e. QNX or a Unix most likely) platform.
The only modifications necessary would be between the high level functions
and the platform specific interfaces. 

We considered using Forth for this(and indeed Forth will play an
important role.) However maintaining Forth, for this kind of app, across
multiple platforms would not be trivial to say the least.

I have experience with Ada in high level applications(database
programming, some trivial web hacks) but I'm doing some research and
getting up to speed with very low level work.

Essentially this is going to be a network proxy, which couples
high level network metadata (Web, FTP, SSH, and ect..) with low level
"network" metadata(all the way down to the Frame Layer) which is able to
route data(not just encapsulated "packets") according to the most
efficient route for it's type.
There are routers which do some of these things already. Hence the idea is
not to replace the routers, but rather to work in conjunction with
routers to perform much more efficient and reliable network filtering,
analysis, and secure communications.  

One of the goals is to enable the proxie(s) to open secure tunnels to
each other, creating a virtual X400 network. Which, if implemented 
wisely, can guarantee the message will traverse the Internet in 90
minutes or less.

Now, I suppose I could port the GNAT runtime. But I'm not at that stage
yet.
All in all, working with Ada is cake. A little tedious to write at times,
but a hell of a lot simpler to use. And I havent had any trouble 
with it fudging up at a critical moment.
And, as you can see, this is large project. Hence, one of my reasons for
using Ada.

"Where the hell did you guys get this idea?"
Well, our hardware junky traced a circuit board and wondered what kinds 
of things she could use it for. So we came up with this idea at the
suggestion of our network guru. Where do I fit in? I read TAOCP, which
"inspired" me to read a lot of math books(Heh.) 

Enough rambling.

That's the lowdown. I've remained purposely vague, because we know what
we want right now, but we havent decided where this project is going.
Like I said, it's a summertime hack. I suppose kinda like modding the
Xbox. Might end up in our collection of computer junk, but for now it's a
lot of fun. I decided to indulge my anal retentiveness and try to build
a system that wont crash(or at least will be very difficult to crack or
crash.) Either way, were learning a boatload of stuff.

Thanks.


Freejack

Re: GNAT and Memory Maps?

[Hyman Rosen]

Simon Wright wrote:
> I would be very surprised if GNAT ever chose to use mmap -- how would
> it know which file to map?

The traditional choice is /dev/zero, which provides an infinitely long
stream of zero bytes. The idea behind using mmap() rather than sbrk() to
acquire memory is that you can mmap multiple regions, and when you release
such a region, memory is returned to the operating system rather than
remaining allocated to the program.

Re: GNAT and Memory Maps?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]


"Freejack" <Freejack@nomail.com> a �crit dans le message news:
pan.2003.07.05.03.42.01.638542.1720@nomail.com...
> I've been picking through the GNAT docs (and Ada docs in general) in an
> attempt to figure out how/if and when/why the Ada compiler might choose to
> use an mmap system call in deference to a malloc/calloc or alloca call.
>
> Basically, I'm doing some low level routines and I need explicit control
> over what pages are swapped and when. ( mmap() mlock() munlock() and
> munmap() are the usual C functions for handling this.)
>
A common advice for this kind of issues is:
   Don't cheat.

If your need is to call mmap() (or whatever), just call it. Don't try to
second guess
some Ada statements that happen to do what you need today (but maybe not
tomorrow).

Ada statements are there to protect you from the underlying implementation.
If your need is to use a particular implementation (which I don't criticize,
there may be
plenty of good reasons for it), just do it openly.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: GNAT and Memory Maps?

[John Kern]

Ludovic Brenta wrote:

> By the way, I came across a post by Robert Dewar where he said
> No_Run_Time is obsolete.  Here is the URL:
>
> http://gcc.gnu.org/ml/gcc/2002-11/msg00321.html
>
>

That is sad because I felt that having No_Run_Time would be a good way to get
reliable Ada or SPARK to run in critical automotive applications co-residing
with other applications on an "accepted" kernel, like OSEK or something.

Re: GNAT and Memory Maps?

[Freejack]

On Mon, 07 Jul 2003 21:40:58 -0400, John Kern wrote:

> Ludovic Brenta wrote:
> 
>> By the way, I came across a post by Robert Dewar where he said
>> No_Run_Time is obsolete.  Here is the URL:
>>
>> http://gcc.gnu.org/ml/gcc/2002-11/msg00321.html
>>
>>
>>
> That is sad because I felt that having No_Run_Time would be a good way
> to get reliable Ada or SPARK to run in critical automotive applications
> co-residing with other applications on an "accepted" kernel, like OSEK
> or something.
 
There is OpenRavenscar (ORK) kernel which MIGHT be of use here.

Perhaps an Ada exokernel would be appropriate. I know Bluebottle
OS(Oberon) runs on an exokernel. Considering the similarities, this might
be a useful approach.

Freejack

Re: GNAT and Memory Maps?

[Rod Chapman]

> > By the way, I came across a post by Robert Dewar where he said
> > No_Run_Time is obsolete.  Here is the URL:

The _name_ is obsolete, but the technology certainly isn't!  It's now
called "GNAT Pro High Integrity Edition" and is fully supported by
ACT.  We have worked closely with ACT to ensure that this runtime
profile is fully compatible with SPARK.  No surprise really - SPARK
was designed from day one to require little or no runtime library.

 - Rod Chapman, SPARK Team

Re: GNAT and Memory Maps?

[Simon Wright]

Hyman Rosen <hyrosen@mail.com> writes:

> Simon Wright wrote:
> > I would be very surprised if GNAT ever chose to use mmap -- how would
> > it know which file to map?
> 
> The traditional choice is /dev/zero, which provides an infinitely
> long stream of zero bytes.

Oh, using MAP_PRIVATE? I live and learn!