PDP-8a renovering

[bqt]

Men dessutom?

Det var just det jag menade med:

> CPUn ska först läsa, sen skriva samt sedan räkna upp en minnespekare för nästa överföring.

DMA'n gör normalt allt det i hårdvaran på en cykel.

VI pratar nog föbi varandra lite. I min värld så är själva uppräknaren av minnespekaren en liten del. Att hämta, avkoda och exekvera ett antal instruktioner är mer arbete. Dessutom måste CPUn veta när det är dags, vilket antingen innebär att polla, eller att få interrupt. Båda implicerar massor av instruktioner.

Så, ja, med "dessutom" menade jag att det är mycket mer än bara hanteringen av minnespekaren som kommer till om CPUn ska göra vad DMA annars gör...

[bqt]

Hur tror du det fungerar på en modern CPU då? Du har fortfarande bara en buss, på vilken minnet sitter. Alla kan inte göra transaktioner samtidigt...

Processorn kan fortfarande jobba internt med register samtidigt som DMA jobbar mot RAM.

Sen har ju vissa arkitekturer flera faser i instruktionscykeln, read-modify-write t.ex. Där kan DMA accessa RAM under modify-fasen.

Notera alltså att DMA inte lastar CPUn, varken på en PDP-8 eller någon modern maskin.

Nej men om CPU lastas eller inte spelar ju ingen roll om man tappar CPU-cykler. Eller pratar du nu ur temperatursynpunkt? Att CPU inte blir lika varm om låter den gå på tomgång så att säga?

Ja. Om du har en CPU som kan göra något utan att referera till minnet/IObussen/annan inblandad del. Annars får CPUn stnällt vänta ett ögonblick. En åtta har som sagt ingen sådan möjlighet, så där blir det alltid lite vänta när DMA sker. Men vänta är alltså fraktioner av en instruktionscykel.
Men som sagt, åven på en modern CPU så är DMA i grund och botten en fråga om att klockcykler på bussen används av något annat än CPUn. Ingen skillnad alls mot hur det är på en åtta. Det är bara så att CPUn har idag lite större möjligheter att göra saker utan att äga bussen. Och det beror på att man har långa pipelines och cache på olika nivåer som gör delarna lite mer oberoende.
Men i grund och botten är det precis likadant på en maskin idag som det är på en åtta.

[sodjan]

> Vi pratar nog föbi varandra lite. I min värld så är själva uppräknaren av minnespekaren en liten del.

Om du menar PC (programräknaren) så var det inte det jag menade.

Jag menar att om DMA'n ska göra i kod så behöver koden även hantera
något slags pakare för indexerad adressering. Denna behöver hanteras
av koden och det kan vara lika mycket som själva flytten av datat.
Pakeren ska läsas in, ökas och skrivas tillbaka. Sen så har många
arkitekturer auto-increment som som en option till indexerad
adressering, men det bli lite överkurs...

Sen så spelar cache och pipelanes inte så stor roll, de förutsätter i alla
fall att minnsbussen är tillgänglig normalt. CPU'n har ju inte heller någon
aning om att en DMA pågår, det är bara några minnesacesser som kommer
att ta lite mer tid än normalt. Så CPU'n kan inte aktivt välja vad den ska
göra under tiden. Och den kan inte välja så speciellt mycket ändå, det
styrs ju av den aktuella koden som ska köras vad den ska göra. Så den kan
inte aktivt välja att "köra från cachen" istället för att vänta...

Med de sagt, så visst har även DMA hanteringen utvecklats sedan PDP8 tiden.
En del gör att köra multiplexat på minnesbussen med CPUns egna accesser o.s.v.

Hur som helst (det blev en lite för stor utvikning detta) så gäller det nog generellt
både för en PDP8 och för dagens processorer att DMA är snabbare än att göra
samma sak i koden direkt.

[MattisLind]

Än roligare är att det finns två typer av Data break på en PDP-8. En del riktigt gamla kontrollrar har inga register som håller adress och räknare, utan dessa ligger i det fysiska minnet istället, så varje DMA-transaktion innebär att devicet läser och modiferar adress och räknare i minnet, och sedan överför ett ord data till där adressen anger. (1-cycle data break respektive 3-cycle data break.)

Som jag förstod three cycle data break är det CPU (ALU) som sköter om att göra increment på CA och WC registren (som mycket riktigt ligger i primärminne), inte devicet. Det finns en signal på IO bussen som kontrollerar om CA ska ökas på med ett eller ej. CPU detekterar även den om det sker overflow i WC och skickar då en signal till devicet. Devicet specar bara adressen i minne där WC lagras.

Så helt utan CPU inblandning kan man nog inte säga att det är, jämfört med DMA på något modernare maskiner.

[bqt]

> Vi pratar nog föbi varandra lite. I min värld så är själva uppräknaren av minnespekaren en liten del.

Om du menar PC (programräknaren) så var det inte det jag menade.

