On Tue, 06 Oct 2015 17:35:36 +0200 Philipp Klaus Krause <p...@spth.de> wrote:
> We are planning to replace SDCC'c current two memory allocators by a new > one. In one of the curent two (used in mcs51, ds390, hc08) malloc() and > friends code is in a critical section, in the other, it is not. > > We have not yet decided which way the new allocator should go here. > > Advantages of critical section inside malloc(): malloc() can be called > from interrupt handlers, multiple threads from OSses without any support > on the OS side. > Advantages of malloc() not having critical sections: Lower interupt > latency, since malloc() can then be interrupted. > > When malloc() does not have critical sections, it is still possible to > get the advantages and disadvatages by wrapping all calls to malloc() in > critical sections (like e.g. the pvPortMalloc from FreeRTOS does). I would personally favour that the default behaviour is that it isn't interrupt safe. If it is interrupt safe and I need very tight IRQ latencies I can't fix it, whereas if I need IRQ protection and the library is not IRQ safe I can fix it In my perfect world I would do sdcc -DTHREADSAFE_MALLOC or similar and the header files would magically make malloc either a direct call or defined to a wrapper in the C lib. The other question is how correct the critical handling on the platforms is - did the Z80 port get the critical handling fixed so it works reliably on all processors ? Alan ------------------------------------------------------------------------------ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user