Bygge av Folk-CPU

Användarvisningsbild
Spisblinkaren
EF Sponsor
Inlägg: 12990
Blev medlem: 13 december 2012, 21:41:43

Bygge av Folk-CPU

Inlägg av Spisblinkaren »

Hej!

Jag börjar denna något flummiga tråd med en ide' jag fått som härstammar från en annan tråd där jag hävdat att vi behöver sansa oss vad gäller den pågående datainvecklingen och inse att under gynnsamma förutsättningar räcker en 32-bitars CPU mer än väl.

Jag har kallat denna CPU för Folk-CPU.

Det är en CPU som är och förblir en 32-bitars för "all" framtid.

Jag har preliminärt tänkt bygga en sådan CPU i FPGA-teknologi.

I bagaget har jag en åtminstone delvis fungerande CPU som jag byggt i den något mindre lämpade CPLD-teknologin.

Jag har tänkt utveckla denna mycket enkla CPU, som liknar en Motorola 6809 (om än asmycket dyrare och sämre :D), till en 32/16-bitars CPU istället.

Jag har dock ett litet problem.

Den kan inte MUL/DIV.

Den kan bara aritmetiskt R/L-skift och då utan sparande av utskiftad bit (dvs Booth-algoritmen för MUL fungerar inte).

Men idag blev jag att tänka på nåt kul.

Vi människor räknar i praktiken aldrig exakt.

Vi gör mest överslagsberäkningar, eller hur?

Så när nu vänsterskift betyder multiplikation med multiplar om två och högerskift betyder division med multiplar om två så kan man låta datorn vara "lika" skicklig på överslagsberäkningar som oss människor.

Dvs MUL/DIV behöver aldrig hårdvarumässigt implementeras!

Låt oss titta på hur fel det kan bli:

Säg att vi vill multiplicera med tre. Vi kan då ta 2 eller 4. Två ger -33% fel, fyra ger +33% fel.

Säg sen att vi vill multiplicera med 750. Vi kan då ta 512 eller 1024. 512 ger -32% fel, 1024 ger +37%

I det andra fallet väljer man naturligtvis 512 och då är det relativa felet dom båda extrema fallen emellan mer eller mindre konstant!

I det absoluta fallet blir naturligtvis felen "värre" ju större talen är men detta är ju mest intressant när det gäller ens egna pengar :D

Den mycket intressanta frågan är nu hur långt man kan komma med detta?

För hur ofta i den folkliga datavärlden måste man ta till exakta olinjära operationer som MUL/DIV?

Please educate me!

MVH/Roger
PS
Så här skulle kanske ett Assemblerprogram kunna se ut:

m X r, r->Acc A

m=multiplicand, r=multiplier

LDA r
Start: CMP #0 (Acc-Memory)
BMI $"r<0"
LDA r
CMP #2
BPL $"r>2"
LDA m
ASL
JMP $Break
$"r>2" LDA r
CMP #4
BPL $"r>4"
-
-
-

$"r<0" LDA r
NEGA
STA $r
JMP Start
$Break ...
Senast redigerad av Walle 12 september 2014, 00:54:48, redigerad totalt 4 gånger.
Anledning: Trådrubrik ändrad efter önskemål av OP
qx5
Inlägg: 1678
Blev medlem: 14 augusti 2014, 04:23:04

Re: The Human Computer

Inlägg av qx5 »

Använd vetenskaplig notation som t.ex 3,0 * 10^8. Då kan man göra räkneoperationerna mot potensen och använda "back-of-the-envelope calculation" som fysikern Enrico Fermi ofta använde.

Vill man t.ex dela ljushastigheten med elektronvolt i joule så beräknar man 10^8 / 10^-19 istället för att ta till alla värdesiffror. Istället får man "8-(-19)" osv. Haken är att felen ackummulerar för varje operation.
Användarvisningsbild
Swech
EF Sponsor
Inlägg: 4694
Blev medlem: 6 november 2006, 21:43:35
Ort: Munkedal, Sverige (Sweden)
Kontakt:

Re: The Human Computer

Inlägg av Swech »

INTEL släppte en matteprocessor för ca 25 år sedan som
körde med överslagsberäkningar i vissa fall.
Det var inte alls populärt och kostade en hel del att rätta till den buggen....
Swech

