Bygge av Folk-CPU

[Spisblinkaren]

Jag leker lite bara

Om basen är 10 så kan vi som sämst få ett 316-procentigt fel.

Detta kommer av det kvadratiska medelvärdet mellan kvoten av två närliggande decimala tillstånd dvs SQRT(10).

Om basen är 2 så kan vi pss som sämst få SQRT(2), dvs 41%.

Medans 10^+/-64 är användbart som maximalt tal att kunna representeras är 2^+/-64 (~10^+/-20) inte lika bra.

T.ex vikten hos en elektron hamnar utanför denna gräns.

Så vi måste ta till ännu en byte.

Men då blir talet så stort så att det blir löjligt

Men vänta nu, när behöver folk i gemen räkna med vikten hos en elektron?

Så vi behöver alltså bara 8 bitars talrepresentation men samtidigt bör vi räkna binärt för annars blir (de ackumulerade) felen väldigt stora!

Samtidigt tycker jag Fermi's sätt att räkna är lysande. För när behöver man decimal precision när det gäller stora eller små tal?

Jag menar, vem bryr sig om elementarladdningen är 1,602*10^-19 Coulomb eller 10^-19?

MVH/Roger

[gkar]

Gör en tabellslagning med kvadrater, tabellen blir då relativt liten.

Om vi förlänger a*b
får vi => ((a+b)^2 - (a-b)^2)/4

a+b och a-b slås i tabell.
Dvs för att multiplicera två 8 bitars tal behövs en 9 bitarstabell.

[TomasL]

Jag menar, vem bryr sig om elementarladdningen är 1,602*10^-19 Coulomb eller 10^-19?

har en jäkla betydelse om du skall räkna.

[Nerre]

Ett sådant block är alltså den minsta minnesmängd som går åt redan vid skrivning av en fil med ett enda tecken.

Det stämmer.

Börjar förstå begreppet fragmentering nu :D

Fast det har inget alls med fragmentering att göra. Fragmentering handlar om att en stor fil delas upp i flera block som ligger utspridda över disken. Det gör att det tar längre tid att läsa in filen än om filens alla block låg efter varandra. Fragmentering får man eftersom ledigt utrymme uppstår där filer har legat och sen tagits bort. På en disk som är nästan tom brukar filerna ligga sekventiellt, men börjar disken bli full så måst utrymme återanvändas och då kan det ligga utspritt.

Det här extra utrymmet som försvinner brukar väl kallas för "slack" och i genomsnitt tappar man ett halvt block per fil. Har man många små filer bli slacket större, har man bara stora filer märks det inte lika mycket.

I moderna filsystem så kan man välja blockstorlek beroende på vad man avser lagra för filer. Ska man lagra en massa småfiler kan man välja 512 bytes block, ska man vara lagra stora videofiler kan man välja 8 kB block.

Sen har väl FAT också den bristen att att ett underbibliotek fungerar som en fil, utrymme som har allokerats till ett underbibliotek blir inte ledigt för andra underbibliotek (därför har defragmenteringsverktyg ett val att "komprimera mappar", som alltså återtar ledigt utrymme som ligger "dolt" i underbibliotek).

[Spisblinkaren]

Tack för den förklaringen!

Jag förstog allt utom det där sista.

F.ö kan jag berätta att det var först när jag försökte "skryta" för min kollega och vän om vad jag nu lärt mig hur en hårddisk är "formaterad" som jag verkligen fattade hur en HD kan bli fragmenterad.

Glömde liksom filborttagning...

MVH/Roger

[Spisblinkaren]

Gör en tabellslagning med kvadrater, tabellen blir då relativt liten.

Om vi förlänger a*b
får vi => ((a+b)^2 - (a-b)^2)/4

a+b och a-b slås i tabell.
Dvs för att multiplicera två 8 bitars tal behövs en 9 bitarstabell.

Snillrikt, men skulle du vilja vara så vänlig och förtydliga det här?

Förlängningen begriper jag.

Att tabellen behöver vara på nio bitar begriper jag också.

Men vad hjälper det att a+b respektive a-b kan slås i tabell?

För mig borde (a+b)^2/4 respektive (a-b)^2/4 stå i tabell för då återstår bara SUB.

Eller menar du att MUL/DIV ändå ska användas?

Och vad blir i så fall förenklingen med det här (sa idioten )

MVH/Roger
PS
Gray, on top of my head:

0: 0000
1: 0001
2: 0011
3: 0111
4: 1111
5: 1110
6: 1100
7: 1000

[Spisblinkaren]

Jag menar, vem bryr sig om elementarladdningen är 1,602*10^-19 Coulomb eller 10^-19?

har en jäkla betydelse om du skall räkna.

Nu är det du som är ute och cyklar

MVH/Roger

