Bygge av Folk-CPU

[Icecap]

rogerk8: varför inte göra en (mycket) RISC istället? Om jag inte minns helt fel behöver man inte mer än 16 olika instruktioner för att kunde göra en fullt funktionsduglig CPU.

Om det sedan ska vara dumt och oanvändbart (vilket ju verkar vara ditt mål) kan du väl ha ett 12-bit ord, 4 bit för kommando och 8 för data.

Eller göra en CPU som kör brainfuck?
Man kan ganska säkert begränsa antal bits som behövs för kommandon och antal funktioner är ju intensivt få så den borde kunde jobba snabbt.

Oanvändbart och överflödigt? Javisst, alltså precis vad du söker.

[Spisblinkaren]

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.

Rätt kul att tänka tanken, dock

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?

Anledningen till detta är dels att jag bara "behärskar" grind-cad (ECS) dels är mycket osäker på hur MUL/DIV kan implementeras.

Samtidigt är ett tillvaratagande av utskiftad bit (carry), om det räcker för både MUL & DIV, en mycket lätt sak att lägga till i min nuvarande "arkitektur".

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

Jag tackar och bugar för dina fina Verilog-program. Jag lovar studera dom ingående. Men jag vill fortfarande kunna implementera dom grind-cad mässigt och detta mest för jag är rätt kass vad beträffar normal programmering. Grindar förstår jag dock som rinnande vatten.

Xilinx skall tydligen ha ett program som motsvarar ECS (CPLDs) för FPGAs. Jag ska försöka få tag i det sen blir det nog ändå en 32/16-bitars CPU av enkelhetsskäl. Detta för att min nuvarande, och faktiskt grundläggande fungerandes, arkitektur då bara behöver dubbleras portmässigt. Dock vill jag minnas att 16/8-bitar fyllde ritbordet rätt rejält...

Bifogar blockschema (no rights reserved )

MVH/Roger

[stekern]

Anledningen till detta är dels att jag bara "behärskar" grind-cad (ECS) dels är mycket osäker på hur MUL/DIV kan implementeras.

Verilog/VHDL är i stort sett bara grindar i text-form, så jag tycker inte det borde vara så mycket jobb för dig att överföra dina grind-kunskaper till det.
Dessutom finns det verktyg för att visa den syntetiserade koden i grindform. Exempelvis så följer det med sådana verktyg i både Xilinx och Alteras programsviter.
Xilinx verkar du vara bekant med, och deras verktyg heter "FPGA editor".

Som jag nämnde, i de flesta FPGAer är det 'dödsenkelt' att implementera en MUL, hårdvaru-block för detta finns redan färdigt,
det är bara att koppla in dina signaler till den.
Vill du göra en själv är det inte heller jättekomplicerat att göra en seriell multiplicerare.

Samtidigt är ett tillvaratagande av utskiftad bit (carry), om det räcker för både MUL & DIV, en mycket lätt sak att lägga till i min nuvarande "arkitektur".

Det går utmärkt att implementera mjukvaru- MUL & DIV utan carry med.
Nedan är principen för en seriell multiplikation i C (plankad från gcc).

Kod: Markera allt

unsigned int __mulsi3 (unsigned int a, unsigned int b)
{
  unsigned int c = 0;

  while (a != 0) {
    if (a & 1)
      c += b;
    a >>= 1;
    b <<= 1;
  }

  return c;
}

[Spisblinkaren]

Med FPGA-editor menas alltså att man kan få se koden realiserad i grindform typ efteråt?

Detta funkar tyvärr inte för mig.

Jag tittade t.ex en lång stund på din trevligt bifogade korta och enkla kodning av en seriell multiplicerare och jag kan berätta att jag fattade absolut ingenting. Förutom unsigned int och !=. Resten var rena rappakaljan för mig Och jag är inte intresserad av att lära mig det heller eftersom det uppenbarligen redan finns ett programspråk jag förstår, dvs grind-cad. Dessutom har man ju inte hur många liv som helst

För mitt projekt återstår således tre saker:

1) Få tag i grind-cad för FPGA (Spartan 3 preliminärt)
2) Undersöka möjligheten att blanda grind-cad med Verilog (som uppenbarligen är överlägset vad beträffar EPROM-emuleringar)
3) Bestämma mig för om (och hur) jag ska grind-cadda (så lilla jag också förstår) MUL/DIV också eller bara se till så att CPU'n kan lösa det via S/W. För faktum kvarstår, det är mycket sällan MUL/DIV behövs överhuvudtaget vid "normal" användning av en dator. Dessutom kladdar det ner designen.

