OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů

Zptky do minulosti!

Právě je 09.03.2021, 12:37

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 87 ]  Přejít na stránku Předchozí  1, 2, 3, 4, 5, 6
Autor Zpráva
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 03.01.2021, 21:25 
Offline
Pan Generální

Registrován: 22.05.2013, 21:14
Příspěvky: 3015
Bydliště: Bratislava
Has thanked: 308 times
Been thanked: 578 times
Lisiak4 píše:
Má vlastně posunutí adresy v paměti o 4 bity zásadní využití? Já fakt nedělám na žádném 1KB intru :)
Ale ked uz ten asembler vies a poznas system, mohol by si :poke:
Aspon nieco jednoduche ;)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 03.01.2021, 21:58 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 13.05.2013, 09:15
Příspěvky: 1953
Bydliště: Brno
Has thanked: 523 times
Been thanked: 174 times
No jo :) Programuji nesystémově. Dost jsem se zdržel tou specifickou části programu, co pracuje s jemným časováním v mé hudební rutině. S tím ale opravdu finišuji. Přemýšlel jsem, že bych hodil něco jednoduchého do mého formátu, prásknul obrázek a hotovo, ale to by bylo jen další zdržení toho, co má pro mne větší význam. Já teď hlavně chci dokončit to s čím finišuji a uvidím :)

_________________
Amiga - PMD 85
Kafasoft


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 08.01.2021, 02:10 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 13.05.2013, 09:15
Příspěvky: 1953
Bydliště: Brno
Has thanked: 523 times
Been thanked: 174 times
Tak jsem nakonec použil SUBQ.L #4, A0. S ADD jsem se do toho moc zamotal v rámci logiky. Opět jsem moudřejší.

_________________
Amiga - PMD 85
Kafasoft


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 11.01.2021, 14:16 
Offline
Stydlín

