RE: [ECOS] Inside eCos : the new operator

RE: [ECOS] Inside eCos : the new operator

[Fabrice Gautier]

> -----Original Message-----
> From: Bart Veer [ mailto:bartv@redhat.com ]
> Subject: Re: [ECOS] Inside eCos : the new operator
> 
> The invocation of the new() operator involves C++ 
> placement syntax,
> which is just part of the standard language.
> 
> If the code looks something like:
> 
>     Object* ptr = new Object(arg1, arg2);
> 
> then this invokes the default new operator, which will perform dynamic
> memory allocation - I suspect it would end up calling malloc(), but
> have not checked this.

In this case, I suspect this will fail if the libc is not compiled as a part
of eCos. In another message you mentionned the fact that eCos was not
written with dynamic allocation in mind so I wonder how it handle a
"dynamic" new operator. Does/Can it uses memory pools? 

> [...]
> I am not sure what gcc patch you are referring to.

The one I had to apply when building the gnu toolchain for eCos (as refered
in the eCos installation documentation)

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

RE: [ECOS] Inside eCos : the new operator

[Robin Farine]

On Mon, 21 Aug 2000, Fabrice Gautier wrote:

> > -----Original Message-----
> > From: Bart Veer [ mailto:bartv@redhat.com ]
> > Subject: Re: [ECOS] Inside eCos : the new operator
> > 
> > The invocation of the new() operator involves C++ 
> > placement syntax,
> > which is just part of the standard language.
> > 
> > If the code looks something like:
> > 
> >     Object* ptr = new Object(arg1, arg2);
> > 
> > then this invokes the default new operator, which will perform dynamic
> > memory allocation - I suspect it would end up calling malloc(), but
> > have not checked this.
> 
> In this case, I suspect this will fail if the libc is not compiled as a part
> of eCos. In another message you mentionned the fact that eCos was not
> written with dynamic allocation in mind so I wonder how it handle a
> "dynamic" new operator. Does/Can it uses memory pools? 
> 
> > [...]
> > I am not sure what gcc patch you are referring to.
> 
> The one I had to apply when building the gnu toolchain for eCos (as refered
> in the eCos installation documentation)
> 
> Thanks
> 
> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 
> 

Fabrice,

The gcc distribution provides default implementations (libgcc) for the
different flavors of the "new" and "delete" operators. They rely on
malloc/free to obtain/release system memory regions.

However, in C++ you can overload any operator or function so you could do
something like this to avoid using the default implementation:

  define a header file, "my_new.h" for instance, that redefines the
  standard flavors of the new and delete operators:

  /* ------------------------------------------------------------------- */

     inline void* operator new (size_t size)
     {
       return my_allocate(size);
     }

     inline void* operator new[] (size_t size)
     {
       return ::operator new(size);
     }

     inline void* operator new (size_t, void* addr)
     {
       return addr;
     }

     inline void* operator new[] (size_t, void* addr)
     {
       return addr;
     }

     inline void operator delete (void* p)
     {
       my_deallocate(p);
     }

     inline void operator delete[] (void* p)
     {
        ::operator delete(p);
     }


  /* ------------------------------------------------------------------- */

  where "my_allocate()" and "my_deallocate()" handle the real job.

Then, include "my_new.h" instead of the standard "new.h" or "new" header
files. Alternatively, you could define custom "new" and "new.h" header
files in a directory that CPP includes from before its private headers
(specified using the -I CPP option).

Note also that you can define other version of those operators with
additional arguments, possibly dummy, such as:

     inline void* operator new (size_t size, MemPartition* mp)
     {
       return mp_allocate(mp, size);
     }

and use it like this:

     Class_A* a = new(an_mp) Class_A(args);

where an_mp has type MemPartition*.

Or you can define class member versions that handle
allocation/deallocation of instances of that or derived classes, but this
becomes a bit more complex ... See

  Working Paper for Draft Proposed International Standard for Information
  Systems Programming Language C++

for a complete reference.


Hope this helps,

Robin

Re: [ECOS] Inside eCos : the new operator

[Bart Veer]

