Hogyan programozhatsz gépi kódban?

Attól függ milyen operációs rendszert használ az ember. Régen a DOS időkben a COM fájl elég egyszerű volt és abban nem volt nehéz akár egy hex editorral megírni egy programot. Ha a mai windows és linux rendszert használsz kell valami fordító ami képes egy olyan fájlt előállítani amit az operációs rendszer le tud futtatni.

Ha más operációs rendszert használ, vagy nem használsz operációs rendszert akkor meg a processzortól függ. De szinte minden esetben célszerű valami fordító rendszert használni ami megfelelően előkészíti a kódot.

Ha meg te magad építesz egy gépet akkor a lefordított gépi kódú programot beégeted egy EPROM-ba és azt végre fogja hajtani a processzor.

Régen, 8 bites mikroprocikhoz (pl. 8085, Z80) volt olyan faék bonyolultságú "fejlesztő rendszer", amiben volt egy nagyon minimális "monitor program" ami segített abban, hogy be lehetett írni a memóriába egyenként a megfelelő értékeket (miután kézzel lefordítottad) és el lehetett indítani (kb. 20-22 gomb volt rajta összesen 0-F-ig a számok /16 db./ és pár parancs gomb).

"Akkor hogyan lehetne a 0001 utastást a processzornak kiadni?"

Két fő eset van, op.rendszerben vagy azon kívül. Azon kívül pl. bootloader-ekben, de szerintem ez most nem opció. Op.rendszeren belül csak úgy, hogy futtatható bináris formára hozod. Win alatt az EXE fájlok alkalmasak rá, Linux kernel alatt pl. at ELF típusú fájlok. (A régi com fájlok Win10-en csak egy kompatibilitási rétegen vagy emuláción keresztül futnak, már ha.)

Szóval megírod assembly-ben, lefordítod egy futtatható kóddá, és elindítod. Olyat tehetsz még, hogy egy magasabb szintű nyelvben írsz valamit, és egy assembly szakaszt szúrsz be valahova, de a lényeg ugyanaz. De közvetlenül így külön egyetlen utasítást felhasználói felületről nem tudsz elküldeni a CPU-nak, csak valamilyen programon belül tudja végrehajtani (ha nincs access violation, stb.)

"Akkor hogyan lehetne a 0001 utastást a processzornak kiadni?"

A processzor úgy működik, hogy a memóriából beolvassa a gépi kódot (prefetch) és a kódnak megfelelően működik tovább. Tehát lényegében a kód vezérli a procit.

Ha mondjuk a nulladik memóriacímről beolvasott gépi kód az ADD utasítás, akkor a proci következő lépése lesz az egyedik címről beolvasni (megfelelő helyre (egy munkaregiszterbe)) egy értéket és a második címről egy másikat. A két értéket összeadja (végrehajtás) és az eredmény egy megfelelő regiszterben jelenik meg.

De ha mondjuk egy JMP utasítást prefecth-el a processzor, akkor a proci csak a köv. memóriacímen található értéket olvassa be és ezután végre is hajtja a JMP-ot. Arra a memóriacímre ugrik amit a JMP utasítás utáni címről beolvasott.

A processzorokban van egy regiszter, ez a PC (program counter) ennek tartalma határozza meg, hogy a proci a memória melyik címéről olvas éppen. Egy JMP esetén a JMP utasítás utáni érték nem egy általános célú regiszterbe, hanem közvetlenül a PC-be fog kerülni. A végrehajtás eredménye meg az lesz, hogy a proci a program végrehajtását nem a soron következő címen, hanem máshol fogja folytatni. Azon a címen, amit a JMP utasítás utáni címről beolvasott.

Utasítást a processzornak közvetlenül nem lehet kiadni.

A folyamat az, hogy a kódot megírod (forrás), lefordítod (gépi kód (tárgykód)), futtatod. A futtatás azt jelenti, hogy az operációs rendszer a (gépi) kódodat beolvassa a memóriába, egy bizonyos címre. Ezt a címet (ORG) te is meghatározhatod, mondjuk 100h. Ezután az opre beállítja a proci PC regiszterét arra a címre, ahova a progidat beolvasta (100h) és ráadja a vezérlést (elindul a végrehajtás).

