Processorvärldens Linux växer internationellt

Trädvy Permalänk
Cyberman
Registrerad
Dec 1999

Processorvärldens Linux växer internationellt

RISC-V är processorvärldens motsvarighet till öppen källkod och växer sig allt mer populär som en del i moderna processorkretsar.

Läs hela artikeln här

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa leder till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jul 2001

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.

Ubuntu | 1440p IPS | 7700k | 1080ti | 32GB@3.6GHz | 960 Pro 1TB
MBP 13" Retina 2014 | iPhone 7+

Trädvy Permalänk
Medlem
Registrerad
Jun 2006

@sniglom: Det är en öppen, fri arkitektur utan några patentproblem. Vem som helst kan implementera designer, utan att behöva betala några som helst licenskostnader.

Det finns en hel rad RISCV-processorer nu, som blivit bättre och mer kraftfullare, både som mikrokontrollers och annat.

Sipeed bland annat påstår att de är en generation från att nå generisk arm-prestanda. Spännande!

Finns också en hel rad FPGA-kärnor för RISCV, som folk kört innan, och linux finns portat till det. Finns även brädor med PCIE som visats upp, där de kört lite spel på, via linuxkärnan och amd's linuxdrivrutiner som är open source.

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Mar 2007
Trädvy Permalänk
Medlem
Plats
Norrköping
Registrerad
Jan 2011
Skrivet av sniglom:

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.

RISC-V har bara en öppen instruktionsuppsättning (ISA). Arkitektur och implementation står andra företag för, dessa kan vara öppna eller stängda.

Trädvy Permalänk
Medlem
Registrerad
Okt 2013

IBM öppnade nyligen sin POWER ISA också:
https://www.nextplatform.com/2019/08/20/big-blue-open-sources...

Mac OS X - Windows - Linux

Trädvy Permalänk
Medlem
Registrerad
Jan 2019

Hoppas detta lyckas! Idag känns allt osäkert. I varje inteldator snurrar ett minix-system som inte kan kontrolleras av andra än invigda!
Antag att det blir världskrig. Hur många datasystem kommer att fungera då?

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Plats
Enköping
Registrerad
Jan 2004

Skulle vilja se något raspberry/orange/banana-pie kort till liknande pris med en risc-v processor

Skickades från m.sweclockers.com

"Applikation är ett textilt handarbete. Tygbitar sys eller limmas fast på ett underlag i syfte att bli en bild eller ett mönster"

Trädvy Permalänk
Medlem
Plats
Den mindre gnälliga delen av gnällbältet
Registrerad
Apr 2005

Dum fråga, uttalas RISC-V som V eller som 5?

Ryzen 3000.

Trädvy Permalänk
Medlem
Registrerad
Jan 2019
Skrivet av brainlessbob:

Dum fråga, uttalas RISC-V som V eller som 5?

Uttalas risk-five!

Skickades från m.sweclockers.com

Trädvy Permalänk
Lyxfällan 🎮
Andreas Eklöv
Plats
Stockholm
Registrerad
Dec 2015

@brainlessbob: Romerska siffror uttalas med ytterst få undantag med dess motsvarande siffra i det arabiska siffersystemet. Final Fantasy XII uttalas Final Fantasy Tolv, RISC-V som RISC-FEM, osv. Precis som @Irre skriver!

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Trädvy Permalänk
Medlem
Registrerad
Okt 2005
Skrivet av loevet:

@brainlessbob: Romerska siffror uttalas med ytterst få undantag med dess motsvarande siffra i det arabiska siffersystemet. Final Fantasy XII uttalas Final Fantasy Tolv, RISC-V som RISC-FEM, osv. Precis som @Irre skriver!

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).

Trädvy Permalänk
Lyxfällan 🎮
Andreas Eklöv
Plats
Stockholm
Registrerad
Dec 2015

@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

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Trädvy Permalänk
Medlem
Plats
Den mindre gnälliga delen av gnällbältet
Registrerad
Apr 2005

@loevet: Jag vet, jag var bara osäker om det var ett 'V' eller en romersk femma. Final Fantasy är rätt så uppenbart att det är vilket nummer i serien det är.

RISC är vad jag vet en klass av processor arkitektur som blandannat innefattar ARM & MIPS. Vad jag vet så finns det inga välkända arkitekturer som heter RISC II, RISC III osv. Då är det inte lika uppenbart.

Ryzen 3000.

Trädvy Permalänk
Rekordmedlem
Plats
Salstad
Registrerad
Feb 2009
Skrivet av brainlessbob:

Dum fråga, uttalas RISC-V som V eller som 5?

Risc V eller Risc Quinque.

