"new" word

"new" word

[fabio de francesco]

Ciao,

While reading "the big online book of Linux Ada programming", by Ken O.
Burtch, I stopped at the following assertion
(http://www.pegasoft.ca/resources/boblap/13.html):

"Usually you allocate memory with the Ada new statement. Where does new
get its memory? It uses the standard C library's malloc function."

Does really Ada use Libc to implement "new"? Is it true?

It seems absurd to me. I don't understand why Ada should depend on a C
standard library. 

Regards,

fabio de francesco

Re: "new" word

[Vinzent 'Gadget' Hoefler]

fabio de francesco wrote:

> While reading "the big online book of Linux Ada programming", by Ken
                                        ^^^^^^^^^^^^^^^^^^^^^

> "Usually you allocate memory with the Ada new statement. Where does
> new get its memory? It uses the standard C library's malloc function."
> 
> Does really Ada use Libc to implement "new"? Is it true?

On Linux it is probably the sanest thing to do. The library is available
and used by virtually every single program (so it is tested, and thus
the bug rate can assumed to be quite low), so why should one write an
Ada specific memory allocator that - in the end - would do exactly the
same thing as the already available and widely used one does?

> It seems absurd to me. I don't understand why Ada should depend on a C
> standard library.

It is not Ada (as in language) depending on it, it is a specific
implementation of Ada (as in runtime) that depends on it.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: "new" word

[Adrian Knoth]

Vinzent 'Gadget' Hoefler <nntp-2005-03@t-domaingrabbing.de> wrote:

[new via malloc of libc]
> so why should one write an Ada specific memory allocator that

To get rid of libc, C and all this? ;) A native kernel interface
would be nice to eliminate possible implementation errors in libc.

On the other hand as far as I can see there is no binary representation
of the linux-kernel, in other words, you'll need to dynamically
adapt the Ada memory layout to the corresponding kernel (+compiler).

Another way would be to specify the Kernel-ABI, but I don't expect
this to happen earlier than Hurd ;)

AdaOS would probably come along with a well-defined ABI and no
libc, but libada.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Mit leerem Kopf nickt es sich leichter.

Re: "new" word

[Vinzent 'Gadget' Hoefler]

Adrian Knoth wrote:

> Vinzent 'Gadget' Hoefler <nntp-2005-03@t-domaingrabbing.de> wrote:
> 
> [new via malloc of libc]
>> so why should one write an Ada specific memory allocator that
> 
> To get rid of libc, C and all this? ;)

Yeah, right. Good idea. Have you already started? When do you expect to
be close to ready? Next century already? ;-)

Maybe it's even much easier to write a completely new lib"c" in Ada.

> On the other hand as far as I can see there is no binary
> representation of the linux-kernel, in other words, you'll need to
> dynamically adapt the Ada memory layout to the corresponding kernel
> (+compiler).

That's already hard enough with (binary) kernel _modules_, which usually
use only a small subset of the kernel's functionality.

> Another way would be to specify the Kernel-ABI, but I don't expect
> this to happen earlier than Hurd ;)

Wow! So it's "Real Soon Now"? I can't wait! ;-)

> AdaOS would probably come along with a well-defined ABI and no
> libc, but libada.

Well, in that case the book would have been called "the big online book
of AdaOS Ada programming", probably shortened to "AdaOS kernel
reference manual". ;-)


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: "new" word

[Thomas Lotze]

Adrian Knoth wrote:

> Another way would be to specify the Kernel-ABI, but I don't expect this to
> happen earlier than Hurd ;)

I think it's a conscious choice not to specify the Linux ABI. Something
about binary-only drivers being discouraged...

-- 
Thomas

Re: "new" word

[fabio de francesco]

Thomas Lotze wrote:
> Adrian Knoth wrote:
>
> > Another way would be to specify the Kernel-ABI, but I don't expect
this to
> > happen earlier than Hurd ;)
>
> I think it's a conscious choice not to specify the Linux ABI.
Something
> about binary-only drivers being discouraged...
>
> --
> Thomas

This is not true. Device drivers can be dinamically loaded as binaries,
provided they conforms to some kind od Linux Kernel-ABI for kernel
loadable modules and they must use some exported kernel functions (like
init_module() and cleanup_module()).

fabio de francesco

Re: "new" word

[Vinzent 'Gadget' Hoefler]

fabio de francesco wrote:

