Kdo je konec tedna posredoval luknjasto kodo v Linuxovo jedro?

Ali ne bi moral biti "to" volatile? Drugače lahko compiler malo preveč optimizira (takrat verjetno ni).

Ali ne bi moral biti "to" volatile? Drugače lahko compiler malo preveč optimizira (takrat verjetno ni).

Seveda, ta koda je stara kot zemlja, ko so bili prevajalniki še zelo preprosti. In procesorji zelo počasni. Danes narediš s tako "ročno optimizirano" kodo več škode kot koristi.

Randomness je 14. maj 2020 ob 19:02 izjavil:

Koda je pravilna.

Veš mogoče, v katerih primerih in zakaj je pravilna?

Na linku piše vse. Celotno zgodovino.

Randomness je 14. maj 2020 ob 18:46 izjavil:

*to bi verjetno moral biti *to++.

Jup

Ni nujno.

Razloži

Periferija CPUja je velikokrat implementirana tako, da imaš en register/IO, ki ga polniš oz. spreminjaš. Zgornja implementacija bi ti dandanes lahko prav prišla na kakšnem ARM Cortex M0 procesorju, če bi hotel paralelno pošiljati podatke prek GPIO registra. Torej imaš en register, kjer se vrednost preslika na izhod. Ker je načeloma pri teh procesorjih clock GPIO periferije enak kot procesorski, ti med polnjenjem registra ni potrebno čakati in kolikor hitro si zmožen spremnijati register, tako hitro se bo spreminjal izhod. Pri navadni for zanki precej izgubiš na preverjanju pogojev in inkrementaciji, zato je lahko ta koda precej hitrejša.

Ampak pri boljših procesorjih je frekvenca jedra precej večja od periferne, zato takšno pisanje ni najboljše saj periferija ni dovolj hitra, da bi se spremembe izrazile na izhodu. Poleg tega imajo boljši procesorji DMA enoto, v kateri se takšne zadeve načeloma implementirajo. Torej drugi periferiji (DMA) poveš, naj ti kopira "count" podatkov iz "from" v "to" in ko konča procesor pade v irq.

Če programiraš nek mikrokrmilnik, ki stane pod $1, ti bi lahko prišla takšna koda prav za kar koli dražjega pa je takšno čaranje neefektivno.

drysmoke je 14. maj 2020 ob 15:52 izjavil:

Spura je 14. maj 2020 ob 15:40 izjavil:

Kaj to pocne in ali je nevarno je povsem nerelevantno. Ko vidim tak zmazek v PR stisnem reject in to je konec. Jst ne rabim pogruntat vseh trikov kako skrit neke hacke, ce v osnovni rejectam vsako kodo, ki ni povsem preprosta in razumljiva.

U ja, take imamo najraje, egoisticno fiksirane birokrate, ki so prepricani, da so najbolj pametni, ce je pa koda njim razumljiva, bo pa vse uredu. Ampak, kaj, ce je koda tebi razumljiva, ampak je ne razumes pravilno?

To kar je Spura napisal je dejansko edina prava odlocitev. Taksnen zmazek kode mora biti resno dokumentiran in precej dobro utemeljen zakaj je tam in kak je benefit taksnega zmazka. Koda mora biti vedno taksna, da jo lahko razumes pri povrsnem branju, ravno zaradi razvoja.

Ampak ja, saj vemo, eni ste super humans in take zmazke razumete tud, ce jih iz aviona gledate. Uredu je.

Sicer se ne bi prerekal z bolj izkušenimi, se mi pa zdi, da "umazano" kodo precej uporabljajo za app, ki delujejo v ozadju, razne interpreterje, driverje in kakor je že en rekel, za kernel. Da se lahk pol prepucavamo kdo je hitrejši.
Sam da pa napišeš "prosinec" namesto januar je pa res preveč.