Arduino a alokace mista pro promenne

[Jaroslav Buchta]

Takhle to samozrejme funguje dobre, ale u AVR je myslim problem v tom, 
ze z FLASH se ctou data uplne jinymi instrukcemi nez z RAM. Takze to 
nutne vede k jinemu kodu funkci.
U ARM a Intel atp., jsou take ruzne pameti pristupne treba jen jako 
datove,  instrukcni, nebo oboje, RO nebo RW , ale leze se tam stejnymi 
instrukcemi, takze to staci rozhodit do sekci a hotovo. Program je 
stejny jen nekde neco proste nejde.
Byva to i slozitejsi, ze je pamet mapovana na vic adres s ruznymi 
metodami pristupu, ale zase je to celkem resitelne linker scriptem, v 
programu se nic nemeni.

Obecne to chce obcas kouknout do map souboru po prekladu, jestli se tam 
nedeje neco co clovek nechce, treba to kopirovani konstantnich retezcu 
do RAM...

Dne 24.10.2019 v 18:56 Miroslav Mraz napsal(a):
> Ono to není jen o lineárním nebo nějak rozsekaném adresním prostoru. 
> Někdy je to jen lenost programátora, který moc nepřemýšlí nad tím jak 
> ten kód píše a co s tím pak překladač může dělat. Mě osobně docela 
> dost poučil přístup jazyka rust - vše je implicitně konstantní, pokud 
> do toho chceme někdy později zapsat, musíme to explicitně vyjádřit už 
> v deklaraci. V C/C++ je to naprosto opačně. Jenže pro konstantní 
> objekty umí obvykle překladač dělat dost efektivní optimalizace. A je 
> opravdu dost málo objektů (proměnných) se kterými je potřeba později 
> nějak hýbat i když se to zpočátku nezdá.
> Pokud z lenosti napíšeme např.
> char * s = "string";
> pak gcc vyhradí pro ten "string" jednak místo ve flash (protože někde 
> musí být pevně uložen), pak ho zkopíruje do sekce .data, kde pro něj 
> také musí být místo. Sice gcc při tomhle obvykle nadává, ale moc na to 
> nespoléhejte. O něco lepší je napsat
> const char * s = "string";
> tady už je "string" uložen v sekci .rodata, ale v sekci .data se 
> vytvoří ukazatel s, to není konstantní objekt, můžete klidně udělat 
> const char c = s++. A když napíšete
> const char * const s = "string";
> pak už sice můžete z řetězce číst jen pomocí indexu, ale ten může být 
> lokální, tedy v registrech, takže do sekce .data se neukládá nic.
> Překladač gcc takhle funguje na všech platformách, takže pokud je 
> sekce .rodata nadefinována tak, že se ukládá do flash (což je možné a 
> velmi časté), pak to takto funguje i na AVR. To je ale otázka linker 
> skriptu, ale protože se s AVR už dost dlouho nezabývám, může to tam 
> být uděláno jinak.
> Nicméně používat modifikátor const všude tam, kde je to jen trochu 
> možné je celkem dobrá praktika, kterou ale využijete spíš v C++, 
> protože tam se deklarovat a inicializovat proměnná dá vlastně kdekoli. 
> V dnešním C už by to mělo jít ale bez problémů také.
>
> Mrazík
>
> Dne 24. 10. 19 v 14:42 Jan Waclawek napsal(a):
>> To je skor prejav toho, ze C (a tym aj C++) nie je pripraveny na koncept
>> roznych pamatovych priestorov. Existuje uz asi 15 rokov navrh rozsireni,
>> tzv. named address spaces, ale nejako sa neujal. Pre AVR je zhodou
>> okolnosti tiez uz asi 10 rokov implementovany
>> https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html , ale aj
>> "vdaka" arduinu sa zakonzervovalo prave skor pouzitie toho 
>> nestandardneho
>> atributu __progmem.
>>
>> Ono to ma este vselijake relativne zlozite suvislosti najma pre vacsie
>> AVRka (nad 64kB FLASH) a aj s kompromisom medzi efektivnym (co sa tyka
>> velkosti binaru aj rychlosti vykonavania a ciastocne aj spotreby RAM) a
>> "unifikovanym" (t.j. kde netreba rozmyslat) kodom.
>>
>> K tomu textu z manualu avr-libc este doporucujem ako doplnkove citanie
>> tento tutorial (v podstate len prvy post z celeho vlakna)
>> https://www.avrfreaks.net/forum/tut-c-gcc-and-progmem-attribute?name=PNphpBB2&file=viewtopic&t=38003 
>>
>>
>>
>> wek
>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list