[TomasL]

Hmm, enligt ditt sätt att se det är 60% fel i beräkningar fullt acceptabelt , nja tror inte det.

[Spisblinkaren]

Jag har dock ett litet problem.
Den kan inte MUL/DIV.

Då ska du inte använda den.

Hur enkel man än vill göra en processor så är väl ändå minimikravet att sen ska klara av de fyra räknesätten. Om den bara har en ALU som kan hantera addition, subtraktion och bitshift - med carrybit - så har man grunden. Det är dessutom extremt enkelt att ordna med enkel logik, så det borde inte vara något man behöver undvika.

Klarar den inte det tror jag inte att den duger att bygga något av. Så hela tråden tycker jag bygger på ett feltänk från början.

Räcker addition, subtraktion, bitskift med carrybit för både MUL/DIV?

Orkar du ge mig länkar eller algoritmer för detta så kan jag tänka mig att uppgradera min primitiva CPU till att åtminstone ta vara på carrybiten.

Jag vägrar nämligen implementera MUL/DIV hårdvarumässigt även om det är den snabbaste metoden.

Detta främst för att jag i nuläget inte förstår hur men om man tar hänsyn till ovan så inser man snabbt att detta inte ens behövs.

Skulle jag sen nödvändigtvis vilja nyttja MUL/DIV kan jag i kompilatorn istället nyttja ADD/SUB/SHIFT/CARRY och realisera en något mer cykelineffektiv variant.

Men som sagt, folk använder i praktiken inte MUL/DIV så what's the point?

Dock är jag väldigt sugen på att uppgradera min CPU så den kan ta vara på CARRY.

Men hitintills ser jag inget akut behov.

Den största bristen med min CPU är att adressbussen är lite i minsta laget (16 bit). Dock gillar jag att databussen är på 8 bitar för det räcker enligt de av mig alla kända anledningar (t.ex ljud och tydligen talrepresentation enligt ovan).

Eftersom jag tycker 32 bitar bred adressbuss är slöseri och 16 för lite så har jag idag lurat på om inte 24 vore optimalt

Kanske man skulle bygga sig en 24/8-bit CPU istället

Känns dock lite krångligt

MVH/Roger

[Spisblinkaren]

Idag kom jag fram till att en 32/16-bitars CPU är optimalt.

Detta för att med 16-bitars adressbuss kan man nätt och jämt lagra och visa min fina svart/vita bild som var på endast 32kB.

Ihop med att 24-bitars adressbuss bara komplicerar arkitekturen har jag beslutat mig för detta.

Jag kommer mao "bara" dubblera bussarnas bredd i min FPGA-variant.

När jag ändå bestämt mig för detta så kommer jag också införa tillvaratagande av utskiftad bit (carry).

Ytterligare en något akademisk förbättring kommer nog också att ske (innebär dock ännu en kontrollsignal).

MVH/Roger

[Spisblinkaren]

Jag har ångrat mig!

Det ska bannemig bli en 24/8-bitars CPU!

Detta för att 8-bitars data är allt vad som behövs både vad gäller bilder (i gråskala) och ljud.

24-bitars bred adressbuss kan sedan adressera hela 16MB vilket är alldeles lagom perfekt!

Och ljudet behöver inte ens komprimeras utan kan samplas direkt vilket ger filer om typ 44kHz*200s~10Ms a' 1B =10MB dvs endast en faktor två större än MP3!

Och när du inte behöver komprimera filerna behövs ej heller MUL/DIV!

MVH/Roger

[Spisblinkaren]

Ytterligare en tanke.

Vem har sagt att Folkdatorn behöver återge ljud med 20kHz bandbredd?

5kHz duger ju gott.

Då är vi alltså nere i en datamängd som är halva MP3 dvs runt 2MB.

MVH/Roger

[Spisblinkaren]

Min Folkdator kommer bara att kunna återge 8-bitars ljud såväl som 8-bitars svart/vita bilder.

I min värld är detta allt som behövs.

Jag kommer dock spana in olika MUL/DIV-lösningar för att inte missa sånt som verkligen behövs.

Men jag kommer inte implementera det i min CPU så länge man kan fixa detta via den egenskrivna kompilatorn.

MVH/Roger

[stekern]

I mina öron låter det lite som du försöker anpassa ett problem till en färdig lösning du har.
I det här fallet, du saknar MUL/DIV och då funderar du på om du kan modifiera problemet till att inte behöva MUL/DIV genom att överslagsberäkna.
Detta kommer givetvis ge ett fullkomligt ointressant resultat, en överslagsräknande dator är rätt oanvändbar.

Eftersom du nu verkar tro att MUL/DIV behövs för att göra exakta beräkningar
(det är i själva verket inte fallet, du kan göra exakt multiplication och division utan hårdvaru MUL/DIV i mjukvara),
varför specar du inte din 'folkdator' till att ha MUL/DIV istället?

