Názory k článku
Generování fraktálů v assembleru

Pěkná implementace využívající SSE3 instrukce je zde, při jednoduché přesnosti se počítají rovnou dva pixely současně. :-)

To vypada dost zajimave. V minulosti jsem se pokousel o MMX verzi (to snad SSE jeste neexistovalo), ale k nejakemu extra zkraceni nedoslo. Sice se dalo pocitat paralelne, ale zase prevody v FX formatu do docela zabily a MMX instrukce maji docela dlouhe opkody.

Nevím, jestli to bude kratší, ale rychlejší by to být mělo. Zrovna nedávno jsem řešil komplexní násobení velkého počtu hodnot v jednoduché přesnosti, a při použití té jejich SSE3 implementace se doba výpočtu zkrátila přibližně na polovinu oproti verzi, kterou vyrobilo GCC. Zkoušel jsem i ICC, s tím se mi povedlo dosáhnout zhruba o 20–30 % rychlejšího výsledku než s GCC.

Proc, proboha, zase ty desne vytvory od Borlandu? Proc ne GAS? Ten je dostupny vsem a zadara!

Viděl jsi datum, kdy PT prográmky psal?

V té době jsem o jiném ASM než TASM jen mlhavě slyšel

tipuju, ze nasm/yasm to s minimalnimi upravami prelozi taky.

Tak GAS bych urcite nepouzil ani dnes, to spis NASM. GAS je sice idealni backend pro GCC i jine softwarove "generovace assembleru", ale pri rucnim pouziti se ukazuje, ze je spatne ovladatelny (upozornovani na chyby, oznacovani registru atd.). Je to samozrejme pouze muj nazor, ale TASM se da pouzivat dost intuitivne, je rychly, pouziva Intelackou syntaxi a hlavne: umi generovat sestnactibitovy kod :-)

Poniektori sme si uz zvykli, ze ine ako (G)AS neexistuje, kedze iba to je akceptovane na istej fakulte. 16-bitove instrukcie su velmi uzitocne napriklad pri pisani boot-loaderu, prave preto existuje aj as86 a ld86, ktore dokazu generovat 16-bitovy kod a pripadne obmedzovat sa na 286 / 386 instrukcie (balicek bin86, v gentoo standartnou sucastou). Ked uz je bootloader hotovy, tak zvysny kod si pekne pisete v as, ld.

Urcite je mozne si na GAS zvyknout, my jsme zase delali hodne v TASMu, takze mi jeho syntaxe vyhovuje lepe. Take nekolik let predtim jsem delal na Intelackych procesorech (8080, 8048, 8052, 8086) a MOSech (6502, potom trosku Motorola 68HC11), vsude je syntaxe blize TASMu nez GASu - ale jak rikam, tady jde o zvyk.

jop, s TASM som robil za blahych cias DOSu. No jo, GAS je AT&T syntax.. a ten as86 je zas intel. Da zabrat ked clovek jeden vecer prepina medzi oboma syntaxami. Cele na co si treba davat pozor, je citanie manualu od Intel procesorov, a dorazne prehadzovanie vsetkych argumentov do opacneho poradia, ako je uvedene v prikladoch :)

Da se nekde hodnotit kvalita clanku? Tento serial je naprosto genialni, ale ze se postupne dostane az takhle daleko by me v zivote nenapadlo, vyborne, genialni, jen tak dal!!! DIKY!!!

Souhlas, kvalitni clanecky...
V dnesni dobe to neni uplne bezne.

BTW, kdysi jsem se zabyval vypoctem Mandelbrotovy mnoziny
na siti transputeru, pote jsem jej psal pro PC snad ve
3 ruznych prostredich a nakonec jsem taky skoncil u ASM.
To ale bylo za dob DOSu, wokna jeste nikdo neznal ;-)

jj, to byly casy (jenom jsem v te dobe neznal ani tucnaka :-(

Jo jo, cesti demoprogramatori na to, ze jich moc nebylo, byli co se tyce asm a inter dost dobri, jeden cas probihala i pekna ceska soutez (bohuzel nazev uz si nepamatuji) kde ucelem bylo dany obrazek (treba ceskou vlajku) vykreslit v tom 13H rezimu programem s co nejmensi velikosti. Pres par desitek bajtu ty programy nebyly. Byl to uplne jiny zazitek z programovani, nez ty dnesni "business" aplikace. Bohuzel ta doba je davno pryc.

Je to uz davno, ale mam dojem, ze ta soutez byla vyhlasena v Parenisti, snad prave Dementem. Nektere programky byly docela zajimave, zvlast pak jeden, ktery cely obrazek stale znovu a znovu prekresloval. Vykreslit vlajku tak, ze se pro kazdy pixel prepise dalsich 64000 pixelu je kumst :-), ale zato to bylo dost kratke.

Potvrzuji, byl to diskmag| Pareniste a pro jeho vysokou kvalitu bych rovnou doporucil kazdemu, at se podiva na sekci archiv a stahne si nektera vydani. http://dee.cz/machina/

testne vedle, objevilo se to i v parenisti, ale pokud si dobre pamatuju puvod byl z vyhne - VCC - Vyhen coding Compo :)

> Bohuzel ta doba je davno pryc.

Neni pryc, i kdyz se ted prakticky cela ceska demoscena vejde do dvou poloprazdnych osobnich automobilu :-). Ale zrovna tento vikend cesti sceneri opet zabodovali: CLRSRC ziskali pekne druhe misto v 64K intru na Frankfurtskem Breakpointu 2007. http://pouet.net/prod.php?which=30226

To su kratke programy v assembleri?:-)

Urcite to pujde o par bytu zkratit, klidne si to muzete vyzkouset. Pokud pocitam i nezbytne inicializace (graficky rezim, ukazatel na video pamet) a uklid (vymazani bufferu klavesnice, nahozeni textoveho rezimu a navrat do DOSu), tak se pod sto bajtu dostat neda.

Pánové, musel jsem se podívat na kalendář, který je rok, že na rootu učí finty v x86 asembleru.

Asembler už má smysl jen pro zábavu, nebo pro ladění grafické knihovny, pokud jste nvidia nebo ati (AMD).

Zhruba platí, že jakýkoliv ASM kód bude za deset let pomalejší než když to pak napíšete v céčku (na těch o deset let novějších architekturách).

Asembler bych použil tak na malé jednočipy, ale na PC už ne-e.

No jistě, a kompilátory se napíšou samy. :-( Třeba nově vznikající XCL se vynoří z nicoty už hotový, že. :-/

Hmm, zajímavý, rozšířený a přitom mylný názor. Jako céčkař však musím říct, že žádný vyšší programovací jazyk neobsahuje některé konstrukce, které jsou nutné pro efektivní zápis určitých algoritmů (namátkou třeba konvoluční filtry, víceslovní aritmetika atd.).

Neříkám, že assembler je vhodný na vše - to v žádném případě! Také céčko, Java, C#, Python apod. zdaleka nejsou vhodné na všechny úlohy. Ale pro určitou skupinu úloh je assembler jediný rozumný jazyk (spolu s jeho "nadstavbami", jako bylo C-- nebo HLL).

Na 95% úloh je assembler příliš nízkoúrovňový, ale co těch zbylých cca 5%?

FastCAD byl napsán celý v assembleru... a spousta kódu tam jistě stále zůstává a udržuje se....

znova jsem propadnul asembleru nedavno (25.5.2007) a to prave kvuli kernelu linux.