Ryzen 5 2400G, Asus ROG STRIX B350-F Gaming, 500GB Samsung 970EVO NVMe M.2 och en väldig massa masslagring. Seasonic Focus+ Gold 650W, Antec P 180 med Schyte o Sharkoon fläktar via en t-balancer, Tittar på en Acer ET430Kbmiippx 43" 4K
Främre ljudkanalerna återges via Behringer DCX2496, högtalare Truth B3031A, Truth B2092A Har också Oscilloskop, mätmikrofon och en Colorimeter.

Trädvy Permalänk
Medlem
Registrerad
Apr 2002
Skrivet av Irre:

Uttalas risk-five!

Skickades från m.sweclockers.com

Precis. (Se https://riscv.org/risc-v-isa/ )

AMD Ryzen7 3800X || Gigabyte X570 Ultra || Evga GTX 1080Ti || Crucial Ballistix Sport 3200 64GB || Samsung 950 Pro 512GB || Samsung 960 Pro 1024GB || XB270HU 1440p IPS G-Sync

Trädvy Permalänk
Medlem
Plats
Västkusten
Registrerad
Aug 2010
Skrivet av mikgus:

Skulle vilja se något raspberry/orange/banana-pie kort till liknande pris med en risc-v processor

Skulle det finnas någon enkortsdator som är RISC-V baserad som kan konkurrera med Raspberry Pi 4 och har hyfsat bra stöd så skulle jag troligtvis köpa om priset var rimligt.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av sniglom:

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.

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...).

Skrivet av brainlessbob:

@loevet: Jag vet, jag var bara osäker om det var ett 'V' eller en romersk femma. Final Fantasy är rätt så uppenbart att det är vilket nummer i serien det är.

RISC är vad jag vet en klass av processor arkitektur som blandannat innefattar ARM & MIPS. Vad jag vet så finns det inga välkända arkitekturer som heter RISC II, RISC III osv. Då är det inte lika uppenbart.

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

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Lyxfällan 🎮
Andreas Eklöv
Plats
Stockholm
Registrerad
Dec 2015

@Yoshman: minsann, det kände jag inte till! Tack för informationen, då har jag lärt mig något matnyttigt idag också 👍

"We're with the press, hired geeks!"
Raoul Duke, Fear n' Loathing in Las Vegas

Trädvy Permalänk
Medlem
Registrerad
Nov 2019

Vi går emot en framtid då vi blir allt mindre hårdvaruberoende.
Bara se på språken.
Maskinkod = ett helvete att porta manuellt på den tid man kodade denna.
Assembler = Nu går det porta program, mindre program utan besvär, men större ett helvete som ovan.
C/fortran/pascal och allt vad språken heter, nu helt plötsligt går det enkelt att porta många av de program man kodade i assembler, men vad gör man då? Jo ännu större program och man fick samma visa med porta..
Och så har de hållit på hela tiden, nu idag är Microsoft C# Core rätt portabelt, där de rekommenderar sig att använda .Net standard om man vill göra libs som fungerar till olika plattformar.

I vilket fall det har hela tiden blivit bara enklare att porta program från olika system, men samtidigt har ens program hela tiden växt i storlek. Men ändå idag satsar många på plattformsoberoende tekniker för deras lösningar.

Om vi tar folks persondatorer så går trenden emot att de kan köra på vad för hårdvara som helst och behovet av datorkraft stagnerar. Jag tycker många persondatorer är onödigt bloatade för vad användarna använder dem trenden till, men os som chromeos etc växer sig starkare.

Det jag menar med detta är att jag tycker det är positivt med konkurrens, för min egen del så en dator med bra webbläsare, rdp/ vnc, SSH och mängder med vpn klienter så kan man utföra det mesta jobb på en server.

Trädvy Permalänk
Medlem
Registrerad
Jun 2006

@lillaankan_i_dammen: Kör du linux fungerar 'det mesta' bara out of the box för nya processorarkitekturer. Titta bara på debian.

X86, X86-64, ARM, ARM med hårdvarufpu, Arm64, MIPS32, MIPS64, MIPS32 little endian, powerpc i olika varianter, ibm's system 360.

Och det bara för arkitekturer som lovas fungera. De har exempelvis släppt stödet för många arkitekturer, men som underhålls av voluntärer, eller är experimentella:

alpha, avr32, hppa, itanium, m32, m68k, or1k, riscv (obviously), SPARC, SPARC64, sh

Det betyder inte att det är perfekt någonstans, på något håll, bara att det finns en rejäl bakgrund med mycket testning, och fördelen med det är ju att du kan köra automatisk kompilering och testning av deras över 51000 paket :).

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Aug 2001

Om man nu ska tala om fördelarna med öppen mjukvara/arkitektur bör det väl påminnas om Google.

Trädvy Permalänk
Medlem
Plats
Piteå
Registrerad
Jul 2017
Skrivet av loevet:

