Intel föreslår x86S – förenklad arkitektur utan legacy-lägen

Min google-fu fick fram en del grejer åtminstone, och verkar existera såväl NOS som kloner. På den sortens system är ju moderkort med passivt bakplan en fungerande lösning också, så att man kan ta över nödvändiga ISA-kort relativt enkelt utan att behöva emulera dem.

Den bollen kan man nog dela ut på lite olika sätt, då det var AMD som var upphovet till att förlänga livet på x86. Nu säger jag inte att just IA-64 var framtiden, men x86-64 var säkerligen dödsstöten för de flesta samtida satsningar på att byta ut x86 mot något bättre.

Väldigt få kunder kommer dessutom att bry sig om huruvida olika problem löses på ett elegant sätt.

Lars-Gunnar, 63, som köper in all IT-utrustning bryr sig inte om huruvida arkitekturen har den "ultimata minnesmodellen" eftersom Excel redan fungerar, typ.

I mitten av 90-talet förväntade sig väldigt många att CPUer som Sun SPARC/MIPS Rxxxxx/DEC Alpha var framtiden, såpass mycket att Intel köpte stora delar av DEC i slutet av 90-talet i samband med att Compaq och sedermera HP köpte upp Compaq/DEC. Det var vad jag kan minnas även en enorm hype kring StrongARM, men såväl Intels egna (i860/i960) RISC-CPUer som StrongARM misslyckades att komma någonstans.

Jag får mest känslan av att historien upprepar sig med att någon uppfinner något nytt och elegant som sedan faller för olika praktikaliteter.

Jo, det problemet kommer man ju inte ifrån, jag tvivlar mest på kompetensen att förstå såna saker i en värld när det mesta är såpass annorlunda inom datorvärlden. Sen är det ju då även alla gamla styrkort och liknande prylar där den ursprungliga tillverkaren upplösts för flera decennier sedan, där känns det ju spontant som en enklare lösning att ha ett system som är designat för att t.ex. ha en ISA-buss från början.

Nja, vad jag minns så var i860 och i960 mycket tidigare än StrongARM. Intel har alltid haft lite olika produkter och ingen av de har var tänkt att bli någon uppföljare till x86.

Intel 860 var VLIW vilket är svårt att kompilera till, men kan bli riktigt snabbt om får till det i assembler, så det användes mest som en DSP i bl.a. dyrare grafikkort.
Vad jag hört så ska i960 ha gått ganska bra på embedded-marknaden.
StrongARM var ganska vanlig som CPU i PDA:er runt millenieskiftet har jag för mig.

Som sagt, AutoCad är en skog av applikationer för respektive disciplin, att kärnan nu äntligen finns till ARM64 betyder i sig väldigt lite för de flesta rent professionellt. För studerande är det ju dock grymt då man absolut klarar sig utan de specifika anpassningarna. Gissar att Architecture blir först eller redan är klart. EAGLE är väl också sannolikt högt upp i kön.

Kollar på mitt konto, på Windows har jag 48 appar att installera, på Mac fyra. Av de fyra är bara två, AutoCad och AutoCad LT kompilerade för ARM64. De två övriga är webbaserade. Av de 48 på Wintel är ju en del webbaserat också.

Mac och ARM är inte på långa väger ett bra val för ingenjörer eller tillverkande industri, det handlar inte om något år är min poäng. Alla dessa CAD/CAM-programvaror har add-ins som är mer eller mindre nödvändiga för respektive disciplin eller bransch. Vissa använder VBA, andra använder .Net för integrering, det finns python-bryggor/wrappers men de är ofta just .Net-applikationer.

Datorer för programmerare och IT-generellt har lite betydelse för stora delar av samhället, IT-branschen och dessa navelskådare är just orsaken till skolplattformar och andra kul IT-konsultprojekt av programmerare som inte förstår att verktyg skall fungera, inte för att en programmera skall få ribba över en ny processorarkitektur.

Arkitekturell CAD och som både Revit och Archicad har startats av arkitekter med programmeringskunskap, till skillnad från AutoCad exempelvis. Nästan alla vettiga add-ins startar med ett ingenjörsbehov, inte ett programmeringsspråksval.

Det tvivlar jag inte på, men hypen då som nu byggde [såvitt jag kan minnas] på att en annan RISC-CPU skulle ta över åtminstone desktopmarknaden inom en snar framtid.

Själv drömde jag om att få köra Windows på Alpha. Jag har även för mig att DEC hade en färdig lösning för virtualisering så att man kunde köra Win32-programvaror med relativt liten prestandaförlust. 🙂

Jo, det är ett sätt att se det. Tyvärr är det få som räknar på saker som är mer svårgripbara än inköpspriset och eventuellt hur länge hårdvaran fungerar. Jag inbillade mig en gång i forntiden även att IT-medvetenheten och kunskaperna skulle öka väldigt mycket när alla och deras farmor hade datorer hemma, men det verkar inte ha hänt än.

Forister här tolkar mig säkert som en generell ARM-motståndare, och det kan jag ju passa på att skriva att jag absolut inte är. Jag är tvärtom glad över de enorma möjligheter som öppnats av att det existerar billiga och snabba CPUer som kan stoppas i olika automationslösningar för konsumenter utan att det påverkar priset nämnvärt.

Hela den mobila marknaden står på ARM i lite olika smaker. Likaså alla möjligheter man fått som hobbynörd att få ihop billiga enkortsdatorer som t.o.m. kan drivas med batterier.

Väldigt intressant att läsa dina uttömmande svar, som vanligt. Forumet borde ha en funktion för att enkelt hitta tillbaka till såna här inlägg.

”Legacy” anses ju ofta som ett fult ord, men även utan nämnvärda programmeringskunskaper så har jag åsikten att det som cementerades på 90-talet kommer hänga med väldigt länge bara på grund av den enorma utbredningen x86 fått sedan vanligt folk fick råd med datorer.

Det blir ju även effekten att många mer eller mindre medvetet hellre jobbar i något som är bekant kontra något potentiellt bättre men okänt.

Få är villiga att ta ens en liten inlärningskurva, vilket man även ser inom Windowsvärlden, i övrigt kommer merparten av alla användare inte att bry sig om vilken arkitektur de kör sina program på. I dagsläget finns ju inte specifikt den ”mjuka övergången”, och det hjälper nog inte att många av vurmarna för andra OS/arkitekturer är fast i sitt perspektiv där det ”bara” är att lära sig något annat.

Är personligen inte oroad över att bakåtkompatibilitet inte kan lösas enkelt med någon form av virtualisering heller eftersom det skett en enorm utveckling åt det hållet i allmänhet de senaste tre decennierna. Det startskottet kommer dock mest sannolikt komma ifrån de som är dominerande, som du är inne på, och inte från några nördar som övertygar världen a’la Kalifornien sent 70-tal.

En skillnad jag stött på är att x86 har bättre stöd för att hantera overflow av heltalsberäkningar.
Nyare, populära programmeringsspråk som t.ex. Swift och Rust vill gärna ha det.

Rust har visserligen en workaround iom att overflow-koll endast är påslaget i Debug-byggen, och avslaget i Release. Då gäller det att alla ens såna buggar har hittats i tester innan släpp ...

Hur är x86 bättre?

Både ARM64 och 32-bit Arm kan specificera om en instruktion ska påverka flaggor eller ej. I majoriteten av fallen vill man inte att flag-fältet ska uppdateras då det är en (av flera) anledningar att CPU får svårt att köra många instruktioner parallellt. Nästan alla ALU instruktioner i x86 kommer ha implicit påverkan på flag-flältet, något som ger extra komplexitet i out-of-order designer.

RISC-V har tagit detta ännu ett steg längre (primärt för att förenkla designen och öka potentiell ILP), där finns inte ens ett flag-fält (vilket fortfarande är "upp till bevis" om det är ett smart drag, finns både uppsida och nedsidan).

Tar vi t.ex. denna Rust-kod som även kollar för overflow i release, ger "panic" vid overflow

pub fn add_with_overflow_check(a: u32, b: u32) -> u32 {
    a.checked_add(b).unwrap()
}

Så ser den relevanta delen ut så här på x86_64, alla kompilerade med samma rustc kompilator

        add     edi, esi
        jb      .ERROR_HANDLING_PATH
        mov     eax, edi
        ret

ARM64

        adds    w0, w0, w1    ;; ALU instructions ending with "s" update flags, instructions without don't
        b.hs    .ERROR_HANDLING_PATH
        ret

ARMv7

        adds    r0, r0, r1   ;; ALU instructions ending with "s" update flags, instructions without don't
        bxlo    lr           ;; 32-bit ARM-ism, this will only take effekt if O-flag is set, is otherwise a no-op
        ;; error handling follows

RISC-V

        mv      a2, a0
        addw    a0, a0, a1
        sext.w  a1, a2
        bltu    a0, a1, .ERROR_HANDLING_PATH
        ret

32-bit Arm är typiskt crazy kompakt, men att nästan alla instruktioner är villkorade är ingen höjdare om man vill bygga "breda" mikroarkitekturer... Men det är guld värt för enkla in-order CPUer

ARM64 är mer kompakt än x86, i detta fall delvis p.g.a. hur ABI är definierat för x86_64 (returvärde måste ligga i eax, första och andra argumentet kommer i edi och esi)

Just i detta fall syns nackdelen med RISC-V designen, det blir en instruktion mer än för x86_64. Majoriteten av instruktioner behöver dock inte flaggor och är en lite förenkling att helt skippa flagfältet. Behövs high-end RISC-V som ställs mot likvärdig ARM64 för att avgöra vem som valt "bäst" här (min gissning är tyvärr på ARM64, vill se RISC-V som slutlig "vinnare").

x86 har direkt stöd för overflow-koll i alla fyra räknesätten, samt vänsterskift (bara med 1 men ändå).

ARM64 har bara stöd i "add" och "sub". "mul" behöver fyra instruktioner.Motsvarigheten för "sdiv" blir flera cmp och branch.
Eftersom RISC-V inte har inga flaggor alls eller "smarta" instruktioner för bit-fippling som ARM har så det blir ännu fler instruktioner, ja.
Om overflow-koll ska vara det normala så spelar det roll.

Jag håller med om att det är bättre när flaggor sätts bara av vissa instruktioner. Ännu bättre vore det om flaggan var kumulativ, så att man behövde kolla den först efter att en beräkning är klar, innan man sparar resultatet eller använder det för control flow. PowerPC har såna instruktioner och flagga, men den verkar bara funka för signed overflow.
ARM har en kumulativ flagga för sina mättande SIMD-instruktioner, men då också bara för add, sub ... och ett par ovanliga DSP-instruktioner. RISC-V's V-utökning har det också för mättade SIMD add och sub.
Den föreslagna "P"-utökningen till RISC-V (SIMD i heltalsregister) har kumulativ flagga för mättnad och använder heltalsregister men den har inte kommit närmare standardisering eller implementering på ett par år, så jag är rädd att någon variant av den aldrig blir av.

Låter lite som Apple, de tog bort allt 32-bit stöd för några år sedan i MacOs. Kontentan blev att alla 32-bitars program/spel som användare har köpt via appstore och inte längre fungerar, så hänvisar Apple att utgivaren till spel/program som har ett antal år på nacken ska uppdatera dessa. Vilket i praktiken aldrig hände och användare fick roll-back och gå tillbaka till föregående operativsystem.
Så hur ser Intel på framtiden, ska man sitta kvar på ett gammalt system eller enbart köpa Amd om man vill behålla sina spel/appar som inte är renodlade 64-bit?

Jag ser att du inte förstod vad jag skrev.
Jag var en av de som var med om det när Apple uppgraderade MacOS till att ta bort allt tidigare stöd för 32bit. De tidigare MacOS var också 64bit system, men de raderade stödet för 32bit applikationer.
Hänt för längesen? Aldrig i Windows miljön iaf. Går du in på C:\ så har du väl 2st program mappar, en vanlig ”program” och en ”program x86”. Så även om du kör Xp 64 bit, så har det fortfarande stöd för 32bit. Nu handlade det väl om att skrota att ens kunna exekvera 32bit?

Kan x86s ge bättre prestanda?

Ja, en ny icke-kompatibel standard löser såklart alla problem.
Låt oss kalla den för tItanium!

Den är ju kompatibel nog att snittpersonen inte kommer märka av det så länge som de kör ett uppdaterat OS. Inte alls som Itanium som var helt annorlunda i grunden.

Ja, förenkla x86 så kan vi få ut lite dugliga x86-processorer med rimlig prestanda ett tag till.

@kotz Senaste det pratades om att fimpa alla uråldriga stenåldersinstruktioner så snackades det om ett prestandalyft på ca 30% över ett bräde. Det är värt det om man kan bibehålla 90% av prestandan i emulerade lager av uråldrig programvara likt rosetta.

Hm, vet du mer specifikt varför det skulle göra så stor skillnad?
Det är väl knappast tal om 30%+ kretsyta som sparas in (och 30% extra kretsyta ger väl knappast 30% prestanda?), så varifrån kommer prestandaökningen?

x86S lär inte ge någon prestandavinst alls i sig själv. Däremot kan man ju ta de transistorer man skulle spara in och i stället lägga de på något som kan förbättra prestanda
Men ja, handlar knappast om några 30 % utan i bästa fall kanske någon enstaka procent.

Det som x86S skulle ändra är att ta bort stöd för något som i praktiken ändå inte används. Tvärtom betyder dess existens mer kod bara för att ta sig förbi "gamla lägen som sendan länge helt saknar relevans i moderna OS". Detta vore huvudsyfte med denna manöver.