5:

Nem csak elméletben. Így működik ez a gyakorlatban is. Nem csak x86 (32/64 bit) létezik, sőt, abból van a legkevesebb.

Védett mód. Hát, ez azért rendszertől függ, mert én pl. úgy egy jó éve freedos-sal vettem az egyik gépemet. Tehát, még a 64 bites procik is valós módban indulnak.

A kérdező talán akkor jár a legjobban, ha keres egy PC emulátort (Bochs, Mozaa, egyéb), vagy feltelepíti a DOS-boxot és ott kezd el kisérletezni.

De vannak egyszerűbb processzorokat emuláló programok is. Pl. a 8008-asnak, a 6800-nak vagy a 6502-nek is vannak nagyon jó emulátorai. Előny, hogy ezek a processzorok még nem ismerték a védett módot, így architekturálisan is egyszerűbbek, könnyebb a működésüket megérteni. Ráadásul nincs "ezer" utasításuk, mint a mai CISC processzoroknak.

Én nem hiszem, hogy a kérdező Z80-as prociban vagy DOS-ban gondolkodna. És a kérdés is ezt volt:

"hogyan lehetne a 0001 utastást a processzornak kiadni?"

Szerintem ő arra kíváncsi, hogy hogyan lehet egy adott gépi kódú utasítást felhasználói felületről végrehajtatni a procival.

Mindegy, én ezért nem fogok lepontozni, de egy kis plusz infó azért jól jön, hogy ne vezessük félre a kérdezőt.

"Én nem hiszem, hogy a kérdező Z80-as prociban vagy DOS-ban gondolkodna."

Azt nem tudhatjuk, hogy a kérdező mire gondolt. Én nem is állítom, hogy z80-ban, DOS-ban gondolkodna, azt viszont kiérezni, hogy a gép, a processzor működése érdekli.

Ha pedig ez, akkor olyan mindegy, hogy z80, vagy DOS, utóbbi meg végképp nem értem miért lenne baj, hiszen ha elmondanám neki a jelenkori PC-kben zajló valóságos folyamatokat, akkor talán egy életre elmenne a kedve attól, hogy megtudja azt, ami érdekli.

A pontozás engem teljesen hidegen hagy.

Egyébként, hogy pontos legyek, a z80-at ÉN nem is említettem.

#5.2020.02.03 01.47: "#4 Igen, így működik elméletben, csak tegyük hozzá, hogy ma már rendszerindulás után védett módban vannak a procik, van egy virtuális-valós memória címfordítás is, stb."

És hogy jön ide a védett mód, és a címfordítás? Az az oprendszer és a proci dolga,hogy a címfordítást "elrejtse" az átlagos programok elől (ld. Intel® 64 and IA-32 Architectures Software Developer’s Manual egy kellemes olvasmány az Intel procikról kicsit lejjebb pár gondolat abból kimásolva, az egész dokumentáció kb. 5000 oldal, de ha valaki komolyan akar foglalkozni intel programzoásával el kell olvasni). Szép is lenne úgy programozni, hogy küzdünk a címfordítással, mert nem tudjuk, hogy hogyan lett betöltve a programunk (ez egyébként már a régi DOS rendszeren is megvolt, és ez volt a lényeges különbség az EXE és a COM fájl között, az az EXE relokálható volt, ennek összes jó és rossz tulajdonságával együtt, a COM nem volt relokálható, ellenben csak egy szegmenset tudott kezelni /max. 64kByte/). Mára a COM kihalt (bár nagyon speciális módon van valami lehetőség virtuális gépen futtatni, én még nem próbáltam, nem tudom, hogy valójában hogyan működik).

#4. válaszadónak (01:17): A prefetch teljesen más célokat szolgál mint amit leírtál. Nagyjából Neumann óta a processzorok műveleti végrehajtási sorozata úgy nézett ki