@brainlessbob: Romerska siffror uttalas med ytterst få undantag med dess motsvarande siffra i det arabiska siffersystemet. Final Fantasy XII uttalas Final Fantasy Tolv, RISC-V som RISC-FEM, osv. Precis som @Irre skriver!

Men jag tror han snarare undrade om V stod för fem eller för bokstaven V.

NZXT H440 | Intel i7 7700K @ 5 GHz | Asus strix Z270H Gaming | 16GB Corsair DDR4 3200 mhz | EVGA RTX 2070 Black | 512 GB Samsung Pro 850 SSD | Corsair HX750 |

Trädvy Permalänk
Medlem
Plats
Enköping
Registrerad
Jan 2004
Skrivet av GuessWho:

Skulle det finnas någon enkortsdator som är RISC-V baserad som kan konkurrera med Raspberry Pi 4 och har hyfsat bra stöd så skulle jag troligtvis köpa om priset var rimligt.

Priset är väl det stora problemet, har sett demokort med R-V processorer men priset har varit högt. Kan ju köpa en Orange pi för en hundring eller en Raspberry för några hundra till.

"Applikation är ett textilt handarbete. Tygbitar sys eller limmas fast på ett underlag i syfte att bli en bild eller ett mönster"

Trädvy Permalänk
Medlem
Registrerad
Aug 2015
Skrivet av Yoshman:

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

Vad säger du om Alfa-arkitekturen då? Enligt mig så var det synd att Intel fick HP satsa på Itanium i stället vilket dödade Alfa. Minns jag rätt så var det den snabbaste processorn ett tag.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av SAFA:

Vad säger du om Alfa-arkitekturen då? Enligt mig så var det synd att Intel fick HP satsa på Itanium i stället vilket dödade Alfa. Minns jag rätt så var det den snabbaste processorn ett tag.

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)...

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Registrerad
Jul 2015
Skrivet av Yoshman:

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)...

Compressed subset i RISC-V skiljer sig ganska mycket från Thumb läget i tidigare Aarch versioner.

RVC är enbart en lista med alias som kan bakas in ganska triviellt för att komprimera kod, det är ett helt frivilligt tillägg, men är rekommenderat för generella implementeringar (bl.a. pga. det sparar ca 20% cache).

Kretsdesignare som vill klämma ur mer prestanda kan t.ex. implementera "macro op fusion" internt, vilket enklare kretsdesigner kan ignorera helt och hållet om de vill spara på transistorer och komplexitet.

Thumb läget i Aarch är ett helt separat exekveringsläge (i stort sett en egen ISA), så för att effektivt använda det måste man undvika byten till och från det läget, opraktiskt om man vill komma åt utökningar av standard ISAn som SIMD samtidigt som man vill spara på bytes, vilket jag gissar står till stor del varför man gett upp på det med Aarch64.

En annan grej jag tror står till skuld att de gav upp på Thumb är att modern Aarch har ganska många CISC liknande kommandon, som t.ex. "LDMIAEQ SP!, {R4-R7, PC}" vilket är en "stack pop and return from a function call", definitivt mindre bytes än motsvarande i RVC men börjar sträva iväg från RISC principen.

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Trädvy Permalänk
Medlem
Registrerad
Aug 2015
Skrivet av Yoshman:

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.

Intressant om Itanium mm.
Att Alpha har dålig kod-densitet ses ju lätt på den den av GCC genererade koden, men vad är problemet med minnesoperationer vid flera kärnor?
Man nämner ju multiprocessorsystem redan i målen med arkitekturen, så man tycker ju de borde ha tänkt på det.

Off topic så finns ett litet påskägg i de ~30 sista sekunderna av ovanstående.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av SAFA:

Intressant om Itanium mm.
Att Alpha har dålig kod-densitet ses ju lätt på den den av GCC genererade koden, men vad är problemet med minnesoperationer vid flera kärnor?
Man nämner ju multiprocessorsystem redan i målen med arkitekturen, så man tycker ju de borde ha tänkt på det.

Off topic så finns ett litet påskägg i de ~30 sista sekunderna av ovanstående.

Alpha har en minneskonsistensmodell som med den specifikation vi idag använder skulle bli ineffektivt att implementera.

Kommer inte ihåg namnet på makrot i Linux-kärnan, men finns något som är en no-op på alla CPU-arkitekturer förutom Alpha just kring minneskonsistens. Aarch64 och RISC-V har klart fördel på denna punkt, dessa designades efter att programmeringsvärlden lärt sig hur en vettig modell bör se ut, så Aarch64 och RISC-V har en 1:1 mappning mot det. Alla de andra skjuter över målet med vad som synkroniseras i varje fall -> sämre prestanda än nödvändigt.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer