Hogyan programozhatsz gépi kódban?

Okos tojás. Ha van egy 16 bites procid, minden regisztere 16 bites, hogy a bánatos p.-ba írsz le egy 20 bites címet? Nincs 20 bites regiszter, az ALU-ja (és a cím számítást az ALU végzi) 16 bites. Minden az utolsó csavarig 16 bites benne. Mégis van egy 20 bites címbusz, és 20 bites címekkel dolgozik. Áruld már el azt a módszert, hogy hogyan lesz egy 16 bites regiszterből 20 bit, hogy ki tud számolni azt, hogy melyik bitet akarod olvasni a memóriából? Akin látszik, hogy semmit nem ért hozzá az pont te vagy, már az első védett módú hozzászólásodból is látszik, hogy csak 100km-es távolságból láttál procit.

A plain bináris amit írtál az nagyon jó de az normális helyen nem futtatható. Mivel a PC világ minden csak nem normális így valami idióta kitalálta, hogy a plain binárist futtathatóvá kell tenni. Meg úgyanígy egy dokumentumban is legyen futtatható részek. Ezzel megágyazva annak, hogy lehet vírust írni (erről most ne nyissunk vitát, van egy marék védett módban is szépen terjedő vírus).

Képzeld ismerem az intel hex-et használom is, éppen most tölttem be az asztalomon lévő mikrokontrollerbe. Alapvetően a fordító programok igen jelentős része azt állítja elő, és pl. a programozó készülék, illetve az itt nálam lévő cucc firmware-je azt képes betölteni a memóriába és onnan lefuttatni. Az, meg, hogy egy futtatható bináris milyen formában van kiírva fájlba az meg totál csak és kizárólag oprendszer/firmware függvénye. Akárhogy kódolhatom a bináris futtatható amikor kiírom fájlba, az attól még bináris futtatható marad nem lesz belőle pucér csajt ábrázoló kép. Még egyszer sehol a világon (leszámítva a már sehol nem használt régi 8 bites rendszereket és ugye talán pont te szóltad le valamelyik hozzászólót a Z80 említésével) nem használnak ma már fejlesztésben - normális célra - plain binárist futtatható dolgok tárolására, mert nem alkalmas rá. A többit meg elképesztő mértékig kevered.

Lehet, hogy nehéz elfogadni de beágyazott rendszer fejlesztő vagyok. Ha hülye lennék hozzá nem lenne munkám. És ágyaztam már be 386-ost, meg egyszer az egyik főnököm ámokfutása miatt megkíséreltük egy i7 köré építeni célhardvert. Végül a józan ész és a jobban kézben tartható ARM proci győzött. De elég sokáig jutottunk a projektben. Szerintem azon kevesek közé tartozom aki programoztam 0-ról i7-et. (nyilván egy csomó minden megvolt a fejlesztő rendszerben hozzá), végül meggyőztem a főnököt, hogy ez nem jó irány, túl sok munka és nem várható eredmény. Te programoztál már natívan i7-est?

"Ha van egy 16 bites procid, minden regisztere 16 bites, hogy a bánatos p.-ba írsz le egy 20 bites címet? Nincs 20 bites regiszter, az ALU-ja (és a cím számítást az ALU végzi) 16 bit"

Szégyen amit itt műveltek. A tudatlanságotok égbekiáltó.

Félrevezettek jószándékú kérdezőket. Nem kéne ezt csinálnotok.

De azért válaszolok, hogy legalább a tévedéseitek száma csökkenjen:

A z80-as processzor meg csak 8 bites nem 16. Na, az vajon hogy képes 64 kB memóriát megcímezni?

Mert a 64 kB megcímzéséhez 16 címvonal szükséges, ugye.

Az x86-osok címszámítását nem az ALU, hanem az MMU végzi.

Ha egy proci 16 bites, az adatbuszt jelent. De nem címbuszt. A kettőnek köze nincs ahhoz, amit te gondolsz, képzelsz.

A proci 40 lábas, tehát látható hogy a 16 bites adat és a 20 bit címbusz helyből 36 lábat lefoglalna, és még meg sincs táplálva (plusz 5 V és GND) a CPU.

Ezért a buszok multiplexelve vannak rajta és emiatt van a szegmentált memória szervezés is.

Kérdező: Ennek egy szavát ne hidd el. Nem épített ez semmit.

Nem i7-et nem programozott soha, de még egy nyomorult prómszám generátort sem lenne képes asm-ben megírni.

Nem viccelek, ez az igazság.