1./ utasítás beolvasás (fetch) - ezönmagában több lépésből áll, és néhány órajel ciklus szükséges hozzá

2./ utasítás dekódolás, - esetleg további adatok beolvasása a memóriából /operandusok/

3./ utasítás végrehajtás - CISC prociknál ez elég hosszú idő is tud lenni, összetetebb utasítások esetén. A RISC-ek egyik lényege,hogy ez az idő kordában legyen tartva. Illetve sok esetben a mikrokontrollereknél kötött a végrehajtási idő, azaz úgy van a hardver kitalálva, hogy minden utasítás azonos idő alatt hajtódjon végre (kivétel a feltételes ugró utasítás, de ennek megint hardver okai vannak, hogy miért nem lehet azt is azonos idő alatt végrehajtani).

Ha jól emlékszem talán az i386 sorozattal jelent meg az Intel világban a prefetch (de lehet már a 286 is tudta, nagyon keveset foglalkoztam 286-ossal), ez azt jelenti, hogy a "várható" következő utasítást az előző utasítás végrehajtása során már beolvassa egy prefetch regiszterbe (ha szabad az adat és a címbusz, illetve a memória), ezzel gyorsítani lehet az utasítás végrehajtás, hiszen már akkor megtörténik a következő utasítás beolvasása amikor az előző még végrehajtás alatt van (egyfajta cache-elés), szintén a fent hivatkozott dokumentum szépen leírja ezt is több helyen (ezt már nem idézem be mert 5-6 helyről kéne összeszedni). A prefetch hátránya, hogy egy jump utasítás esetén "bukott" dolog, mert akkor nem a megfelelő utasítás lesz bent a cache-ben (erre is vannak megoldások, főleg a mai prociknál ahol a belső cache amibe a prefetch történik elég nagy, és törekszünk olyan programra, hogy az ugrás ne legyen nagyon távoli, lehetőleg férjen be a cache-be, ezzel nagy mértékben lehet gyorsítani a program végrehajtását).

"Utasítást a processzornak közvetlenül nem lehet kiadni."? Ezt fejtsd ki mert ez így nagyon nem állja meg a helyét.

"A folyamat az, hogy a kódot megírod (forrás), lefordítod (gépi kód (tárgykód)), futtatod. A futtatás azt jelenti, hogy az operációs rendszer a (gépi) kódodat beolvassa a memóriába, egy bizonyos címre. Ezt a címet (ORG) te is meghatározhatod, mondjuk 100h. Ezután az opre beállítja a proci PC regiszterét arra a címre, ahova a progidat beolvasta (100h) és ráadja a vezérlést (elindul a végrehajtás)." szépen leírtad a ".COM" fájl működését, de a mai Windowsok és különösen más operációs rendszerek a .COM-ot már nem támogatják. Az .exe (és maradjunk windows világban) betöltése során egy halom más lépés is megtörténik, és nem kötelezően a 100H-n kezdődik a program (eleve nagyobb mint 64kByte, és relokálható, úgy mint pl. az ELF bináris).

Semmi nem zárja ki, hogy az ember neki álljon kézzel egy hex editorral exe-t vagy elf binárist írni, mert a szerkezete ismert, de tényleg egyszerűbb egy fordító és egy linker program használata, ezekből ASM-hez léteznek ingyenes nagyon jó programok, és nem is kell hozzájuk túl bonyolult IDE, elég egy szövegszerkesztő amiben megírjuk a forrásprogramot, lefordítjuk (parancs sorból) és linkeljük(szintén parancs sorból, de van olyan ASM fordító ahol ez egyszerre is megtörténhet).

---

Lepontozáshoz: azért írtam a többi nem windows alapú rendszert mert a kérdésből nem derült ki és továbbra sem látszik, hogy milyen környezet van, és egy oprendszer nélküli esetben ahol egy egyszerűbb hardver van egészen másképpen kell megcsinálni. De ez igaz a mikrokontrollerekre is.

