De opmars van RISC-V

Op weg naar opensource-processors

Tot slot

Risico's

In de kracht van het open karakter van RISC-V ligt ook het gevaar: er zijn geen validaties, en geen vereisten voor compliance aan de standaard. Er is overigens wel een compliance-programma, maar verplicht is het niet. Dat brengt weer mogelijke compatibiliteitsproblemen met zich mee, maar het zou ook versnippering mogelijk maken. Het staat bedrijven namelijk vrij de RISC-V-ISA te nemen, een fork te maken en hun eigen smaak te ontwikkelen. Zo zou Nvidia of WD zomaar een eigen fork kunnen maken en geen bijdragen meer leveren aan de ISA.

En juist bijdragen aan de ISA maken het potentieel zo sterk, en bovendien zijn ze hard nodig. Zo zijn er nog geen cruciale features, zoals ondersteuning voor cryptografie, virtualisatie of zelfs simd, hoewel daar wel aan wordt gewerkt. Wel zijn er optionele extensions, analoog aan bijvoorbeeld de sse- en mmx-entensies van x86, zoals bijvoorbeeld voor floating point- ondersteuning.

Een argument dat RISC-V wegens zijn volledige openheid inherent veiliger zou zijn dan meer gesloten ISA’s houdt geen stand. Wie zich zorgen maakt om eventuele backdoors van overheden of andere organisaties dan wel individuen, is niet vanzelfsprekend gevrijwaard van risico’s met een open ISA. Er moet immers nog altijd een microarchitectuur worden ontworpen op basis van de ISA, en die microarchtectuur moet in silicium worden gerealiseerd. In die realisatiefase kunnen beveiligingsrisico’s worden geïntroduceerd, hoewel meer openheid uiteraard altijd gewenst is.

RISC-V als opensource-ISA heeft tal van voordelen, maar ook flinke valkuilen. De beschikbaarheid van een vrij toegankelijke architectuur waaraan iedereen kan bijdragen om de standaard verder te ontwikkelen is een mooie extensie van het opensource- en open hardware-principe. Zo makkelijk en laagdrempelig als dat voor iedereen met een pc is voor software, is dat voor hardware niet het geval. Het ontwikkelen van microarchitecturen en chips is, hoe opensource en vrij toegankelijk de ISA ook is, nog altijd een kostbare aangelegenheid. Daarmee is het voor lang niet iedereen weggelegd chips te ontwerpen, maar het gebruik van producten op basis van RISC-V staat iedereen vrij.

RISC-V voor de hobby

Daar komen steeds meer producten voor op de markt, waaronder ook producten die voor eindgebruikers interessant genoeg zijn om mee te experimenteren. Om een paar voorbeelden te noemen: SiFive heeft een mitx-bordje met vier U74-cores en een S7-core aangekondigd. Deze Big.little-configuratie wordt gecombineerd met 8 GB ddr4-geheugen, onboard netwerk en usb 3.2-poorten. Met een prijskaartje van bijna zeshonderd euro is het instappen wel prijzig, maar het kan veel goedkoper. De tak van Alibaba die verantwoordelijk is voor RISC-V-ontwikkeling, T-Head, heeft een soort Raspberry-kloon aangekondigd met een XuanTie C906 singlecore-processor aan boord. Met ondersteuning voor onder meer Debian-linux, usb- en hdmi-poorten en een micro-sd-kaartlezer en ten minste 256 MB geheugen aan boord zou dat een leuk testplatform voor RISC-V voor hobbyisten kunnen worden. Het leukste aan het bordje is de prijs: die zou twaalfeneenhalve dollar worden.

De komende jaren zullen moeten uitwijzen hoe RISC-V zich verder ontwikkelt en wat de grote bedrijven erachter doen. Als iedereen een eigen variant afsplitst en achter gesloten deuren doorontwikkelt bloedt het initiatief langzaam dood. Maar als het concept, net als het grote software-voorbeeld Linux, omarmd wordt door de industrie, kan RISC-V uitgroeien tot een waardevol alternatieve architectuur.

Reacties (140)

[dmantione]

Het is een beetje spijtig dat tegenwoordig niemand meer assembler kent, want de enige manier om een instructieset te bekijken is om naar de instructies zelf te kijken. Ik ben dan van oude stempel en "spreek" de assemblertalen van de nodige processoren, dus kan de instructieset wel op zijn merites beoordelen.

En mijn oordeel over RISC-V is niet postief, vernietigend zelfs: RISC-V maakt mijn inziens dezelfde fouten als MIPS. RISC-V is net als MIPS:

• Een load-store-architectuur
• Een architectuur met 32 registers
• Een architectuur met zeer weinig adresseermodes
• Een architectuur zonder voorwaardelijke instructies

Met name het gebrek aan adressseermodes is kwalijk: Het gevolg van het gebrek daaraan is dat voor veelvoorkomende bewerkingen in programmeertalen, zoals het indexeren van arrays, extra registers en instructies nodig is om het geheugenadres te berekenen waar gelezen moet worden. Als je dus in een lus arrays doorloopt en de compiler de index niet naar een pointer kan omzetten dan moet keer op keer binnen de lus de extra instructies uitgevoerd worden. De MIPS en RISC-V hebben dus lekker veel registers, maar ze hebben ze ook nodig ook.

Minder kwalijk doch zeker relevant: Processoren hebben tegenwoordig lange pijplijnen, het vermijden van brand-instructies brengt dan ook veel op. Voorwaardelijke instructies zijn dan ook een belangrijk middel om branches te voorkomen.

Het oorspronkelijk idee achter MIPS, was dat het gebrek aan rekenkracht per instructie de processor zover versimpelde dat dit door een hoge kloksnelheid gecompenseerd zou kunnen worden. Dit is nooit waargemaakt en daarmee was MIPS gedoemd de strijd te verliezen. Voor RISC-V geldt nu hetzelfde.

Als we kijken naar de dominante architecturen X86 en ARM dan hebben deze architecturen hun adresseermodes en voorwaardelijke instructies op orde. ARM deed dat reeds vanaf het begin, X86 heeft zich in de loop der tijd op orde gebracht. De enige kwestie waar RISC-V in het winnende kamp zit, is dat het een load-store-architectuur is. X86 is nog altijd een registergeheugenarchitectuur en dat levert X86 nog altijd een (relatief beperkt) nadeel op. ARM is wel load-store.

Kortom, ik zou als ik een berg geld had om te investeren nooit op RISC-V inzetten: Ja de architectuur is gratis, maar je hebt gewoon een architectuurnadeel t.o.v. X86 en ARM. Dat is wellicht met bruut geweld (kloksnelheid, heel veel kernen) enigszins te compenseren, maar als je voor een exotische architectuur kiest dan wil je dat die een voordeel is, geen nadeel.

[koelpasta]

Een architectuur zonder voorwaardelijke instructies

Hoezo? Er zitten toch gewoon conditional instructions in de diverse RISC ISA's?
Hoe zou een processor moeten werken zonder voorwaardelijke instructies?

Met name het gebrek aan adressseermodes is kwalijk: Het gevolg van het gebrek daaraan is dat voor veelvoorkomende bewerkingen in programmeertalen, zoals het indexeren van arrays, extra registers en instructies nodig is om het geheugenadres te berekenen waar gelezen moet worden. Als je dus in een lus arrays doorloopt en de compiler de index niet naar een pointer kan omzetten dan moet keer op keer binnen de lus de extra instructies uitgevoerd worden. De MIPS en RISC-V hebben dus lekker veel registers, maar ze hebben ze ook nodig ook.

Ja, maar dat is toch ook het hele idee achter een RISC architectuur?
De instructies zijn simpler en korter dus per instructie doe je minder werk vergeleken met een CISC maar verbruik je ook minder stroom en die oppervlak.
Huidige intel architecturen hebben zo te lezen 14 staps pipelines. Dan is het een behoorlijke hit om je pipeline leeg te maken.
De pipeline in die RISC-V lijkt 5 stappen diep te zijn. Dan is het nog niet zo erg om de pipeline vanwege een branch te flushen.
Daarnaast, er is ook nog de compiler.
Bijna niemand programmeert meer in assembly. Er worden hogere talen gebruikt.
RISC architecturen in zn algemeenheid leunen op de intelligentie van compilers. Compilers kunnen de staat van de CPU deels voorspellen en daardoor optimale(re) reeksen instructies genereren.
De compiler zorgt er dus voor dat die pipeline optimaal gevuld blijft. Je kunt op basis van wat jij schrijft helemaal niet zeggen dat die lus waar je het over hebt trager loop op een RISC-V cpu vergeleken met een x86 cpu. Het zou kunnen, maar dat kunnen we niet opmaken uit wat jij aanhaalt.

Verder lees ik op wikipedia dat de (enige) addresseringsmode van de RISC-I (eerste RISC architectuur) al van het type 'BASE + OFFSET' is.
De addresseringsmode die je nodig had voor je lusje zat dus al vanaf het begin in de RISC architectuur.

Minder kwalijk doch zeker relevant: Processoren hebben tegenwoordig lange pijplijnen, het vermijden van brand-instructies brengt dan ook veel op. Voorwaardelijke instructies zijn dan ook een belangrijk middel om branches te voorkomen.

Ja, maar welke processoren hebben zo'n lange pipeline ? (hint:x86)
En mischien meer relevant, hoe lang in de pipeline in een RISC-V architectuur?