Nej, det var inte PC jag menade.
Som jag menade så var det att om CPUn är inblandad, så måste CPUn läsa data från devicet, skriva det till en address, öka den addressen, och dessutom uppdatera räknaren. Allt i programkod. Det innebär att när data finns tillgängligt så måste devicet interrupta CPU, CPU hoppa till interrupthanteraren, spara intern state (allt detta är helt oberoende av vad som begär ett interrupt). Sedan måste CPUn hoppa till den hanterare som ska göra motsvarande som DMA gör, och väl i den koden så ska som sagt var instruktioner finnas som läser device-data, skriver till minne, uppdaterar pekare och räknare, och till slut hoppar ur interrupthanteraren igen. Massor av kod. Själva hanteringen av address och räknare är en väldigt liten del av allt detta.

(Ovan om det är läsning från device till minne, vid minne till device så sker transport av data i andra riktningen, uppenbarligen.)

Jag menar att om DMA'n ska göra i kod så behöver koden även hantera
något slags pakare för indexerad adressering. Denna behöver hanteras
av koden och det kan vara lika mycket som själva flytten av datat.
Pakeren ska läsas in, ökas och skrivas tillbaka. Sen så har många
arkitekturer auto-increment som som en option till indexerad
adressering, men det bli lite överkurs...

Japp.

Sen så spelar cache och pipelanes inte så stor roll, de förutsätter i alla
fall att minnsbussen är tillgänglig normalt. CPU'n har ju inte heller någon
aning om att en DMA pågår, det är bara några minnesacesser som kommer
att ta lite mer tid än normalt. Så CPU'n kan inte aktivt välja vad den ska
göra under tiden. Och den kan inte välja så speciellt mycket ändå, det
styrs ju av den aktuella koden som ska köras vad den ska göra. Så den kan
inte aktivt välja att "köra från cachen" istället för att vänta...

Med de sagt, så visst har även DMA hanteringen utvecklats sedan PDP8 tiden.
En del gör att köra multiplexat på minnesbussen med CPUns egna accesser o.s.v.

Hur som helst (det blev en lite för stor utvikning detta) så gäller det nog generellt
både för en PDP8 och för dagens processorer att DMA är snabbare än att göra
samma sak i koden direkt.

Multiplexat på minnesbussen? Mnjä. Det är ju just vad DMA är. Du läser ett diskblock från en disk. Emellanåt
kommer ett ord från disken över bussen, emellanåt kommer en access från CPUn. Samma på en åtta som
på en Alpha.
Däremot händer det ofta nuförtiden att en instruktion görs över många cykler, och att DMA accesser kan komma i "hål" under själva exekveringen av en instruktion. Det är just vad vår pipeline ger oss. Cache gör att bussen inte alls behöver bandas in, vilket lämnar den mer tillgänglig för DMA (bortsett från att cache också svarar snabbare på CPUns accesser).

Men japp, CPUn kan inte välja vad den ska göra om DMA håller bussen upptagen. Det är bara att vara god och vänta.

Så. Nu kanske vi pratat förbi varandra tillräckligt?

[bqt]

Än roligare är att det finns två typer av Data break på en PDP-8. En del riktigt gamla kontrollrar har inga register som håller adress och räknare, utan dessa ligger i det fysiska minnet istället, så varje DMA-transaktion innebär att devicet läser och modiferar adress och räknare i minnet, och sedan överför ett ord data till där adressen anger. (1-cycle data break respektive 3-cycle data break.)

Som jag förstod three cycle data break är det CPU (ALU) som sköter om att göra increment på CA och WC registren (som mycket riktigt ligger i primärminne), inte devicet. Det finns en signal på IO bussen som kontrollerar om CA ska ökas på med ett eller ej. CPU detekterar även den om det sker overflow i WC och skickar då en signal till devicet. Devicet specar bara adressen i minne där WC lagras.

Så helt utan CPU inblandning kan man nog inte säga att det är, jämfört med DMA på något modernare maskiner.

Hmm. Exakt hur det tekniskt är löst med 3-cycle databreak kommer jag faktiskt inte ihåg, men att anända den existerande ALUn verkar ju klokt.

Men det är bara en del riktigt gammalt skrot som använder denna lösning. De flesta DMA-kontrollrar för en åtta gör faktiskt inte så. Så CPU-inblandning (om man vill kalla ALUn för CPUn) är inte normalt på åttor heller.

[MiaM]

Som jag menade så var det att om CPUn är inblandad, så måste CPUn läsa data från devicet, skriva det till en address, öka den addressen, och dessutom uppdatera räknaren.

Fast om man har en 1802-CPU (som nog för övrigt är en god kandidat till en av de märkligaste massproducerade processorerna) så kan man faktiskt läsa från devicen och skriva till minnet i samma cykel, eftersom minne och i/o har separata fysiska adressbussar (om än bara ett par enstaka bitar för i/o). Dessutom räknas adresspekaren upp av instruktionen. Visst går det ändå åt cykler för att läsa in instruktionen som utför detta och det går åt en loopinstruktion o.s.v., men det lär ändå bara behöva bli 3-4 cykler för varje överföring mellan i/o och minne, med andra ord i princip i klass med "3 state break" på åttan.

[Nerre]

