Welcome, Guest. Please login or register.


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

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 26.0.1410.64 Chrome 26.0.1410.64
    • View Profile
Re: Assembly programozás
« Reply #450 on: 2013.April.14. 21:37:55 »
Ezzel az OUT 191,12 -vel mekkora sebességnövekedést lehet elérni assembly cucc esetén ?
Z80 System

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 20.0 Firefox 20.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #451 on: 2013.April.14. 21:57:50 »
Quote from: Z80System
Ezzel az OUT 191,12 -vel mekkora sebességnövekedést lehet elérni assembly cucc esetén ?
Függ az utasítások hosszától, rövideknél többet, átlag lehet egy 10-15%

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 26.0.1410.64 Chrome 26.0.1410.64
    • View Profile
Re: Assembly programozás
« Reply #452 on: 2013.April.14. 22:01:05 »
És mi a gubanc vele ? Miért nem kapcsolja be a zozotools, vagy a fejlesztett exos ?
Z80 System

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 20.0 Firefox 20.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #453 on: 2013.April.14. 22:32:45 »
EXOS 2.4-be megszavazta a nép :-D

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 26.0.1410.64 Chrome 26.0.1410.64
    • View Profile
Re: Assembly programozás
« Reply #454 on: 2013.April.27. 10:02:14 »
Ha valakinek az az elborult ötlete támadna, hogy multithread programot ír EP -re, ami ugye technikailag mondjuk azt jelentené, hogy a program bekapcsolna valami nagyobb frekvenciás HW megszakítást, mittudom én egy 500Hz,1KHz,2Khz (vagy tovább felfele) azért legalább kellene, hogy a szálak folyamatosnak tűnjenek a valós időben. Úgy tudom lehet ilyen frekvenciájú megszakításokat bekapcsolni.

Namost a megszakítás azt csinálná, hogy az adott (eppen megszakított) "szál" nyilvántartott memória struktúrájába lementené a regisztertartalmakat, mindent, árnyékot, stack -et, IP -t, és venne egy másik szál struktúrát amiből meg feltöltené a regisztereket, szintén mindet. Természetesen az SP/IP visszatoltéshez valami olyan trükköt alkalmazva, hogy a RETI kiadása előtt valami területre (pld. nulláslap első 100H -ján keresni valami használható helyet) lementene egy kis programocskát, ami feltölti SP -t és ráugrik az új IP -re. Aztán módosítaná a stack -en a megszakítás visszatérési címét ennek a kis programocskának a címére, és a RETI akkor oda "térne vissza", nem oda ahol megszakította az előző szálat, a kis programocskánk meg ugye beleugrana az új (nyilván korábban már megszakított) szálunkba.

Így akkor tehát párhuzamosan futnának a "szálak" olyan időosztással amit a megszakítással megadunk.

A kérdésem az lenne, hogy vajon milyen frekvenciával lennénk képesek ezt a szál váltogatást csinálni, hogy azért pár órajelciklus még a futó szálnak is maradjon, mielőtt jön az új szálváltó megszakítás ? Tehát egy olyan kód, ami összes regisztert lepakolja memóriába, aztan az összeset visszatolti egy másik memóriáról, és kiad még 1-2 utasítást, megfejelve mindezt a megszakítások esetleges késleltetésével (ha van a megszakításkezelésnek valami büntetése), vajon milyen frekivel lehetne ezt pörgetni ? Teszem azt 1KHz -es megszakításnál, mikor ugye egy szál az egy ezredmásodpercig futna, akkor az egy ezredmásodpercnek kb. hány % -a mehetne el fentebb cizellált szál váltó kód futtatására és mennyi maradna a tényleges szál futtatásra ?
« Last Edit: 2013.April.27. 10:11:38 by Z80System »
Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 18.0 Firefox 18.0
    • View Profile