De enige kwestie waar RISC-V in het winnende kamp zit, is dat het een load-store-architectuur is. X86 is nog altijd een registergeheugenarchitectuur en dat levert X86 nog altijd een (relatief beperkt) nadeel op. ARM is wel load-store.

Gek, want bovenin noem je de load/store architectuur van MIPS een vernietigend nadeel:

RISC-V maakt mijn inziens dezelfde fouten als MIPS. RISC-V is net als MIPS:

-Een load-store-architectuur

Dus is het nou een voordeel of een nadeel? Wat zijn de alternatieven?

[dmantione]

Hoezo? Er zitten toch gewoon conditional instructions in de diverse RISC ISA's?
Hoe zou een processor moeten werken zonder voorwaardelijke instructies?

Ik maak hier verschil tussen een branch, zoals op de ARM BEQ, BLT enz. en voorwaardelijke instructies zoals op de ARM ADDEQ, ADDLT, enzovoorts. Een klassiek voorbeeld is het algoritme voor de grootste gemene deler in ARM-code:

gcd:
cmp r0, r1
beq klaar
subgt r0, r0, r1
suble r1, r1, r0
b gcd
klaar:
bx lr

Probleer dit maar eens naar MIPS te vertalen en je snapt waarom dit ARM zo krachtig maakt.

Ja, maar dat is toch ook het hele idee achter een RISC architectuur?
De instructies zijn simpler en korter dus per instructie doe je minder werk vergeleken met een CISC maar verbruik je ook minder stroom en die oppervlak.

Traditionele CISC, zoals iemand anders hier schrijft, is de VAX het meest klassieke voorbeeld, maar in zeker zin ook de klassieke x86, voeren instructies uit via een microcode. Het idee achter RISC is de instructieset zo te ontwerpen dat geen microcode meer nodig is en alle instructies in hardware uitgevoerd kunnen worden.

De kwestie RISC/CISC zegt niet noodzakelijk iets over de hoeveelheid werk die een instructie verzet. Een ARM verzet vaak meer werk per instructie dan een X86, maar toch heet het ding de Acorn Risc Machine. En mijn inziens terecht, omdat ook een complexe monsterinstructie als ADDLT R0,R2,R4 ROR #16 gewoon hardwarematig uitgevoerd kan worden: De barrelshifter die de ROR uitvoert en de logica om de optelling uit te voeren zijn opgenomen in de pijplijn; er is geen microcode nodig.

Wel zou ik stellen dat MIPS een fundamentalische RISC is, juist omdat het heel minimalistisch is ontworpen en het de oorspronkelijke RISC-ideeën nauw volgt. De ontwerpers van de ARM waren op de hoogte van RISC, maar ze hadden een 6502-achergrond, wat ze mogelijk geholpen heeft om het belang van krachtige adresseermodes te zien. De pijplijn van een ARM-processor is weliswaar wat complexer dan die van een MIPS-processor, maar je hoeft dusdanig veel minder instructies uit te voeren dat het dat meer dan waard is.

Huidige intel architecturen hebben zo te lezen 14 staps pipelines. Dan is het een behoorlijke hit om je pipeline leeg te maken.
De pipeline in die RISC-V lijkt 5 stappen diep te zijn. Dan is het nog niet zo erg om de pipeline vanwege een branch te flushen.

Dat lijkt me juist: Bij een pijplijn van 5 stappen is de noodzaak voor voorwaardelijke instructies nog niet zo groot. Vraag is of dat vol te houden is: Naar mate je hogere frequenties wilt bereiken, moet de pijplijn langer worden en die hoge kloksnelheid is nu net zo essentieel voor een fundamentalische RISC-architectuur als RISC-V.

Daarnaast, er is ook nog de compiler.
Bijna niemand programmeert meer in assembly. Er worden hogere talen gebruikt.
RISC architecturen in zn algemeenheid leunen op de intelligentie van compilers. Compilers kunnen de staat van de CPU deels voorspellen en daardoor optimale(re) reeksen instructies genereren.
De compiler zorgt er dus voor dat die pipeline optimaal gevuld blijft. Je kunt op basis van wat jij schrijft helemaal niet zeggen dat die lus waar je het over hebt trager loop op een RISC-V cpu vergeleken met een x86 cpu. Het zou kunnen, maar dat kunnen we niet opmaken uit wat jij aanhaalt.

Compilers kunnen veel, maar je kent er nu magische krachten aan toe. Neem een data-afhankelijke beslissing, bijvoorbeeld je converteert een string naar hoofdletters. Voor ieder teken van de string moet bepaald worden of dat teken alfabetisch is. In een tekst zoals ik hier tik zijn de meeste tekens alfabetisch en dus zal de branch-voorspelling kunnen helpen, maar zodra er een spatie, punt of komma volgt, gokt de branch-voorspelling mis: Dan krijg je een pipeline-stall. Met voorwaardelijke instructies heb je dat probleem niet: Je hebt geen branch dus gokt de processor ook nooit mis: De processor met voorwaardelijke instructies heeft een architectuurvoordeel. Of de machinetaal door een mens of door een compiler geschreven is heeft hier geen enkel invloed op.

Verder lees ik op wikipedia dat de (enige) addresseringsmode van de RISC-I (eerste RISC architectuur) al van het type 'BASE + OFFSET' is.
De addresseringsmode die je nodig had voor je lusje zat dus al vanaf het begin in de RISC architectuur.

Nee, want bijvoorbeeld:

var a:array[0..255] of cardinal;

begin
t:=0;
for i:=low(a) to high(a) do
t:=t+a[i]
end;

De cardinal is 4 bytes groot. Het geheugenadres van het te lezen element is dan ook basis + 4 * index en daar heeft de RISC-V geen adresseermode voor. Die moet de 4* index in een hulpregister berekenen, dus dat is een extra move, en een extra shift, 3 instructies nodig voor wat X86 en ARM in 1 instructie kunnen.

Ja, maar welke processoren hebben zo'n lange pipeline ? (hint:x86)
En mischien meer relevant, hoe lang in de pipeline in een RISC-V architectuur?

X86 spant beslist de kroon vanwege de extreem complexe barok-instructieset. Maar in beginsel geldt dat zodra de frequentie omhoog gaat, de pijplijn groeit. Het is heel eenvoudig: Sommige bewerkingen, bijvoorbeeld vermenigvuldigen en helemaal delen, vereisen heel veel transistorschakelingen. Bij een hoge kloksnelheid kun je minder transistoren laten schakelen per klokpuls, dus moet je het op een gegeven moment gaan verdelen over meerdere pijplijnstadia.

Als er al RISC-V-processoren zijn die enigzins kunnen wedijveren met koerante X86- en ARM-processoren ben ik heel benieuwd naar de hoeveelheid pijplijnstadia. Dat zullen er geen 5 zijn.

Gek, want bovenin noem je de load/store architectuur van MIPS een vernietigend nadeel:
Dus is het nou een voordeel of een nadeel? Wat zijn de alternatieven?

Dan hen je me op dit punt verkeerd begrepen: Load-store is een kenmerk van MIPS en RISC-V en ik vermeld het als één van de kenmerken van RISC-V, niet als een nadeel: Ik geef pas in het stuk erna een oordeel over die kenmerken. Over load-store is dat oordeel positief, anno 2020 kunnen we stellen dat een load-store-architectuur een beter idee is dan een registergeheugenarchitectuur.

Bestaan er nog meer alternatieven? Als we het hebben over krachtige processoren niet. Maar, bijvoorbeeld, bij de AVR-architectuur zijn geheugen en registers één en hetzelfde. Een dergelijke architectuur is zinvol voor microcontrolers, waarbij processor en geheugen in één chip samen zitten. De 6502 zit in het andere extreem: In beginsel is de 6502 registergeheugen, maar hij gaat nog een stap verder, via de zeropage-adresseermode kan een deel van het hoofdgeheugen een functie krijgen die registers hebben.

[Reactie gewijzigd door dmantione op 23 juli 2024 09:48]

[.oisyn]

Een ARM verzet vaak meer werk per instructie dan een X86

Conceptueel ja. Onder water is het uitvoeren van een x86 instructie op een moderne CPU vele malen complexer dan dat, door oa register renaming en out of order - en speculative execution

[Icelus]

Ik maak hier verschil tussen een branch, zoals op de ARM BEQ, BLT enz. en voorwaardelijke instructies zoals op de ARM ADDEQ, ADDLT, enzovoorts. Een klassiek voorbeeld is het algoritme voor de grootste gemene deler in ARM-code:

Probleer dit maar eens naar MIPS te vertalen en je snapt waarom dit ARM zo krachtig maakt.

ARM64 is hier ook vanaf gestapt en heeft geen conditional execution.

The A64 instruction set does not include the concept of predicated or conditional execution. Benchmarking shows that modern branch predictors work well enough that predicated execution of instructions does not offer sufficient benefit to justify its significant use of opcode space, and its implementation cost in advanced implementations.

https://www.element14.com.../ARM.Reference_Manual.pdf

[dmantione]

Ze zijn niet zo maar verwijderd, maar vervangen door voorwaardelijke selectie:

https://developer.arm.com...ional-select-instructions

Je kunt dus nog gewoon branch-instructies vermijden.