Så, för att vara envis, undrar jag nog mest om tillvaratagande av carry samt inskiftning av 0:or från höger (ASL) respektive 0:or från vänster (ASR) räcker för att mjukvarumässigt kunna lösa MUL/DIV (om än något mindre klockcykel-effektivt).

Jag kommer studera detta när/om lusten faller på.

MVH/Roger
PS
Det är nåt med textbaserade programmeringsspråk som jag aldrig tyckt om. Jag vet inte vad men kanske för att dom lätt blir så nördiga och svårlästa med komplicerade variabelnamn, käcka men obegripliga pekare och funktionsdefinitioner utanför själva programmet. De programmeringsspråk jag hitintills lärt mig tycka bäst om är LabView, ECS och Assembler.

[stekern]

Så, för att vara envis, undrar jag nog mest om tillvaratagande av carry samt inskiftning av 0:or från höger (ASL) respektive 0:or från vänster (ASR) räcker för att mjukvarumässigt kunna lösa MUL/DIV (om än något mindre klockcykel-effektivt).

Ja, och det var just detta som mjukvaran som du satt och stirrade på skulle illustrera (iaf för mul, men principen för div är i stort sett den samma).
Det den även skulle illustrera var även att carry inte ens är nödvändigt, det räcker med shift, addition och and.
ASR skiftar för övrigt inte in 0:or från vänster, utan den mest signifikanta biten. LSR (Logical Shift Right) var nog vad du menade.

[Spisblinkaren]

Detta var mycket intressant!

Jag ska ta mig en seriösare titt på ditt program och be att få återkomma med frågor om det är ok?

Kanske jag tom försöker koda mig en dividerare baserad på ditt trevliga program när du nu säger att principen är densamma.

F.ö ber jag om ursäkt för min något negativa ton. Jag mår inte så bra och är ganska obstinat när det gäller att lära mig nya saker som jag lätt inbillar mig att jag inte behöver.

MVH/Roger

[MiaM]

Du kan väl kanske som en idé titta på några av de klassiska 8-bitarsprocessorerna från 70-talet, för att se hur enkla de är i förhållande till vad de lyckades uträtta. 6502 var ju den som var överlägset billigast då det begav sig, det beror väl delvis på konstruktionen men kanske också på att de pressade priserna på andra sätt.

[hassefikonkasse]

Jag tror jag har ett gäng antika processorer någonstans om dom är svåra att få tag i.

[Spisblinkaren]

Så, för att vara envis, undrar jag nog mest om tillvaratagande av carry samt inskiftning av 0:or från höger (ASL) respektive 0:or från vänster (ASR) räcker för att mjukvarumässigt kunna lösa MUL/DIV (om än något mindre klockcykel-effektivt).

Ja, och det var just detta som mjukvaran som du satt och stirrade på skulle illustrera (iaf för mul, men principen för div är i stort sett den samma).
Det den även skulle illustrera var även att carry inte ens är nödvändigt, det räcker med shift, addition och and.
ASR skiftar för övrigt inte in 0:or från vänster, utan den mest signifikanta biten. LSR (Logical Shift Right) var nog vad du menade.

Det slår mig nu som en blixt från klar himmel att AND faktiskt innebär MUL, så om:

a=1101 (13d)
b=1010 (10d)

och c=a*b där b är multiplikatorn

så borde

c0' bli 0000 (dvs 0*1101 eller att c0'(0)=b0 & a0, c0'(1)=b0 & a1, c0'(2)=b0 & a2, c0'(3)=b0 & a3)
c1' bli 1101 (dvs 1*1101)
c2' bli 0000 (dvs 0*1101)
c3' bli 1101 (dvs 1*1101)

eller

c= summan av

0000000
0011010
0000000
1101000

där varje rad är vänsterjusterat (LSL) ett steg och i övrigt bara påfyllt med nollor.

dvs 10000010 eller 130 VSV

MVH/Roger
PS
Jag kom på det i huvet att MUL ju innebär bitvis AND men sen skulle jag mha stekerns program illustrera det också.

Jag har nog suttit i två timmar utan att schematiskt kunna visa det samtidigt som jag gjorde det i ett abstrakt nafs ovan.

Tack stekern!

Återstår DIV

Mycket nöje med mitt korkade kladd

[Spisblinkaren]

Här ska ni få se på nåt roligt

Genom att försöka skriva ett multiplicerande assemblerprogram för min primitiva CPU 1.0 insåg jag rätt snart att jag saknade två saker:

1) Ett eller flera sätt att hantera och manipulera adresser (och därmed tabeller)
2) En extra accumulator att lagra en räknare i (som ju används jämt i typ for/while)

Lite kikande i min 6809-manual gav tipsen accumulatorbaserad index-addressering och auto increment/decrement.