=== Idézet a fenti Intel dokumentációból:

Fejezet címe: "PROTECTED-MODE MEMORY MANAGEMENT"

"The memory management facilities of the IA-32 architecture are divided into two parts: segmentation and paging.

Segmentation provides a mechanism of isolating individual code, data, and stack modules so that multiple

programs (or tasks) can run on the same processor without interfering with one another. Paging provides a mechanism

for implementing a conventional demand-paged, virtual-memory system where sections of a program’s

execution environment are mapped into physical memory as needed. Paging can also be used to provide isolation

between multiple tasks. When operating in protected mode, some form of segmentation must be used. There is

no mode bit to disable segmentation. The use of paging, however, is optional.

These two mechanisms (segmentation and paging) can be configured to support simple single-program (or singletask)

systems, multitasking systems, or multiple-processor systems that used shared memory." ...

"All the segments in a system are contained in the processor’s linear address space. To locate a byte in a particular

segment, a logical address (also called a far pointer) must be provided. A logical address consists of a segment

selector and an offset. The segment selector is a unique identifier for a segment. Among other things it provides an

offset into a descriptor table (such as the global descriptor table, GDT) to a data structure called a segment

descriptor. Each segment has a segment descriptor, which specifies the size of the segment, the access rights and

privilege level for the segment, the segment type, and the location of the first byte of the segment in the linear

address space (called the base address of the segment). The offset part of the logical address is added to the base

address for the segment to locate a byte within the segment. The base address plus the offset thus forms a linear

address in the processor’s linear address space."

...

"If paging is not used, the linear address space of the processor is mapped directly into the physical address space

of processor. The physical address space is defined as the range of addresses that the processor can generate on

its address bus.

Because multitasking computing systems commonly define a linear address space much larger than it is economically

feasible to contain all at once in physical memory, some method of “virtualizing” the linear address space is

needed. This virtualization of the linear address space is handled through the processor’s paging mechanism."

===

"Szép is lenne úgy programozni, hogy küzdünk a címfordítással, mert nem tudjuk, hogy hogyan lett betöltve a programunk (ez egyébként már a régi DOS rendszeren is megvolt,"

A DOS rendszereken nem volt címfordítás. A DOS eleve valós módú oprendszer volt és szegmens:offset kezelte (címezte) a memóriát. A valódi (fizikai) címet lehetett elérni USER space-en.

"szépen leírtad a ".COM" fájl működését,"

Nem egészen. Én a plain bináris, futtatható állományok működését írtam le. Ezek közé tartozik a .com is.

Téged talán az tévesztett meg, hogy belépési címnek 100h-t írtam, de ahogy hangsúlyoztam is, ez az érték nem fix.

"de a mai Windowsok és különösen más operációs rendszerek a .COM-ot már nem támogatják."

Ennek semmi jelentősége. Ha emulálja a PC-t a gépén, akkor olyan mindegy, hogy a host opre mit támogat és mit nem.

Én azért tettem erre javaslatot, mert ezt látom a legcélravezetőbbnek, hogy megismerje a kérdező azt, amit szeretne. Legalábbis véleményem szerint.

A RISC meg úgy van, hogy ott leválogatják a CPU utasításkészletét oly módon, hogy a leggyakrabban használt műveleteket tartalmazza és ezen műveletek ne legyenek komplexek. Ha azok, felbontják őket. Így képesek kialakítani egy olyan architektúrát, amely (majd') minden utasítást egy órajel ciklus alatt lefuttat, azonban ugyanazon tevékenység itt jellemzően több utasítást igényel.

Úgy súlyoznak, hogy a komplex műveletek (szorzás, osztás) lassabbak lesznek (vagy nem is lesznek), de ez a lassúság kifizetődik, mert ezekből a műveletekből kevés van, ritkán használják a programozók. Azonban amit sűrűn használnak, azok lepörögnek egy ciklus alatt.

CISC-nél ezeket a lépéseket benyomják egy utasításba, ezért is lesz a CISC drága és összetett.