Welcome, Guest. Please login or register.


Author Topic: Assembly programozás (Read 199676 times)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 14083
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #900 on: 2015.May.04. 19:11:29 »
A nem hivatalos utasítás készletben nincs jelen?
Nincs. Újabb (Z80 kompatibilis) prociban sem.

Offline Tuby128

  • EP lover
  • *
  • Posts: 972
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 21.0 Firefox 21.0
    • View Profile
Re: Assembly programozás
« Reply #901 on: 2015.May.04. 21:10:27 »

egyébként milyen környezetbe,rutinba kellene a CALL HL, CALL IX, CALL IY?

valami generál egy HL értéket és azt hívja meg PL.:?


 Tegyünk egy gondolatkirándulást:
 Vegyünk egy multitaszkos OP rendszert, mint a sokat emlegetett SymbOS.
 Mondjuk szeretnék futtatni egyszerre több pici programot, amik csak 300 Byte-osak, de nagyon sokan vannak.
 Mindegyik relatív ugrásokkal bír belül. A karakteres kiíráshoz, vagy bill. bekéréshez pedig az OP rendszert hívja RST rutinnal. Tehát semmi abszolut címzés nincsen benne.

 Ugye ilyenkor betöltöm a lemezről a programokat valahova. Meg a másikat megint máshova, míg a végén van 30 segédprogramom a memóriámban. Minden segédprogram helyét eltároltam egy tömbbe.
 Hogy hívjam meg őket gyorsan, és kapjak visszatérési értéket, ha nincs CALL HL utasításom?

 Természetesen újra hallom Zozo hangját, ahogyan javasolja a JR utasítást. De azért vegyük le a kalapunkat, és valljuk be, ez nem az igazi.

Offline lgb

  • EP addict
  • *
  • Posts: 3555
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://lgb.hu/
Re: Assembly programozás
« Reply #902 on: 2015.May.04. 22:55:38 »
Tegyünk egy gondolatkirándulást:
 Vegyünk egy multitaszkos OP rendszert, mint a sokat emlegetett SymbOS.
 Mondjuk szeretnék futtatni egyszerre több pici programot, amik csak 300 Byte-osak, de nagyon sokan vannak.
 Mindegyik relatív ugrásokkal bír belül. A karakteres kiíráshoz, vagy bill. bekéréshez pedig az OP rendszert hívja RST rutinnal. Tehát semmi abszolut címzés nincsen benne.

 Ugye ilyenkor betöltöm a lemezről a programokat valahova. Meg a másikat megint máshova, míg a végén van 30 segédprogramom a memóriámban. Minden segédprogram helyét eltároltam egy tömbbe.
 Hogy hívjam meg őket gyorsan, és kapjak visszatérési értéket, ha nincs CALL HL utasításom?

 Természetesen újra hallom Zozo hangját, ahogyan javasolja a JR utasítást. De azért vegyük le a kalapunkat, és valljuk be, ez nem az igazi.

Attol fugg. Ha co-operativ multitask akkor onkent lemondanak az idoszeletukrol a process-ek. Ilyen pl a RiscOS. Hatranya, hogy egy "task" siman lezuzza az egeszet, ha ugy dont, hogy o rossz fiu lesz, vagy csak programozasi hiba, es nem adja at a vezerlest. Masik hatrany, hogy ennek tudataban kell irni ala programokat. A preemptive multitask viszont ugy mux, hogy van egy hardware timer, ami eleg surrun (pl masodpercenkent 50-szer) interrupt-ot general. Az interrupt handler fogja, es lementi a regisztereket (a PC is megvan, ha verembol kiveszi hol volt), visszatolti egy masik task elmentett cuccat, es oda ter vissza. Legegyszerubb esetben vmi round-robin szeru "korbe megyunk a task-ok kozott" cuccos. Ezt szokas esetleg megfejelni nemi prioritassal, pl hogy egy adott prioritasu task csak akkor kapja meg a vezerlest, ha egy nagyobb prioritasu nem szeretne szinten futni. Igy mux a SymbOS is pl. Annak felepitese alapvetoen mikrokernel, azaz a kernel (benne az emlitett CPU scheduler, ami csinalja ezt a valtogatast) minimalis, a konkret OS funkciokat is "taskok" latnak el, csak ezek system minositesuek es altalaban magasabb prioritassal rendelkeznek, mint a "user" minositesuek. A masik kernel tipus a monolitkus kernel, ahol a kernel funkciok egyben a kernel reszei.

