Milyen programokat fejlesztettél?

Várj, a moderátor nem fogja csak úgy kilőni az üzeneteinket :D Én úgy gondolom, hasznos dolgokat lehet megosztani itt egymással, hanem, hogy mi érdekel, nos, az nem éppen, ebbe sorolható kategóriába :D Hanem,

Autohotkey-re visszatérve, a GDIPlus.ahk hasznos lehet. Azt főként úgy tudod használni, ha beírod a script elejére, hogy #Include GDIPlus.ahk

54 (2021.09.26 10:51): Bocs, kicsit rosszul írtam, mert egy korábbi válaszomból másoltam és így nehezebben érthető. Az eredeti mondatban még volt így értelme: "assembly - C kombinációban írt programjával" ez a mondat elejével értelmes. De amikor kimásoltam nem gondoltam végig rendesen. Helyesen: "Assembly - C kombinációban szoktam programokat fejleszteni". Ez gyakorlatilag azt jelenti, hogy a program egy része Assembly-ben, egy része C-ben van megírva. Hogy mikor mennyi része melyikben sokszor az alkalmazástól, és az elérhető C fordítótól függ. Vannak olyan rendszerek ahol a C fordító "buta" és nagyon rosszul fordít, ilyenkor több rész van Assemblyben, és kevesebb C-ben. Kisebb feladatoknál sokszor eleve Assemblyben kezdünk.

Ami egy érdekes példa, és sokan nem gondolnak rá, hogy sokszor maga a proci nem tud szorozni (nincs benne szorzó modul/szorzó utasítás), és nagyon erősen fordító függő, hogy a szorzást hogyan implementálják. És sok esetben elég sok memória és CPU igénye tud lenni egy kevésbé jó szorzásnak.

Azért sem látom értelmét annak, hogy ide betegyem kódomat mert ezeknek a nagyon hardver közeli rendszerek programjai teljesen érthetetlenek a hardver ismerete nélkül.

Nézzünk egy példát:

MOV A,0x2B

OUT 0x3F,A

Utasítás sor mit csinál? Ha nem ismerjük a hardvert akkor ez pontosan nem mond semmit. Ha tudjuk, hogy pl. a 0x3F egy karakter nyomtató címe, akkor ez feltehetően egy + jelet fog kinyomtatni a nyomtatón. De ugyanígy lehet pl. egy soros port inicializálása is, ha ott egy sorosporti hardver van. De nem egy esetben van memóriába ágyazott IO, na az ott még cifrább tud lenni. Tényleg nem látom sok értelmét ilyen programokat közzé tenni.

A másik fele pont az assembly esetén, hogy nagyon erősen processzor függő. Mint fent írtam pl. van olyan processzor (még mai is, elterjedten használt mikrokontrollerek között) amelyekben nincs szorzás művelet. (Még egész szorzás sincs benne!). Aki nem ismeri az adott processzort nyilván beszól azért ha az ember egy fél képernyőnyben tudja megírni a szorzást, mert azt mondja miért nem használod az MUL vagy IMUL utasítást (általában valami ilyesmi szokott lenni). Aztán magyarázzam, hogy használnám ha létező utasítás lenne az adott hardveren. És pl. pont a szorzásnál van az is, hogy nagyon függ a szorzó eljárás attól, hogy pl. van-e balra shift, vagy csak balra rotálás, vagy balra rotálás a carryn keresztül, vagy a balra shift a kieső bitet eldobja vagy beteszi a carrybe (eddig találkoztam már mindenféle megoldással különböző processzoroknál,mert a balra shift/rotálás megvalósítása is lehet sokféle, van olyan amelyik mindegyik megoldást támogatja, van amelyik csak egyet. Nyilván teljesen más lesz a kód ha az egyik vagy a másik balra shift/rotálás megoldás létezik csak. Ugyanígy szintén pl. a szorzás esetén vannak olyan eljárások amelyek gépiszóhosszon belül maradnak, van amelyik 2xszóhosszt is tudnak kezelni, illetve vannak olyanok amelyek több szavas szorzó eljárások, pl. két darab 4 szavas szám szorzása egymással úgy, hogy az eredmény 8 szó tud lenni). És ez még csak a szorzás és pl. már ez is sok féle képpen implementálható helyesen, de ez annyira hardver függő, hogy teljesen felesleges közzétenni kódot hardver ismerete nélkül /azt meg közzé se tehetem, mert azt pl. nem én fejlesztettem/. És mondom még csak ott tartunk, hogy két számot össze akarunk szorozni ami azért valljuk be nem egy túl ritka feladat.