De motivatie klopt op zich: Voorwaardelijke instructies zorgen dat de instructie pas uitgevoerd kan worden als de vorige bekend is, omdat de instructie afhankelijk is van de vlaggen, dus als je een "out of order"-processor hebt, zet dit een beperking op hoeveel instructies je parallel kunt uitvoeren. Dat betekent evenwel niet dat branches beter zijn: Bij een branch weet je niet wat de volgende instructie is die je moet uitvoeren, dus ook dat is een enorm obstakel voor "out of order".

Branchvoorspelling helpt natuurlijk, maar bij data-afhankelijke branches kun je proberen te voorspellen wat je wilt, als de data willekeurig is, valt er niets te voorspellen. Ze zijn bij ARM slim genoeg om dit te onderkennen en dus was een alternatief nodig: Voorwaardelijke selectie. Voorwaardelijke selectie gebruikt de vlaggen niet en is dan ook vriendelijk voor "out of order". X86 heeft (nog) geen voorwaardelijke selectie en dus loopt ARM op dit punt voor op X86.

Een nadeel van voorwaardelijke selectie is dat meer instructies nodig zijn dan bij voorwaardelijke instructies. Voor situaties waarbij een processor "in order" is (processoren voor lichte taken) hebben voorwaardelijke instructies dan ook de voorkeur boven voorwaardelijke selectie.

Dit is dus zeker geen kwestie dat MIPS/RISC-V het goed hadden en ARM fout, maar eerder dat ARM nog weer een stap verder is.

[Immutable]

Welke ISA denk je dat het meest geschikt is voor extreme multicore cpu's? Stel voor duizenden en duizenden cores?
X86? ARM of RISC-V
Welke zou jij dan kiezen van de 3?

[dmantione]

Op dit moment denk ik X86, omdat X86-processoren instructies hebben gekregen voor hardwarematige threadsynchronisatie. Dat komt omdat X86 voorloopt bij processoren met veel kernen. Inmiddels zijn er ook ARM-processoren met heel veel kernen en twijfel ik er niet aan dat ARM zal volgen, als ze dat al niet gedaan hebben, want zo dicht zit ik ook niet op het nieuws.

Kleine nuance is bij de verbinding tussen de kernen: Bijvoorbeeld het Japanse team achter de K Computer heeft heel veel kundigheid heeft met netwerken tussen processoren in computers met enorme hoeveelheden kernen. Dat team gebruikte de SPARC-architectuur en nu de ARM-architectuur. Andere processorfabrikanten zullen zich hier ook in moeten gaan verdiepen als de hoeveelheid kernen verder groeit.

[Fiander]

Kleine aanvulling, Intel had een videokaart ( ik geloof Larrabee ofzo ) met 24 x86 cores en 4 weg hyperthreading.
Het was de bedoeling dat deze naar de 80 cores zou schalen.

helaas gecanceld als videokaart, maar daarna een doorstart gekregen als Xeon Phi, helaas ook is deze dit jaar ook gecanceld.

[Immutable]

Dan ben ik benieuwd dus, naar de reden om dat te cancelen. Is dat technisch? Of was de investering het niet waard. Toch wel interessant die hele CPU business. Straks krijg je enorme groei in "edge" computing waarbij dus performance per watt, en systeem talen beide enorm interessant beginnen te worden. Gaan we weer afstappen van VM's zoals JVM en .NET runtime puur omdat we op de edge zoveel mogelijk computing power uit heel weinig energie willen pompen.
Ik zie daarin dus systeemtalen enorm weer terug komen, die harde binaire output genereren met weinig resources die ze gebruiken. Kosten besparing op hardware via RISC-V kan wel een doorslag geven vanwege de opensource karakter. Linux draait ook werkelijk overal. Daarnaast heb je nu een taal zoals Rust die heel wat beter met multi-cores omgaat dan C en C++. Bij low resources heb je praktisch alleen de keuze uit C en C++, daar is nu een derde bij gekomen dat chips met multi-cores veel beter in het gereel kan houden.

[dmantione]

Intel is met de MIC-architectuur gestopt, omdat niemand het wilde hebben. De verkoopcijfers van MIC zijn echt schrikbarend laag geweest, alleen aan wetenschappers die in exprimentjes geïnteresseerd waren kon men ze slijten.

MIC beloofde dat, omdat het X86 was, je je code niet hoefde te porteren. De problematiek was, dat de Atom-kernen van de MIC zo traag waren, dat als je je code niet opnieuw schreef, de hoeveelheid prestaties die je eruit haalde slecht was. Wilde je wel je code omschrijven, dan werd het opeens extreem complex, waarbij een MIC een kleine hoeveelheid snel en een grote hoeveelheid conventioneel geheugen had. Je code daarvoor geschikt maken was vaak veel meer werk dan het naar een GPU omschrijven, die sowieso meer rekenkracht dan een MIC had.

[Fiander]

Het waren/zijn wel x86 cores, maar het er zit geen Out-of-order executie in, en de 512 vector processing is NIET de zelfde als van een reguliere x86. juist dat laatste zorgt ervoor dat om performance te krijgen, je echt wel iets moest doen.

[kdekker]

Er zijn zeker wel krachtige andere processoren, vb SPARC en POWER. Beide volgens mij RISC, maar het onderscheid RISC/CISC is door de jaren heen kleiner geworden. Ook RISC processoren hebben complexe instructies. De pipeline diepte van SPARC/POWER ken ik niet en programmeren in assembly doe ik gelukkig niet meer.

[dmantione]

Power is al een betere instructieset op het gebied van adresseermodes dan MIPS en RISC-V, maar niet zo goed als X86 en ARM. Wat PowerPC wel erg goed doet zijn de vlagregisters. Dat maakt Power van alle architecturen het best geschikt voor "out-of-order" en uit Power-code zal dan ook meer parallelisme gehaald kunnen worden. Dat is het voornaamste argument nog voor de Power-architectuur.

SPARC voldoet niet meer aan de huidige inzichten voor een goede instructieset. Het is ook niet bijgehouden, dus verouderd. We kunnen het dan ook best zo snel mogelijk vergeten.

[tonkie_67]

Ben blij dat je hierboven verdere uitleg mbt 1e reactie geeft want (ook) ik las dat je load-store als 1 vd grote nadelen noemde en niet als een algemene eigenschap.
Wellicht proberen om dergelikke lange en gedetailleerde reacties pre-post nog eens door te lezen en je in de lezer te verplaatsen om zo mogelijke onduidelijkheden vooraf eruit te filteren...

[Hans1990]

Huidige intel architecturen hebben zo te lezen 14 staps pipelines. Dan is het een behoorlijke hit om je pipeline leeg te maken.
De pipeline in die RISC-V lijkt 5 stappen diep te zijn. Dan is het nog niet zo erg om de pipeline vanwege een branch te flushen.

Je maakt hierin de aanname dat een ISA ook een implementatie is. Wie schrijft voor dat een RISC-V processor 5 pipeline stages moet hebben? Wie schrijft Intel dat voor? Immers zijn zij daar ook op teruggekomen tussen de P4 en Core series

Daarnaast, er is ook nog de compiler.
Bijna niemand programmeert meer in assembly. Er worden hogere talen gebruikt.
RISC architecturen in zn algemeenheid leunen op de intelligentie van compilers. Compilers kunnen de staat van de CPU deels voorspellen en daardoor optimale(re) reeksen instructies genereren.
De compiler zorgt er dus voor dat die pipeline optimaal gevuld blijft. Je kunt op basis van wat jij schrijft helemaal niet zeggen dat die lus waar je het over hebt trager loop op een RISC-V cpu vergeleken met een x86 cpu. Het zou kunnen, maar dat kunnen we niet opmaken uit wat jij aanhaalt.

Dit is geen argument. Handwerk is inderdaad nog zeldzaam, misschien wat hand-coded routines voor gebruik van extra instructiesets die de compiler niet standaard genereert. Tegelijkertijd; een compiler kan maar zulke snelle of compacte code genereren als de features die in de ISA beschikbaar zijn. Als een processor addressing modes mist, dan moet het extra instructies generen om dat dus te doen. En dan komen we precies uit op je volgende punt:

Verder lees ik op wikipedia dat de (enige) addresseringsmode van de RISC-I (eerste RISC architectuur) al van het type 'BASE + OFFSET' is.
De addresseringsmode die je nodig had voor je lusje zat dus al vanaf het begin in de RISC architectuur.

Je linkt naar een MIPS artikel. Een base + offset load addressing is erg primitief, er zijn nog talloze meer die veel gebruikt worden. Het is vrij gebruikelijk, vooral als je met strings gaat werken, om de pointer of de offset per read te incrementen. In een RISC ISA met 1 addressing mode, moet er na een MOV alsnog een ADD volgen. Met complexere addressing modes kan dat in 1 instructie. In tight loops, wat bijvoorbeeld in een strlen(), strcpy() of andere string operaties vaak het geval is, bespaar je al gauw tientallen procenten.

En dan komen we op een stukje efficientie aan; de hardware *in* de processor bestaat uit een losse memory load/store unit en een losse ALU. Waarom zouden we paar bits of transistors besparen om die niet *tegelijk* aan het werk te zetten? Het encoderen/decoderen van instructies kost ook energie, en is zelfs aanzienlijk veel meer dan het daadwerkelijk rekenen van een "computer". De welbekende CISC vs RISC trade-off met werk/instructie of aantal instructies is zeker waar, tot op zekere hoogte. Je zou ook geen 4-bit adder meer gebruiken om met 64-bit getallen te werken.

