Processorvärldens Linux växer internationellt

Förvirrande rubrik även om jag förstår vad som menas. Öppen/fri arkitektur kanske?

Jag hoppas det ska komma friare alternativ tids nog. Vill äga min hårdvara, inte bara min mjukvara. Hade varit roligt att verkligen få bygga en annorlunda dator, det känns som allt är x86 och ARM just nu.

Fast hur ska man veta att det är en romersk siffra i detta fall? Säger man X-COM eller TEN-COM?

Bra fråga hur som! Jag har också sagt RISC-V (och inte five).

@sKRUVARN: Ja det krävs ett mått av insikt i per fall-basis Eftersom RISC är en etablerad instruktionsuppsättning kan V tolkas som versionsnumrering, och därmed uttalas Five (även om RISC inte fått versionsnummer fram till RISC-V).

X-COM är ju en förkortning av Extraterrestrial Combat, så där är X inte en siffra eller versionsnummer. Men som sagt, det krävs en viss kontextuell insikt för att veta

Mikroarkitekturer som implementerar RISC-V både kan och kommer nog i praktiken innehåller både licensierad och patenterad teknik, lär i alla fall gälla eventuellt kommande högpresterande modeller. Svårt att undvika.

Vad det handlar om är en öppen ISA (Instruction Set Architecture) specifikation utan licenskrav. Kompilatorstödet för RISC-V förbättras snabbt, men än så länge är det inte alls på samma nivå som x86 och ARM.

Just nivån på programvarustödet lär vara det som avgör ödet för RISC-V. Blir det bra nog lär ARM få det tufft på sikt då RISC-V på många sätt påminner om Aarch64 (64-bitars ARM). Dessa två är, givet dagens kunskap, så nära man kan komma "perfekta" ISA.

POWER har nog motlut, men här finns ju ändå en långt mer mogen programflora jämfört med RISC-V. Och även om POWER inte är en "perfekt ISA" måste det vara #3; givet dess ålder får man säga att IBM verkligen visste vad de gjorde när de designade POWER. ISA som MIPS och SPARC har inte åldrats med värdighet, absolut inte samma problem som x86 men alla dessa dras med massor med dåliga beslut (givet dagens krav, många av designbesluten var helt vettig när de togs, men ingen "fine-wine" precis...).

Femman kommer av att detta är den femte RISC designen som skapats vid Berkeley

1. RISC I (som jag tror senare blev MIPS)

2. RISC II (som utvecklades till SPARC)

3. SOAR/VLSI-BAM

4. SPUR

5. RISC-V

Alpha var en bra ide fram till att CPUer fick mer än en kärna... Precis som SPARCs registerhjul är designen för minnesoperationer i Alpha ett lysande exempel på hur rejält smarta idéer kan bli ordentliga ankare när det sker lite mer fundamentala förändringar i vad som är mest viktigt.

Alpha har också riktigt dålig kod-densitet (ett problem den delar med MIPS och SPARC, men dessa är inte fullt lika dåliga på den punkten). Ett litet problem när det begav sig, ett allt större problem ju mer RAM-latens sackar efter hastigheten hos CPU-kärnorna.

Itanium är ett exempel på att man kan göra allt enligt konstens alla regler, men ändå hamna i en dynghög. Itanium togs fram i en tid när man från akademiskt håll var övertygad om att framtiden låg i att göra mer optimeringar i programvara som kompilatorer då komplicerade breda out-of-order designer har rätt dålig prestanda vs antal transistorer skalning.

Tankevurpan det visade sig hela det spåret hade är att man bara kan ta hänsyn till statisk information för optimering, dynamiska aspekter där utfallet beror på hur den data man råkar jobba med påverkar körningen kräver av (när man är efterklok ) rätt uppenbara skäl information som bara finns när man faktiskt kör programmet.

Det RISC-V och Aarch64 (som man måste vara medveten om är en helt ny ISA från 32-bitars ARM, så finns en anledning varför ARM-prestanda först nu drar iväg så pass) är optimerat för är just att göra "IPC mot antal transistorer"-kvoten så bra som möjlig. Dessa ISA har egenskaper som möjliggör effektivt utnyttjande av väldigt många pipelines i backend, detta genom att designa instruktionerna så att de har minimalt med beroende mellan sig (hos 32-bitars ARM och än mer i x86 har tyvärr de flesta instruktioner en påverka på ett för CPU-kärnan globalt tillstånd, flag-fältet).

x86 har också problemet att överhuvudtaget vet var instruktioner börjar och slutar. μ-op cachen har flera fördelar (Cortex A77 har en μ-op$ av strömsparande orsaker), men för x86 är den helt kritisk för att kunna nå riktigt hög IPC då det är enda realistiska sättet att kunna avkoda tillräckligt med instruktioner per cykel.

Just här finns ett beslut som fundamental skiljer sig mellan RISC-V och Aarch64. Hos RISC-V kan instruktioner vara 2- eller 4-bytes, hos Aarch64 är de alltid 4 bytes. Båda har för- och nackdelar, högre kod-densitet mot enklare front-end. RISC-V är inte i närheten av x86 där instruktioner kan vara allt från 1-15 bytes (OK med variabel längd, men vem tyckte 1-15 bytes uppdelade i variabellängd-prefix, variabellängd-opkod och variabellängd-argument lät vettigt)...