Det är inte särskilt komplicerat att implementera i en FPGA (vilket du säger att du kommer använda),
multiplicerare finns i de flesta FPGAer redan som färdiga block och en seriell dividerare är inte heller rymdforskning direkt.

Om inte annat kan du fritt planka från den här eco32 CPU implementationen av jag gjorde för ett tag sen =P
dividerare: https://github.com/skristiansson/eco32f ... #L155-L196
multiplicerare: https://github.com/skristiansson/eco32f ... #L198-L222

[MiaM]

Vilket förträffligt tillfälle att klämma in en infodump om datalagring på skivor

Lite flummigt funderar jag då på om det inte får plats större minnesmängd längst ut än längst in (i samma skivsektor)?

Alla skivor kan rymma mer information på de yttre än på de inre spåren.

T.ex. blir det lite bättre ljud i början på en vinylskiva jämfört med på slutet. Om man spelar 70-talets gamla vinylskivor med äkta fyrkanalljud (CD-4) med bärvågor modulerade med fram-back-skillnadsinformationen så är risken för dålig läsning av bärvågorna större längre in än i början på skivan.

Vanliga disketter som är formatterade med t.ex. en PC har samma datamängd per spår. Det gör att risken för läs/skrivfel är störst längst in. Därför har man första spåret längst ut och ofta filsystemformat där "det viktigaste" börjar på spår 0.

Disketter formatterade med t.ex. Commodores 1541 (diskdriven till t.ex. C64) (eller även de flesta andra 8-bit-diskdrives från Commodore, förutom 3,5"-driven 1581 tror jag) eller DD-disketter för Macintosh ("800k") kör olika datamängd på olika spår. I Mac-fallet körs motorn rent fysiskt i olika hastighet på olika spår. Commodore 1541 är lite fiffigare och byter klockfrekvens på elektroniken. I båda fallen är det bara ett par fasta steg som hastigheten kan varieras med, vilket gör att man får grupper om kanske något halvdussin spår där första spåret i gruppen har bäst datasäkerhet och sista spåret i gruppen har sämst datasäkerhet. Det här gör också att det inte är någon speciell poäng med att ha "viktigaste datan" i början på disketten. För att snabba upp processen att först läsa i katalogen var en fil ligger och sen läsa själva filen så ligger katalogen och listan över lediga block i mitten (spår 18 av 35 möjliga) på 1541. (Jag vet inte hur Mac gör).

Sidospår: Commodores 1541 (och dess släktingar såsom t.ex. 4040) är konstruerade på så tidig stenålder att 5,25"-disketterna bara var specade för 35 spår. Ganska tidigt ändrades specen till 40 spår och hålet för läshuvudet blev fysiskt större på disketterna. 1541's mekanik kan flytta läshuvudet över hela 40-spår-utrymmet, men det finns ingen helt lämpligt valbar klockfrekvens som ger god datasäkerhet på spår 36-40. Med hygglig kvalitet på disketterna så kan man ändå med egna hack använda dessa spår, men de används inte av standardmjukvaran i diskdriven. Lite synd, lite mer detaljer i elektroniken för en till (lägre) klockfrekvens och smärre ändring i mjukvaran hade gett 14% mer utrymme per diskett. På den tiden hade det varit värt mycket, ca 195 istället för ca 170k/diskett.

Alla moderna hårddiskar lär väl ha olika datahastighet på olika spår. Gamla hårddiskar med MFM-interface hade samma datahastighet. De första hårddiskarna med mycket enkel elektronik behövde hjälp från kontrollern för att hålla reda på vilka spår som behövde "diskanthöjning" vid skrivning, därav att man behöver ange "write precomp" (spårnummer) när man talar om för en MFM-kontroller vad den anslutna disken har för data.

Både gamla diskettkontrollers och gamla hårddiskkontrollers kunde skriva enskilda block/sektorer separat. Orsaken var att ett helt spår (en sida) rymmer drygt 5k på en diskett och än mer på en hårddisk, och det var ju rätt mycket data med dåtida mått. T.ex. har kontrollern i C= 1541 bara 2k RAM. Det här gör att det måste finnas synkmönster och mellanrum mellan varje sektor, och det äter upp en hel del utrymme. Om man skippar detta och bara har ett "mellanrum" per spår så kan man klämma in mer data. Amiga gör så om jag inte minns fel, och får därför in 11 sektorer om 512 bytes per spår, istället för de 9 PC får in. (PC går om jag inte minns fel att mixtra om att få in 10 sektorer med nåt rätt enkelt hack, fdread och fdformat tror jag programmen hette, men det var "ostandard")