Du kan kjøre vanlige Windows-programmer på nye Windows 10 for ARM

[vidor]

 

En ting er å emulere RISC med CISC, men det mer krevende å emulere CISC med RISK.

Arkitekturen i en moderne x86 prosessor (P6 og nyere) har veldig mye mer til felles med en RISC-arkitektur enn en klassisk CISC-arkitektur...

 

En Intel Skylake for eksempel har fire enkle og en kompleks dekoder som dekoder x86-instuksjoner til "micro-op" som er RISC-lignende instruksjonsett. CPU'en vil også prøve å optimere disse "micro-op" videre, ved hjlp av teknikker som "maco-Op fusion", "micro-op fusion", etc.

Det er faktisk noen legacy CISC-instruksjoner som aldri lenger brukes i moderne kompilatorer, men som må støttes grunnet bakoverkompatibilitet som faktisk ikke Skylake sin komplekse dekoder støtter. Disse instruksjonene må "falle tilbake" til en mikrokode i prosessoren som gjør software-oversetting.

Ser du på Zen-arkitekturen til AMD har de i større grad valgt å droppe hardware-støtte for veldig gamle instruksjoner for å få CPU-designet enklere. Intel sin "front-end" på prosessoren er en av de mest kompliserte delene på Core-arkitekturen.

 

Skjønner godt om arkitekturdesignet blir løst på gjennomtenkte måter for å forenkle prosessordesignet og ha høy klokkefrekvens. For alt jeg vet er dette er fornuftig kompromiss da prosessordesign er rimelig avansert. Det er endel å støtte for å være kompatibel med alle spesialfunksjonene de har støttet og implementert over tid. En ting er at en prosessor emulerer dette "in-house" bak en op-kode spesifikasjon. Det spiller jo ingen rolle for brukeren så lenge output er forutsigbart. En har fremdeles op-koden som man eksponerer ut og om man støtter en slik kommando så må den også emuleres på en annen plattform, forhåpentligvis like kjapt.

 

De fleste ønsker å bruke de funksjonene som er tilgjengelig og kjappe for å lage responsive systemer. Når man designer metasystemer for noe annet klarer jeg ikke helt å se rasjonalia i det.

 

Det er til slutt markedet som bestemmer om ideen og implementasjonen er god. De kan markedsføre fletta av dette, men underliggende design må være godt for å ha en sjanse til å ikke floppe.

 

Tror nok hele prosjektet til MS har med å fjerne seg litt fra den sterke knytningen de har til Intel ved å åpne for alternativ. Det er mange grunner for at de burde ha egeninteresse av å lage en best mulig løsning.

Endret 25. desember 2017 av vidor

[vidor]

Ser ut til at det ikke er så lenge til folk kan begynne å teste W10 på ARM

 

http://bgr.com/2017/12/07/snapdragon-845-vs-835-qualcomm-galaxy-s9-windows-10/

Endret 9. desember 2017 av vidor

[Lostfields]

Høres veldig castle in the sky ut dette prosjektet til MS. Tror det når jeg ser det, for å si det sånn.

 

Det blir en rimelig stor overhead på emuleringen av å kjøre X86 til ARM så man trenger mye ytelse på ARM for å få en brøkdel av av ytelsen på X86, og det er ikke så få linjer native X86 kode i de fleste program at det på noen måte utgjør at optimaliserte systemkall er majoriteten av en .exe på flere megabyte. En kan nok optimalisere rimelig bra som utvikler hvis man kompilerer native, men det MS satser på her er jo å lage er jo å lage en transparent emulering av native X86, så da konkurrerer dem jo mot native ARM og ekstremt gode JIT-løsninger som allerede har et stort forsprang.

 

Dette virker mest som usubstansiert PR designet for å overselge Windows 10 ARM.

Det kan sikkert bli et verdifullt produkt for noen som ikke har så store ytelseskrav, men MS burde holde seg for god til å prøve på innsalg sånn som dette.

 

Ta en titt på https://www.extremetech.com/computing/249292-microsoft-declares-windows-10-arm-devices-will-run-x86-code-near-native-speed