Registrován: 11.01.2021, 11:47
Příspěvky: 9
Has thanked: 0 time
Been thanked: 11 times
Ahoj. Jen pár nepodstatných komentářů.
Ve tvém psaní se často uvádí něco jako "zvýšit o 4 bity", "posunutí o 4 bity" apod. Mám v tom zmatek. Jedná se o překlep a mají tam být "4 bajty"? Ne, že by "posunutí o 4 bity" nešlo, ale význam je zcela odlišný.
Ohledně rozhodování, jaké instrukce použít při řešení problému: Na základní 68k CPU jsou pravidla jednoduchá, triviální: Použít takové instrukce, jejichž počet taktů k provedení je v součtu vždy minimální :-) U CPU 020 se to komplikuje kvůli instrukční cache a u 030+ ještě víc kvůli datové cache.
Když si nejsem s časováním jistý, tak vždy nakouknu do tabulky a seznamu
http://oldwww.nvg.ntnu.no/amiga/MC680x0 ... iming.HTML
Z tabulky pak dobře vyplývají určité zvláštnosti a techniky, které rozumný programátor na 68k používá.
Například je všeobecně známé, že když to jde, používáme MOVEQ místo MOVE nebo CLR. MOVEQ ale umí nastavit jen signed 8bit hodnotu a vždy ji rozšíří na celý rozsah 32 bitů. Takže ne vždy jde použít. Pokud se přičítá nebo odečítá jen malé číslo v rozsahu čtyř bitů, použije se ADDQ nebo SUBQ. U datových registrů se dá volit, jestli je operace jen nad 16 nebo celými 32 bity registru (addq.w/addq.l).
Je také dobré si uvědomit, že jakékoliv aritmetické operace s adresovými registry pracují vždy s plným rozsahem 32 bitů. Z toho vyplývá několik vlastností: addq.w #x,Dx je rychlejší než addq.w #x,Ax, protože to druhé se vždy rozšiřuje na 32 bitů. Ze stejného důvodu je add.w #x,Ax pomalejší než add.w #x,Dx, a (Ax,Dx.w) je pomalejší než (Ax,Dx.l). Na druhou stranu nám to umožňuje snadno přidávat 16bit offsety (add.w Dx,Ax místo add.l Dx,Ax). Proto to tak Motorola udělala.
Pokud se adresuje paměť, vždy je lepší používat adresový mód než aritmetiku rozepisovat (fetch=načtení instrukce vždy trvá 2 takty). Takže raději add.w offs(A0,d0.w),d1 než add.w d0,a0 + add.w offs(a0),d1. Samozřejmě to platí jen pokud je to možné (v prvním případě může být "offs" jen osmibitový).
Je dobré si uvědomit, že postinkrementace (Ax)+ je "zadarmo". Tedy že není rozdílu mezi (Ax) a (Ax)+. Je tedy výrazně rychlejší než nějaké move.w (Ax),Dx + addq.w #2,Ax.
Ale predekrementace -(Ax) už zadarmo není a vyžaduje dva takty k instrukci navíc!
Pokud je to možné, tak si uvědomíme, že adresace s offsetem d(Ax) je vždy o 4 takty pomalejší (2 takty na fetch wordu + 2 takty na aritmetiku) než (Ax) nebo (Ax)+. Takže když to jde, tak čteme nebo zapisujeme data postupně a ne na přeskáčku.
Jedny z nejpomalejších instrukcí jsou DIVS/DIVU, MULS/MULU a rotace a posuny. Hlavně na ty druhé se zapomíná.
Všechny rotace a posuny trvají 6(nebo 8)+2*n taktů, kde n je počet posunů. Proto nenápadně vypadající instrukce asr.l #8,d0 (tak často používaná při fixed-point aritmetice) trvá mnohdy smrtících 24 taktů :-) Často se proto volí spíše jednodušší swap pro získání celé části hodnoty (fixed-point formát je pak samozřejmě 16:16). Pokud to tedy je možné a nebo je třeba použít 32 bitů.
CLR instrukce je spíše zbytečná. Na mazání datového registru je rychlejší moveq, na smazání adresového se dá klidně použít sub Ax,Ax (i když je to časově stejné) a na mazání paměti je lepší používat movem, když je to možné.
MULU/MULS jsou v časování zajímavé tím, že záleží na hodnotě prvního operandu (viz odkaz). Paradoxně tak může být MULS rychlější než MULU. Naopak rychlost MULU je snadnější předvídat (záleží jen na počtu bitů nastavených na 1). Obecně ale stejně platí, že když je to možné, tak je dobré použít bitové posuny + aritmetiku nebo tabulku.
ADD.W Dx,Dx je rychlejší než LSL.W #1,Dx. ADD.W + ADD.W je pořád rychleší než LSL.W #2!
DIVU/DIVS je bohužel zabiják výkonu. 140 (resp. 158) taktů (plus mínus 10%)! Takže pokud je to jen možné, je třeba použít bitové posuny pro dělení mocninou dvěma. Nebo využít tabulky. Nebo zvážit úpravu celého algoritmu, aby dělení nebylo zapotřebí.
Skoky (Bcc instrukce) jsou pomalé. Když už je potřebujeme, tak volíme krátký skok BCc.b (někteří píšou .s místo .b). Instrukce DBCc trvá 10 až 14 taktů (obvykle 12 - DBF instrukce). Proto je lepší krátké smyčky rozvinout, když se neopakují příliš často (k tomu je dobré používat REPR makra, například). BSR/JSR + RTS je pomalé a pokud je to možné dá se použít rychlejší lea.l .return(pc),Ax + bra.b ... + jmp (Ax). Samozřejmě pokud nám jde o každý takt, protože čitelnost programu dostane pořádnou ránu ;)
V případě nedostatku registrů je vhodné buď pracovat jen s 16 bity a využít celý rozsah datových registrů a prohazovat poloviny pomocí SWAP. Nebo využít adresové registry. A taky je možno použít A7, pokud víme co děláme (pozor na přerušení pokud kód už běží v privilege módu!). V tom případě je asi vhodné rozlišovat používaný registr jako A7 od operací nad standardním zásobníkem (SP), abychom se v tom nepoztráceli.
Když už není kde brát a potřebujeme si něco do paměti uložit, tak zvážíme jestli k tomu nevyužít zásobník ( -offset(SP) ), nebo adresaci pomocí PC (např. add.w .value(pc),Dx). Bohužel PC-relative adresace nemůže být používána jako cílový operand :-( Vše je lepší než používat celou 32 bitovou absolutní adresu. Zvážíme taky výhody relativní PC adresace s ofsetem a registrem: d(PC,Dx). Bohužel offset "d" může být jen osmibitový, takže data musíme ukládat blízko našemu kódu (a když tak data přeskočit BRA instrukcí - pořád to může být výhodné).
TST instrukci použijeme jen v krajní nouzi. Je dobré nezapomínat, že stavové bity jsou nastavovány většinou instrukcí pokud se pracuje s datovými registry nebo pamětí (nenastavují se při aritmetice s adresovými registry!). Takže raději move.w (Ax),Dx + beq.b, když stejně hodnotu v Dx použijeme, namísto TST.w (Ax) + beq.b + ...
Ošetření přerušení je relativně pomalá záležitost. Procesor musí uložit návratovou adresu, udělat odskok, přerušovací rutina často musí uložit obsah registrů (movem), pak je na konci zase načíst (další movem) a následuje RTE, které samo trvá 20 taktů... Takže když nemusíme, neděláme to :-)
U procesorů 020+ pak platí jiné závislosti. Naprosto zásadní je správné používání instrukční a datové (030+) cache. Rozvinování smyček je proto třeba dělat jen do určité velikosti (aby nevznikaly cache-miss). Data je vhodné mít "packed" pěkně pohromadě (takže více polí hodnot než jedno pole velkých struktur). Některé věci jsou výrazně rychlejší (posuny a rotace mají konstantní čas, násobení a dělení je rychlejší, ...).
http://oldwww.nvg.ntnu.no/amiga/MC680x0 ... index.HTML
U 040 a 060 je zásadní počítat s instrukční pipeline, kterou už CPU má -- tedy paralelní fetch, decode a execution instrukce (060 navíc spekulativní out-of-order execution). Takže je vhodné instrukce řadit tak, aby zdrojový operand aktuální instrukce nezávisel na cílovém operandu předcházející instrukce a CPU tak nemuselo čekat. Instrukce mohou běžet paralelně a pokud chceme ručně optimalizovat, musíme s tím počítat a podle toho se zařídit. ( Poznámka: U složitějších CPU je pak už obtížné ručně optimalizovat a je lepší to nechat na překladači (bolestivě zjištěno už v roce 2000 na tehdejším Celeronu a Athlonu :-)). )
Těch různých technik a dobrých "rad" by bylo určitě víc. A hodně by jich souviselo s Amigou a specifikami jejího hardware.
Ale stará definice říká, že program je algoritmus pracující nad daty.
Největší optimalizace se tedy dosáhne tím, že se tyto dvě složky chytře navrhnou.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 11.01.2021, 22:43 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 13.05.2013, 09:15
Příspěvky: 1953
Bydliště: Brno
Has thanked: 523 times
Been thanked: 174 times
Ahoj :)