Re: Assembly programozás
« Reply #455 on: 2013.April.27. 10:18:50 »
1 kHz-en valószínűleg legalább 10% (12 16 bites regiszter mentése és visszaállítása, megszakításkezelés, és annak az eldöntése, hogy melyik lesz a következő futtatandó szál).

Offline lgb

  • EP addict
  • *
  • Posts: 3497
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 27.0.1453.65 Chrome 27.0.1453.65
    • View Profile
    • http://lgb.hu/
Re: Assembly programozás
« Reply #456 on: 2013.April.27. 10:22:56 »
Quote from: Z80System
Namost a megszakítás azt csinálná, hogy az adott (eppen megszakított) "szál" nyilvántartott memória struktúrájába lementené a regisztertartalmakat, mindent, árnyékot, stack -et, IP -t, és venne egy másik szál struktúrát amiből meg feltöltené a regisztereket, szintén mindet. Természetesen az SP/IP visszatoltéshez valami olyan trükköt alkalmazva, hogy a RETI kiadása előtt valami területre (pld. nulláslap első 100H -ján keresni valami használható helyet) lementene egy kis programocskát, ami feltölti SP -t és ráugrik az új IP -re. Aztán módosítaná a stack -en a megszakítás visszatérési címét ennek a kis programocskának a címére, és a RETI akkor oda "térne vissza", nem oda ahol megszakította az előző szálat, a kis programocskánk meg ugye beleugrana az új (nyilván korábban már megszakított) szálunkba.

Amit akarsz azt CPU schedulernek hivjak, es altalaban ugye multitask OS-ek fontos resze, es pont igy mukodik :) Ott persze vannak olyan finomsagok, hogy ha egy process "sleep" allapotban van (pl I/O eredmenyere var, vagy a program azt mondja hogy sleep(10) ezert 10 sec-re nem kell futnia, stb) vagy nagyobb prioritast kert, akkor nem feltetlen rr (round-robin) sorrendben, linearisan kapja a cpu time slice-okat.

Amugy a primo emulatoromban is van hasonlo mar :) ha erzekeli hogy megnyomod az F1-et (ez a verzio meg nincs release-elve ...) akkor lementi a regisztereket (az egeszet Int handlerben nezi csinalja) es nem oda ter vissza, igy megkapja az ember a menut, ahol mar CPU allapotat, memoriat is lehet vizsgalni. Es persze vissza lehet terni az emulacio futtatasahoz is. Vegulis ezt is fel lehet ugy fogni, hogy ket program fut parhuzamosan ugymond, csak eppen a valtogatas koztuk user triggerelt es nem automatice :D A gondom csak az vele, hogy neha beall az egesz gep tole, de gyanitom hogy en rontottam el valamit valahol.

Quote
Így akkor tehát párhuzamosan futnának a "szálak" olyan időosztással amit a megszakítással megadunk.

Ja, std time sharing system, amit anno az uts (unix time sharing) kepeben talaltak fel, es megszulettek a multitask OS-ek :)

Quote
A kérdésem az lenne, hogy vajon milyen frekvenciával lennénk képesek ezt a szál váltogatást csinálni, hogy azért pár órajelciklus még a futó szálnak is maradjon, mielőtt jön az új szálváltó megszakítás ? Tehát egy olyan kód, ami összes regisztert lepakolja memóriába, aztan az összeset visszatolti egy másik memóriáról, és kiad még 1-2 utasítást, megfejelve mindezt a megszakítások esetleges késleltetéséhez (ha van a megszakításkezelésnek valami büntetése), vajon milyen frekivel lehetne ezt pörgetni ? Teszem azt 1KHz -es megszakításnál, mikor ugye egy szál az egy ezredmásodpercig futna, akkor az egy ezredmásodpercnek kb. hány % -a mehetne el fentebb cizellált szál váltó kód futtatására és mennyi maradna a tényleges szál futtatásra ?