(Ändrat AMD till INTEL)
Senast redigerad av Swech 15 augusti 2014, 10:21:44, redigerad totalt 1 gång.
ds77
Inlägg: 2216
Blev medlem: 24 juli 2008, 09:38:07
Ort: småland

Re: The Human Computer

Inlägg av ds77 »

Nerre
Inlägg: 26700
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: The Human Computer

Inlägg av Nerre »

"Får den här filen plats på disken?"
"Ja, det verkar den göra."
"Oj, den råkade skriva över en massa andra filer eftersom jag inte räknade så exakt."
Användarvisningsbild
Spisblinkaren
EF Sponsor
Inlägg: 12990
Blev medlem: 13 december 2012, 21:41:43

Re: The Human Computer

Inlägg av Spisblinkaren »

Här har du fel, Nerre.

Det enda som behövs för dom där beräkningarna är linjära operationer dvs ADD/SUB.

MVH/Roger
Nerre
Inlägg: 26700
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: The Human Computer

Inlägg av Nerre »

Nja, du behöver dividera filens totala storlek med blockstorleken för att veta hur många block den kommer att ta upp.

Men det var bara ett exempel på hur "ungefärliga" beräkningar kan ställa till med problem. Jag tror det bli oerhört svårt att ha en användbar dator som bara räknar ungefärligt.

När vi människor räknar ungefärligt så har vi normalt på förhand bestämt oss för hur många värdesiffror vi behöver, och när man höll på med mer komplexa beräkningar i matten så minns jag att det var noga med att inte räkna ut en massa ungefärliga mellanresultat för ett litet fel i ett mellanresultat kunde ge stor skillnad i svaret.

Vi människor vet också när ett resultat är ungefärligt och inte och kan "räkna bättre" om vi inser att det behövs.
Användarvisningsbild
Spisblinkaren
EF Sponsor
Inlägg: 12990
Blev medlem: 13 december 2012, 21:41:43

Re: The Human Computer

Inlägg av Spisblinkaren »

Har du nåt bättre exempel på när exakta olinjära operationer behövs? :)

Skulle man t.ex kunna koppla upp sig mot internet utan olinjära operationer?

För om man kan det, skulle man kunna lägga ut nödvändiga MUL/DIV på en server nånstans...

MVH/Roger
PS
Jag kan tänka mig att t.ex bildkomprimering kräver MUL/DIV. Fast folk i allmänhet...
Nerre
Inlägg: 26700
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: The Human Computer

Inlägg av Nerre »

Med tcp/ip måste datat delas upp i paket så det ryms inom MTU, så där behöver man nog kunna dividera.
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: The Human Computer

Inlägg av xxargs »

Ett 'litet' fel infann sig i en av MS C-libbar av en viss version med felaktiga avrundningsregler (det finns flera att välja mellan även på en matteprocessor) vilket gjorde att mp3-uppspelare och kodare som kompilerades på den plattformen fungerade inte alls utan gav bara oljud och brus, tydligen var det en liten flagga fel till matteprocessorn så att det avrundades efter ekonomiska avrundningsregler som default och inte enligt det som används inom naturvetenskap - det räckte...

Vet att när man läser om numerisk analys så ägnas väldigt stor del åt just hur trunkering, avrundning och begränsande av antal värdesiffror och hur det kan propagera vidare i ofta de iterativa beräkningarna. Detta är en konst att navigera rätt där för trovärdig resultat och just oväntad trunkering med mindre antal återmatade värdesiffror än dom verkliga använda i beräkningen innan, när man skulle fortsätta en avbruten beräkning, visade vägen till det som senare kallas fraktalgeometri.
Användarvisningsbild
Swech
EF Sponsor
Inlägg: 4694
Blev medlem: 6 november 2006, 21:43:35
Ort: Munkedal, Sverige (Sweden)
Kontakt:

Re: The Human Computer

Inlägg av Swech »

Grundfrågan är väl snarare att människor lätt tröttnar på en uppgift
Beräkna 342/67 är tröttsamt
350/50 är mindre tröttsamt
För en dator är det inte tröttsamt alls, varken 342/67 eller 350/50
så det är mänskliga beteende som du försöker överföra till en maskin

Swech
Användarvisningsbild
Icecap
Inlägg: 26139
Blev medlem: 10 januari 2005, 14:52:15
Ort: Aabenraa, Danmark

Re: The Human Computer

Inlägg av Icecap »

