<div><font>Χαιρετώ ξανά και as i promise: <a href="http://hg.chania-lug.gr/hoo2">http://hg.chania-lug.gr/hoo2</a><br></font></div><div><font><br></font></div><div><font>Βέβαια είναι ακόμα υπό ανάπτυξη, αλλά τουλάχιστον δουλεύει για Cortex-M3/4 που το δοκίμασα μέχρι στιγμής όχι όμως για M4F.  Αυτό θέλει διαφορετικό context_switching για τους FP registers + ένα πονοκέφαλο το lazy stacking και δεν το έχω κάνει ακόμα.<br>
</font></div><div><font><br></font></div><div><font>Τώρα μερικά συμπεράσματα που άργησαν λιγάκι γιατί έλειπα και που δεν ξέρω αν είναι αυτονόητα για κάποιους:</font><font><br></font></div><div><font>Οι δοκιμές έγιναν με την libc (base) και με την newlib (aka nano libc <a href="http://sourceware.org/newlib/">http://sourceware.org/newlib/</a>)<br>
</font></div><div><font>Επίσης σε καμία περίπτωση, τουλάχιστον με το CooCox που δουλεύω προς το παρόν δεν χρειάστηκε να "πω" στον Linker να πάρει τις δικές μου συναρτήσεις αντί αυτών μέσα στη libc.<br></font></div>
<div><font><br></font></div><div><font>Base: (size -O0 ~ 25K)<br></font></div><div><font>1) Αν δεν παρέχουμε κάποια συνάρτηση από τις malloc/free κτλ τότε ο compiler γκρινιάζει [cc] sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'<br>
</font></div><div><font>2) Αν του τη δώσεις αλλά δεν κάνεις τίποτε άλλο τότε οι κλήσεις πάνε ως εξής:<br></font></div><div><font>   malloc() -> _malloc_r() -> _sbrk_r() -> _sbrk()<br></font></div><div><font>  Δηλαδή με ένα απλό tailoring της _sbrk() καθάρησες.</font><font><br>
</font></div><div><font>3) Αν του δώσεις και τις malloc/free πέρα από την _sbrk() τότε οι κλήσεις πάνε<br></font></div><div><font>   malloc()-> your way<br></font></div><div><font>αλλά οι _malloc_r() -> _sbrk_r() -> _sbrk() παραμένει.<br>
</font></div><div><font><br></font></div><div><font>Γενικά απλά κάνοντας μια υλοποίηση τις _sbrk() να παίρνει και να δίνει heap είσαι ΟΚ. (Βέβαια εγώ δεν έκανα αυτό)<br></font></div><div><font><br></font></div><div><font>NewLib: (size -O0 ~ 6K --> καμία σχέση)<br>
</font></div><div>
<font>1) Αν δεν παρέχουμε κάποια συνάρτηση από τις malloc/free κτλ τότε ο compiler γκρινιάζει [cc] sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'</font><font><br></font></div><div>
<div><font>2) Αν του τη δώσεις αλλά δεν κάνεις τίποτε άλλο τότε οι κλήσεις πάνε ως εξής (ομοίως με base libc):<br></font></div><div><font>   malloc() -> _malloc_r() -> _sbrk_r() -> _sbrk()<br></font></div><div><font>  Δηλαδή και εδώ με ένα απλό tailoring της _sbrk() καθάρησες.</font></div>


<div><font>3) Αν του δώσεις και τις malloc/free πέρα από την _sbrk() τότε οι κλήσεις πάνε<br></font></div><div><font>   malloc()-> your way<br></font></div><div><font>αλλά οι _malloc_r() -> _sbrk_r() -> _sbrk() παραμένει.<br>
<br></font></div><div><font>Τώρα για την _malloc_r() αυτή είναι μια "και καλά" reentrant έκδοση της malloc και όχι απλά thread safe. αλλά χρησιμοποιεί ένα struct "τόσο" με το συμπάθιο, το struct reent.<br>
<br>Αυτά προς το παρόν.<br><br>Φιλικά</font></div><div><font>Χρήστος<br></font></div>
<font><br></font></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font>
</font></blockquote></div><font><font></font><br></font>