Az ezredmasodperccel az a gond, hogy gondold el, van overhead-je a context switchingnek (ha mar multitask OS szeru dolog, hasznaljuk a szakkifejezeseket onnan). Ha tul gyakran van, akkor egyre jelentosebb CPU idot visz el ez a muvelet, viszont annal folyamatosabbnak tunik az egyes szalak futasa. Linux eseten is csak std 100Hz volt anno amugy, most epp nem tudom :) meg az ujabb kernelekben mar dynamic tick stb is van (valtozik hogy mikor jon a kov scheduling interrupt attol fuggoen hogy a run queue-ban varakozo processekrol mit tud a kernel - azert is fontos ez mert ha tobb ideig nem kell egy process-nek sem a CPU akkor tovabb lehet halt-ba tenni vagy mas energiatakarekos modba lokni addig a cpu-t, ez pl notebook eseten nagyon durva kulonbsegeket okoz, hogy mennyire jo ebben az adott OS!). Imho egy Z80 eseten se erdemes 100Hz fole menni, felteve ha altalanos OS-t irsz ugymond, nyilvan ha valami specko celra kell, adott korulmenyek kozott, akkor lehet tobb, de a switching overhead-jere szamitani kell!
« Last Edit: 2013.April.27. 10:33:02 by lgb »

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 26.0.1410.64 Chrome 26.0.1410.64
    • View Profile
Re: Assembly programozás
« Reply #457 on: 2013.April.27. 10:25:52 »
Hmmm... olyan területeken ahol a többszálúság önmagában megengedhető, és nem kizárt, akkor talan 10% nem is irdatlan áldozat ... Persze ez azt is mutatja, hogy kb. ez a gyakorlati határ, ha 2KHz -re mennénk, akkor ott már 20% lenne, 5KHz -en akkor 50%, és akkor ezek szerint 10Khz környékén már nem is futna a szálak kódja, csak a szálváltóé ... afelett meg ugye már a szálváltó is elnyelne, kihagyna megszakításokat ...
Z80 System

Offline endi

  • EP addict
  • *
  • Posts: 7305
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Opera 9.80 Opera 9.80
    • View Profile
    • Honlapom
Re: Assembly programozás
« Reply #458 on: 2013.April.27. 10:45:42 »
én a book of life játékomba ilyen x Hz-s digi lejátszást tettem megszakításba
arra emlékszem, hogy regiszter lementéssel kb használhatatlan lassúságú volt, ezért úgy oldottam meg hogy egy olyan regisztert használt amit máshol nem használtam a programban :)
mondjuk ez a hang miatt elég magas freki volt, bár hangminőség tekintetében persze gáz volt
ja meg hogy pont ebbe a játékba miért tettem ilyet, az érthetetlen... pont hogy inkább gyors render kellett volna
Vigyázat! Szektás vagyok! :)

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 26.0.1410.64 Chrome 26.0.1410.64
    • View Profile
Re: Assembly programozás
« Reply #459 on: 2013.April.27. 11:10:04 »
Most nézem, hogy a megszakításkezelő függvényben (C függvény) nem állítottam naked -re a függvényt, vagyis a C generált oda normal RET utasítást a végére, mégis működik a kód ... Miért nem baj az, hogy a megszakítás végén sima RET van, nem pedig RETI ?
Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 18.0 Firefox 18.0
    • View Profile