Rozdíl mezi byte a bite si ji uvědomuji, ale v minulosti jsem s tím měl problém. Nečekal bych, že rotace je pomalá. Uvědomuji si, že je lepší použít třeba celý byte, jako 1 informaci, ale hlavně v specifických částech mého hudebního formátu pracuji i na bitové úrovni a mám v 1 byte třeba tři informace. Díky za info o CLR, mazání Ax pomocí sub dělám :). Na takty se snad začnu hrát později. Něco upravím i teď, mám teď na mysli nějakou komplexnější optimalizaci. Já mou hudební rutinu i tak mnohonásobně zpomaluji, zatím je to v pohodě a v rámci ASM jsem rád že jsem rád :). Ale je to fajn pakárna na odreagování se. K té A7, já ji raději zatím vůbec nepoužívám, mne to v ní přepisovalo hodnoty, ale nepřistupoval jsem k ní jako k zásobníku. Ty píšeš, že to není nutný? Asi tedy něco dělám špatně, mé řešení zatím je že ji nepoužívám. Zásobník jsem zatím nepoužil. Hudební rutina ho potřebovat dle všeho nebude.

Mohl by si mi prosím uvést příklad na to jak udělat rychlejší verzi JSR, RTS, kde použiješ LEA.L? To je asi jediná věc u které jsem se úplně ztratil a neporozuměl ji a která by mne zajímala, stačí mi celistvější kód uveden v řádcích, tedy jeho hlavní struktura. Díky moc za vše!