En waarom is RISC-V dan zo ontworpen? Nou ik denk om een andere reden:

Ja, maar welke processoren hebben zo'n lange pipeline ? (hint:x86)

Zelfs een ARM Cortex-m4 processor heeft al conditional branches, en dat is een korte pipeline (3 of 5 stages meen ik). Ik heb meerdere malen gezien in mijn eigen onderzoek werk dat ik daardoor een decoding algoritme met ruim 2x zo weinig instructies kan laten compilen, puur omdat er geen branches nodig zijn. De keuze uit een Cortex-m0+ of m4 processor is dan gauw gemaakt, ondanks dat de m0+ enkele tientallen procenten zuiniger is. Echter om dat verschil te compenseren, zou die processor ruim 2x zo zuinig moeten zijn.

Nu is dat 1 gebruikscenario, maar er is dus een goede reden waarom een partij als ARM niet slechts 1 core design levert. RISC-V heeft wel instructieset extensies, maar dat zijn eigenlijk het terugbrengen van instructies die omwege transistorcount er uit zijn gesneden. Bijvoorbeeld de meest simpele RISC-V processor die je kan bouwen heeft niet eens integer multiplier. Dat bespaard veel transistors (=kosten), en dat kan ook als je code die niet nodig heeft. Maar heel snel is het niet, en zowat elk modern higher-level programma maakt er gebruik van (bvb array of structs addresseren).

[Reactie gewijzigd door Hans1990 op 23 juli 2024 09:48]

[PPie]

RISC-V is net als MIPS:
Een load-store-architectuur
Een architectuur met 32 registers
Een architectuur met zeer weinig adresseermodes
Een architectuur zonder voorwaardelijke instructies

De eerste 3 beschrijven RISC: Load-store, veel registers en weinig addressing modes.
Alle vier beschrijven ARMv8, wat toch een erg bruikbare ISA is, gezien de beschikbare implementaties.
(Specifiek hebben ze daar de voorwaardelijke instructies uitgehaald om beter geschikt te zijn voor OoO executie).
Ook op x86 wordt aangeraden om de voorwaardelijke instructies te mijden.

[dmantione]

Nee, ARM blijft een instructieset met veel adresseermodes die zeker niet in de fout van MIPS valt. Voorwaardelijke instructies in ARMv8 zijn niet zo maar verwijderd, ze zijn vervangen door voorwaardelijke selectie waardoor het vermijden van branches mogelijk blijft. Ik ben niet op de hoogte dat voorwaardelijke instructies op x86 vermeden zouden moeten worden, wel weet ik dat in ieder geval AMD ze in zijn "Software Optimization Guides" nog steeds van harte aanbeveelt, zie bijvoorbeeld hoofdstuk 7.3 van:

https://www.amd.com/syste...7414_15h_sw_opt_guide.pdf

[RandomMens]

Da ben ik benieuwd wat je mening is over de overstap van x86 naar ARM voor computers?

[dmantione]

ARM zit wat architectuur betreft iets netter in elkaar dan X86. Bijvoorbeeld het addressermodemechanisme waar ik hier op doelde is bij ARM generieker dan op X86 en dus breder inzetbaar. Maar X86 heeft in grote lijnen zijn zaakjes op orde, dus ik denk dat de architectuurwinst van x86 naar ARM om die reden beperkt is, maar wel degelijk bestaande. ARM heeft aanzienlijk minder dingen die uitsluitend nog vanwege de compatbiliteit ondersteund worden, omdat veel in één keer goed gedaan werd. Dat ARM-apparaten vaak zuinig zijn, maar toch verhoudingsgewijs indrukwekkende prestaties kunnen bieden is mede een gevolg van de architectuur.

[Reactie gewijzigd door dmantione op 23 juli 2024 09:48]

[RL600]

Hoe kijk je aan tegen bijvoorbeeld de nieuwe M1 van Apple? Goede ontwikkeling of juist niet? Zie je het toekomst hebben of meer een gimmick?

[dmantione]

Met wat ik ervan gelezen heb ben ik er behoorlijk enthousiast over en wat me vooral interesseert is hoe ze het voor elkaar krijgen x86-emulatie zo efficiënt te krijgen; de benchmarkcijfers die ze tonen zijn voor emulatie ongehoord dus ik denk dat er in de M1 faciliteiten zijn om dat te versnellen.

Wat ik wel een beetje vrees is dat Apple de hardware helemaal dicht gaat timmeren en ze zich vooral op het algemene publiek gaan richten en enthousiastelingen als wij er niet veel bijzonders mee kunnen.

[RandomMens]

In plaats van emulatie werken ze met binaire translatie dacht ik. En daarnaast heeft de M1 chip een neural engine, wat dus bepaalde processen versneld en dus mogelijks kan spelen in versnellen van binaire translatie. Ik ben echter niet zo goed op de hoogte van veel van de details, ik haal veel info uit YouTube kanalen dus kan zijn dat ik dingen verkeerd begrijp of onthou.

[Immutable]

Tegenwoordig zit zelfs in chips van enkele dollars een Neural Engine. Is wel iets wat straks redelijk standaard in elke SoC gaat zitten. Net als een GPU.
Heb hier een kendryte K210 liggen, zit ook gewoon een Neural Engine in die je kan programmeren voor o.a. pattern matching e.d.

[gerwim]

Mooi artikel trouwens waarom de M1 zo snel is:
https://debugger.medium.c...chip-so-fast-3262b158cba2

[aaahaaap]

Geen goeie ontwikkeling uiteraard, x86/UEFI is al niet al te best, maar ARM is nog vele malen erger. Mooi voor een fabrikant die alles dicht wil timmeren, niet mooi voor de vrijheid van de eindgebruiker.

[Reactie gewijzigd door aaahaaap op 23 juli 2024 09:48]

[Immutable]

Wat is vrijheid. Is een afspraak tussen mensen en partijen een vorm van vrijheid afnemen?
Een bepaalde ISA is een soort protocol afspraak.
Europa is een soort protocol, afspraak betreft hoe en wat mag op de handelsmarkt.

Ik denk dat veel mensen niet echt snappen dat afspraken nodig zijn, maar dat het wel een deel van je vrijheid afneemt. Wat wil je dan? Een wereld zonder wetten en afspraken met ultieme vrijheid?

Vrijheid is zoooo relatief.

[SG]

Is zuinig ook meer iets door gerichte architectuur ontwikkeling voor meer mobile markten.
De meer gerichte procedé kiezen voor zuinige toepassingen.
daarbij komt de big Little dat kan X86. 8x fat cores met 4 stom cores met zeer geavanceerde power management zoals Apple.
Dan kan X86 ook flink stuk zuiniger.

Daarnaast on die memory ipv alleen cache help ook vooral in performance.

Zo als GPU de infinity cache heeft in GPU markt al flinke performance win.
mem on die is zeer low latency
en heeft nog minder last van cache missen.

[ro8in]

Misschien beetje offtopic. Maar heb jij misschien een goed begin punt om assambler te leren? Want het staat wel altijd nog op mijn lijstje van dingen die ik ooit nog eens wil leren.

[EzriDax]

Misschien dan beginnen met assembly op een z80 of 6502 processor, oud, maar volgens mij een goed startpunt.

[psychicist]

Als je geïnteresseerd bent in assembly programmeren voor RISC instructiesets, heb je een tutorial voor ARM en een boek voor RISC-V. Het RISC-V boek is zeer leesbaar en bevat vergelijkende code voor ARM, MIPS en x86.

POWER is wat ingewikkelder en er zijn weinig goede tutorials voor. Ik heb afgelopen zomer mijn code van (64-bit) x86 naar (64-bit) ARM en POWER geport en ga deze kerstvakantie verder werken aan de RISC-V port.

[Immutable]

En als je geen RISC-V processor hebt, kun je altijd een VM gebruiken. Er is zelfs de discussie tussen RISC-V VM en WebAssembly VM

[psychicist]

Ik heb tot nu toe alleen maar QEMU gebruikt, omdat er geen goedkope hardware beschikbaar is die sneller is

Ik hoop wel dat de opvolgers van de SiFive Unmatched snellere cores en nog meer geheugen aan boord hebben, zodat het wel de moeite waard wordt om zo'n bord aan te schaffen. De ontwikkelingen zijn niettemin mooi om te zien, nadat ik vorig jaar nog mensen bij SiFive heb gesproken over de beschikbaarheid van goedkope hardware om Linux op te draaien.

[dmantione]

Youtube is je vriend, bijvoorbeeld deze twee video's:

https://www.youtube.com/watch?v=wLXIWKUWpSs
https://www.youtube.com/watch?v=cFGJhn97e3s

Dit is ook een leuk kanaal, gaat over een Commodore 128 in assembler programmeren. Zo heb je naast een complexer x86 processor ook een simpele 6502-processo en kun je een beeld krijgen van de verschillen:

https://www.youtube.com/channel/UC4hnwmds9vAIJICAieAUEZA

[EzriDax]

Ze kan het echt goed uitleggen.

[Squee]

Geweldige inhoudelijke reactie. Helaas kan ik vanwege mijn werk zelf niet zulke sterke uitspraken doen, dus heb ik het maar bij een historische beschouwing gelaten

[.oisyn]