> Thomas Lotze wrote:
>
> I think it's a conscious choice not to specify the Linux ABI.
> Something about binary-only drivers being discouraged...
>
> This is not true.

<beatles>Yes it is.</beatles>

> Device drivers can be dinamically loaded as
> binaries, provided they conforms to some kind od Linux Kernel-ABI

Which does not exist.

> for
> kernel loadable modules and they must use some exported kernel
> functions (like init_module() and cleanup_module()).

And their internally used data structures must match the kernel ones.
And because /this/ is version dependent there is a problem.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: "new" word

[fabio de francesco]

Vinzent 'Gadget' Hoefler wrote:

> And their internally used data structures must match the kernel ones.
> And because /this/ is version dependent there is a problem.

If you mean these conventions changes from kernel version to kernel
versions, I must agree with you. Yet they change only with major kernel
releases, as they changed after 4 years passing from 2.4.x to 2.6.x (as
far as it concerns production releases).

fabio de francesco

> 
> Vinzent.
>

Re: "new" word

[Vinzent 'Gadget' Hoefler]

fabio de francesco wrote:

> Vinzent 'Gadget' Hoefler wrote:
> 
>> And their internally used data structures must match the kernel ones.
>> And because /this/ is version dependent there is a problem.
> 
> If you mean these conventions changes from kernel version to kernel
> versions, I must agree with you.

Unfortunately this includes minor version changes, too.
See <URI:http://lwn.net/Articles/115591/> for a deeper insight.

They even do it on purpose, not for a reason. ;->


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: "new" word

[fabio de francesco]

Adrian Knoth wrote:
> Vinzent 'Gadget' Hoefler <nntp-2005-03@t-domaingrabbing.de> wrote:
>
> [new via malloc of libc]
> > so why should one write an Ada specific memory allocator that
>
> To get rid of libc, C and all this? ;) A native kernel interface
> would be nice to eliminate possible implementation errors in libc.
>
> On the other hand as far as I can see there is no binary
representation
> of the linux-kernel, in other words, you'll need to dynamically
> adapt the Ada memory layout to the corresponding kernel (+compiler).

No, it isn't required. You don't need a Kernel-ABI in order to access
system calls in kernel space, as I wrote in another post in this
thread. There is a standardised way to access syscalls through
interrupt H80.

Imagine you write a new syscall in Linux kernel and you want to use it
before it is binded into the LibC, you can do it with some simple
Assembly inline C/C++/Ada and whatever else programming language.

Same way you can access sys_sbrk() that is the standard syscall that
provide memory in user space.

fabio de francesco


>
> Another way would be to specify the Kernel-ABI, but I don't expect
> this to happen earlier than Hurd ;)
>
> AdaOS would probably come along with a well-defined ABI and no
> libc, but libada.
>
>
> --
> mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver
> 
> Mit leerem Kopf nickt es sich leichter.

Re: "new" word

[Lutz Donnerhacke]

* fabio de francesco wrote:
>> On the other hand as far as I can see there is no binary representation
>> of the linux-kernel, in other words, you'll need to dynamically adapt
>> the Ada memory layout to the corresponding kernel (+compiler).
>
> No, it isn't required. You don't need a Kernel-ABI in order to access
> system calls in kernel space, as I wrote in another post in this
> thread. There is a standardised way to access syscalls through
> interrupt H80.

This is useless for structured parameters. For those you need the exact
memory layout.

> Imagine you write a new syscall in Linux kernel and you want to use it
> before it is binded into the LibC, you can do it with some simple
> Assembly inline C/C++/Ada and whatever else programming language.

Please do so for setsockopt(2).

Re: "new" word

[Larry Kilgallen]

In article <slrnd3g58c.r83.adi@ppc201.mipool.uni-jena.de>, Adrian Knoth <adi@thur.de> writes:
> Vinzent 'Gadget' Hoefler <nntp-2005-03@t-domaingrabbing.de> wrote:
> 
> [new via malloc of libc]
>> so why should one write an Ada specific memory allocator that
> 
> To get rid of libc, C and all this? ;) A native kernel interface
> would be nice to eliminate possible implementation errors in libc.
> 
> On the other hand as far as I can see there is no binary representation
> of the linux-kernel, in other words, you'll need to dynamically
> adapt the Ada memory layout to the corresponding kernel (+compiler).
> 
> Another way would be to specify the Kernel-ABI, but I don't expect
> this to happen earlier than Hurd ;)
> 
> AdaOS would probably come along with a well-defined ABI and no