Samtidigt är en av dom största bristerna med CPU 1.0 att accumulator-värdet skrivs över varje gång en branch-instruktion utförs.

Lösningen blir följande:

1) En extra accumulator, B (16-bit)
2) Ett indexregister, X (32-bit)
3) Immediate, Extended och Indexed vad beträffar X, A, B
4) Ett internt tempregister, T (32-bit)

där indexed bara kommer implementeras som "accumulator offset indexed" och "auto increment/decrement indexed".

Nedan följer ett roligt exempel på varför CPU 2.0 blir suverän. 3ggr snabbare, typ

Observera att hela mul-algoritmen inte är implementerad. Delprodukterna (c0'-c3') behöver vänsterjusteras och adderas också.

Intressant lärdom är dessutom att man behöver dubbla termbitbredden för att få plats med resultatet

MVH/Roger

[MiaM]

Det brukar väl finnas någon slags latchning av in- eller utdata på en ALU, som inte direkt räknas som "register" men ändå används för att mellanlanda värden t.ex. när man ska köra PC & data -> ALU - addidion -> PC. Ett sådant mellanregister behövs ju också för att kunna göra t.ex. addition mot accumulatorn. ACC & data -> ALU - addition -> ACC, typ.


P.S. för lite inspiration så kan studerande av 6502's lite lagom märkliga addresseringsmodes vara en idé? Men kopiera inte 6502's dumma idé att ha åttabitars stackpekare...

[Spisblinkaren]

Tack MiaM för att du alltid är så inspirerande!

Utan att gå för mycket in på detaljer kan jag säga att ACC & data -> ALU - addition -> ACC har jag löst genom att ha ett postregister efter min "ALU" (som i praktiken bara är en heladderare, FA) där jag kan lagra FAn's värde. Jag använder även detta postregister flitigt för mellanlagring av data (med en kontrollsignal kallad ADD_00 som alltså adderar nollor) men detta räcker inte när det kommer till bl.a brancher (där jag då måste skriva över värdet i min enda accumulator, ACC A).

Så därför ska jag ha ett regelrätt tempregister också (även om ytterligare ett indexregister kanske är mer kutym).

Nu tänkte jag försöka uppdatera mitt blockschema för CPU 2.0. Återkommer när det är klart.

MVH/Roger

[MiaM]

Varsågod

Varför räcker "postregistret" inte för en branch?

En branch är ju egentligen bara en add (eller sub) till PC.

Enda specialaren med branch är ju om man har bredare adressbuss än processorns databredd, då måste man bestämma sig för att en branch antingen sker inom samma "page" eller så måste den ske i två cykler med carry/borrow å sånt, och den flaggan vill man kanske ha i separat flaggregister för att slippa skriva över ordinarie flaggor...

[Spisblinkaren]

Om du tittar på min microprogrammering av BEQ nedan kanske du eventuellt förstår.

BR står alltså för Branch Register och den får in flaggorna N (MSN) och Z (LSN) från en operation i FA.

När godtycklig OP-kod (IRR) "fetchas" är alla register noll (dvs BR & IRC, Instruction Register Counter).

Om instruktionen är en branch sätts kontrollsignalen Branch till ett och flaggorna ovan latchas in.

Beroende på flaggvärdena utförs sedan branchen eller också stegas bara PC upp.

Som synes av mina noteringar så laddas A med offset dvs rr (2-kompl) varvid det gamla värdet redan där skrivs över. Dessutom laddas sedan A med PCHB.

Postregistret används naturligtvis för mellanlagring av additionerna men ovanstående visar att det vore käckt att ha ytterligare ett internt tempregister istället för A så att branch-uträkningarna inte påverkar A och att man därför kan göra nya CMP och brancher på samma värde.

Nu spånar jag bara...

Eller kanske det är onödigt? För varför måste man göra ytterligare en branch? Är det inte rätt naturligt att A-värdet skrivs över vid en branch?

Vid nyttjande av två accumulatorer känns det dessutom som om att det bara är A som ska användas. Annars blir det ju en BEQ med nyttjande av A eller en BEQ med nyttjande av B. I vilket fall som helst kommer endera skrivas över.

Här känns det faktiskt som om T är berättigat.

Oj, vad mycket detaljer det blev

MVH/Roger
PS
H är förresten inte "Half Carry" utan "Byte Carry". Jag har bara lånat uttrycket

[stekern]

Jag har lite svårt att följa med i alla förkortningar, t.ex. PCHB = PC High Byte?
Hursomhelst verkar det verkligen bakvänt om en branch skriver över accumulatorn.
Och, tar det 10 klockcycler för att utföra en branch?(!)