Voor iemand die zo'n mooie inhoudelijke post schrijft is het dan wel weer jammer dat je het steevast assembler noemt ipv assembly . Die laatste is de taal, de eerste is de tool die je gebruikt om de taal om te zetten naar een byte code die de cpu snapt.

[leuk_he]

Doet het modulaire (en 64 bit en 128 bit standaarden) dit traditionele nadeel teniet?

Extra functionaliteit nodig voor speciale processors voeg je toe in je eigen tapeout.

[dmantione]

De meeste modulaire opties houden de basis intact en daarmee ook de vrij essentiële kwesties als adresseermodes en de hoeveelheid registers. De overstap naar 64 bit heeft de verschillende architecturen de mogelijkheid gegeven een aantal problemen van hun instructieset aan te pakken (alle software werd toch al herschreven naar 64-bit). Zo is op x86 bijvoorbeeld de hoeveelheid registers verdubbeld: X86 was met 8 registers altijd zeer krap bemeten, maar nu het er in 64-bit 16 zijn is die kwestie de wereld uit.

[leuk_he]

Als 16 registers het probleem voor x64 heeft geholpen dan zou je denken dat 32 registers in riscv die bottleneck ook beperkt.

[flowerp]

Ik ben dan van oude stempel en "spreek" de assemblertalen van de nodige processoren

Het is natuurlijk wel zo dat tegenwoordig assembly nagenoeg niet meer bedoeld is voor de mens om in te schrijven, maar juist als target voor compilers. Dat betekend dat er toch een andere complexiteit in kan zitten die voor de mens erg onhandig is, maar voor een compiler juist makkelijk te benutten.

[dmantione]

Dat snap ik, maar je zult de assembleertalen toch moeten kennen om te kunnen beoordelen hoe krachtig ze zijn, ook al is dat vanuit het oogpunt van hoe goed een compiler daar code voor kan schrijven. Compilers hebben weliswaar wat andere voorkeuren dan mensen, maar uiteindelijk zijn beiden gebonden aan de instructies die een processor ondersteunt.

[Squee]

Leuk artikel! Ik wilde wel nog wat extra's toevoegen over de historie van RISC/CISC.

Het is namelijk geen toeval dat RISC-V bij de universiteit van Berkeley vandaan komt; dat was een van de twee originele universiteiten die begin jaren 80 aan het originele RISC onderzoek werkten. Vandaar dat het ook RISC-V (Romeinse 5) heet, RISC-I en RISC-II waren hun originele research chips van het RISC concept. De professor die dat leidde, David Patterson, is ook een van de krachten achter RISC-V en het was volgens mij ook aan zijn onderzoeksgroep waar Krste Asanovic indertijd zijn PhD heeft gedaan. Tegelijkertijd werd er bij Stanford onder leiding van professor John Hennessy ook aan RISC concepten gewerkt. Hennessy en Patterson zijn ook heel erg bekend voor hun boeken over computer architectuur, wat werkelijk standaard werken zijn als academisch lesmateriaal (vooral Computer Architecture: A Quantitative Approach, en ook Computer Organization and Design: The Hardware/Software Interface). In deze boeken introduceerden ze de versimpelde DLX instructieset, gebaseerd op hun initieele RISC onderzoek, die eenvoudig maar ook krachtig genoeg was om studenten de concepten van computer architectuur te leren.

De origine van RISC in dit onderzoek kwam vooral door de observatie dat in die tijd de processoren en instructiesets onnodig complex geworden waren, en dat er een groot gedeelte van de instructies slechts weinig gebruikt werden. En dan had men het niet over x86, dat had toen bij lange na nog niet de dominante positie dat het nu heeft, er waren vooral wat IBM PCs en klonen; het zal in die tijd vooral de VAX van Digital zijn geweest en wellicht IBM's System/370; die voor grote "server" toepassingen gebruikt werden (al kon je nog niet echt van servers spreken zoals deze dag - het was meer een grote centrale machine met veel remote terminals), en de Motorola 68k voor desktops/workstations. De VAX instructieset was wellicht het toppunt van CISC, met enorme complexe operaties in een enkele instructie - die dan vaak via micro-code werden uitgevoerd in de processor. David Patterson had eerder veel gewerkt aan dit soort micro-code, en het idee van RISC komt eigenlijk neer om deze micro-code de werkelijke instructieset te maken; wat leidde tot een veel simpelere implementatie in de micro-architectuur van de processor. Het idee van RISC was niet geheel nieuw in dit onderzoek; er waren al eerdere processors geweest van o.a. IBM en CDC die bepaalde RISC ideeen implementeerden, maar het Berkeley/Stanford onderzoek waren uiteindelijk de grondleggers van het nu algemeen geaccepteerde RISC concept.

Toen Berkeley met de eerste test chips van RISC kwam, bleek hoe enorm krachtig het idee was; de chips waren zeer klein en efficient, en haalden daardoor een hogere performance dan de super complexe VAX machines. Dit leidde tot veel aandacht voor deze ideeen; zo werd het RISC onderzoek van Berkeley gebruikt als basis voor de ontwikkeling van SPARC bij Sun Microsystems (die daar voor de Motorola 68k gebruikten in hun Unix workstations), en de Stanford ontwerpen gingen verder als spin-off als MIPS. Ook rond deze tijd kregen enkele mensen van Acorn computers in Engeland lucht van deze nieuwe ideeen, en daaruit is de ARM architectuur toen ontstaan (Arm werd pas later als spin-off bedrijf gevormd uit Acorn, in 1990 - en vierde net een week geleden zijn 30e verjaardag). Daarna begonnen ook de andere tech bedrijven van die tijd aan RISC ontwerpen, zoals POWER (en later de PowerPC afgeleidde) van IBM, PA-RISC van HP, en Digital volgde wat later met Alpha als opvolger voor hun VAX architectuur. En dan zijn er nog een boel die ik ongenoemd laat, zelfs Intel had een ontwerp met hun i860/960. Helaas zijn inmiddels veel van deze RISC architecturen uitgestorven of op sterven na dood, vooral vanwege het enorm verpletterende succes van x86. Arm doet het natuurlijk heel erg goed, en wat RISC-V precies zal gaan brengen zullen we in de komende jaren te weten komen!

[Jeroenneman]

Kunnen we binnenkort ook premium commentaar gaan plaatsen? Ik zou voor bovengenoemde reactie namelijk meer betalen dan voor het artikel zelf.

[MennoE]

Beetje flauwe reactie. Ik vond het een leuk artikel.

[flowerp]

Niet perse flauw dat premium commentaar. Daar zou best in een premium omgeving micro-credits voor gegeven kunnen worden, waarvan de ontvanger weer andere premium content mee zou kunnen betalen.

[Omega]

Het is een prijzig apparaatje, maar ik ben heel erg geneigd om een HiFive Unmatched van SIFive aan te schaffen. ITX form factor, redelijke RISC-V processor, 16GB aan RAM (Had eerst 8, is gratis geupgrade na klachten), PCI-e slotje, gigabit ethernet.

Dit lijkt mij een hele leuke machine om mee te spelen.

[Lanfear89]

Als x86 uit de jaren 70 is, waarom gebruiken we het nog en wordt er niet overgestapt op efficiëntere instructiesets? Of is mijn beeld van instructiesets nu verkeerd?

Hoe het bij mij overkomt: alsof we nog steeds lompe CRT's zouden gebruiken terwijl er al lang allerlei flatscreens bestaan

[Reactie gewijzigd door Lanfear89 op 23 juli 2024 09:48]

[Squee]

Als x86 uit de jaren 70 is, waarom gebruiken we het nog en wordt er niet overgestapt op efficiëntere instructiesets? Of is mijn beeld van instructiesets nu verkeerd?

Hoe het bij mij overkomt: alsof we nog steeds lompe CRT's zouden gebruiken terwijl er al lang allerlei flatscreens bestaan

Het ligt wel wat genuanceerder dan dat; er zijn veel verbeteringen/uitbreidingen gemaakt op x86, de bekendste natuurlijk de x86_64 extensie voor 64 bits, maar ook dingen als 32-bit mode in de 80386, paged/virtual memory, MMX, SSE, AVX etc. De kracht van x86 is de backwards compatibility die ook aangehaald wordt in dit artikel; het feit dat je hele oude x86 programma's nog steeds op moderne Intel/AMD processors kan draaien. x86 is overigens niet de enige architectuur die dat doet; SPARC had ook een hele lange traditie van backward compatibility waar je bepaalde binaries voor de eerste SPARC processoren uit mid jaren 80 nog steeds zou kunnen draaien op de laatste SPARC M8. POWER van IBM heeft waarschijnlijk een vergelijkbaar verhaal.

Maar het radicaal veranderen van de instructieset is niet zo makkelijk; omdat je software ecosysteem er klaar voor moet zijn. Het beste voorbeeld is natuurlijk wat Apple de afgelopen twee decennia twee keer gedaan heeft; van PowerPC naar x86, en nu van x86 naar hun eigen Apple silicon. Dit konden ze alleen maar oplossen door te zorgen dat een deel van het software ecosysteem al klaar was voor de nieuwe instructieset, en voor alle oudere programma's hebben ze Rosetta ontwikkeld om een vertaling te maken naar de nieuwe instructieset - maar dat kost wel performance, vooral toen bij de eerdere overstap van PowerPC naar x86.