Meanwhile, other operating systems already have that.

Re: "new" word

[Florian Weimer]

* Adrian Knoth:

> Another way would be to specify the Kernel-ABI, but I don't expect
> this to happen earlier than Hurd ;)

The kernel ABI is fairly stable.  There are only a few dozen syscalls,
and it's easy to write Ada wrappers for them.

It doesn't buy you that much because large parts of the GNAT run-time
on GNU systems rely on services provided by the C run-time library.
Tasking and I/O are examples.  Duplicating this infrastructure is the
hard work, and doing it right even for older kernels is quite a
challenge.

Re: "new" word

[Lutz Donnerhacke]

* Florian Weimer wrote:
> * Adrian Knoth:
>> Another way would be to specify the Kernel-ABI, but I don't expect
>> this to happen earlier than Hurd ;)
>
> The kernel ABI is fairly stable.  There are only a few dozen syscalls,
> and it's easy to write Ada wrappers for them.

IBTD.
The parameters of the syscalls are usually C-header-file defined structures.
The memory layout of those structures are hard to determine.
BTDT.

> It doesn't buy you that much because large parts of the GNAT run-time
> on GNU systems rely on services provided by the C run-time library.

It uses a C-written wrapper for those bindings.
So GNAT does not know the ABI but obtain it from the C compiler.

> Duplicating this infrastructure is the hard work, and doing it right even
> for older kernels is quite a challenge.

Of course, but the job is hard, because there is no defined way to derive
the correct interface portable. The reason why is simple: There is no
portable interface beside C-header files.

Re: "new" word

[Robert A Duff]

Adrian Knoth <adi@thur.de> writes:

> AdaOS would probably come along with a well-defined ABI and no
> libc, but libada.

So AdaOS is not intended to support programs written in C?

;-)

- Bob

Re: "new" word

[Adrien Plisson]