Je fajn, že si se zde ozval. Já příspěvky i zdvojoval ale na AP v současný době není někdo kdo dělá v ASM, nebo o tom nevím. Tak jsem opět byl připraven zdvojovat... .

Nedávno jsem se přes FB spojil ještě s někým, kdo má zájem o ASM na Amize a je to programátor, tak čas ukáže jak u něj tak u mne :) Prvně jsem si s ním psal tak před týdnem.

_________________
Amiga - PMD 85
Kafasoft


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 11.01.2021, 23:23 
Offline
Pan Generální

Registrován: 22.05.2013, 21:14
Příspěvky: 3015
Bydliště: Bratislava
Has thanked: 308 times
Been thanked: 578 times
defor píše:
U složitějších CPU je pak už obtížné ručně optimalizovat a je lepší to nechat na překladači (bolestivě zjištěno už v roce 2000 na tehdejším Celeronu a Athlonu :-)). )
Na tomto mieste si dovolim tak trosku nesuhlasne sa ozvat ;)
Suhlasim s tym, ze bezny kompiler dokaze zoptimalizovat kod lepsie, ako bezny programator.
Ale stojim si za tym, ze dobry programator, znaly danej platformy, vzdy dokaze napisat efektivnejsi (kratsi a rychlejsi) kod nez hoc aj ten nalepsi a najspickovejsi kompiler.
Napriklad v tejto diskusii o tom pisem viac a uvadzam aj niekolko konkretnych prikladov a merani.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 12.01.2021, 11:11 
Offline
Stydlín

Registrován: 11.01.2021, 11:47
Příspěvky: 9
Has thanked: 0 time
Been thanked: 11 times
Busy píše:
defor píše:
U složitějších CPU je pak už obtížné ručně optimalizovat a je lepší to nechat na překladači (bolestivě zjištěno už v roce 2000 na tehdejším Celeronu a Athlonu :-)). )
Na tomto mieste si dovolim tak trosku nesuhlasne sa ozvat ;)
Suhlasim s tym, ze bezny kompiler dokaze zoptimalizovat kod lepsie, ako bezny programator.
Ale stojim si za tym, ze dobry programator, znaly danej platformy, vzdy dokaze napisat efektivnejsi (kratsi a rychlejsi) kod nez hoc aj ten nalepsi a najspickovejsi kompiler.
Napriklad v tejto diskusii o tom pisem viac a uvadzam aj niekolko konkretnych prikladov a merani.

Nechci tady začínat nějaký off-topic.
Četl jsem si tvůj test a souhlasil bych, že ručně napsaný krátký kód v assembleru je (může být) rychlejší. Těžko se to rozporuje, protože něco takového nikdy nebude pravidlem. Snadno si umím představit i pravý opak, kdy překladač vygeneruje pro daný úkol rychleji běžící kód.
Tu poznámku jsem tam psal skutečně jen jako připomenutí faktu, že s narůstající složitostí CPU (jejich instrukční sada, jejich vnitřní paralelizace, ...) je pro člověka velmi složité poskládat instrukce tak, aby chod byl "optimální". Moje osobní zkušenost je už dvacet let stará, kdy jsem poprvé a naposledy pro kamarády dělal PC demčo a naučen z Amigy jsem ho ve velké míře dělal v assembleru. Algoritmy jsem si ale pak napsal i v C, přeložil to Intel překladačem (Athlon 1GHz) a kód byl
rychlejší. Teď už si nevzpomenu o kolik, ale samotný fakt, že byl, mne uvedl do deprese ;-) Už tehdy byly instrukce na sobě závislé a některé se mohly provést paralelně, pokud ale byly splněny určité podmínky. A pokud by to chtěl člověk udělat ručně v assembleru, musel by mít stále otevřenou dokumentaci a tabulku a kontrolovat si splnění těchto podmínek. Jak je to v současnosti netuším. V době, kdy se na PC mladí lidé už ani neučí programovat v jazycích s překladem do nativního kódu a jejich znalosti končí u JavaScriptu nebo Pythonu, se mi jeví myšlenka programování v assembleru na PC v praxi jako sci-fi.
P.S.: Low-level optimalizace se teď spíše týká využití SIMD instrukcí (v překladači jako intrinsic functions) a samozřejmě paralelizace obecně. Tam se skrývá skutečné zrychlení.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 12.01.2021, 11:46 
Offline
Stydlín