Als processor fabrikant van instructieset wisselen is heel erg risicovol; een goed voorbeeld is wat er met de Intel Itanium gebeurd is indertijd, die niet gebaseerd was op de x86 instructieset. Initieel werd dit als de opvolger/vervanger van x86 gepresenteerd, maar omdat de eerste producten (en vooral de compilers) tegen vielen en mensen liever op x86 bleven kreeg het niet genoeg voeten aan de grond. Toen AMD met de x86_64 extensie kwam die x86 naar 64-bits bracht, verdween de interesse helemaal (en daarnaast vielen de prestaties van Itanium ook tegen ten opzichte van x86). De reden dat een bedrijf als Apple dat wel kan doen is omdat zij een sterke greep hebben op beide de hardware en de software wereld; het is een tamelijk gesloten software ecosysteem en zij beheersen ook het besturingssysteem wat op de processors draait.

En dan ben ik nog niet eens ingegaan op wat een instructieset efficient maakt...

[PPie]

Het beste voorbeeld is natuurlijk wat Apple de afgelopen twee decennia twee keer gedaan heeft; van PowerPC naar x86, en nu van x86 naar hun eigen Apple silicon.

Sterker nog, daarvoor nog de overstap van 68k naar PowerPC.

[Squee]

[...]

Sterker nog, daarvoor nog de overstap van 68k naar PowerPC.

Ja en daar voor van 6205 naar de 68000... maar ik wilde niet te ver uitweiden Ik ben ook niet zo bekend met wat Apple precies voor techniek had voor de 68k/PowerPC overschakeling; ik kan met herinneren dat de vroege PowerPC Macs wel een 68k modus hadden, maar of dat met emulatie of met een fysiek aanwezige 68k chip was weet ik niet meer.

[PPie]

De 6502 werd niet gebruikt in de Mac, maar in de Apple II.
De Mac is begonnen op de Motorola 68000, daarna overgestapt op de PowerPC, daarna x86 en nu ARM.
Ongelofelijk dat dit ondertussen de 4e ISA is die gebruikt wordt!
De PowerPC gebruikte emulatie.
Wat grappig was, was dat het bedrijf Connectix een snellere emulator verkocht: Speed Doubler.

[SG]

In de markt is legacy heel belangrijk. Probleem van x86 is dat hardware en OS en software verschillende bedrijven zijn waar je dus op hardware en OS en applicaties keihard moet pushen om markt migratie te realiseren. Apple heeft Hardware de OS en Applicatie ontwikkel en ontwikkel omgeving zelf in handen.

En daarmee zal Risc-V een niche markt zijn en migratie zeer moeilijk gaan.
Dan heb je nog Nvidia met ARM die zou dus ook eigen ARM soc en gpu platform kunnen pushen.
Maar goede ontwikkel omgeving die daarbij hard mee pushen en OS in eigen handen. Zou kansen vergroten. Zo niet zal dat ook moeizaam gaan. En ook dan iets voor de zeer lange adem.

Wat nV met Apple gemeen heeft is dat nV Cuda zwaar gepushed heeft en Apple de taal Swift.
Terwijl de D taal die ook C++ zonder Legacy vervangt heel stuk moeizamer gaat.

Het lange tijd geleden dat ik op HEX toetsenboardje machine code in 68000 controler in klopte.

[kdekker]

Het klopt dat IBM, (toen nog) Sub, HP etc veel deden voor compatibiliteit. Dat zat deel in de processor en meer in het OS. Dwz als je met C/C++ of andere hogere programmeertaal werkte. HP kreeg namelijk op Itanium ook PA-RISC binaries draaiend (met een emulatielaag: Aries).

Een belangrijke reden voor behoud compatibiliteit waren de prijzen van hardware en software. Compatibiliteit was nodig voor klantbinding. Anders kwam er ook geen nieuwe systeem of nieuwe investeringen in software.

[OCU-Macs]

Jouw reactie is meer premium dan dit hele artikel!

[K-aroq]

Waarom gebruiken we dan nog steeds Linux, een OS dat op Unix dat in de jaren 60 is ontwikkeld? Omdat iets oud is, is het nog niet overbodig. Iets is pas overbodig als het ingehaald is iets beters.

[Blokker_1999]

Linux is niet op Unix ontwikkeld, het is een Unix compatibel systeem dat ontstaan is in de jaren 90. Vele van de tools die er op werken zijn door de jaren heen helemaal herschreven en ook in de kernel zelf zal niet veel meer overblijven van de originele versies.

[jpsch]

Windows NT was toch ook opnieuw geschreven? Dan verschilt dat toch niet zoveel van Linux/Unix?

[dmantione]

Als je een nieuw besturingssysteem maakt, dan moet dat besturingssysteem natuurlijk ook programmatuur kunnen draaien en daarom is het logisch om een nieuw besturingssysteem compatibel te maken met een bestaand besturingssysteem. Unix is in de jaren '70 ontwikkeld, de jaren '60 is onjuist, maar ook jaren '70 is natuurlijk een hele leeftijd.

Maar... zoals Blokker_1999 schrijft is Linux Unix-compatibel gemaakt en is het dus niet zo dat we software uit de jaren '70 gebruiken. Wel is het zo dat Unix veel beter in elkaar zat dan bijvoorbeeld het destijds dominante MS-DOS. Unix zat in tegenstelling tot MS-DOS ook nog eens niet vastgeketend aan 16-bit en omdat Linus Linux vanaf het begin als 32-bit besturingssysteem heeft ontworpen was compatibiliteit met Unix voor hem een logische keus.

[rob12424]

Om het nog leuker te maken: Linux is eigenlijk GNU/Linux. De GNU vinden veel mensen onbelangrijk. Maar GNU was een deel van GNU Hurd. GNU Hurd is de voorganger en tegelijkertijd de opvolger van Linux en is ontstaan in de jaren 80 als ik het goed heb: https://en.m.wikipedia.org/wiki/GNU_Hurd

Als dit OS stabiel en zo als bedoeld uitkomt denk ik zelfs dat het sterker en krachtiger is dan elk ander OS op de markt. Omdat het designated independed multicore/thread server is. Linux is een soort van Unix cloon (POSIX compatible noemen ze dat volgens mij) Windows is dat tegenwoordig ook (steeds meer)

Maar daar zit ook gelijk het nadeel van de ontwikkeltijd van GNU Hurd in. Welk proces er ook faalt in het besturingssysteem. Het OS en de Kernel MOETEN blijven draaien en het evt. Overnemen.

[Reactie gewijzigd door rob12424 op 23 juli 2024 09:48]

[N8w8]

Nou, niet helemaal.
GNU wilde een compleet vrij OS maken, ze hadden daarvoor vanalles, maar nog geen kernel.
Hurd zou de kernel moeten worden, dus Hurd is juist een deel van GNU.
Linus begon de Linux kernel, samen met GNU software kon je daarmee een compleet OS bouwen.

Nu is men "massaal" aan de Linux omdat het gewoon goed werkt voor vanalles, dat is geen passief proces maar zorgt er ook voor dat er veel wordt geinvesteerd om het nog beter te maken.
De Linux gemeenschap en GNU gemeenschap zijn ook niet dezelfde; de eerste is meer pragmatisch ingesteld, de laatste meer idealistisch. Dus al zou GNU willen dat Linux wordt opgevolgd door Hurd, ze hebben daar niks over te zeggen.

Maar, als het Hurd team ooit iets aflevert dat niet alleen aan eoa ideaal voldoet, maar in de praktijk ook gewoon beter werkt dan Linux, natuurlijk raakt men daar dan wel in geinteresseerd.
Maar er is niet veel dat erop wijst dat dat ooit gaat gebeuren.

Het ontwerp heeft idd wel wat leuke eigenschappen die bijv stabiliteit ten goede zouden kunnen komen, maar het is ook weer niet zo dat dat bij Linux zo'n groot probleem is in de praktijk.
Want als er iets kan falen aan de kernel, kan je ook de oorzaak daarvan verhelpen zodat het om te beginnen al niet faalt (dat is het streven iig).
Daarnaast is Hurd door die opzet ook fundamenteel langzaam, als ik t me goed herinner.

Misschien vindt het nog wel een bepaalde niche, bijvoorbeeld de Intel Management Engine draait op Minix dacht ik, dat is ook zo'n microkernel Unix-achtige bedacht door academici.
Mss leuk in theorie, maar in de praktijk gewoon niet populair, behalve bij specifieke eisen.

edit: Maar, ja, GNU is wel vrij om in hun eigen project/distro, Linux te vervangen door Hurd, als ze dat ooit willen. Alleen is dat niet zo heel relevant voor de rest van de (Linux) wereld.

[Reactie gewijzigd door N8w8 op 23 juli 2024 09:48]

[aadje93]

X86 mag dan uit jaren 70 zijn, het is wel steeds verder uitgebreid. X86 was origineel een 16 bits instructie set, nu is het na de tussenstap van 32 bits dus 64 bits geworden 😉

[GekkePrutser]

Nou, compatibiliteit. Als we op die flatscreens niet dezelfde programma's konden tonen als op de CRT's, dan zouden we waarschijnlijk nog veel meer CRT gebruiken.

Met name in het bedrijfsleven wordt er nog heel veel legacy software gebruikt. Overigens niet alleen met intel. We hebben op het werk nog een aantal oude Sun SPARC en HP-RISC servers omdat de software die daarop draait niet op iets nieuwers beschikbaar is.

[FooLsKi]