Nem tudja mi az az intel hex formátum, azt állítja, hogy a plain bináris nem futtatható, de azzá tették. Ezek égbe kiáltó hülyeségek. Hazugságok.

Itt írok az intel hex-ről. Lap alján. Ha érdekel.

[link]

Kedves nagyon ostoba válaszadó. És ezzel befejezem mert nagyon eltértünk a tárgytól.

Vegyük a Z80-at. Az egy 8 bites proci, de rengeteg! helyen képes 16 bitesként működni, megvannak benne a 16 bites műveletek. Ezek az ún. regiszter párok. Ugyanígy az utasítás számláló (PC) 16 bites. Az adatbusz 8 bites, a címbusz 16 bites. Tiszta eddig? Számtalan 16 bites művelete van, vannak utasítása amelyek regiszterpárt tudnak címzésre használni, így a teljes 16 bites memória terület kicímezhető.

Nézzük a 8086-8088-at, az programozás szempontjából totálisan mindegy, hogy hogyan van multiplexálva a busz (tényleg mindegy). Ami számít, hogy belül minden téren 16 bites. Az utasítás számláló (PC v. IP ki hogy nevezi), a stack pointer minden belső regisztere 16 bites. Mégis 20 bites az adatbusza.

"Az x86-osok címszámítását nem az ALU, hanem az MMU végzi.

Ha egy proci 16 bites, az adatbuszt jelent. De nem címbuszt. A kettőnek köze nincs ahhoz, amit te gondolsz, képzelsz. A proci 40 lábas, tehát látható hogy a 16 bites adat és a 20 bit címbusz helyből 36 lábat lefoglalna, és még meg sincs táplálva (plusz 5 V és GND) a CPU. Ezért a buszok multiplexelve vannak rajta és emiatt van a szegmentált memória szervezés is."

Ezt írod. Ez égbekiáltó ökörség, és a te egyetlen szavadat sem szabad elhinni. Semmi köze annak, hogy hogyan van szegmentálva a memória ahhoz, hogy hány kivezetése van a procinak.

Az ALU-nak részt kell vennie a címszámításban. Ha nem az utasítás számításban, akkor az indexelt címzésben. Ki kell tudni számolni, egy adat helyét egy tömbben, ha az a tömb a memóriában van. Na most legyél okos de nagyon édes pici burgonyám (ahogy te írtad korábban). 16 bites minden regiszter, ezek szerint egy tömb max. 64kByte lehet? Hát nem. És pl. a Z80-nál azért lehetett könnyen dolgozni 64kByte-os memóriával mert rengeteg 16 bites utasítása volt, és a tömb index számítást el lehetett végezni a 16 bites utasításokkal, és 8 bites környezetben simán lehetett kezelni a 16 bites címteret. Ugyanez a 8086/88 világban kicsit összetetebb mert nincs 16 bitesnél nagyobb utasítása és nincs 16 bitesnél nagyobb ALU-ja (sem). Ezért kellett bevezetni a szegmentálást, hogy valahogy egy 16 bites környezetben lehessen kezelni 20 bites címeket. A cím egyrésze jön a szegmens regiszterekből és egy része a "címzésből" (ennek vannak előnyei, hátrányai).

A többi sértegetést nem veszem magamra. Azokra az emberekre jellemző ez a totális vagdalózás akik ténylegesen nem értenek semmihez, és kiragadnak egy két gondolatot.

"Kérlek!

Áruld el nekem, miért szóltok hozzá olyasmihez, amihez lövésetek nincs, csak innen-onnan összeolvasgatott, rosszul értelmezett butaságok tömkelege? Mire jó ez?"

Konkrétan jelöld meg mi az ami nem igaz abból amit írtam? Telejsen konkrétan, lehjetőleg releváns hivatkozással. Nem olyan oldalakról amit olyanok írtak akik csak messziről láttak procit. Ami dokumentumból konkértan hivatkoztam az Intel által kiadott kézikönyv magáról a processzorról. Ennél szerintem kevés autentikusabb forrás létezik. Aki meg teljesen fogalmatlan az te vagy mert de dobálsz olyan fogalmakat amikről ténylegesen lövésed sincs.

"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."

Ezt ha egy magyar tanár látná már sírva fakadna. A kolléga valahol már kifejtette mit is jelent a prefetch. Innen látszik, hogy te vagy az aki össze vissza hadoválsz mindent. Ha egy nagyon pici agyad lenne akkor tudnád, hogy a "pre" előtag az annyit jelent "elő" "előre" tehát a prefetch csak és kizárólag valami előolvasás (féle) lehet. Már csak ha a szóból indulok ki. Már innen látszik, hogy semmit az égvilágonnem értesz a processzor működéséből és a prefetch algoritmusból sem. Innen kezdve egészen biztosan teljesen hiteltelen amit írsz.

"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."

Ezt te érted, hogy mi az amit ide írtál? Mi köze az oprendszernek a processzor címkezeléséhez? A szegmens:ofszet kezelést (és ha a szegmenst "sz"-el írod akkor az ofszetet is "sz"-el kéne írni okostojás) a processzor végzi és ennyi. A DOS meg egy operációs rendszer.

Következő okosságod:

"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."

Hol volt arról szó, hogy bármit is emulálni kéne? A kolléga leírta, hogy a COM-ot a mai Windowsok már nem támogatják. És az, hogy különböző trükkökkel lehet COM-ot futtatni az megint egy másik kérdés kör. De önmagában a windows már nem támogatja. Elképszető ostobaságot írtál itt is.

"Az x86-osok címszámítását nem az ALU, hanem az MMU végzi.

Ha egy proci 16 bites, az adatbuszt jelent. De nem címbuszt. A kettőnek köze nincs ahhoz, amit te gondolsz, képzelsz."

Ezt részben már kifejtettem. De hol látsz te egy 8086-os prociban MMU-t (ha már DOS-ról beszélsz, akkor nézzük a 8086/88-as procit). Előttem van (sajnos csak papiron) a 8086-os proci gyári könyve (igen elővettem, de nem tudom miért vitatkozom ilyen ostoba emberrel). Ebben szerepel EU (execution unit), BIU (Bus interface unit), ALU. MMU nincs benne. Ugyanígy a kolléga által hivatkozott hivatalos Intel kézikönyv (Intel® 64 and IA-32 Architectures

Software Developer’s Manual) letölthető a netről, és nincs benne az a rövidítés, hogy MMU, tehát nincs MMU-ja a processzornak. Kár, hogy ilyen egyszerűen ellenőrizhető dologban is hazudsz.

"Ahogy nőt a memória egyre nagyobb igény volt arra, hogy a program ne mindig ugyanoda kerüljön"

Ezen jót nevettem.

Nem a memória mérete, hanem elsősorban a multitaszk miatt - tehát hogy egy időben több program futhasson - vált szükségessé a plain bináris formátum mellett egy olyan, amelyet a memória bármely részébe be lehet tölteni."

Édes térdzoknim. Érted amit böfögsz, vagy jönnek ki összefüggéstelen dolgok a szádon? Megint az állitásodban vannak igazságok, de az ok-okozat /kérdés-válasz/ között nincs logikai kapcsolat. Szakadjunk el attól, hogy nem értesz hozzá. Már jóval a multitaszk előtt igény volt arra, hogy ne mindig ugyanoda oda töltsük a programot. Pl. az XT 3.0-s DOS operációs rendszere nem tudott multitaskot, mégis volt EXE fájlja! Sőt a COM-ot se mindig ugyanoda töltötte be a memóriába, csak annyit tett, hogy ahova betöltötte annak megfeleleőn beállított a szegmens regisztereket. Az elméleted már itt bukás (megint egy rendkívül könnyen ellenőrizhető dologban hazudsz).

"Az eltérés kulcsa ugyanis a méret, na meg az a tény, hogy ezek a file-ok (mz .exe, pe .exe, .elf, .coff, stb) elkivánnak a futásukhoz sok memóriát és sok szegmenst. Tudod burgonya, bár még nem hallottál erről, de létezik ám olyan a PC-kben, hogy SS, DS, CS, ES regiszter."

Miért is igényli pl. egy "Hello, World!" program a sok szegmenst és a sok memóriát? Azt nem lehet ezek szerint megrni exe-ben? Akkor mibe írjam meg? Nagyon okos tojás. A többire nem reagálok.

Elolvastam az agymenésedet a linkelt oldalon. Bocs, hogy onnan hivatkozok, de ha tényleg te írtad akkor nagy baj van a fejecskédben:

"Valamikor régen, az INTEL cég kidolgozott emiatt a probléma miatt egy formátumot. Ez a formátum a hangzatos INTEL HEX nevet viseli. A lényege, hogy bináris adatállományokat lehet tárolni, vagy továbbítani úgy, mintha azok szövegesek lennének."

Te magad írtad le, hogy az Intel HEX bináris adat tárolására való. Hol írtam bármi mást? Már annyira ostoba vagy, hogy magadnak mondasz ellent. Pont ezt írtuk le, hogy Intel HEX formátumban lehet bináris (akár az általad plain binárisnak nevezett agymenés) fájlt tárolni, azt be lehet egyszerűen olvasni a memóriába. És mit olvasok a honlapodon ugyanezt. Na erre varjál gombot. Ennyire ostoba emberek csak az amerikai filmekben vannak. Amúgy a honlapodon az értelmetlen fogalmazásokat javítsad ki, mert sok helyen olvashatatlan a szöveg annyira béna a fogalmazás. Ennél még a google fordító is jobban fordít.

"16 bites minden regiszter, ezek szerint egy tömb max. 64kByte lehet? Hát nem."

Hát de. Ha megnézed az x86 lábkiosztását, fel fog tűnni, hogy nem a0..a16 és d0..d16 van a lábakon, hanem AD0..AD16, tehát a cím és az adatbusz multiplexált, közös. De csak 16 bitig. A másik 4 bit ami lemarat a 20-ból, ott figyel tisztán a17..a20 formájában.

A címgenerálás meg úgy néz ki, hogy ott a 16 címbit, ezt 16-tal (10h) felszorzod (eltolás éppen 4 bittel. Figyelsz???) majd hozzáadod a többi négy (jé! Itt is négy! Figyelsz???) címbit tartalmát. Így jön ki a 20 bites cím.

Az ALU kussol, a szegmens regisztereket a Sín illesztő egység (BIU) kezeli.

Amiről te beszélsz, (tömb index, stb) ahhoz ott vannak az index regiszterek.

"a Z80-nál azért lehetett könnyen dolgozni 64kByte-os memóriával mert rengeteg 16 bites utasítása volt,"

*felsóhajt* A z80-nak 16 bites REGISZTEREI voltak (és vannak) nem utasításai. Persze csak néhány regiszter, nem az összes.

Annál is inkább, mert az ALU-ja csak 4 (igen, négy) bites.

"A kolléga valahol már kifejtette mit is jelent a prefetch."

Igen, ebben kivételesen igaza volt, de ti ezen ugráltok, hogy a prefetch után nem fetch-et írtam. Ez az egész muníciótok, semmi más.

"Ezt te érted, hogy mi az amit ide írtál? Mi köze az oprendszernek a processzor címkezeléséhez? "

Hát nagyon sok. Igaz, ez inkább védett módban csúcsosodik ki. Tudod, paging, descriptor táblák, stb, stb. Azt, hogy a lapozás (védett mód) milyen szegmensekben történik (4k, 4M) azt bizony az OPRE határozza meg. De ezt hagyjuk is. Éppen ezek megismerésétől féltem a kérdezőt, most még.

"Miért is igényli pl. egy "Hello, World!" program a sok szegmenst és a sok memóriát? Azt nem lehet ezek szerint megrni exe-ben? "

Egy hello world nem igényli, de a programozók nem csak hello worldot írnak. Attól, hogy vannak progik amelyek kisebbek, pár tíz kB-osak, még van igény nagyobb, memóriaigényesebb porgikra is.

" Pl. az XT 3.0-s DOS operációs rendszere nem tudott multitaskot, mégis volt EXE fájlja!"

Az lehet, de volt 640kB (vagy akár 1 MB) memóriája és monotaszkos volt. Ezért volt szükség az .exe megalkotására. Tudod, hülyén nézett volna ki ennyi memóriával egy olyan gép, amely csak plain binárist (tudod, amiről te eddig nem hallottál) tudott volna futtatni, max. 64k-ban.

"Hol volt arról szó, hogy bármit is emulálni kéne?"

Én írtam a kérdezőnek, hogy futtasson egy emulátort, vagy DOSboxot. Ebben az emulátorban, DOSboxban létrehozhat akár a DOS debugja segítségével bináris (com) állományokat, amelyeket futtathat is, biztonságosan, mert max. az emulátor áll fejre, de nem lesz a gépének semmi baja. Egy kezdőnek ez a legjobb alternatíva, szerintem.

"A kolléga leírta, hogy a COM-ot a mai Windowsok már nem támogatják."

De ez kit érdekel? Az emulátor vagy a DOSbox támogatja, futtatja.

Na csá..

"Te magad írtad le, hogy az Intel HEX bináris adat tárolására való. Hol írtam bármi mást?"

Te azt írtad, hogy futtatható az intel hex. Kérkedtél vele, hogy ezt is ismered. Csak felsültél. Most meg szemétkedsz.

Én ugyanis ezt írtam:

"A lényege, hogy bináris adatállományokat lehet tárolni, vagy továbbítani úgy, mintha azok szövegesek lennének."

A hangsúly ezen van: ÚGY mintha szövegesek lennének. Mert hát, abban a formájukban azok is.

"Amúgy a honlapodon az értelmetlen fogalmazásokat javítsad ki"

Az a rész megvolt ott a lap tetején, hogy (az oldal fejlesztés alatt.)? :o( Nem volt meg.

Javítás:

"a0..a15 és d0..d15 van a lábakon, hanem AD0..AD15, tehát a cím és az adatbusz multiplexált, közös. De csak 16 bitig. A másik 4 bit ami lemarat a 20-ból, ott figyel tisztán a16..a19 formájában.

"*felsóhajt* A z80-nak 16 bites REGISZTEREI voltak (és vannak) nem utasításai. Persze csak néhány regiszter, nem az összes.

Annál is inkább, mert az ALU-ja csak 4 (igen, négy) bites."

Megint egy könnyen ellenőrizhető hazugságod van. És ez megint bárki által fél másodperc alatt bizonyítható.

Z80 kézikönyv. Utasítás készlet fejezet főcímei között mit látunk:

"16-bit load group"

"16-bit Arithmetic group"

Lehet, hogy teljesen hülyének nézel, de olvasni megtanultam, és elővettem a megfelelő kézikönyvet, amiben megint ott van, hogy ismét hazudsz, és olyat állítasz ami már a gyártó szerint sem igaz.

"LD dd,nn" utasítás leírása: The 2-byte integer nn is loaded to the dd register pair, where dd defines the

BC, DE, HL, or SP register pairs" A 2-byte tegnap még 16 bit volt, de lehet,hogy kialakulóban van egy térdzokni nevezék tan ahol a két byte 8 bit...

Ha ez nem 16 bites utasítás akkor mi az?

De menjünk tovább (és én 16 bites aritmetikáról is beszéltem) és láss csodát, mit ír a Z80 processzor kézikönyve:

"ADD HL,ss" 16 bites aritmetikai utasítás (ő is így hivja nem én találtam ki, nézd meg a kézikönyvet, kb. két tucat helyről letölthető a netről):

"The contents of register pair ss (any of register pairs BC, DE, HL, or SP)

are added to the contents of register pair HL and the result is stored in HL." Majd kicsit lejebb a példa:

"If register pair HL contains the integer 4242H, and register pair DE contains

1111H, at execution of ADD HL, DE the HL register pair contains 5353H."

Lehet, hogy én vagyok megint tudatlan, de a 4242H szerintem egy 16 bites szám (jó csak 15 mert a legmagasabb helyiértéken véletlünl 0 van). Tehát ez a Z80 gyártója szerint is egy 16 bites utasítás.

És tudod már általános iskolában megtanultuk, ha egy kijelentésre legalább 1 cáfolat található akkor az hazugság (és itt eddig 2 konkrét példát hoztam, hogy miért hazugság amit leírsz). Ez alapján aki itt nem ért ahhoz amiről beszél nem Én vagyok, hanem Te. MErt eddig már legalább 4 tételes bizonyítékot felmutattam, hogy miben tévedsz, alátámasztva megfelleő hivatkozással. Te eddig egyetlen egy tételes bizonyítékot nem tudtál mutatni.

Következő ugyanezen kijelentés második része (előbb már bemásoltam, de megismétlem):

"...Annál is inkább, mert az ALU-ja csak 4 (igen, négy) bites."

Szintén a Z80 gyári kézikönyv fejezete:

"Arithmetic Logic Unit (ALU)

The 8-bit arithmetic and logical instructions of the CPU are executed in the ALU. Internally, the ALU communicates with the registers and the external data bus by using the internal data bus. Functions performed by the ALU include:"

Én itt az első mondatban 8-as (nyolcas) számot látok és nem 4-est ahogy te olvastad. Valószínűleg alapvető szövegértési (de inkább számértési) problémáid is vannak.

De lehet, hogy csak simán 2-vel osztasz mindent ha az úgy jó neked.

A többi agymenésedről,hogy mi köze a külső busz multiplexálásnak a processzor belső működéséhez arról már nem fogok vitát nyitni. Mert ott is látszik, hogy égtelen ökörségeket beszélsz. Kicsit sokáig tartana minden egyes hazugságodat kikeresni a megfelelő szakirodalomból (amit mint láthatód már pár helyen elvégeztem és bemutttam, hogy eddig legalább 4 hazugságod volt itt).