A lenyeg, nem kell semmi JP izebize ehhez tulsagosan.

Olyannal nem szoktak tokolni, hogy csak relativ cimzes/ugras legyen benne, helyette a betoltheto programokban van egy relokacios tabla, ami alapjan az OS at tudja irni a nem relativ cimzeshez kapcsolodo byte-okat, ami akar adat is lehet (pl egy tablazatban memoriacimek).

Offline Zozosoft

  • EP addict
  • *
  • Posts: 14083
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #903 on: 2015.May.04. 22:58:56 »
a betoltheto programokban van egy relokacios tabla, ami alapjan az OS at tudja irni a nem relativ cimzeshez kapcsolodo byte-okat
Erre egyébként az EXOS-nak van egy elegánsabb megoldása (relokálható fájlformátum).

Offline lgb

  • EP addict
  • *
  • Posts: 3555
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://lgb.hu/
Re: Assembly programozás
« Reply #904 on: 2015.May.04. 23:00:31 »
Erre egyébként az EXOS-nak van egy elegánsabb megoldása (relokálható fájlformátum).

Jah, de ez mar implementacio kerdese, hogyan oldod meg, nem feltetlen tabla stb, a lenyeg, hogy nem kell "kerulni" a nem relativ cuccokat, eleg egy megoldas, hogy ezeket a konkret betoltesnel relokalni lehessen a megfelelo helyre :)

Offline Ferro73

  • EP lover
  • *
  • Posts: 819
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
Re: Assembly programozás
« Reply #905 on: 2015.May.05. 17:21:52 »
Ha jól emlékszem ezeket nem assembler módon oldották meg, még x86-on sem.
A probléma szerintem ott van elásva, hogy míg az x86-nál 16 Bájtos lapok voltak,vannak addig az EP-nél 16384 Bájt.

Mert a kis rutinokat "org 4000h" kezdéssel lehet fordítani és csak be kellene lapozni esetünkben az 1. lapra.
Mint ahogy használja is a 3. lapon az ~össze ROM C000h indítási, fordítási ponttal.
Csak a rutinok 16384 Bájt helyet foglalnak nem pedig 300 Bájtot.

Offline lgb

  • EP addict
  • *
  • Posts: 3555
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://lgb.hu/
Re: Assembly programozás
« Reply #906 on: 2015.May.05. 21:17:49 »
Ha jól emlékszem ezeket nem assembler módon oldották meg, még x86-on sem.
A probléma szerintem ott van elásva, hogy míg az x86-nál 16 Bájtos lapok voltak,vannak addig az EP-nél 16384 Bájt.

Mert a kis rutinokat "org 4000h" kezdéssel lehet fordítani és csak be kellene lapozni esetünkben az 1. lapra.
Mint ahogy használja is a 3. lapon az ~össze ROM C000h indítási, fordítási ponttal.
Csak a rutinok 16384 Bájt helyet foglalnak nem pedig 300 Bájtot.

Kulonbozo dolgokrol beszelunk. x86-oson (legyen most 8088 az egyszeruseg kedveert, 80286, majd 386-on stb mar egeszen meg van ez kutyulva protected moban) egy "lap" (inkabb szegmensnek hivjak) mindig 64K, az a 16 byte az, hogy minden 16. byte-on kezdodik egy voltakepp. Azaz a fizikai cim egyenlo a szegmens cim szorozva 16-al (azaz balra shift-elve 4-szer, ugyanaz) plusz az offset. 8088 egy darab (64K meretu) szegmenst kepes latni, igaz kulon kodra, adata, veremre, illetve egy extra celra (persze allithato mindegyik uarra). EP-n ugye a 16K-s szegmensekbol lehet 4-et belapozni a Z80 cimtartomanyaba, es nem fugg attol aztan, hogy a hozzaferes celja mi (kod/adat/verem/stb). 286-ostol kezdve egy szegmens merete nem feltetlen fix, hanem 64K-nal kisebb is lehet, es hw szintu hozzaferes korlatozas is van (ie "biztonsagos" oprendszerhez), itt a szegmensek mar 16Mbyte-ban kevereghetnek, es a szegmensregiszterek un szelektorokat tartalmaznak, ami a GDT vagy LDT-ben (globalis/lokalis deszkriptortabla) irja le a szegmenseket. 386 es folotte a szegmensmeret alapjat byte-tol lapra (4K) lehet modositani, igy egy szegmens nagyobb lehet, mint 64K mar, es 32 bites cimzessel persze ezt ki is lehet hasznalni. Hozzatennem, hogy valojaban modern OS-ek nem igazan hasznaljak tul sok mindenre a szegmentalasi modelt, helyette az un lapozas technikat alkalmazzak (ez nem uaz a lap mint a fenti lap, meg a szegmentalas, itt fix meretu 4K-s lapok vannak, meg laptablak, de ebbe ne menjunk bele itt szerintem), ami csak 386-os ota van x86-ban. Mas ISA-kon meg mas dolgok is elfordulnak persze, nem csak x86 letezik.