>>>>> "Fabrice" == Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

    >> -----Original Message-----
    >> From: Bart Veer [ mailto:bartv@redhat.com ]
    >> Subject: Re: [ECOS] Inside eCos : the new operator
    >> 
    >> The invocation of the new() operator involves C++ 
    >> placement syntax,
    >> which is just part of the standard language.
    >> 
    >> If the code looks something like:
    >> 
    >> Object* ptr = new Object(arg1, arg2);
    >> 
    >> then this invokes the default new operator, which will perform dynamic
    >> memory allocation - I suspect it would end up calling malloc(), but
    >> have not checked this.

    Fabrice> In this case, I suspect this will fail if the libc is not
    Fabrice> compiled as a part of eCos. In another message you
    Fabrice> mentionned the fact that eCos was not written with
    Fabrice> dynamic allocation in mind so I wonder how it handle a
    Fabrice> "dynamic" new operator. Does/Can it uses memory pools?

Internally the kernel does not use this default invocation of the new
operator, so it never gets linked in and there is never any need for
malloc().

If application code starts to use the default new operator then you
would have to ensure that a suitable one is available. This could mean
writing your own, or providing your own malloc(), or enabling the C
library package.

Bart Veer // eCos net maintainer

Re: [ECOS] Inside eCos : the new operator

[Bart Veer]

>>>>> "Fabrice" == Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

    Fabrice> While trying to find answers to some of my questions I came accross this
    Fabrice> code:
    Fabrice> (in kernel/current/src/common/kapi.cxx. line ~370)

    Fabrice>     Cyg_Interrupt *t = new((void *)intr) Cyg_Interrupt (
    Fabrice>         (cyg_vector)vector,
    Fabrice>         (cyg_priority)priority,
    Fabrice>         (CYG_ADDRWORD)data,
    Fabrice>         (cyg_ISR *)isr,
    Fabrice>         (cyg_DSR *)dsr );
    Fabrice>     t=t;
    Fabrice>    CYG_CHECK_DATA_PTR( handle, "Bad handle pointer" );
    Fabrice>     *handle = (cyg_handle_t)intr;

    Fabrice> The "t=t;" line is the most surprising to me but the
    Fabrice> syntax of the new operator seems very interresting too.

    Fabrice> I'm wondering what is the behaviour of the new operator
    Fabrice> in a C++ eCos program? Can it do dynamic allocation? What
    Fabrice> will happen in the above 'new' call if intr is a Null
    Fabrice> pointer? Does the gcc patch required to compile it
    Fabrice> explain all that? Are the 't' variable and the "t=t;'
    Fabrice> line just a way to bluff the compiler?

The invocation of the new() operator involves C++ placement syntax,
which is just part of the standard language.

If the code looks something like:

    Object* ptr = new Object(arg1, arg2);

then this invokes the default new operator, which will perform dynamic
memory allocation - I suspect it would end up calling malloc(), but
have not checked this.

However it is possible to define alternative new operators which take
one or more arguments. In this case I believe that the intr argument
provides a suitable region of memory for the C++ object, and the
specific new() operator being used will just re-use this memory rather
than allocate a new chunk from the heap. For more details of placement
new, see e.g. Stroustrup 3rd edition and check the index (there is no
point in providing page numbers here, that book has gone through many
revisions already).

Passing a NULL pointer to new() would be a bad idea: you would be
explicitly telling the compiler that the interrupt object should be
placed at location 0, and it would probably do just that with
resulting nasty consequences.

The "t=t" line just stops the compiler from warning that the variable
t has been set but not used. The compiler will optimize this away. It
should be possible to write the code as:

    (void) new((void*) intr) Cyg_Interrupt ( ... );

and do away with the t variable completely, but that code is even more
likely to confuse people.

I am not sure what gcc patch you are referring to.

Bart Veer // eCos net maintainer

[ECOS] Inside eCos : the new operator

[Fabrice Gautier]

Hi,

While trying to find answers to some of my questions I came accross this
code:
(in kernel/current/src/common/kapi.cxx. line ~370)

    Cyg_Interrupt *t = new((void *)intr) Cyg_Interrupt (
        (cyg_vector)vector,
        (cyg_priority)priority,
        (CYG_ADDRWORD)data,
        (cyg_ISR *)isr,
        (cyg_DSR *)dsr );
    t=t;
   CYG_CHECK_DATA_PTR( handle, "Bad handle pointer" );
    *handle = (cyg_handle_t)intr;

The "t=t;" line is the most surprising to me but the syntax of the new
operator seems very interresting too.

I'm wondering what is the behaviour of the new operator in a C++ eCos
program?
Can it do dynamic allocation?
What will happen in the above 'new' call if intr is a Null pointer?
Does the gcc patch required to compile it explain all that?
Are the 't' variable and the "t=t;' line just a way to bluff the compiler?


Thanks

A+
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com