( apal | 2020. 11. 10., k – 11:41 )

Amikor időre (pontos időzítéssel) készítesz egy hardvert kezelő program részletet, ott szó sem lehet az optimalizálásról, különösen a sorrend változtatásról. Bonyolultabb esetben lehet dönteni az egyes műveletek átlapolásáról, de csak az adatlap(ok) alapján, amit ugye nem olvasott a fordító. ;)

En mondjuk ennyire nem latom borusan ezt a kerdest ;) Legalabbis a tapasztalat is es az elvart mukodes is hogy pl periferia-illesztesnel a volatile-kent dekralt valtozok eleresenek sorrendjet tartani kell a forditonak - felteve persze ha a nyelvi elemekbe ez nem utkozik. Pl ha egy funct(a,b) hivas eseten az a is meg b is volatile read, akkor nem ismert a sorrend, de ha azt mondod hogy whatever_t x,y; x=a; y=b; funct(x,y); akkor az a-t elobb kell kiolvasnia az mmio-regiszterbol mint a b-t. Es a fordito azert megoldja hogy ezutobbi annyira hatekony legyen mint az ezelobbi - csak a jo sorrend garantalt. 

De persze, vannak szelsoseges peldak, peldaul ami nagyon tetszik az a low speed usb bitbang implementacio 12MHz-s AVR-en, ahol 8 orajeled van ugye letudni egy bitet, minden nyalanksaggal (pl stuffing). Na, ott azt valoban nem erdemes C-ben irni es egyebkent is eleg jol ismerni kell az architekturat ;) Lasd pl: https://github.com/harbaum/I2C-Tiny-USB/blob/master/firmware/usbtiny/in…, mint szep pelda.