Registrován: 11.01.2021, 11:47
Příspěvky: 9
Has thanked: 0 time
Been thanked: 11 times
Lisiak4 píše:
K té A7, já ji raději zatím vůbec nepoužívám, mne to v ní přepisovalo hodnoty, ale nepřistupoval jsem k ní jako k zásobníku. Ty píšeš, že to není nutný? Asi tedy něco dělám špatně, mé řešení zatím je že ji nepoužívám. Zásobník jsem zatím nepoužil. Hudební rutina ho potřebovat dle všeho nebude.

Ty různé tipy jsem uvedl spíše jako příklad. A neznamená to, že je třeba je při programování používat. Bohatě stačí, že o nich člověk ví, a kdyby něco nutně potřeboval zrychlit, může se k nim uchýlit. To platí i o použití A7 registru. A7 je u 68k procesorů používám jako stack-pointer. Assemblery proto pro něj mají synonymum "sp". Existuje sice několik specifik, kromě nich je ale A7 stejný jako ostatní A0-A6 registry. Takže když je programátor opatrný, může ho využít. Jen nesmí zapomenou vrátit mu jeho původní hodnotu, protože jinak mu "rts" instrukce načte nesmyslnou návratovou adresu. Problém s použití A7 registru pro běžné operace je v supervisor módu (uvnitř přerušení), protože supervisor-stack může být kdykoliv použit znovu v případě, že vznikne přerušení o vyšší prioritě než to, které je momentálně ošetřováno. V user-modu je to ale v pohodě (68k mají dva A7 registry - user a supervisor).
Kód:
; this runs safely in user-mode only!
move.l a7,.storedStackPtr ; store stack-pointer
lea.l .myDataTable(pc),a7
....
move.w (a7)+,d0 ; we can use a7 here but don't do bsr/jsr/rts!
...
move.l .storedStackPtr(pc),a7  ; restore stack-pointer!
rts ; then this return works


Lisiak4 píše:
Mohl by si mi prosím uvést příklad na to jak udělat rychlejší verzi JSR, RTS, kde použiješ LEA.L? To je asi jediná věc u které jsem se úplně ztratil a neporozuměl ji a která by mne zajímala, stačí mi celistvější kód uveden v řádcích, tedy jeho hlavní struktura. Díky moc za vše!

Je to jen takový laciný trik, jak o něco málo zrychlit skoky do podprogramů.
Jde jen o to, že kombinace bsr + rts trvá 34 taktů. Když si můžeme dovolit uložit návratovou adresu
do registru, tak můžeme použit prosté lea+bra+jmp, které trvá 26 taktů. Žádné velké zrychlení to není. Ale dělalo se to. Dělaly se i šílenější věci -- třeba přímé přepisování adresy skoku v JMP instrukci. Pokud by se volání dělalo opakovaně ve smyčce, pak by to už mohlo být významnější. Otázkou ale je, jestli pak není lepší podprogram vůbec nevolat a spíše ho vložit do smyčky a třeba i smyčku rozvinout, aby se vůbec nikam neskákalo... Určitě nemá smysl optimalizovat něco, co se provádí v rámci celého programu jen zlomek času. A už vůbec neoptimalizovat, když člověk teprve konstruuje algoritmus. Prostě klasické: "Premature optimization is the root of all evil".
Kód:
 lea.l .continue(pc),a5 ; (8 cycles)
 bra.w .subroutine       ;  (10 cycles)
