Utilitzant resload_Protect#?
Teoria
Hi ha diverses situacions en les que pot ser d'utilitat ésser informat quan el programa instal·lat realitza accessos a certes ubicacions específiques en memòria. Amb les funcions
resload_Protect#? és possible protegir certes ubicacions de memòria contra lectura i/o escriptura pel processador. Aquesta protecció implica
que cada accés a una d'aquestes àrees protegides, cas de realitzar-se, generarà una excepció de Falla d'Accés i provocarà l'aparició del quadre de diàleg apropiat per part de WHDLoad.
Si vostè declara com a protegida un àrea de memòria usant una funció resload_Protect#?, WHDLoad modificarà els descriptors de la pàgina afectada
en l'arbre de traducció de la MMU. Després, a cada accés a la pàgina protegida, la CPU generarà una excepció de Falla d'Accés. El gestor d'excepcions dintre de WHDLoad verificarà el
motiu de l'excepció. Si el motiu ha estat un accés a una pàgina protegida però l'accés no correspon a l'àrea protegida, els accessos seran emulats, i el programa
continuarà executant-se normalment. D'altra banda WHDLoad sortirà de l'execució amb el quadre de diàleg apropiat. Si l'accés es realitza dintre del flux d'instruccions (és a dir,
la CPU ha intentat carregar codi) sempre serà emulat, o en altres paraules, les funcions resload_Protect#?
només afectaran a la lectura i escriptura de dades. El fet que cada accés a una pàgina protegida (la grandària de pàgina és actualment $1000) generi una falla d'accés, encara que l'àrea
protegida tingui una longitud de només 1 byte, provoca un gran alentiment de la velocitat d'execució del programa, especialment si parts del codi estan situades en la mateixa pàgina.
Si el programa depèn de la velocitat d'execució, existiran diferències quant a l'execució del mateix. Per tant és possible que alguns programes no funcionin amb la funcionalitat de
protecció.
Exemple: sumes de control per codi
Si s'instal·la un joc emprant WHDLoad, vostè haurà d'aplicar un patch a les rutines de càrrega en el carregador original del joc de tal forma que utilitzin WHDLoad per a carregar
les dades del joc. Alguns jocs realitzen sumes de control sobre certes àrees de codi per a detectar si el codi original ha estat modificat. Aquestes rutines de detecció poden ser -en
determinades ocasions- bastant difícils de trobar. Però usant la funcionalitat resload_Protect#? de WHDLoad gens pot ser més senzill que això.
Tot el que s'ha de fer és protegir contra lectura els bytes que han canviat en el codi del joc. Ara cada rutina que intenta realitzar una suma de control i llegir el codi "parxat" provocarà
una falla d'accés i vostè coneixerà on es troba situada la rutina.
Limitacions
No s'ha de protegir la pàgina de memòria on apunta el SSP. Si ho fa, i ocorre una Excepció, resultarà en una Falla de Doble Bus atès que la CPU no serà capaç d'escriure l'entorn de
pila de l'excepció. Després d'una Falla de Doble Bus només és possible realitzar un reset per a continuar amb l'execució. WHDLoad verificarà si hi ha un conflicte de l'àrea protegida
mitjançant l'SSP i acabarà en cas afirmatiu, però això no serà d'ajuda si el SSP canvia posteriorment.
- 68020 + 68851
- Aquest maquinari no està suportat actualment.
- 68030
- Les transferències de 3 bytes no estan suportades i generen una Falla d'Accés real, tals transferències ocorreran si s'accedeix una paraula llarga en una adreça imparella a la frontera
d'una pàgina (per ex. "
tst.l ($fff)
" on la pàgina a $1000 estigui protegida),
atès que això és invàlid en un 68000 probablement vostè mai vegi alguna cosa com aquesta.
- Transferències bloquejaades ocasionades per
tas
, cas
o cas2
no estan suportades i generen una Falla d'Accés real; no és realment un problema
donat que les transferències bloquejades no estan suportades pel maquinari dels Amigues
- 68040
- Aquest maquinari no està suportat actualment.
- 68060
- No estan suportats el accessos a fluxos de dades desalineats i generen una Falla d'Accés real, un accés desalineat és un accés que abasta dos pàgines (i almenys una d'elles està
protegida), per exemple "
tst.l ($ffe)
" afecta a la pàgina $0..$fff i la pàgina $1000..$1fff, aquesta limitació és realment un problema i causa que la funcionalitat de
resload_#Protect sigui pràcticament inutilizable en ocasions, Potser més endavant intentaré donar suport a això però és difícil.
- No estan suportats el accessos a fluxos de dades desalineats i generen una Falla d'Accés real si ambdues pàgines afectades es troben protegides, la major part de les vegades aquesta
situació pot ésser evitada.
- Les transferències bloquejades causades per
tas
, cas
o cas2
no
estan suportades i generen una Falla d'Accés real. Això no és un problema donat que les transferències bloquejades no estan suportades pel maquinari dels Amigues
- S'executaran incorrectament les instruccions que estiguin en una pàgina protegida (i per tant siguin emulades) i accedeixin a la porció de supervisor del registre d'estat.
Aquestes instruccions sempre veuran el bit de seguiment (trace bit) amb valor 1 i la màscara de prioritat d'interrupció (interrupt priority mask) amb valor 7 i
qualsevol modificació a la porció de supervisor no tindrà efecte (és a dir que la porció de supervisor romandrà sense canvis)
- Les instruccions
movem
poden accedir un àrea protegida sense crear una excepció de Falla d'Accés. Això és possible degut al fet que solament el primer accés
(paraula o paraula llarga) serà verificat contra l'àrea protegida.
move16
y les operacions de doble precisió (FPU) no estan suportades i causaran
una Falla d'Accés real
- un "
move (mem),(mem)
" amb adreces d'origen i destí que es solapin degut a una desalineació s'executarà incorrectament, per exemple "move.l ($ffc),($ffe)
"
on la pàgina $1000..$1fff estigui protegida i la memòria abans d'execució contingui
($ffc)=$11112222, ($1000)=$33334444, després de l'execució $1000 contindrà $11114444 i no $22224444