[En-Nut-Discussion] Suggestion for C++ initialisation change.

[Phil Maker]

G'day,

The problem:

	malloc/new inside C++ constructors always return 0 since they
	are not initialised. e.g.

	class V {
	  float *p;
	public:
	  V(int n) {
	    p = malloc(sizeof(float)*n);
	  }
        };

	V x(10);

The answer, I think (whence this message):   

	Modify avr_nutinit.c so we initialise the Heap before 
	calling the constructors. I've done this by breaking 
	the NutInit function into NutInitHeap and NutInit and putting
	them in separate init sections, i.e.


void NutInitHeap(void) __attribute__ ((naked)) __attribute__ ((section(".init5")));
void NutInit(void) __attribute__ ((naked)) __attribute__ ((section(".init8")));

void NutInit(void)
{
    /*
     * We can't use local variables in naked functions.
     */
#ifdef NUTDEBUG
    outp(7, UBRR);
    outp(BV(RXEN) | BV(TXEN), UCR);
#endif

    /* Create idle thread
     */
    NutThreadCreate("idle", NutIdle, 0, NUT_THREAD_IDLESTACK);
}

void NutInitHeap(void)
{

    /* If we have external RAM, initialize stack pointer to
     *  end of external RAM to avoid overwriting .data and .bss section
     */
    SP = (u_short)(NUTMEM_END);

    /* Then add the remaining RAM to heap.
     *
     * 20.Aug.2004 haraldkipp: This had been messed up somehow. It's nice to have 
     * one continuous heap area, but we lost the ability to have systems with
     * a gap between internal and external RAM.
     */
    if ((u_short)NUTMEM_END - (u_short) (&__heap_start) > 384) {
        NutHeapAdd(&__heap_start, (u_short) NUTMEM_END - 256 - (u_short) (&__heap_start));
    }
}

	The alternative would be to move the whole initialisation process
into a lower number init segment. 

	Any comments/thoughts from the gentle audience.