.continue
...
...
.subroutine
  ; do something
  jmp (a5) ; we return back  (8 cycles)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 20.02.2021, 21:28 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 13.05.2013, 09:15
Příspěvky: 1953
Bydliště: Brno
Has thanked: 523 times
Been thanked: 174 times
@defor: já mám hlavně s A7 problém, že se mi v ní smaže má hodnota nějakou, kterou jsem do ní ani nedal. Nemusím tedy k A7 přistupovat jako k zásobníku a můžu zabezpečit aby se tak nedělo? Můžu tedy použít klasické move jako u ostatních registrů? To se ale tedy nějak musí zabezpečit a to je tedy asi nějaká další instrukce, tedy další zdržení? Přistupovat k A7 jako k zásobníku je od tohohle postupu ještě pomalejší? Jedna z možností je asi použít A7 na krátkou dobu, protože pokud by to bylo na déle, ta hodnota se mi v ní bez mého přičinění změní.

Jinak čemu ještě nerozumím je alokace paměti, od každého jen slyším, že je to lehký. Nemám páru, jestli to vůbec potřebuji k nesystemovemu programování a když jo tak co alokovat a proč. Vůbec nerozumím tomu principu. S tímhle mám problém, jakmile něco není mého, pochopit to. Zatím jsem to tedy neřešil, ale když si tady třeba mi to více ozřejmíš. Nebo mě stačí nasměrovat na nějakou literaturu... .

Edit: konkrétní literaturu k alokaci paměti a né Wikipedii.
Edit2:

_________________
Amiga - PMD 85
Kafasoft


Naposledy upravil Lisiak4 dne 20.02.2021, 22:23, celkově upraveno 3

Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 20.02.2021, 21:49 
Online
Radil

Registrován: 18.10.2014, 23:10
Příspěvky: 261
Has thanked: 17 times
Been thanked: 64 times
https://en.wikipedia.org/wiki/Motorola_68000


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 20.02.2021, 22:50 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 13.05.2013, 09:15
Příspěvky: 1953
Bydliště: Brno
Has thanked: 523 times
Been thanked: 174 times
Antony/DTA píše:
https://en.wikipedia.org/wiki/Motorola_68000
Díky, přesně tohle jsem nemohl najít :god:

_________________
Amiga - PMD 85
Kafasoft


Nahoru
 Profil  
 
 Předmět příspěvku: Re: Amiga Assembler 68000/020
PříspěvekNapsal: 23.02.2021, 12:04 
Offline
Stydlín

Registrován: 11.01.2021, 11:47
Příspěvky: 9
Has thanked: 0 time
Been thanked: 11 times
Lisiak4 píše:
@defor: já mám hlavně s A7 problém, že se mi v ní smaže má hodnota nějakou, kterou jsem do ní ani nedal. Nemusím tedy k A7 přistupovat jako k zásobníku a můžu zabezpečit aby se tak nedělo? Můžu tedy použít klasické move jako u ostatních registrů? To se ale tedy nějak musí zabezpečit a to je tedy asi nějaká další instrukce, tedy další zdržení? Přistupovat k A7 jako k zásobníku je od tohohle postupu ještě pomalejší? Jedna z možností je asi použít A7 na krátkou dobu, protože pokud by to bylo na déle, ta hodnota se mi v ní bez mého přičinění změní.

Jinak čemu ještě nerozumím je alokace paměti, od každého jen slyším, že je to lehký. Nemám páru, jestli to vůbec potřebuji k nesystemovemu programování a když jo tak co alokovat a proč. Vůbec nerozumím tomu principu. S tímhle mám problém, jakmile něco není mého, pochopit to. Zatím jsem to tedy neřešil, ale když si tady třeba mi to více ozřejmíš. Nebo mě stačí nasměrovat na nějakou literaturu... .

Edit: konkrétní literaturu k alokaci paměti a né Wikipedii.
Edit2:


