Subj : Re: where can I find a malloc for standalone programs ?
To   : comp.programming
From : DEMAINE Benoit-Pierre
Date : Sat Aug 20 2005 02:10 am

> Do you have any functions in the boot ROM for memory allocation?

there is nothing but the code I write.

> For
> your environment, that's where the foundation of malloc should be. you
> can write some simple algorithms in assembler to handle this, given
> that you have one application. I don't quite see your concern about
> endianness (do you have two processors of different endianess?) or
> alignment (memory allocation should always match the most restricted
> alignment for all datatypes).

I have one task to do, on a single processor, but I sware I
encontour/endorse  all possible problems you could imagine
on a programmable device.

> I'm curious though why you have NO operating system.

thats a fact, and it does not depend on me.

> I've done enough
> embedded programming to say that the overhead of a kernel is much lower
> than the warts produced in the main program logic to deal with the
> equivalent of task switching.

I know it looks silly, but after 6 months negociations,
I could not obtain rigth to use a standard kernel.
Now my reports mention all those problems which are making
the project later and later ...

> For memory allocation, it can be
> customized to a great extent. (e.g., you allocate either for string
> data or certain structures which are fixed size, then designing a
> memory pool that allocates strings from the top and structs from the
> bottom might be better than a generic malloc(). Yes that means possibly
> another parameter to your version of malloc() to indicate which one.

no, the manifacturer told me that for example, I can do what ever i want
 within /let say/:
0x1000-0x2000 for ROM storage (which will be practically FLASH memory), and
0x3000-0x4000 for RAM use, where I can spread ay stuff I need.

so, if I need 16bytes for very personal stuff, I can afford
to the malloc system: 0x3010-0x3fff

those are known adresss to me.

> One critical tip:
> ALWAYS check the return value from malloc() and deal with the case that
> it could NOT get the memory you requested. In testing, if nothing else,
> you should be able to dump memory in that event and debug by checking
> malloc's data structures.

thanks, I am aware of that, but yor tip is not gonna help much when you
have neither screen, nor network, nor even serial port to report error.

but thas offtopic :p

-- 
DEMAINE Benoit-Pierre (aka DoubleHP ) http://www.demaine.info/
\_o< If computing were an exact science, IT engineers would not have work >o_/

.