Bjarni Juliusson skrev den 2015-03-01 18:35:
On 03/01/2015 05:45 PM, Pontus Pihlgren wrote:
On Sun, Mar 01, 2015 at 05:07:22PM +0100, Bjarni Juliusson wrote:
Oj, hmm. Då måste vi dels komma ihåg adressen för den föregående instruktionen, dels ogöra dess effekt i efterhand. Vi kan ju
nja. magnus sa ju att mmu:n skulle ignorera minnesaccesser, skulle inte det helt ogöra instruktionens effekter?
Nej.
Eller är det sidoeffekter i CPU:n du tänker på, flaghor som sätts eller liknande?
Ja.
Processorn exekverar ju instruktionen oavsett vad den får för data från minnet. I efterhand måste vi kunna återställa ackumulatorn, X, Y, flaggorna, och stackpekaren. Så MMU:n måste komma ihåg var senaste opkoden fetchades ifrån innan trappen, så att vi kan se vad den var, ogöra effekten, och sätta tillbaka programräknaren för att starta om instruktionen. Jag tänkte mej att MMUn har två register, ett som latchar in adressen när man gör en fetch och ett annat när man inte gör det. Båda registrena är läsbara från CPUn på nät sätt så att man kan kolla var man fick en fault (och hoppa tillbaka). I fallet fault under fetch är det enkelt; då returnerar man ju alltid en jmp istället och får inga sidoeffekter. I det andra fallet så kommer man att exekvera instruktionen, men man ignorerar skrivningar och returnerar bara 0.
Det är några saker som man måste fundera på lite för att lösa. Till exempel ADC lägger ju till carryn och sätter den igen, även om man adderar med 0. Här är det en utmaning att veta vad den var innan. Eller AND, om man returnerar 0 så kommer den att cleara A. Båda ovan skulle gå att lösa eftersom man kan räkna ut vad det är som kommer att skita sig, så man kan returnera nåt bra istället :-)
Insåg just att man lyckligtvis inte kan göra dataåtkomster med indirekt absolut adressering. Det hade varit rena döden. Enda indirekta data-adresseringen är via sida 0, som man rimligen alltid har mappad och både läs- och skrivbar. Så det där jag sa om I/O är nog ingen fara, man kan inte råka göra I/O man inte skulle ha gjort. Eller ja, förutom totalt degenererade situationer som att man gör ett indirekt hopp via en adress som ligger på skarven mellan en omappad sida och en I/O-sida, så att det slutar med att man gör en läsning till ett I/O-register två gånger. Det känns som en situation som det är helt acceptabelt att lösa genom att blänga på programmeraren.
Ditt sista exempel här skulle man slippa eftersom man har koll på vad instruktionen försöker göra och om den får det. Det enda problemet här vore möjligtvis om man gör typ ett indirekt hopp där indirekt-adressen ligger i I/O-området, då kommer man att få två accesser. Men gör man det har man nog redan förlorat. Jag tror ingen MMU löser det problemet... Sen har man ju lite buggar att ta hänsyn till (eller kanske fixa?) i MMUn. Jag har nåt minne av att om man gjorde en indirektadressering och halva adressen låg på nästa sida så tog den istället första adressen från innevarande sida? -- Ragge