Re: Assembly programozás
« Reply #460 on: 2013.April.27. 11:14:26 »
Quote from: Z80System
Most nézem, hogy a megszakításkezelő függvényben (C függvény) nem állítottam naked -re a függvényt, vagyis a C generált oda normal RET utasítást a végére, mégis működik a kód ... Miért nem baj az, hogy a megszakítás végén sima RET van, nem pedig RETI ?
EP-n nincs jelentősége, és a RET gyorsabb is. A RETI-nek csak akkor van jelentősége, ha a hardver felsmeri ezt az utasítást, és a megszakításkérés törlésére használja, de EP-n szoftveresen kell törölni a megszakítást a B4h porton.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13531
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 20.0 Firefox 20.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Assembly programozás
« Reply #461 on: 2013.April.27. 11:16:09 »
EP-n (és a legtöbb Z80-as házi számítógépben) teljesen jó a RET is. Akkor kell a RETI, ha rendes Zilog rendszer van kiépítve (SIO, CTC, PIO, DMA), ezek az IC-k észlelik a RETI utasításkódját, és ebből tudják, hogy a megszakításkérésük ki lett szolgálva.

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 26.0.1410.64 Chrome 26.0.1410.64
    • View Profile
Re: Assembly programozás
« Reply #462 on: 2013.April.27. 11:56:13 »
Igy néz ki a megszak kódom:


Code: [Select]
di

push af

ld a,#0x30
out (0xb4),a

ld a,#1
ld (_g_WasIRQ),a

pop af

ei

még néhany utasítás, aztan

ret



Namost a megszak végén ugye megvolt már a b4 port írás, és ei is,
és van pár utasítás még a ret előtt.

Előfordulhat hogy a pár utasítás közben jön újra megszakítás igény, és rászakít a megszakításra ? Vagy azért az összes RET monitorozva van a CPU által, es megszakban egy RET előtt nincs újabb megszak ? Tehát mintegy kötelezővé van téve a CPU által hogy a megszakot valamilyen RET -tel kell zárni, és barmit is mókolok én a megszakokkal a megszakításkezelőben, RET előtt nem lesz újabb megszak ?
Z80 System

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 18.0 Firefox 18.0
    • View Profile
Re: Assembly programozás
« Reply #463 on: 2013.April.27. 12:03:39 »
Quote from: Z80System
Namost a megszak végén ugye megvolt már a b4 port írás, és ei is,
és van pár utasítás még a ret előtt.

Előfordulhat hogy a pár utasítás közben jön újra megszakítás igény, és rászakít a megszakításra ?
Ez nem probléma, feltéve, hogy a megszakítások egymásba ágyazása nem végtelen. A Z80 nem kezeli speciális módon a RET utasítást a rutin végén, a megszakításkezelés ugyanolyan, mint egy egyszerű DI + RST 38H utasítás. Arra is lehetőség van, hogy a B4h port törlése és az EI utasÍtás azonnal a rutin elején történjen, így például egy lassú 50 Hz-es megszakítási rutint megszakíthat egy gyorsabb 1 kHz-es.

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 26.0.1410.64 Chrome 26.0.1410.64
    • View Profile
Re: Assembly programozás
« Reply #464 on: 2013.April.27. 12:15:06 »
Quote
így például egy lassú 50 Hz-es megszakítási rutint megszakíthat egy gyorsabb 1 kHz-es.
Hmmm ... na erre még sosem gondoltam ... a megszakításkezelés innentől kezdve tényleg nem más mint egy szubrutinhívás, ami abban különbözik csak a call -tól, hogy nem általunk meghatározott helyen történik a kódunkban, hanem bárhol, ahol a megszak történik.

Csak az átlagfelhasználása az, hogy megszak kezelés első soraként letiltunk megszakokat, és utolsó soraként meg engedélyezzük őket, aminek a hatása akkor az lesz, hogy ultraminimálisra csokkentjuk az esélyét, hogy még a RET előtt bekövetkezzen egy újabb megszakítás, de igazából MEG NEM SZÜNTETJÜK a lehetőségét, elvileg lehetséges hogy az EI után de még a RET előtt megszakból megszakít újra.

Ebből viszont az is következik, hogy még csak nem is kötelező az előbb említett szál kezelő megszakításból előszor RET -et kiadva valami nulláslap szerű helyre rakott kódra ugrani, a stack megfelelő kezelése mellett akkor a megszakításkezelőből egyből ugorhatunk a kiválasztott új szálra, nem ?
Z80 System