Možná bude lepší na nestandardní používání A7 pro tentokrát zapomenout. Je to jen takový trik, jak mít k dispozici o jeden registr víc, když by to rutina "strašně moc" potřebovala.
U MC68k řady procesorů je A7 v podstatě zcela normální adresový registr (jako A0 až A6) jen s několika výjimkami: Je používán instrukcemi JSR/BSR/RTS/LINK/UNLK/PEA (a možná ještě nějakou, teď nevím) jako adresa zásobníku. A7 se proto v assemblerech a dokumentaci nazývá SP (stack-pointer). Jeho zvláštností je, že nemůže obsahovat lichou adresu, což je ale pochopitelné, uvážíme-li, že například RTS instrukce automaticky načítá ze zásobníku návratovou adresu, která má 4 bajty a jak víme, tak 68000 nemůže číst wordy z lichých adres! Další "zvláštností" je, že A7 je jediný registr, který v procesoru existuje dvakrát: Jednou pro user-mode a podruhé pro supervisor-mode. To má ten příjemný efekt, že když procesor jde do supervisor módu (tedy obvykle z důvodu přerušení), není hodnota A7 změněna tím, že by se na zásobník ukládala návratová adresa. K tomu je právě použita supervisor A7' varianta. Instrukce RTE (return-from-exception) pro načtení návratové adresy využije tento zásobník.
To vše dohromady znamená, že A7 se dá použít jako běžný adresový registr, pokud si programátor dá pozor. Nebezpečné je jeho nestandardní používání v supervisor-modu, kdy nemáme zajištěné, že náš program nebude zastaven přerušením o vyšší prioritě. V tom okamžiku totiž procesor využije A7' pro uložení návratové hodnoty!
Pokud ti to stále není jasné, tak doporučuji nějaké povídání o tom, co je zásobník, k čemu se používá a jeho využití při skocích do podprogramů (BSR/JSR/RTS) a podobně.
Nerozumím, jak se ti může A7 přepsat něčím "co jsi do ní nedal". Výše uvedené instrukce manipulují s A7 registrem (inkrementují/dekrementují ho) a ukládají hodnoty na adresy v něm uložené. Je to vše jasně dokumentované a předvídatelné.
Ale opakuji: Použití A7 jako normálního registru (například k nějakému krátkodobému uložení hodnot) je věc nestandardní a bude asi lepší na celou tuto věc zapomenout, pakliže si nejsi jistý tím, co děláš.

Alokace paměti je komplexní věc. Může být snadná, ale i složitá. Podle požadavků. První věc je, zvážit, jestli je vůbec nějaké alokace paměti zapotřebí. Budou v průběhu běhu programu vznikat a zanikat nějaké "objekty", které vyžadují nějaké množství paměti? O jak velké nároky se jedná? Jak ty "objekty" vznikají? Zcela nahodile, nebo nějak organizovaně (například postupně vznikají a pak zase zanikají ve stejném pořadí)? Je možné předvídat maximální množství těchto objektů? A tak dále, a tak podobně. Alokace paměti je v podstatě práce se zdroji (resources) jako každá jiná: Máme k dispozici zdroj (resource), v tomto případě paměťový blok, a k němu chce přistupovat a používat jej blíže nespecifikované množství procesů. A pod pojmem "proces" tady nemusíme přímo myslet běžící aplikaci operačního systému (application/process/task/thread apod.), ale třeba i jen nějaký úsek našeho vlastního programu, který si pro sebe chce ukrojit kousek z toho většího paměťového "koláče". Alokace paměti je pak způsob jak z něho ukusovat, a jak pak ty kousky zase dávat dohromady a scelovat pokud možno tak, aby nám na konci vznikl zase původní koláč. Funkce "Allocate" nám vrátí adresu kousku paměti, a funkce "Free" ji zase vrátí zpátky do koláče. A že to může být jednoduché i složité, je hned zřejmé, když si představíme, že volání "Allocate" chtějí různě velké kousky paměti, a požadavky na alokaci a uvolnění "Free" mohou přicházet v různém pořadí. Je pak zřejmé, že rozdrobení koláče je jen otázkou času. Proto existuje velké množství různých strategií, jak tomu předcházet. O "memory managementu" byly napsány stovky článků a knih. Hledej toto heslo na internetu.


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 87 ]  Přejít na stránku Předchozí  1, 2, 3, 4, 5, 6

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 2 návštevníků


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz