Vlákno názorů k článku Trasování a ladění nativních aplikací v Linuxu: pokročilejší možnosti nabízené GNU Debuggerem od jaromrax - Obdivuju to, to musim rict. Ale mam otazku...
-
Smazaný profil
Ale isteze. Napr. encoder x264, x265 ma kopec kodu v asm. Dokonca autor pravidelne organizuje ucast na summer of code, kde sa snazi projekty vylepsit. Poziadavky na vstup do SoC su: assembler - expert.
Takisto som raz stretol cloveka, ktory vytvara ochrany proti piratom do hier. Bez assembleru sa takyto clovek nepohne.
-
Pavel TišnovskýZlatý podporovatelTak tvorba delších programů pouze v assembleru je na zařízeních, kde běhá linux (což už musí být dost silné stroje, žádné PIC10), asi hodně výjimečná, ale kratší kusy kódu se pořád tvoří. Spousta lidí se například pouští do své zaručeně nejrychlejší :-) implementace FFT či části nějakého kodeku popř. aspoň filtru.
Osobně se však mnohem častěji setkám právě s potřebou odladění kódu, který klidně vznikl překladem kdoví kde nebo v JITu a kde jiná možnost není (třeba změna původního zdrojáku na produkci nebo živém zařízení nehrozí a i kdyby to šlo, tak některé problém s přístupem do paměti "zmizí" ve chvíli, kdy se nový překlad provede s přidáním debug symbolů apod.).
-
host (neregistrovaný)
Ale jo. MIPS, ARM.
Zrovna teď píšu něco pro NEON (SIMD jádro) na Cortex-A9 dvoujádře v Zynq7020, Linux 3.14.2.
Jde o rychlost, takže nejdřív to začlo v Cortex-A9 asm, potom pokus o vektorizaci a přepis do NEON intrinsic v C -O3. Ale ani to nedávalo takové výsledky, jakých se mělo podle předpokladů dosáhnout (gcc měl vlastní hlavu, jak instrukce zpřeházet, a bohužel ne příliš efektivně). Takže zpět do asm a ruční práce s každou instrukcí. Vše nad tím samozřejmě už C.
Ono je to tak, že na klasických strojích, když to drhne, tak se koupí lepší stroj, nebo se to rozhodí mezi více strojů. V embedded, když už to máte vyvinuté a osazené a zákazník najednou chce přidat ještě to či ono, tak přechod z C do asm na kritických místech je většinou první volba. Teď jsem třeba věc, která trvala v C -O3 po různých optimalizačních cestách naproti gcc 47 T/bajt srazil na 13 T/bajt (díky NEONu).
Poslední roky ale platí (vyšší verze gcc 4, gcc 5 -O3/-Ofast), že nemá cenu přepisovat C do asm bez nějaké další pomoci, třeba v podobě v C překladači nepodporovaných instrukcích (dosažitelných jen z asm) nebo ještě ne příliš dobře podporovaném hw (třeba právě ty SIMD) apod. Před pár lety jsem míval skóre tak 10 až 25 % na rychlosti C -O3 -> asm, teď jsem tu věc nahoře v ARM asm napsal jen na 47 T/bajt, takže rovná 0. Jo, možná stárnu...