fabio de francesco wrote:
> Ciao,
> 
> While reading "the big online book of Linux Ada programming", by Ken O.
> Burtch, I stopped at the following assertion
> (http://www.pegasoft.ca/resources/boblap/13.html):
> 
> "Usually you allocate memory with the Ada new statement. Where does new
> get its memory? It uses the standard C library's malloc function."

it does not seem entirely true...

if i understand the ARM correctly (ARM95 - 13.11 Storage Management), 
the new statement gets its memory from a storage pool. if you don't 
define your own storage pool for an access type, the implementation 
will provide a default standard storage pool.

so it should be the standard storage pool which uses the standard C 
library's malloc function.

> Does really Ada use Libc to implement "new"? Is it true?
> 
> It seems absurd to me. I don't understand why Ada should depend on a C
> standard library. 

not totally absurd. Linux has been developped in C, so system 
interfaces are provided in C. be it the standard C library or the 
system programming interface, your Ada runtime would have used C anyway.

also note that it is this particular implementation of Ada which does 
that. the ARM does NOT define anything in term of the C standard 
library, so each implementation uses what fit best.

-- 
rien

Re: "new" word

[Larry Kilgallen]

In article <1110966980.482176.111570@f14g2000cwb.googlegroups.com>, "fabio de francesco" <fmdf@tiscali.it> writes:
> Ciao,
> 
> While reading "the big online book of Linux Ada programming", by Ken O.
> Burtch, I stopped at the following assertion
> (http://www.pegasoft.ca/resources/boblap/13.html):
> 
> "Usually you allocate memory with the Ada new statement. Where does new
> get its memory? It uses the standard C library's malloc function."
> 
> Does really Ada use Libc to implement "new"? Is it true?

Of course not.  Ada is a language standard, and allocates memory out of
thin air.  That memory has no physical reality and costs nothing. It is
unlimited in size.

Some particular Ada _implementation_ however, has to deal with physical
memory.  It is possible that some implementation might be layered on top
of the C memory allocation facilities.

> It seems absurd to me. I don't understand why Ada should depend on a C
> standard library. 

Some operating systems are very C-centric in their operating system calls,
and without direct experience I would say that Linux is likely one of them.
I have seen "portable" C programs which spend half of their lines of code
rolling their own version of facilities that are built into other operating
systems.

Re: "new" word

[fabio de francesco]

Larry Kilgallen wrote:
> In article <1110966980.482176.111570@f14g2000cwb.googlegroups.com>,
"fabio de francesco" <fmdf@tiscali.it> writes:
> > Ciao,
> >
> > While reading "the big online book of Linux Ada programming", by
Ken O.
> > Burtch, I stopped at the following assertion
> > (http://www.pegasoft.ca/resources/boblap/13.html):
> >
> > "Usually you allocate memory with the Ada new statement. Where does
new
> > get its memory? It uses the standard C library's malloc function."
> >
> > Does really Ada use Libc to implement "new"? Is it true?
>
> Of course not.  Ada is a language standard, and allocates memory out
of
> thin air.  That memory has no physical reality and costs nothing. It
is
> unlimited in size.

Your sarcasm is totally inopportune. Maybe you don't even know the
difference between what is provided by the OS and what comes from the
Standard C Library.

Standard C Library provides memory to C user programs through asking
pages to the kernel, that is malloc -> brk -> (assembly code) int h80
-> sys_brk(C code in kernel).

So what forbids to whichever Ada implementation to directly ask memory
to the kernel the same way LibC does?

> Some particular Ada _implementation_ however, has to deal with
physical
> memory.  It is possible that some implementation might be layered on
top
> of the C memory allocation facilities.
>
> > It seems absurd to me. I don't understand why Ada should depend on
a C
> > standard library.
>
> Some operating systems are very C-centric in their operating system
calls,
> and without direct experience I would say that Linux is likely one of
them.
> I have seen "portable" C programs which spend half of their lines of
code
> rolling their own version of facilities that are built into other
operating
> systems.

What has it got to do with the question? While kernel is written with
C, if you want to use a syscall from user space you have to issue a
software interrupt in a standardised way (see syscalln() macros) to
access kernel space. So what would prevent an Ada implementation to
call sys_brk using the very same technique? In theory Ada
implementation doesn't need LibC, it only need to access kernel.

Ciao,

fabio de francesco

Re: "new" word

[Vinzent 'Gadget' Hoefler]

fabio de francesco wrote:

> access kernel space. So what would prevent an Ada implementation to
> call sys_brk using the very same technique?

Nothing.

> In theory Ada
> implementation doesn't need LibC, it only need to access kernel.

Absolutely correct. If you look at only one implementation.

So an easier way to look at it might be considering the libc just as an
additional - and already available - portability layer.


Vinzent.

-- 
worst case: The wrong assumption there actually is one.

Re: "new" word

[Robert A Duff]

"fabio de francesco" <fmdf@tiscali.it> writes:

> Ciao,
> 
> While reading "the big online book of Linux Ada programming", by Ken O.
> Burtch, I stopped at the following assertion
> (http://www.pegasoft.ca/resources/boblap/13.html):
> 
> "Usually you allocate memory with the Ada new statement. Where does new
> get its memory? It uses the standard C library's malloc function."

Taken as a statement about Ada, it is of course false.
The Ada standard does not specify where the memory comes from.

However, if you're implementing Ada on an operating system,
you're going to call that operating system, and if it's written
in C, you're calling C.  You normally want to call well-documented
interfaces, which are *not* necessarily direct calls into the "kernel"
(i.e. trapping into protected-mode code).  And you'd like to
call portable interfaces (which libc is).

The above statement could also be misleading if you think it implies
that each invokation of "new" calls "malloc", one for one.
For efficiency, an Ada implementation is likely to have it's own
allocator internally, and only call malloc (or something)
once in a while.

And, as somebody else mentioned, you can write your own allocators in
Ada, and cause (some or all) "new"s to be hooked into them.

Probably what the author of the above meant to say was,
"It's similar to the C library's malloc function."

But "new" does a lot more than allocate memory -- it initializes it,
which can involve calling all kinds of user-written code.

> Does really Ada use Libc to implement "new"? Is it true?
> 
> It seems absurd to me. I don't understand why Ada should depend on a C
> standard library. 

Ada (the language) does *not* depend on the C standard library;
you are correct that that would be absurd.  Ada is implemented
on many systems that contain zero code written in C.

But I don't see why an *implementation* of Ada should not do so,
on systems where it's available.

- Bob

Re: "new" word

[Wes Groleau]

Robert A Duff wrote:
> For efficiency, an Ada implementation is likely to have it's own
> allocator internally, and only call malloc (or something)
> once in a while.

This assumes (1) that the Ada vendor's allocation code is efficient,
and/or (2) that the platform's malloc is not.

Verdix tried that in the 1980s--and the results were dismal.
Their fix for serious heap fragmentation problems was to tell
us the linker commands/pragmas to make 'new' bypass their
code and go directly to malloc.

-- 
Wes Groleau
-----------

    "Thinking I'm dumb gives people something to
     feel smug about.  Why should I disillusion them?"
                             -- Charles Wallace
                             (in _A_Wrinkle_In_Time_)

Re: "new" word

[Larry Kilgallen]

In article <39v2kqF636c21U1@individual.net>, Wes Groleau <groleau+news@freeshell.org> writes:
> Robert A Duff wrote:
>> For efficiency, an Ada implementation is likely to have it's own
>> allocator internally, and only call malloc (or something)
>> once in a while.
> 
> This assumes (1) that the Ada vendor's allocation code is efficient,
> and/or (2) that the platform's malloc is not.

I don't know malloc, but on VMS the underlying allocation interfaces
provide a rich variety of semantics that are just what Ada would need
(in my opinion) for implementing storage pools, etc.  I find it hard
to believe the same versatility would be available from a common C
runtime library routine, but I am biased.

Re: "new" word

[Martin Krischik]

Larry Kilgallen wrote:

> In article <39v2kqF636c21U1@individual.net>, Wes Groleau
> <groleau+news@freeshell.org> writes:
>> Robert A Duff wrote:
>>> For efficiency, an Ada implementation is likely to have it's own
>>> allocator internally, and only call malloc (or something)
>>> once in a while.
>> 
>> This assumes (1) that the Ada vendor's allocation code is efficient,
>> and/or (2) that the platform's malloc is not.
> 
> I don't know malloc, but on VMS the underlying allocation interfaces
> provide a rich variety of semantics that are just what Ada would need
> (in my opinion) for implementing storage pools, etc. 

Same for Windows or OS/2.

> I find it hard 
> to believe the same versatility would be available from a common C
> runtime library routine, but I am biased.

However, there was a discussion about the Unix and Linux services for memory
allocation - at that was very primitive indeed. No comparison to the
sophisticated memory services of the DOS world. And for Linux/Unix I can
see that using malloc is the better option. Besides: it makes Interfaces.C
much easier.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: "new" word

[Randy Brukardt]

"fabio de francesco" <fmdf@tiscali.it> wrote in message
news:1110966980.482176.111570@f14g2000cwb.googlegroups.com...
> Ciao,
>
> While reading "the big online book of Linux Ada programming", by Ken O.
> Burtch, I stopped at the following assertion
> (http://www.pegasoft.ca/resources/boblap/13.html):
>
> "Usually you allocate memory with the Ada new statement. Where does new
> get its memory? It uses the standard C library's malloc function."
>
> Does really Ada use Libc to implement "new"? Is it true?

"Ada" doesn't do anything. "Ada implementations" do whatever makes sense on
their target system.

On Windows, for instance, Janus/Ada uses the Windows heap manager to
allocate memory. (Presumably, malloc uses the same manager, but I don't know
that for sure.) We could write our own heap manager, but what would be the
point? The OS is already providing the services.

It does make sense on some targets to use malloc, because most
implementations want to be as compatible as possible with C (so interfacing
to C works well). But in any case it's up to the implementer. They can do
whatever makes the most sense for their target.

                  Randy.

Re: "new" word

[Wes Groleau]

fabio de francesco wrote:
> "Usually you allocate memory with the Ada new statement. Where does new
> get its memory? It uses the standard C library's malloc function."
> 
> Does really Ada use Libc to implement "new"? Is it true?

Is the book writing about Ada, or about GNAT?  It is not completely
true about "Ada" -- each compiler vendor has their own method.
HOWEVER, if the compilar and run-time runs on an operating system,
memory allocation _has_ to eventually get back to that operating
system's allocation mechanism, no matter how many levels of indirection
are in between.

-- 
Wes Groleau
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^  A UNIX signature isn't a return address, it's the ASCII equivalent ^
^  of a black velvet clown painting.  It's a rectangle of carets      ^
^  surrounding a quote from a literary giant of weeniedom like        ^
^  Heinlein or Dr. Who.                                               ^
^                                -- Chris Maeda                       ^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^