Het is natuurlijk niet zo dat die instructieset 100% "set in stone" is, die is in al die jaren onderhevig geweest aan optimalisaties en modernisering. Was het inderdaad een volledig statische set geweest, dan had je gelijk gehad.

[SG]

Nou eigenlijk wel je heb de core instructie set. Dan kan de hardware implementor er extra toevoegen wat bijvoorbeeld twee zware instructies combineert of specifieke feature . Compiler maken dan executabel die sowieso gpu detecteert en dus juiste instructies pakt zo niet dan de basic fallback pakt.
X86-64 is niet AMD64 maar grotendeels er zijn kleine verschillen.
Tussen architectuur families kunnen er ook kleine verschillen zijn naast de extensie verschillen.

[shredder]

Intern wordt er binnen x86 ook van RISC gebruik gemaakt. Zie bijvoorbeeld https://stackoverflow.com...-core-in-their-processors.
Er is zoveel aan toegevoegd en veranderd dat de huidige instructieset c.q. verwerking wel compatibel is maar lang niet meer lijkt op die uit de jaren 70.

[BadRespawn]

Een instructieset maken is veel complexer dan flatscreens maken, er vergt dus veel meer tijd. Zodoende zijn ze daar al vele decennia mee bezig.

[RuudSint]

Ik draaide in de jaren 70 al met RISC op een Archimedes computer

https://nl.wikipedia.org/wiki/Acorn_Archimedes

De clubleden die op de Amiga en een 286 of oudere PC draaide stonden toen verlekkerd naar me te kijken. Er waren toen ook al emulators dus software van andere platforms binnen bereik...

[monotype]

Jaren 80 denk ik dat je bedoelt. Archimedes werd geintroduceerd in 1987.

