( TCH | 2021. 02. 23., k – 11:04 )

Én meg pont erről beszéltem, hogy pont a homecomputereken nem volt túl sok értelme erőltetni a tiszta assembly-t, főleg 16 biten nem. Ami sebességkritikus azt célszerű assemblyben megírni, a többinek meg teljesen mindegy.

Arról, hogy ahogy te megközelítetted, annak a konzolokon volt értelme egyedül (meg árkádon). Mondjuk C64-en még csak-csak meg lehet indokolni, hogy a gyári BASIC-ja gagyi és a hardware meg a rendszer is viszonylag egyszerű, tehát lehet több pepecselés lesz, ha beviszel valami magas(abb) szintű nyelvet is a képletbe, mint ha azt a pár tucat rutint/makrót egyszer megírod, aztán csak használod minden cuccodban, de a két nagyságrenddel bonyolultabb hardware-es és software-es környezettel bíró Amiga gépcsalád esetén nem sok indokot lehet felsorakoztatni a mindent is assemblyben megközelítés mellett.

Sz*rk: Alámszerkesztettél.

> Csak azt mondom, hogy 20 évvel ezelőtt, amikor mi hasonló dolgokat csináltunk (demók, játékok), akkor assembly-t használtunk és rácsodálkoztam, hogy valaki máshogy közelíti meg, mint mi akkor.

Pont ezt magyarázom, hogy az a megközelítés nem feltétlen volt jó.

> az interruptok és a multitaszk rendszer bármikor elveheti a vezérlést. Ha a processzor annyira gyors, hogy egy erősen optimalizált ciklust megszakítás nélkül végrehajtva pont jól sikerül kirajzolnia egy képet, akkor logikus volt ezt a lehetőséget letiltani. Pl. egy pixel széles oszlopokból kirajzolt szinusz scroller nem hagyott sok időt másra.

Nem azt mondtam, hogy nem volt értelme átkapcsolni kizárólagos módba, hanem azt, hogy nem alap, hogy ezzel nyitunk, hogy letiltjuk az OS-t. Nyilván, egy demo-nál kellett az egész gép, de mi van a felhasználói cuccokkal, vagy a játékokkal?

> Nem az OS függvényeit hívtuk, hanem kézzel hajtottuk végre kb. ugyanazt (illetve gondolom néhány esetben egyszerűbbet, kevesebbet, csak annyit, amennyit éppen kellett. Elhagyva ilyen-olyan paraméterek vizsgálatát, elhagyva mondjuk nem kritikus hibák kezelését, stb.)

Hát pont ez az, hogy "kb. ugyanazt (illetve gondolom néhány esetben egyszerűbbet, kevesebbet, csak annyit, amennyit éppen kellett. Elhagyva ilyen-olyan paraméterek vizsgálatát, elhagyva mondjuk nem kritikus hibák kezelését, stb.)". Egyszóval nem úgy lett a hardware felparaméterezve, ahogy kellett volna. És így keletkezik a non-portable Amiga software, meg az upgrade-blocking Amiga software. Arról nem is beszélve, hogy ha tényleg ugyanazt implementáljátok le, mint az OS függvény, akkor elhanyagolható lesz a különbség, amit nyertetek vele; pont azért volt gyorsabb, amit a rendszerkerülgető kóderek írtak, mert a felét nem csinálta meg annak, amit kellett volna.

> Én nem teszteltem, de elfgoadtam amikor a nálam okosabbak és tapasztaltabbak azt mondták, hogy az OS függvényeket nem lehet használni mert túl lassúak.

Mely rutinok? Milyen körülmények között? Mihez képest? És mi az, hogy "nem lehet"? Miért lenne blocker egy könyvtárlista, egy fájlnyitás, vagy egy képernyő nyitása? Vagy a GUI programozása? Nem csak demoeffektek vannak, amiknek kell a hardware 101%-a. (Illetve ez sem igaz, mert általában zene is szólt alatta, tehát volt még szabad erőforrás az effekten túl.) Egyébként egyel feljebbi bekezdés: ha rendesen ugyanazt leimplementáljátok, mint az OS, akkor nem sokkal vagytok előrébb.

> Simán lehet, hogy megszokás volt a legfontosabb. C=64-en assembly-ben toltuk, Amigán meg csak ugyanazt a megközelítést folytattuk.

Erről beszéltem.

> Én pont akkor kezdtem el sok év assembly programozás után C-t megtanulni és használni, amikor olyan programokat kezdtem írni Amigán, amik OS függvények hívásával dolgoztak.

A nyelv mellékes, assemblyből is lehet hívogatni az OS-t. Csak pepecselősebb.

> Viszont ezek nem próbáltak időkritikus módon video memóriát manipulálni, stb. Kitettek ilyen-olyan requestereket meg ablakot rajzoltak meg fájlokat nyitottak meg, írtak, másoltak, stb.)

Tehát nem is volt értelme assemblyben megírni. Vagy letiltani hozzá az OS-t.