Subj : Re: where can I find a malloc for standalone programs ? To : comp.programming From : Ed Prochak Date : Mon Aug 22 2005 02:55 pm DEMAINE Benoit-Pierre wrote: > > Do you have any functions in the boot ROM for memory allocation? > > there is nothing but the code I write. Are you writting the boot ROM too? or is it just that there are no ROM routines available to you? > > > 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. But on a single processor you had problems with endianness? > > > 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 ... How about a simple custom kernal? Even at this point you might find some benefit. Otherwise, write your main loop as a simple task switcher, where the "tasks" are functions called or not called based on some global state variables. > > > 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. So writting the malloc() routine should be easy. You need a corresponding free() function also. And BTW, those don't have to be the function names, since these will be custom, you can use whatever names you like. You know the needs of your main application so you can customize the memory allocation. for example, if your application never needs a chunk of memory smaller than, say 32bytes, then you might consider always allocating space in chunks of 32bytes. (so malloc(33) would actually provide you with 64 bytes). This avoids external fragmentation in exchange for internal fragmentation. There's lots of algorithms for this. Check some OS textbooks if you don't like the examples suggested so far. They can help you with the trade-offs between them. > > > 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 that's exactly WHY you have to check, and deal with the error appropriately, including in the worst case forcing a reboot. Hopefully you have other options such as * setting global status so the task currently using memory can finish and free some up. * throwing data away until memory becomes available. * preallocating memory at startup > > 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_/ This last item (error recovery) brings up a final option. Given a limited fixed amount of memory, don't use malloc() at all. assign fixed amounts to various global data structures and be done with it. This isn't always possible but if you study you application carefully, you might be lucky and can structure it this way. (I know, you said you needed malloc, but look again. maybe just an array of structures, or similar fixed data structure, would work.) HTH, Ed .