Söndagsmatiné: Om RISC-V – det öppna processoralternativet

Internt ja, men det är inte så man ser på x86, det är en CISC-Cpu.

Han nämner ju att gränsen mellan CISC och RISC är väld luddig idag. Distinktionen mellan CISC och RISC har alltid varit rätt poänglös, bilden som visas i videon belyser det rätt väl

MIPS, AVR och några till stämmer väl in på RISC beskrivningen, SPARC och POWER/PowerPC börjar sudda ut den gränsen, 32-bit ARM gör beskrivningen meningslös.

32-bitars ARM skapades på 80-talet och den är långt ifrån det man kan beskriva med "kör många enklare instruktioner". ARM instruktionsuppsättningen gör rätt bra är skapa riktigt kompakt kod, detta m.h.a komplexa instruktioner. T.ex. kan alla register sparas ned med en enda instruktion (inget vare x86 eller de andra RISC:arna, inklusive ARM64, kan), en enda instruktion man både återställa alla register + utföra ett hopp tillbaka till den som anropade en subrutin. (Finns flera andra saker också).

Alla moderna x86 designer har en annan design internt, en design som stämmer bra överens med beskrivningen av RISC ovan. Men även moderna "RISC" CPUer gör samma sak, d.v.s. det tar relativt komplexa instruktioner och delar upp dem i fler enklare instruktioner internt.

De relevanta skillnaderna mellan t.ex. x86_64, RISC-V och ARM64 på ISA-nivå har implikationer även på designen av mikroarkitektur. De två viktigaste är att x86_64 kan utföra aritmetiska operationer mot RAM medan i stort sätt alla "RISC" CPUer bara kan utföra aritmetiska operationer mot register, och den för multi-core CPUer viktigaste skillnaden är vilka garantier ISA ger runt hur andra CPU-kärnor observerar operationer av en viss kärna.

Det senare har ingenting med RISC/CISC att göra, x86 och SPARC (som är/var en RISC) använder samma minnesmodell, en modell som är relativt lätt för människor att förstå sig på men som visat sig inte alls vara optimal när man började skruva upp antalet kärnor.

32-bit ARM, MIPS och PowerPC drog det hela lite för långt åt andra hållet, man försökte göra en modell som skalade bättre och som drog mindre ström men den visade sig inte heller vara speciellt optimal för den riktning utvecklingen av programspråk och tekniker för multicore tagit.

Just detta beslut kan inte ändras med mindre än att bryta kompatibilitet med alla existerande multitrådade program!!!

RISC-V och ARM64 designades i samband med att dagens idéer kring multicore togs fram, på just denna punkt använder de nära identisk design vilket är optimal för (dagens) multitrådade program.

Vad det gäller instruktioners komplexitet är RISC-V rätt mycket en vidareutveckling av MIPS, så den är lite närmare "kör fler lite enklare instruktioner", men på det stora hela är de inte mycket enklare än t.ex. x86_64.

ARM64 (som är en helt separat instruktionsuppsättning från 32-bit ARM) ligger på liknande nivå, men i genomsnitt tenderar ARM64 generera färre instruktioner än både RISC-V men även än x86_64. ARM64 är inte alls lika komplext som 32-bit ARM, men det finns en del "högre nivå instruktioner" som specifikt finns för att kompilerad kod ska kunna göras mer effektiv.

TL;DR beskrivningen av RISC vs CISC är inte bara meningslös idag, den är i fallet ARM direkt felaktig. Den distinktion man kan göra är mellan load-store designs (alla relevanta "RISC" CPUer faller i den kategorien, d.v.s. kan bara utföra beräkningar mot register) och icke-load-store designs (alla relevanta "CISC" CPUer faller i den kategorien).

RISC-V definierar en grundspecifikation och ett antal tillägg. För mikrokontrollers och små inbyggda-system kan man mycket väl kombinera dessa helt efter krav, det är normalt inget större problem.

För "vanliga" datorer har man i praktiken krav på att RV64I(64-bit stöd)+V(vector instruktioner, motsvarar SSE/AVX hos x86)+G("normala" instruktioner för heltal och flyttal upp till 64-bit)+C("komprimering" av instruktioner, d.v.s. instruktioner man vara 2 eller 4 bytes mot annars alltid 4 bytes).

Övriga utökningar får behandlas på samma sätt som x86_64 hanterar röran med utökningar där samt som ARM hanterar olika versioner (som normalt alltid är så att version V+1 är ett superset av version V). D.v.s. i praktiken skapas bibliotek som vid runtime kollar vad CPUn stödjer och väljer "optimal" variant efter detta. Missar man att kolla detta kraschar programmet (vilket händer om man t.ex. kör AVX-512 instruktioner på en CPU som saknar stöd för dessa).

Jag är övertygad att enda rimliga väg framåt för ARM är att erkänna sig besegrade av RISC-V på mikrokontrollers och CPUer för enklare inbyggda system. Ska det vara värt för ARM att befinna sig på dessa marknader måste de ta en licenskostnad som prisar ut dem mot RISC-V.

Tror nog också ARM inser detta då de specifikt pekade ut detta åt de som under ARM/Nvidia debaclet tyckte att ARM stod ju på egna ben tidigare, därför är det väl självklart att man kan göra det framåt (världen är inte statisk...).

Går att köpa 32-bit RISC-V mikrokontrollers som prismässigt ligger betydligt närmare 8-bit mikrokontrollers med stängd ISA än vad de ligger 32-bit ARM.

ARM har dock flera fördelar över RISC-V när man ställer ARM64 mot 64-bit RISC-V, så ARM måste lyckas med en omställning där man går mot allt dyrare och mer högpresterande kretsar. RISC-V är (tyvärr) rätt långt från den marknaden idag, de kan absolut nå dit, men är många år och väldigt stora investeringar bort än så länge.

Väntar fortfarande...