In Byte magazine (toendertijd een veelgelezen blad) stond in 1987 een mooie review van de A310, die met een 8MHz ARM (V1 - zonder extensies of cache die de huidige generatie ARM's nu wel hebben) rondjes liep rond hoger geklokte x86's van z'n generatie.

Zie https://vintageapple.org/..._Heuristic_Algorithms.pdf pagina 125 en verder.

[GewoonWatSpulle]

Ik ben al enige tijd aan het spelen met Arduino vervangers op basis van RISC-V o.a. SeeedStudio heeft betaalbare bordjes en zelfs met display geïntegreerd! Ik ben benieuwd wanneer de eerste betaalbare quad core borden/chips komen een ITX form factor zou mij al super gaaf lijken rond de 100-150 euro.

[Cergorach]

Hoe verhoud zich dat qua performance/functionaliteit/energieverbruik/kosten tot de 'normale' alternatieven?

[Immutable]

Risc-V microcontrollers heb je heel veel performance voor je geld. En volgens mij is het energieverbruik ook heel goed. Maar ik persoonlijk zou hem niet gebruiken voor een professioneel product. Je weet niet hoe lang ze nog leverbaar zijn, het is allemaal heel jong. Ik zou professioneel nog steeds gewoon voor STM32 kiezen e.d. vanwege andere argumenten die heel sterk zijn voor een professioneel product. Zoals bewezen legacy etc.

Ik zie RISC-V zeker in de goedkope Microcontroller markt volledig overnemen in de nabije toekomst, omdat de marges zo klein zijn. Wanneer een bedrijf komt met deze chips met goede support, en lifetime cycles en pin zekerheid zodat je je hardware kan upgraden naar een toekomstige chip.. Dan zeker.
RISC-V is nu gewoon hobby, ook leuk omdat het zo goedkoop is. Maar dat kan wel een weg zijn om het steeds populairder te laten worden, en ervoor zorgen dat tools volwassener gaan worden.

Wat ik de gaafste combinatie vind is RISC-V microcontroller + Rust als programmeertaal.

[Reactie gewijzigd door Immutable op 23 juli 2024 09:48]

[Cergorach]

Dit is het eerste 'Premium' artikel wat ik heb opengemaakt sinds de eerste twee. Puur omdat ik interesse heb in open source processors (als alternatief tot bv. ARM based procs). Wat ik hier dan lees is niet meer of uitgebreider (in tegendeel zelfs) dan wat gegoogle op dit onderwerp en dan uitkomen op Wikipedia en niche sites die gespecialiseerder zijn dan Tweakers.net wat betreft dit onderwerp. Het enige 'voordeel' is dat het in het Nederlands is, wat voor velen van ons, absoluut geen voordeel is.

De doelgroep lijkt hiermee dat deze artikelen gericht zijn op lezers die nog nooit eerder naar dit onderwerp hebben gekeken en bij het lezen van het onderwerp denken "Dat lijkt me wel interessant!" maar nooit eerder de moeite hebben genomen om het zelf uit te zoeken. Wat me juist een kleine doelgroep zou lijken op basis van een naam als Tweakers.net, juist een doelgroep die zelf dingen gaan uitzoeken en gaan 'tweaken'. Of voor de mensen die niet eens wisten dat het onderwerp bestond...

[Sissors]

"Maar Wikipedia heeft hier ook informatie over" is wel echt een dooddoener. Op die manier kan je wel heel veel dingen wegstrepen, omdat op het internet op andere plaatsen ook informatie te vinden is.

De doelgroep hiervan lijkt mij simpelweg de mensen die anders bijvoorbeeld een populair-wetenschappelijk tijdschrift wel interessant zouden vinden. Niet extreem diep erop ingaan, want dat volgt toch geen hond. Geen artikel waar je 3 uur nodig voor hebt om erdoorheen te gaan, maar gewoon eens wat meer achtergrond informatie.

Als het punt is dat andere websites er ook informatie over hebben dan kunnen we Tweakers wel opdoeken. Waarom reviews doen? Andere hebben ook reviews. Waarom nieuws over komende producten bijvoorbeeld? Kan je ook op andere websites vinden.

[Cergorach]

Als het punt is dat andere websites er ook informatie over hebben dan kunnen we Tweakers wel opdoeken.

Erm... In het (verre) verleden was dat anders, dan verwezen Engelstalige sites juist naar Tweakers.net omdat ze hier veel dieper ingingen op het onderwerp. Daarnaast de discussies/kennis die onder de artikelen en gelinkte draadjes op het forum ontstonden. Juist die discussies onder het artikel gaan dan verdwijnen omdat de artikelen achter een paywall gaan verdwijnen, waarom zouden mensen die deze kennis al hebben hier extra voor gaan betalen terwijl ze de discussie wel open voor iedereen kunnen voeren op het forum...

En men moet zich inderdaad heel goed gaan afvragen welke toegevoegde waarde Tweakers.net brengt... Wil men gaan concurreren met Computer Idee?

[TheJoe]

Cergo, kan het niet zo zijn dat je Tweakers simpelweg ontgroeid bent met je kennis?

[Cergorach]

Dat is een veel te makkelijk antwoord!
Kijk eens naar die comments met die groene achtergronden, veel daarvan hebben kennis/perspectieven die je niet snel ergens anders vind. Dat is de reden dat ik nog op Tweakers.net kom. Als dit achter een paywal had gezeten was waarschijnlijk alleen Squee er met een goede toevoeging geweest en de rest van de supporters hebben alleen reacties op anderen die niet subscriben, de kans is klein dat ze dat wel met 'Premium' gaan doen.

Waar voorheen Tweakers.net diepgaande artikelen had over RAID en alles wat daaraan gerelateerd. Later veel SSD informatie wat toen nog erg niche was. Waar de discussies na de artikelen door gingen op het forum. Over de jaren heen is Tweakers.net steeds breder geworden in zijn coverage, maar op een gegeven moment met als gevolg, dat de diepgang steeds minder diep en uniek werd. Mijn persoonlijke mening is dat ze gewoon een onderwerp/niche moeten kiezen en daar sterke kennis op in moeten kopen. De vraag blijft echter of dat iets is waar de huidige eigenaar op zit te wachten...

[SG]

Denk het niet. met niche website bereik je kleine groep mensen en als je verdien model afhankelijk bent van bereiken van grote groep zul je toch meer op de massa richten. Niche groepen is meer voor puur vrijwilligers werk die er hobby van maken. Was ooit zo begonnen vermoed ik .

[HADES2001]

Denk dat hij meer refereert naar het gedeelte premium terwijl de info die er staat ook op wikipedia staat. Wiki staat er niet om bekend uitgebreide informatie te hebben maar voor het grootste deel een simpele basis.

[Beerebeest]

De doelgroep hiervan lijkt mij simpelweg de mensen die anders bijvoorbeeld een populair-wetenschappelijk tijdschrift wel interessant zouden vinden. Niet extreem diep erop ingaan, want dat volgt toch geen hond. Geen artikel waar je 3 uur nodig voor hebt om erdoorheen te gaan, maar gewoon eens wat meer achtergrond informatie.

En dit is nu net waarom ik heel blij ben met dit soort artikelen, ik ben geen wetenschapper die gewend is om ellenlange artikelen te lezen in een andere dan mijn eigen taal (sterker nog, ik ben "maar een chauffeur" die geïnteresseerd is in dit soort artikelen).
Als dit soort artikelen meer op T.net komen dan ga ik waarschijnlijk toch de stap maken om een abonnement hier op te nemen.

[rob12424]

Ja maar dan kijk ik naar de reacties van Squee en Dmantione. En dan heb ik iets was het niet mogelijk om die te interviewen /laten discussiëren en dan het artikel te schrijven?

Overigens als je dan toch een artikel schrijft wat premium moet zijn. Ik vraag mij af wat AMD gaat doen. Zij hebben FGPA's De CEO is er bijna groot mee gebracht en stond aan de wieg van de PowerPC. Ik zou die interviewen en het vuur aan de schenen leggen met betrekking tot RISC-V,AmD en FGPA's en X86. Zij weet als geen ander de voor en nadelen denk ik?

[dmantione]

Op het moment dat Premium-artikelen gesloten worden voor het grote publiek stort de hoeveelheid reacties in en daarmee ook de reacties die het artikel het lezen waard maken. In dit geval constateer ik dat de auteur niet het vereiste niveau heeft om de extra informatie die reacties toevoegen te compenseren. ... met als gevolg een artikel als dit, zonder de reacties eronder, aanzienlijk minder waard is om geld voor neer te tellen.

[Reactie gewijzigd door dmantione op 23 juli 2024 09:48]

[Chinco]

Ik kwanlm wel vanuit interesse, nadat ik gisteren bij het artikel over Windows op ARM_64 in een reactie een link las naar een blog post over ARM vs. x86. (van @pbook pBook in 'nieuws: Microsoft begint publieke test met x64-emulatie Arm-versie ... .) Dat was een half uur "well spend" met begrijpelijke, maar technische informatie.

Daarna was dit "premium" artikel toch wel te teleurstelling. Na het lezen van dit artikel heb ik nog volop vragen als energieverbruik, verhouding tot de ARM en x86 ISA, waar is dan de implementatie voor een controller van WD, enzovoorts.

Leuk artikel hoor, maar ik mis technische diepgang. Maar misschien ben ik te veel nerd vergeleken met de rest van de tweakers.

[Timdows]

Kijk, hier kom ik voor op tweakers, de comments

Met nu een link (uit een vorige post) naar echt een geweldig artiekel (en ik had meer dan 30 minuten nodig om er door heen te gaan en ondertussen wat termen op te zoeken)

Zou bijna opperen om een weekelijks overview naar externe artiekel op te zetten

[kftnl]

Premium moet je denk ik niet zien als een soort peer reviewed wetenschappelijke journal, maar meer als tegenhanger voor de artikelen die je in betaalde papieren bladen ziet. Geen korte nieuwsartikelen, maar gewoon wat interessante achtergrond in begrijpelijke taal. Als je daar niet voor wel betalen is dat toch prima? Dan doe je het niet.

Ik vind dit gewoon een interessant artikel en heb er weer een paar nieuwe dingen uit opgestoken.

Denk dat als je al expert bent op een gebied dat je niet moet verwachten heel veel te gaan leren erover op Tweakers.

[Reactie gewijzigd door kftnl op 23 juli 2024 09:48]

[K-aroq]

Tsja, als je zo gaat kijken. Waarom zou je een stuk onderzoeksjournalistiek gaan lezen. Je kunt zelf de basisinformatie ook wel vinden en als je dan nog een half jaartje extra onderzoek doet kan je ook alle informatie vinden. Of waarom zou je een brood kopen. Gewoon meel, gist, water bij elkaar gooien, kneden, rijzen, kneden, rijzen, afbakken. Als je daar om 3 uur 's nachts mee begint heb ik om 7 uur bij het ontbijt vers brood.

[Anoniem: 454358]

Ik vind het ook geen cent extra waard, niet het niveau van betaalde content op een tech site in ieder geval, het niveau van dit artikel is niet veel hoger dan dat van een spreekbeurt op de havo bijvoorbeeld, erg oppervlakkig, weinig diepgang en erg kort.

[Zeerob]

Ik wil de schrijver van dit artikel zeker niet te kort doen. En het is niet gemakkelijk om zo'n artikel goed te schrijven, er is heel veel over te vertellen. Maar de meest interessante informatie heb ik eerlijk gezegd gelezen in enkele zeer goede comments.

[i7 930]

Dan toch worden ook Tweakers met andere affiniteiten misschien wel geprikkeld om hier nader onderzoek naar te doen en wellicht gaan ze hierdoor met deze kennis experimenteren. Als je kennis hebt en je kan het toepassen, kun je ook pas iets bijdragen.

[iTiamo]

Waar kan ik meer lezen over de Raspberry-kloon van T-Head?

[Dirk_P_Broer]

Hier op LinuxGizmos.com

[iTiamo]

Heel erg cool! Kijken of ik er één kan bemachtigen.

[Immutable]

Je hebt nog veel meer RISC-V chips op de markt.
Zo heb je ze van Microcontrollers: https://www.antratek.nl/s...I16Mn1ji1gaRoCvWAQAvD_BwE
Tot aan de Kendryte K210... die zelfs een Neural Engine heeft waarmee je video kan aansluiten en pattern matching kunt toevoegen. Door dingen te trainen met Tensorflow-lite.
Zelf heb ik beide, maar ben bezig met eerst de microcontroller. En het liefst programmeren met Rust natuurlijk.

Hier nog wat meer te koop: https://www.antratek.nl/catalogsearch/result/?q=Risc-V zoals de HiFive welke wat duurder is omdat het niet Chinees is. Maar dat betekend vaak wel veel meer resources en informatie op internet betreft de HiFive chips.

[Reactie gewijzigd door Immutable op 23 juli 2024 09:48]

[Manatwork]

Dit lezende vraag ik me af wat er eigenlijk geworden is van Transmeta’s Crusoe processor. Die chip kon als ik het mij goed herinner overweg met meerdere ISA’s. En zou dan ook overweg moeten kunnen met RISC-V. Als het nog bestaat...

[Dirk_P_Broer]

Transmeta is in 2009 opgeheven, zie Wikipedia...

[psychicist]

Voormalig CEO van Transmeta Dave Ditzel heeft een aantal jaar geleden Esperanto Technologies opgericht en er wordt bij het bedrijf sindsdien inderdaad gewerkt aan RISC-V chips, waarvan nu een eerste versie klaar lijkt te zijn.

Art Swift, ook een voormalig CEO van Transmeta, is nu CEO van Esperanto Technologies na te zijn vertrokken bij Wave Computing.

[Reactie gewijzigd door psychicist op 23 juli 2024 09:48]

[beerse]

De crusoe processor van transmeta was voor zover ik weet een (risc?) cpu die zich als verschillende andere cpu-s kon voordoen. Of dat in ieder geval zou moeten kunnen doen. Waar/hoe dat gebleven is zou je in de analen van internet wel moeten kunnen terug vinden.

Wel zie ik tegenwoordig in cpu-ontwerpen (en ook gpu ontwerpen en zo) dat er veel 'in software' wordt opgelost. Dat is het concept van de crusoe cpu. Het concept is er nog wel maar ik weet niet van enige erf-opvolger van de crusoe.

[kdekker]

Waarom wordt in het artikel het woord 'arm' steeds met kleine letters geschreven, terwijl het, net als RISC, een afkorting is... En daarbij heeft het woord arm ook nog een paar andere betekenissen (gebrek hebben of lichaamsdeel). Wel een leuk artikel.

Waarom zou RISC-V hoge ogen gaan gooien? Oracle heeft de hardware ontwikkelingen voor SPARC min of meer stilgezet. Waar ze nu op in lijken te zetten, is x86. En Fujitsu SPARC, daar weet ik niet van wat daar van terecht moet komen als Oracle met weinig nieuws op SPARC front komt. MIPS alternatieven zijn er niet veel meer (Siemens Nixdorf (Wincor) nog? Sony al lang niet meer). Dan had je nog het Franse Bull met POWER processoren (klonen van IBM, weet niet of ze die zelf maakten). Maar dat lijken allemaal markten te zijn, waar niet al te veel leven meer in zit.. Al met al is x86/x64 dominant... Wat hebben we dan nog? Sequent, SGI, Cray, DEC, Unisys: het is allemaal weg/overgenomen.

Maar misschien is RISC iets voor de EU (zie ook: https://nl.hardware.info/...opa-chips-laten-ontwerpen)?

PS Een gestandaardiseerde processor architectuur is 1 ding, maar een gestandaardiseerd OS is ook noodzakelijk. In UNIX land is dat maar deels voor elkaar gekregen. De hegemonie van Windows (in minder mate Linux en Apple) is steeds omdat er maar 1 OS maker is (al geldt dat het minst voor Linux).

[Reactie gewijzigd door kdekker op 23 juli 2024 09:48]

[Femme]

Oracle is gestopt met de ontwikkeling van Sparc. Fujitsu heeft nog wel plannen volgens Wikipedia maar is voor supercomputing overgestapt op Arm. De Fugaku supercomputer staat momenteel bovenaan in de supercomputing top 500 met bijna 160.000 Fujitsu A64FX processors. Dat ding is overigens nog wel leuke inspiratie voor Apple. De A64FX heeft 32GB unified geheugen bestaande uit hbm2 stacks met een bandbreedte van 1TB/s (Apple M1 met lpddr4 is maar 60GB/s).

Ik denk dat we meer hebben aan Arm als sterke tegenhanger voor x86 dan fragmentatie over allerlei risc-architecturen die op zichzelf weinig meer voorstellen. Het mooie van het business model van Arm is andere partijen creatief kunnen zijn met Arm designs of zelf designs kunnen maken op basis van de Arm-achitectuur, zodat je uit veel meer smaken kunt kiezen dan een architectuur waar maar twee fabrikanten processors voor maken.