Szoval x86-oson nem "16 byte-os lapok vannak" :) Max real modban a szegmensek kezdetehez van koze annak a bizonyos 16 byte-nak. Valoban, ha egy "primitiv" OS-t veszel (nem multitask, miegymas) akkor elonyos az x86, lassuk pl a CP/M-bol orokolt stuffokat a DOS-ban: a programok a 100h cimre toltodnek be stb. Remek, mondhatni, mert egy 64K-s szegmens "belulrol" offset szinten "ugyanaz" fuggetlenul attol, hogy a szegmens hol kezdodik, es "majdnem" barhol kezdodhet, max 15 byte memoriat pazarolunk el. Az adott szegmensen belul pedig a 100h mindig 100h, az hogy a fizikai memoriaban ez hol van, az mas kerdes.

Node, amit szerintem te keversz, hogy "hogyan oldottak meg". Tuby128 modern, multitask peldat hozott fel, azt meg relokalni szoktak x86-oson is persze. Ha erdekel megmutatom hogy kell, Linux alatt kozvetlenul assembly-ben is dolgoztam sokaig anno. Az nyilvanvalo viszont, ha nem modern peldat veszel, akkor mas az abra. 8088-on nehez "modern" peldat venni, de Z80/EP-re pl ott a SymbOS. Nyilvan relokalni kell, ha nem akarsz elveszteni egy egesz 16K-s teruletet mert "fix" ertekekkel dolgozol. Ahogy irtam, modernebb x86-osokon is reloaklnak termeszetesen, sot nem is igazan hasznalnak szegmenseket, mert minek: megnehezitik azt, hogy a process-ek (megfelelo engedely birtokaban) pl IPC-t csinaljanak (InterProcess Communication) stb.

Masreszt ezt nem "assemblerben" szoktak megoldani, hanem az adott toolchain object file formatuma hordozza az osszes szukseges infot ami segitsegevel a linker ebbol valamit eloallit. Ami adott esetben lehet PIC (Position Independent Code) jellegu kod is akar. Tehat nem neked kell gondoskodni feltetlen, a relokaciorol, azt majd az OS megteszi. Ehhez persze vmi info kell neki az igaz,

EXOS-nal nyilvan alapvetoen szinte alomnak tunt a 4Mbyte cimtartomany, nem hinnem hogy azon aggodtak volna, hogy pazarolunk-e egy lapot ROM-ra akkor is ha csak 300 byte kell neki abbol, stb. De amugy ha mar itt tartunk, ahogy Zozo is emlitette, van am EXOS-ban is ilyesmi, hogy relokacio, ha jol remlik a "relocatable system extension" ami talan a 7-es (?) tipusu az exos file header szerint. Szoval meg csak SymbOS-re sincs feltetlen szukseg, mint "modern" pelda :)

No, remelem igy ertheto.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 14083
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #907 on: 2015.May.05. 21:37:34 »
nem hinnem hogy azon aggodtak volna, hogy pazarolunk-e egy lapot ROM-ra akkor is ha csak 300 byte kell neki abbol,
ROM-nál nem, de RAM-nál igen, erre szolgál az említett 7-es fejlécű áthelyezhető rendszerbővítő, ill (a fájl formátum szinten azonos) 2-es fejlécű felhasználói áthelyezhető modul, amit pl. betölthető a BASIC bővítések használnak.

Offline Tuby128

  • EP lover
  • *
  • Posts: 972
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 21.0 Firefox 21.0
    • View Profile
Re: Assembly programozás
« Reply #908 on: 2015.May.05. 21:41:49 »
Na de mit csinál? Átír minden JP és CALL utasítás után található számot?

Offline Zozosoft

  • EP addict
  • *
  • Posts: 14083
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #909 on: 2015.May.05. 21:50:26 »
Na de mit csinál? Átír minden JP és CALL utasítás után található számot?
Így is lehet mondani... lényegében igen, de nem csak ilyen utasításoknál lehet áthelyezhető cím.

"Amikor a rendszer egy abszolút byte betöltése tételt talál, akkor a soron következő 8 bitet tárolja a címszámláló aktuális címére, és e számláló tartalmát megnöveli eggyel. Amikor egy áthelyezhető szó betöltése tételt talál, akkor beolvassa a soron következő 16 bitet és az aktuális címszámláló tartalmát ezekhez hozzáadja. Az eredményül kapott szót - először az alsó byte-ot beírva - tárolja a címszámláló címére, majd a címszámláló tartalmát megnöveli kettővel."

Offline Tuby128

  • EP lover
  • *
  • Posts: 972
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 21.0 Firefox 21.0
    • View Profile
Re: Assembly programozás
« Reply #910 on: 2015.May.05. 21:58:32 »
És hogyan tesz különbséget data és program közt. Hisz datacsomagban is lehet ugrásnak vagy hozzáférésnek látszódó kód. Hogy nem keveredik meg, ha van egy kis "lyuk" két végrehajtandó rutin közt?

Offline Zozosoft

  • EP addict
  • *
  • Posts: 14083
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #911 on: 2015.May.05. 22:02:48 »

Offline lgb

  • EP addict
  • *
  • Posts: 3555
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
    • http://lgb.hu/
Re: Assembly programozás
« Reply #912 on: 2015.May.05. 22:15:38 »
Eltekintve most az EXOS (amugy ugyes) hasonlo formatumatol, "hazilag" amator modon pl lehet csinalni ilyet ugy, hogy leforditjuk az asm projectunket org X-szel, majd org Y-al. Ahol az eredmeny elter, ott nyilvan arrol van szo, hogy pozicio fuggo kod/adat akarmi van. Ha az X egyenesen nulla volt, akkor eleg tarolni azt, es megjegyezni hol kulonbozott a masiktol es hozzaadni annyit, ahova relokalni akarod. Ez persze tulegyszerusitett pelda, es gyakorlatban akkor jo, ha 256 byte-os hataron akarod tartani a cuccost, kulonben kell kulon low/hi byte-kkal is esetleg foglalkozni, stb. Ez persze az "amator" megoldas, fejlettebb assembler-ek tudnak olyan output-ot eleve ami hordot ilyen informaciot, aztan a linker dolga ebbol vmit gyakrtani, ami persze szinten lehet vmi relokalhato formatum persze! Viszont a fenti pelda mutatja, hogy nem kell tul nagy varazslat ide, ha a legegyszerubb esetbol indulunk ki legalabbis :)

Offline Ferro73

  • EP lover
  • *
  • Posts: 819
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
Re: Assembly programozás
« Reply #913 on: 2015.May.07. 17:23:47 »
Házilag is egyszerű csak külön értelmezöt kell készíteni.
Az EXOS "7" fejléce? akár az ASMON tud ilyet készíteni.
Csináltam is ilyet mégpedig ha jól emlékszem valami ":color"
bővítményt alakítottam át mert a program nemvolt több mint pár száz bájt de egy teljes szegmenst (16536 bájt) lefoglalt.
Akkor még nem értettem ezekhez a csomagokhoz de mennél több programot értelmeztem annál egyszerűbbnek tűnnek.
Egyébként meg egyszerűbb megoldás is van ha csak 300 bájtos rutinokat gyártanál.
Elemez PL. a fájl tömörítőt. ".DTF" ???

Offline Ferro73

  • EP lover
  • *
  • Posts: 819
  • Country: hu
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 37.0 Firefox 37.0
    • View Profile
Re: Assembly programozás
« Reply #914 on: 2015.May.09. 07:30:15 »
Na de mit csinál? Átír minden JP és CALL utasítás után található számot?

De nem csak ezeknél még az esetleg "LD HL,xxxx" és társai használatakor is.

Én úgy csinálnám a pogikat, hogy lefordítanám "ORG 0000h" majd azokat az utasítás címeket amelyeket módosítani kell egy táblázatba tenném és a *.bin elejére tenném.
Így betöltés után módosítom azokat amiket kell, szimplán hozzá adva a program kezdőcímét.
És végül másolom a módosított programot a kiválasztott kezdőcímre.