Assembly helye 2017-ben
2017-06-09T23:46:21+02:00
2017-06-11T11:48:46+02:00
2022-07-21T12:56:42+02:00
  • Precíz időzítés igényt utoljára 8 bites architektúrán láttam, még az USB hajnalán, aholis az USB low speed (1,5 Mbps) protokollját szoftverből csinálták. Ma már USB-re számos mikrovezérlőben ott a hardver, ráadásul minimum a 12 Mbps-es verzióra.

    A 3..4 usec-nél nem szigorúbb időzítés esetén pedig ott van a kiolvasható illetve interrupt generálásra alkalmas hardver timer.

    Ma átgondolva nem igazán találok olyan feladatot, ahol inkább assembly-hez nyúlnék, mintsem a megfelelő célhardverrel rendelkező mikrovezérlőt C-ben programozzam.
    Mutasd a teljes hozzászólást!
  • Mi a manó!
    Mutasd a teljes hozzászólást!
  • Akkor is jó optimalizálni, ha cache-ra gyúrsz, a "következő" adat elérés ilyenkor (gyki) 0 órajel.
    Az adatstruktúrát megváltoztatva (sorrend, packed, bitek, ect.) is lehet pár %-ot kicsikarni.

    Általában méret függő a dolog, néha egy jól megválasztott algoritmus C implementációja pont elég tud lenni.
    Mutasd a teljes hozzászólást!
  • 8 bites mikrovezérlőknél, ahol nagyon precíz feladatokat kell megcsinálni, és számítanak a us időtartományok, ott szerintem még mindig az asm a nyerő. Illetve ami miatt én nem szeretem a magasabb szintű nyelveket, hogy mindegyikkel van valami nyűg, ami miatt reszelni kell az egész kócerájt, és rámegy mindig x óra arra, hogy alapvető dolgok működjenek (pl. IDE frissítés után eltérő include fájlok miatt már nem fordul le a program.. stb. millió ilyennel találkoztam).
    Vagy pl. ha valami teljesen egyedi kommunikációs protokollt kell megvalósítani nagy sebességen (pl. 1-wire).
    (Ja meg ha PC-n törni kell programot... )
    A nagyobb architektúráknál viszont már túl összetettek a perifériák, a memória kezelése, asm-ben nagyon elnyúlik a kód.
    ... de véleményem szerint az asm-nek van létjogosultsága.
    Mutasd a teljes hozzászólást!
  • Elektronikai környezetben minden órajel számíthat ott, ahol szinkron futási időt kell kicentizni. Ott nincsen helye C-nek.

    Ahol cikluson belül kicentizve tud elég lenni adott processzor regiszter tömbje nevetségeset gyorsítani, azt sem bíznám még C-re.
    Mutasd a teljes hozzászólást!
  • Újabban a fordítók is jó kódot tudnak csinálni, ha akarnak polinomiális idő alatt lehet optimális kódot gyártani egy feltalált algoritmussal vagy mi a szösz.
    Mutasd a teljes hozzászólást!
  • Kb. utoljara en csinaltam egy wildcard felismerot.
    Az egyetlen fajta wildcard, az a numerikus digit volt, a tobbi dolognak stimmelnie kellett. 1..48char hosszu mintákra kellett mennie.

    A feldolgozas 1,2,3 x 16byte-onkent ment, sse-vel.
    - eloszor a szamokat at kellett alakitani 0-kra, majd johetett egy pcmpeq, majd vegul pmovmsk ki lehetett szedni az egyezo biteket, arra jott egy string hosszusaganak megfelelo mask es megszuletett az eredmeny.

    Ez egy cnc program dekoder része volt és nagy megelegedesemre brutalgyors lett a teljes dekodolasi feladat :D

    ----------------------
    Aztan fel eve szinten asmoztam, de annak nem volt tul sok ertelme (10-20% max).
    Ott egyeneseken elhelyezkedo szakasz-sorozatokon vegzett AND muveletet akartam csinalni. De ott annyi volt az IF, hogy az kivette az SSE erejét.

    ----------------------
    A funkcionalis programozas miatt en amugy bizakodo vagyok. Ott az egesz folyamatot a fordito elvileg belegyurja egy hatalmas functba. Pont ez nalam is az elso lepes hagyomanyosan, aztan az extra meg a SIMD megfejelve az ember altal megtervezett adatelhelyezessel meg shuffling-al.

    Szoval a nagy optimizalt konyvtarak hasznalataval ilyen a folyamat:

    bitmap.load
    blur(bitmap)
    shift(bitmap)
    trhreshold(bitmap)

    Ekkor ha a bitmap nagyobb, mint valamelyik cache, akkor az gyakorlatilag olyan, mintha nem is lenne az a cache.

    Ezzel szemben:

    bitmap.load
    bitmap.blur.shift.threshold

    Itt egy pipeline-t adunk meg, ahol csak 1 ciklus van, nem annyi ciklus, ahany muvelet, emiatt maximalisan lokalis a memora hasznalat es igy L1 cache speeddel tud menni.
    Ha vegul erre jon egy ertelmes C->SSE konverzio, az lenne a hab a tortan :D
    Mutasd a teljes hozzászólást!
  • Régen nyúltam assemblyhez, de két dolog azért eszembe jut:

    1) Oprendszerek nagyon alacsony szintű részében. A boot szektor kódját, ami átvált 16 bites módból 64 bites módba, meg beállít mindenféle deszkriptor táblát, nem fogod tudni magas szintű nyelven megírni. De mondjuk a taszkváltás mechanizmusa is elég platformfüggő ahhoz, hogy standard C-ben ne lehessen megírni, viszont nem is olyan gyakran használt, hogy mondjuk a GCC-be intrinsic-ként beépítsék (legalább is úgy tippelem, mert most lusta vagyok utánanézni).

    2) Amikor a CPU olyan képességét szeretnéd használni, ami nem illeszkedik szépen egy magas szintű nyelv koncepcióira. Például 32 bites x86-on a DIV utasítás 64 bitet oszt 32 bittel, a MUL utasítás 64 bites kimenetet ad két 32 bites bemenetre, de magas szintű nyelven tipikusan nem így működik az osztás/szorzás művelet. Ha megnézed például a GMP kódját, látni fogsz benne kb. két tucat architektúrára finomhangolt assembly kódot. A feladat megoldható "tiszta" C-ben, de a maximális teljesítményhez az kell, hogy a CPU minden képességét kihasználd, nem csak azokat, amikhez a C hozzá enged férni.

    Ezek persze nagyon rétegigények. Ahol komolyabb az igény (például az SIMD utasításkészletek kihasználásához), a fordítók is igyekeznek ráfeküdni a problémára, és módot adni arra, hogy ASM nélkül is közelébe érj a kívánt teljesítménynek.
    Mutasd a teljes hozzászólást!
  • Elöljáróban annyit, hogy van közeli ismerem fél tucat architektúráról és assembly nyelvezetéről.
    Dolgoztam még sok évvel ezelőtt silány C fordítóval, ez főleg 8 bites architektúrákon tapasztalható.
    Ma leginkább 32/64 bites architektúrák vannak életemben (mikrovezérlő, SBC, x86 Linux szerver), amely targetekre GCC fordít.

    Kérdésem, amin tűnődök: ha GCC vagy vele azonos, jó kódgenerátorral rendelkező és egyúttal ügyesen optimalizáló C fordítód van, milyen konkrét esetekben célszerű ma még C helyett assembly-ben kódot írni?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd