För ett år sedan hade jag sagt: verkar ju vara som att gå över ån efter vatten.
Men nu när man ser Apples M1 faktiskt ha högre IPC när den kör x86_64 kod än någon existerande x86_64 CPU känns det som: det är verkligen en väg AMD/Intel borde kika på!
Jag tror både Itanium och Transmeta hade rätt idé, för dem fallerade det på att de i botten använde en olämplig design.
VLIW, som Transmeta använde på HW-nivå, har visat sig fungera riktigt bra på vissa specifika fall men det verkar vara fel strategi för den typ av kod som man typiskt kör på skrivbordet.
Redan när IA64 designades hade man börja misstänka att VLIW hade en rad begränsningar som gjorde det olämpligt för en traditionell CPU. Man använde något som man kallade EPIC (Explicitly Parallel Instruction Computing), men har själv lite svårt att se hur det egentligen skiljer sig på något relevant sätt från VLIW.
För IA64 var sedan stöd för x86_64 lite av en nödlösning, men i fallet Transmeta var det ju den ISA man designade för att köra. Det som var rätt med idén är att översätta den väldigt komplexa x86_64 ISAn till något som är långt enklare att avkoda. Men tror att det hela föll just på valet av VLIW, vissa saker kan översättas väldigt effektivt till det (Itanium fungera faktiskt rätt bra på vissa HPC laster) men det fungerade öken på branch-tung kod med liten statiskt ILP.
Att översätta från x86_64 till ARM64 är mycket enklare att göra effektivt, det bortsett från den stora miss-match i minneskonsistensmodell. Men givet att Apples M1, som av allt att döma implementerar x86_64 minnesmodellen i HW, faktiskt har högre IPC än någon av AMD/Intels CPUer pekar det på att en statiskt översättning av x86_64 till semantiskt motsvarande "vettig" ISA verkar vara rätt väg framåt.
Frågan är hur mycket effektivare AMD/Intels skulle kunna göra detta om man specifikt designade en modern ISA vars huvudsyfte är att köra kod översatt från x86_64 fast där den nya ISAn har finesser som fast instruktionslängd och uppstädning av de tusentals x86 instruktioner som i praktiken aldrig används idag...
VLIW/EPIC blev ju inte så intressant, men det är ju just för att ISA i sig inte har så stor betydelse i den historien. För Intel så fick x86 features som först bara hittades i enterprisesystem som PA-RISC och SPARC-maskiner samt IA64, RAS-funktioner, virtualisering och så vidare. Funktioner som på den tiden till stor del levde i chipset och inte bara i CPU.
En intressant sak med Transmeta var att det gick att uppdatera vilken instruktionsuppsättning som processorn stöder. Efficeon gick från att ha SSE2 till SSE3 (NX-bit också tydligen) t.ex.
Transmeta fungerade nog bra på den marknaden de hade, men den nischen var inte stor. Via/Centaur överlevde trotts att de hade ungefär samma marknad de inriktade sig på, men har inte utvecklats mycket sedan dess. Centaur kan utveckla en processor med relativt lite resurser, men det är allt runtomkring som gör Vias processorer mindre attraktiva. Chipset och integrerad grafik blev en viktig del där de inte kunde hänga med alls. ARM-marknaden har inte samma problem med alla delar som ska integreras med GPUn och operativsystemen och har kunnat spendera stora resurser på de delarna för att de har så stor marknadsandel i konsumentelektronik, infotaintment, appliances, nätverk o.s.v.
Vad det gäller bytet från Intel till M1 så ligger nog också en stor del av besparingen gällande effektförbrukning i andra delar än just CPU, varken Intel eller AMD kan konkurrera med de som levt på den handhållna marknaden när det gäller allt detta.
Mycket av förbättringarna för x86-64 bör man kunna göra i front-end. Just Intel, AMD och Via som har licenser har nog väldigt liten anledning att inte köra x86 fram till front-end. Det som är intressant är väl om AMD verkligen återupplivar sina planer på att även designa custom-processorer för ARM64, men det är nog mest intressant för att få liv i servermarknaden på ARM64 som på sätt och vis backat då många lagt ner eller skalat ner sina satsningar. Senare gäller åtminstone satsningarna som gäller hårdvara tillgänglig på öppna marknaden då.