CPU'n har ju inte heller någon aning om att en DMA pågår, det är bara några minnesacesser som kommer
att ta lite mer tid än normalt. Så CPU'n kan inte aktivt välja vad den ska
göra under tiden. Och den kan inte välja så speciellt mycket ändå, det
styrs ju av den aktuella koden som ska köras vad den ska göra. Så den kan
inte aktivt välja att "köra från cachen" istället för att vänta...

Nej, men om CPUn har flera faser i en instruktionscykeln så kan DMA-controllern "passa på" att använda bussen när CPU är i ett steg där den inte accessar RAM.

Ett bra exempel är väl hur ABC80 hanterade bildminnet. Grafikgenereringen hade "direkt access" till grafikminnet, men CPU behövde aldrig vänta utan det satt en "buffertlösning" mellan som CPU skrev till och som sen klockade in datat i minnet baserat på vertikal synk (så den inte störde grafikgenereringen).

[MattisLind]

Men det är bara en del riktigt gammalt skrot som använder denna lösning. De flesta DMA-kontrollrar för en åtta gör faktiskt inte så. Så CPU-inblandning (om man vill kalla ALUn för CPUn) är inte normalt på åttor heller.

Hmm. I en åtta är väl ALUn nästan hela CPUn... Three cycle använder i princip allt i CPUn förutom PC, ackumulator och L. Egentligen tycker jag det är ganska smart eftersom i/o devicet blir otroligt simpelt och man kan ändå få väldigt låg latency jämfört med interrupt.

Nej, men om CPUn har flera faser i en instruktionscykeln så kan DMA-controllern "passa på" att använda bussen när CPU är i ett steg där den inte accessar RAM.

Ett bra exempel är väl hur ABC80 hanterade bildminnet. Grafikgenereringen hade "direkt access" till grafikminnet, men CPU behövde aldrig vänta utan det satt en "buffertlösning" mellan som CPU skrev till och som sen klockade in datat i minnet baserat på vertikal synk (så den inte störde grafikgenereringen).

Normalt sett kan inte ett device vänta på att CPUn ska göra något som passar så att den kan hoppa in och överföra lite grand. Kommer data från en disk så måste det in minnet innan bufferten flödar över...

[Nerre]

Jag har alltid trott att det primära syftet med DMA är att avlasta processorn, men det du beskriver är ju nåt helt annat (att man på grund av tidskritiska grejer inte har tid att vänta på ett vanligt interrupt)?

[bqt]

Jag skulle nog säga att främsta orsaken till DMA är hög överföringshastighet på data. Det var (är?) svårt att med processorn inblandad uppnå de hastigheter på dataöverföring som kan krävas. Så det kan både handla om tidskritiskt, på grund av buffertar, och rent hastighetsmässigt, man vill ha data så fort det går. Disk är ju inte det snabbaste direkt. När data väl kommer så vill man få in det så fort det går. Sedan gör det ju programmering mycket enklare med. Skönt att slippa hantera hela den delen. Om man blandar in interrupt, och hela CPUn, så sjunker hastigheten radikalt.

Då, men ännu mer nu, så är avlastning av CPUn, sett ur en rent exekverande synvinkel, inte så viktigt. En vanlig CPU i de flesta datorer sitter mest och spinner och gör inget alls nästan hela tiden i alla fall. Så ur den synpunkten så skulle ingen lida om CPUn istället skyfflade lite mer data.

[anders_bzn]

Nu tillbaks till min verklighet, jag försökte köra testet en gång till igår. Det fungerade till en början, men sen började utskrifterna se konstiga ut. Efter lite felsökning inser jag att att en bit i TX datat alltid är satt till ett!

Det som är konstigt är att det är exakt samma fel på samma bit som jag hade för ett tag sedan. Sen har det dessutom dykt ett fel på konsolen, när man trycker in 7777 och sedan "load address" så laddas adressen 7767, lustigt är att det är samma bit som felar med TX datat. Fast biten sitter fast nedåt mot noll.

Ska testa några mer saker för att få några ledtrådar till, men dessa felen måste jag fixa först. Som vanligt lite framåt och sedan ett steg tillbaks.

[anders_bzn]

Gårdagens session i labbet gav mig en insikt, maskinen är inte stabil. Den fungerade när jag först kom ut där, sen kom samma fel tillbaks. Det blev också bättre en stund när jag tog ut diskkontrollern. Troligtvis är den en trasig bussdrivare/mottagare i databussen.

Sen hände detta:

J-vla kisel hög...

[pbgp]

O_O håll ut! Tråkigt när det känns som att det går baklänges.

[anders_bzn]

Ja, kollade schemat lite. Insåg att siffrorna multiplexas ut med en räknare, avkodare och en enkel RC-oscillator. Mätte på den och det kom bara skurar med spikar ut. Sen insåg att den har en signal utifrån som kan stänga av den. Nämligen POWEROK.

Jag kunde inte släppa det så innan jag gick till jobbet var jag tvungen att mäta på den med oscilloskopet och mycket riktigt, den fladdrade upp och ner i takt med hur siffrorna blinkar på fronten.

Det förklarar också varför datorn känns instabil, när power ok signalerar att spänningen är dålig stannar CPU:n...

Så nu är jag tillbaks där tråden startade, i nätagget!