Názory k článku Flat assembler: vývojářský nástroj ze staré školy

ono možná nejde ani tak o to, že by byl FASM tak dobrý, jako že GAS je špatný. Špatný v porovnání třeba s assemblery, které se skutečně používaly pro i velké aplikace. TASM a MASM, v nich vznikaly i větší projekty. FASM taky není žádný král v oznamování chyb; prostě skončí na řádku XY a to je tak vše. V tomto ohledu zlaté TASM a MASM, ale chápu, že dneska to už asi málokoho trápí.

on GNU Assembler asi nikdy nebyl myšlen na skutečné programování něčeho většího, na to mu tam chybí lepší chybová hlášení (třeba u maker) a příliš nízkoúrovňový přístup. Taky ještě relativně nedávno měl jen AT&T syntaxi a i přes některé její výhody jsem se toho nechtěl dotýkat ani dlouhým klackem :-) S Intelí syntaxí je to už lepší, ale IDEAL režim starého dobrého TASMu mi stále chybí. A ani FASM ani NASM tohoto stavu stále nedosahují.

Svého času jsem k překladům používal JWASM, což byl v podstatě s MASM kompatibilní překladač, ale na rozdíl od MASM byl open source a pod licencí, která umožňovala i komerční použití bez omezení. Co si pamatuji, tak to skutečně kompatibilní bylo s MASM 6.x, a nebyl problém svižně přeložit poměrně rozsáhlé projekty i pro win 32, protože zde byly přiloženy windowsí hlavičkové soubory konvertované do asm. Teď ale koukám, že "svého času" už je fakt dávno, neboť se JWASM už nějakých 10 let nevyvíjí.

Je to tak. Popravde jsem myslel, ze JWASM se stale vyviji, ale zda se, ze uz fakt ne.

Cau Pavle, ja jsem dlouho pouzival assembler WASM od Watcomu, nyni OpenWatcom.

Za mne syntaxe skoro ala turbo assembler a taky umi kompilovat pro DOS16, DOS32, Win16, Win32, a nakonec i linux!
A navic zvlada i specifikaci predavani argumentu pres vyjmenovane registry pro C-ckovy kod :-)

Treba toto, tri ruzne kusy kodu z jednoho meho projektu (rezidentni SLIP/ETH IP protokol 'prevodnik'):

`prolog.inc`:
.model tiny,SYSCALL
.286
 
_TEXT segment public 'BRIDGECODE'
 
ifndef VERSION
VERSION equ 011ACh
endif
 
;This forces everything into the same segment :-)
ASSUME CS:_TEXT, DS:_TEXT, SS:_TEXT


`COM_ASM.ASM`:
include 'prolog.inc'
include 'uart.inc'
 
public _ComSetChainISR
public _ComISR
 
extrn _ComRecvChar:near
extrn _ComSendChar:near
 
extrn _BridgeFIFOLen:byte
 
; ISR chaining ....
CHAIN_ISR dd ? ; SEG ^ OFS
HAVE_ISR_CHAIN dw 0
HAVE_SMART_CHAIN dw 0
 
_ComSetChainISR:
mov CS:HAVE_SMART_CHA­IN,BX
 
mov word ptr CS:CHAIN_ISR,AX
mov word ptr CS:CHAIN_ISR+2,DX
 
or AX,DX
mov CS:HAVE_ISR_CHA­IN,AX
 
ret


'COM.H':
// for IRQ chaining
WORD ComSetChainISR(void far *ISR,WORD Smart);
#pragma AUX ComSetChainISR parm [ DX AX ] [ BX ] value [ AX ] modify [ DX ];


Diky za info. Nainstaluju a zavzpominam (kdysi byl Watcom, tedy ne assembler, ale C/C++, vzyvan pro svoje optimalizace)

Mně se linkování před spuštěním dělo v DOSu i v CP/M, aby to nevypadalo, že se tahle magie musí dělat až v Linuxu.

assembler je prilis nizkourovnovy, C, Golang jsou podle me tak akorat a C++, Rust uz to s abstrakci trochu prehaneji.
co si myslite vy o prilisne/nedos­tatecne abstrakci, je objektove programovani zas takova pomoc, nebo templatovani, metaprogramovani, nezdrzuje to spis cloveka?

no to mi pripadne jako tvrzeni, ze pro dopravu je kolo moc pomale a letadlo zase moc velke a blbe se parkuje doma na predzahradce ;) IT je strasne rozsahla oblast a je asi rozdil nekde nasazovat nejaky PIC* a na strane druhe lepit obrovske enterprise systemy. Asi bych si nedovolil rict, co je akorat na tak obrovske skale.

* pro PICy nejaka cecka existuji, samozrejme. Jen je typicke, ze priklady jsou ukazovany pro PIC16 nebo PIC18, proc asi? :)

Na škále dopravních prostředků s kolem a letadlem by mrňavé PICy s 25 bajty RAM a zásobníkem na dvě návratové adresy nejlépe vystihlo "A jak dlouho ještě budete driftovat?"

Rust je příklad jazyka, který (schválně) není OOP, ale některé vlastnosti OO jazyků implementuje (zapouzdření atd.) - osobně nejsem taktéž příznivcem OOP, ale je třeba si položit otázku, co přesně má daná abstrakce řešit a proč bych ji (ne)měl potřebovat. Doporučuju se podívat třeba sem: https://www.thecodedmessage.com/tags/beyond-oop/

Metaprogramování je nástroj jako každý jiný. Nemá smysl si tu otázku pokládat takto obecně.

Golang

Z toho seznamu budu reagovat pouze na golang. Za mě super jazyk v původní podobě. Přesně věděl, kde chce být, co chce řešit a co řešit nechce. Silně a staticky typový jazyk, s velmi snadnou možností si vyrobit vlastní typy. Jméno a Příjmení jsou odlišné datové typy, i když je to string. Funkce přijímající jméno nepřijme příjmení. Nezkompiluje se to. A je to tak správně.

V přednáškách Kevlin Henney vysvětloval, jak tohle použít. Super vysvětlení. Snadno pochopitelné, velmi snadno se potom píšou programy, kde všechno je vlastní datový typ. Krásné jednoduché a velmi kompaktní programy.

Potom přišel někdo, kdo vůbec nepochopil tento princip a přišel s tím, že nutně potřebujeme generika. Tak tam jsou generika. Zcela zbytečně, přidává to další bordel, který tam vůbec nemusí být. A ještě k tomu syntaktický. Kdyby někdo udělal knihovnu pro generika (což jde, protože tam jsou interfaces), tak to nebude komplikovat zdroják.

Před x lety jsem slyšel námitku, že tam nejsou výjimky. No nejsou no, protože vlastně vůbec není jasné, co je to výjimka. Programátor má ošetřit všechny stavy a ne jen jít zlatou cestou. Opět, když se poctivě ošetřují všechny stavy na místě, kde vznikají, výsledkem je pěkný a kompaktní program. A pokud opravdu někdo nutně potřebuje výjimku proto, aby tento error stav mohl nechat probublat vejš, tak tohle v golangu udělá velmi snadno. Není potřeba tam nic cpát. No, takže očekávám, že do deseti let bude mít golang výjimky.

asi jo, ale zase do toho nemichaji jako pejsek s kocickou vsechno tak, jako v C++. Takze Go sice narusta ale zatim nijak zavratne (fingers crossed).

Co je horsi - generika zpusobila, ze uz vyvojari nevedi, jak se funkce prekladaji. Ztraci se tam to kouzlo jazyku C/Go, kde +- lidi tusili, co se deje pod kapotou. U generik ne, tam je pozdnejsi urceni, co a jak se bude prekladat.

Otázka zní, zda vůbec je u Go tohle tak podstatné. Ani programátoři v C to do detailu často nevědí.

tak kdyz rekneme A, tak musime rict i B. Pokud to neni podstatne (a mnohdy neni), tak to neni nahrada za assembler. A pokud to je nekdy podstatne a potrebujeme to vedet (zrovna nedavno se tady resilo preteceni), tak to jazyk nema skryvat, aby to byla nahrada za assembler.

[06g]
Myslim, ze v C++ je to vic o programatorovi jak se rozhodne jej pouzivat, nez o jazyku samotnem. Zrovna C++ nabizi ruzne moznosti, ale nic si sam od sebe primo nevynucuje. (napr v C# mate uz jako vstupni bod programu tridu, podobne v Jave. V C++ porad je to jen funkce). A to i presto, ze se C++ dost meni* a podle meho mineni nekdy trochu zbytecne**.

Jsou programatori, kteri C++ pouzivaji vicemene jako C s prisnejsi typovou kontrolou. A je opacny extrem, kdy kdyz se kod nejezati spicatymi zavorkami, neni to podle nich to prave C++ (je pak super takovy kod cist a jeste vetsi balada je to ladit). Ja jsem toho nazoru, ze vsechno ma svuj cas a sve misto a sablony se maji pouzivat stridme. To vsechno C++ umoznuje.

* A ja se obavam, ze se meni proto, ze B. Stroustrup a lide, kteri maji vliv na vyvoj C++ maji fedry z agresivniho nastupu nekterych radoby nastupcu tohoto jazyka a taky menici se mentalite programatoru. A tak se snazi prizpusobit. Kdyz jsem pred casem cetl vyjadreni Stroustrupa o potrebe vetsi ochrany pameti, delalo se mi nejak nevolno ...

** Napr. Zavedli se anonymni funkce, misto toho, aby se trochu vice propracoval koncept funktoru. Jsem presvedcen, ze vylepsene funktory mohli nabydnout velmi podobne moznosti, jako maji funkce napr. v jazyce Lua. Funktor je objekt. funkce - v C++ - je porad jen funkce, i kdyz umi zdilet kontext.

15. 5. 2024, 23:03 editováno autorem komentáře

C++ má za mě proti C pár velkých výhod
* věci jako std::unique/sha­red_ptr, std::unique_lock a podobné objekty, které vážou uvolnění nějakého zdroje na životnost objektu a je tak těžší udělat memory leak
* dědičnost a abstraktní třídy na to, aby některé objekty šli implementovat dvojím způsobem, třeba pro účely testů, řešení přes tabulky pointerů na funkce v C je dost hnusné

Šablony se občas hodí, ale jejich nadužívání s argumentem, že jsou rychlejší než virtální funkce se mi nelíbí - kód v hlavičkách se překládá pro každý soubor, následně při linkování vypadne jako duplicitní, občas se inlinuje, občas ne a primární problém je často volat funkci miliardkrát, takže přínos šablon je potom jen to, že program běží ještě pomaleji v debugu, dlouho se překládá a hůř se ladí, nehledě na to, že to občas ani není čitelné. Navíc generický kód se bez specializací špatně optimalizuje pro časově kritické operace. Neříkám, že se to občas nehodí.

V neobjektových jazycích jako Julia a Rust jsem psal příliš málo na to, abych je komentoval.