Med logikkrets är det enklare att bygga en enhet som ändå räknar exakt. Det sparas inte heller tid vid att "slumpa" talen så jag ser inte någon nytta med funktionen. Skulle det vara något som är vettigt med detta är det i en kompiler (som ju måste ta hand om uträkningar när MPU saknas) som kan begränsa noggrannheten och då spara operationer, funktionen är alltså mest en programmeringsfråga och inte en hårdvarafråga.
Användarvisningsbild
Spisblinkaren
EF Sponsor
Inlägg: 12990
Blev medlem: 13 december 2012, 21:41:43

Re: The Human Computer

Inlägg av Spisblinkaren »

qx5 skrev:Använd vetenskaplig notation som t.ex 3,0 * 10^8. Då kan man göra räkneoperationerna mot potensen och använda "back-of-the-envelope calculation" som fysikern Enrico Fermi ofta använde.

Vill man t.ex dela ljushastigheten med elektronvolt i joule så beräknar man 10^8 / 10^-19 istället för att ta till alla värdesiffror. Istället får man "8-(-19)" osv. Haken är att felen ackummulerar för varje operation.
Det här tycker jag är helt suveränt!

Vet du vad det innebär?

Ett flyttal av idag representeras ungefär så här:

(-1)^s*m*b^q

Där s är teckenbiten, m mantissan dvs den decimala biten och q potensen på två-komplementform.

Mao lagrar man s (1 bit), m (hela 23 bit!) och q (8 bit)

där basen b faktiskt inte ens ingår utan är "valbar".

Med ditt resonemang skulle man kunna lagra s som en bit, skippa m (alltid 1) och q som ~+/-64.

Dvs att om man vill representera ett tal decimalt skulle man kunna göra det på detta sätt med begränsningen att tal utanför 10^+/-64 inte kan representeras.

Här återstår då bara frågan när tal utanför denna talmängd ens behöver kunna representeras.

Mao, när behöver man t.ex ett tal > 10^64?

På detta sätt kommer man dessutom ner i en databussbredd som inte är större än dom härliga 8!

MVH/Roger
Användarvisningsbild
Spisblinkaren
EF Sponsor
Inlägg: 12990
Blev medlem: 13 december 2012, 21:41:43

Re: The Human Computer

Inlägg av Spisblinkaren »

Nerre skrev:Nja, du behöver dividera filens totala storlek med blockstorleken för att veta hur många block den kommer att ta upp.
Rätta mig gärna om jag har fel men säg att din hårddisk är på moderna 100 GB.

Jag tvivlar starkt på att antalet block är större än 100.

Dvs varje block är på maximalt 1GB.

I min idealiserade värld handlar det inte om GB-storlekar på program utan snarare om MB.

Så jag ser inga som helst problem med detta.

Samtidigt kan man kanske fråga sig om en HD ens behöver block :)

MVH/Roger
Användarvisningsbild
Spisblinkaren
EF Sponsor
Inlägg: 12990
Blev medlem: 13 december 2012, 21:41:43

Re: The Human Computer

Inlägg av Spisblinkaren »

xxargs skrev:Ett 'litet' fel infann sig i en av MS C-libbar av en viss version med felaktiga avrundningsregler (det finns flera att välja mellan även på en matteprocessor) vilket gjorde att mp3-uppspelare och kodare som kompilerades på den plattformen fungerade inte alls utan gav bara oljud och brus, tydligen var det en liten flagga fel till matteprocessorn så att det avrundades efter ekonomiska avrundningsregler som default och inte enligt det som används inom naturvetenskap - det räckte...

Vet att när man läser om numerisk analys så ägnas väldigt stor del åt just hur trunkering, avrundning och begränsande av antal värdesiffror och hur det kan propagera vidare i ofta de iterativa beräkningarna. Detta är en konst att navigera rätt där för trovärdig resultat och just oväntad trunkering med mindre antal återmatade värdesiffror än dom verkliga använda i beräkningen innan, när man skulle fortsätta en avbruten beräkning, visade vägen till det som senare kallas fraktalgeometri.
Vill bara säga det att ditt trevliga snack är lååååångt över min kompetensnivå :D

MVH/Roger
PS
Men jag vet vad fraktaler är för nåt. Kommer ihåg en kursare som plottade Mandelbrotsmängden. Fascinerande!
Skriv svar