Ik kon helaas niet zo snel het aantal instructies vinden dat beschikbaar is in ARMv8
'Reduced' in RISC slaat niet op het aantal instructies, maar op de complexiteit van de instructies. ARM is een zogenaamde
load-store architectuur. Waar je bij ARM b.v. alleen een 'add' instructie hebt die 2 registers bij elkaar optelt, kan je bij x86 op allerlei manieren aangeven waar ie de waardes om op te tellen vandaan moet halen, een register, een geheugenlocatie, een geheugenlocatie via allerlei vormen van indirecte adressering. etc.
Omgekeerd gebruikt Intel ook al jaren microcode om de complexere instructies om te zetten in eenvoudigere deel-instructies
Klopt, en daar zit nu net het probleem.
Moderne CPU's doen aan
instructie-level parallellisme. Een enkele core heeft meerdere execution units: integer units, logic units, floating point units, etc. De CPU kan meerdere instructies in parallel uitvoeren, zolang deze instructies maar niet van elkaar afhankelijk zijn. Om dit efficiënter te maken worden meerdere instructies vooruit gedecodeerd en in een zogenaamde re-order buffer (ROB) gezet. In de ROB wordt de volgorde van instructies veranderd (rekening houdend met afhankelijkheden) zodat er zo optimaal gebruik gemaakt kan worden van alle execution units.
Hoe verder je in het voren kan kijken, hoe beter je kan re-orderen en hoe efficiënter je de execution units kan benutten.
Omdat x86 instructies in vele vormen komen, zijn de instructies van variabele lengte. Dit heeft als gevolg dat je pas weet waar de volgende instructie staat als je de huidige instructie gedecodeerd hebt. Huidige x86 CPU's lukt het met veel moeite (en relatief complexe decoders) om 4 instructies tegelijk te decoderen. Dit is al jaren zo en het lijkt niet te lukken om dit te verbeteren (google: x86 decode bottleneck).
ARM CPU's , daarentegen, hebben dankzij de simpelere instructies een vaste instructie grootte, je weet dus precies waar de volgende instructie begint. Dit maakt het triviaal om meerdere instructies parallel te decoderen. De Apple M1 bijvoorbeeld decodeert 8 instructies tegelijk. Een bredere decoder betekent dat je een grotere ROB kan vullen, en een grotere ROB betekend dat het makkelijker is alle execution units bezet te houden (je hebt immers meer instructies om mee te schuiven). De Apple M1 heeft een relatief grote ROB, en ook een hele brede CPU (veel execution units). Dit alles zorgt er voor dat de M1 per kloktik heel veel werk kan verzetten, met x86 is dit simpelweg niet mogelijk.
Uiteraard zijn er ook nadelen aan RISC. Omdat er meer instructies zijn en deze een vaste grootte hebben, is de code iets groter. Dit betekent ook dat het meer geheugen bandbreedte kost om die instructies aan te voeren. De variable lengte x86 instructies functioneren eigenlijk als een soort instructie compressie. RISC CPU's zijn meer afhankelijk van geheugen bandbreedte dan CISC CPU's. Dit wordt over het algemeen opgelost door een RISC CPU te voorzien van een relatief grote CPU cache. Wat bij Apple's chips ook het geval is.
Anandtech heeft een
goed artikel dat hier diep op in gaat.