Det i sig är inte ett problem då versionen på HW > versionen som programvaran (Windows i detta fall) använder sig.
ARMv8.4-A är ett strikt superset av ARMv8.2-A, så om man bara zoomar in på CPU-delen har M1 inga problem att köras på Windows.
Huvudproblemet är ju att M1, likt de flesta ARM-system, är en systemkrets och för att köra Windows måste det till Windows-drivers för minst GPU och grundläggande I/O för M1.
Skrivet av medbor:
Om jag förstått det rätt angående Rust så är ganska mycket valideringar gjorda redan när det kompileras och tas sedan bort från det som exekverar, det känns som det borde lämna stora gap för säkerhetsbrister kompenserat med mer prestanda?
"Safe Rust" har en semantik som möjliggör för kompilatorn att upptäcka en lång rad av de absolut värsta buggarna som gäckar dagens program redan vid kompileringstillfället. D.v.s. om det kompilerar finns inte dessa buggar, då de inte finns behöver man inte heller leta efter dem vid runtime -> win/win då det ger snabbare program som är garanterad korrekt.
Vissa saker är omöjliga inom ramen av "safe Rust", t.ex. skriva drivrutiner då kommunikation med HW uppför sig "magiskt" jämfört med RAM. Du kan läsa samma adress flera gången och få olika svar hela tiden trots att ingen annan del av CPUn skrivit något.
I "safe Rust" får du ett kompileringsfel om du har data-race, minnesläcka etc. Man kan fortfarande göra off-by-one fel, den absolut största källan till säkerhetsbuggar i C/C++, men i safe-Rust fångas det runtime (likt Java/C#/Python m.fl.).
Det kommer massor med nya språk hela tiden, men väldigt få introducerar något egentligen av värde. C (slutet 60-talet / tidigt 70-tal) gav oss en portabel assembler som än idag är grunden för i princip alla operativsystem, LISP (sent 50-tal) gav oss de saker som många kanske tänker att Java gav oss (automatiskt minneshantering och en virtuell maskin).
Rust är det första sedan C++ som kan realistiskt användas som systemspråk, d.v.s det går att skriva OS-kärnor. Egentligen är det bara C som fungerar, standard C++ går inte använda utan man måste i praktiken köra en nedskalad version. Rust i OS kärna blir också en delmängd av hela miljön, men den delmängden är (kommer bli, man har inte nått 1.0 än) definierad av specifikationen.
Rust knäckte an vår tids största problem: data-race. Få andra moderna språk har tillfört något egentligt av värde är, Go är ett av undantaget då det gjorde hantera av massiv I/O väldigt enkelt. Även om Go egentligen gör samma sak som Erlang, fast Go har också effektiviteten nära C/C++/Rust samt att Go har en syntax många känner igen, att vara annorlunda som t.ex. Erlang är i praktiken ett stort problem.
Tyvärr är inget "gratis". Rust har lite Emacs-känsla över sig, d.v.s. det är en nära vertikal och rätt hög inlärningströskel, tror tyvärr det kommer sätta stopp för språket att bli ett nytt Python eller JavaScript sett till popularitet. Orkar man sig över tröskeln blir man belönad, de flesta lär välja en bekvämare väg.
Skrivet av x86:
Tittar man på de senaste årens utveckling från Apples sida, t.ex. Slopat 32-bitsstöd, OS-förändringar, SwiftUI, non-user-upgradeability, så är det tydligt att de dels har banat väg för sin ARM-plattform, och dels för att ”soften the blow” så att det inte är ARM-releasen som tar bort alla de där sakerna. Då hade mottagandet varit betydligt svalare.
Så, jag tror nog att Apple kan visa intresse för Bootcamp framöver, när hela produktsviten är ersatt.
Slopandet av 32-bitars stödet ända ned på HW-nivå är en del av förklaringen till hur Apple lyckades designat en CPU som så totalt demolerar alla andra CPU-designer sett till prestanda per MHz med hög absolut perf (Cortex A78 lär leda perf/W ligan av "big-core" ARM64, men den ligger en bra bit efter både Firestorm och X1 i absolut perf).
Ställer man 32-bitars Arm mot x86 ser man rätt mycket samma story vi sett genom historen när x86 ställs mot något annat: Arm är bättre på vissa saker, t.ex. blir programmen kompaktare medan x86 är bättre på andra, det är svårt att designa "breda" x86, men det är ännu svårare att designa "breda" 32-bitars Arm (p.g.a. hur ISA är designad).
Ur flera aspekter är 32-bitars Arm och 64-bitars Arm extremer, fast åt olika håll. Lär vara förvirrande, många var ju helt övertygade om att det inte skulle gå att designa en Arm CPU som prestera motsvarande high-end x86. För 32-bitars Arm är det nog sant, man skulle kunna komma nära men det skulle inte gå att göra något likt Firestorm som så totalt kör över både Willow Cove och Zen 3 sett till perf per MHz och perf per Watt samtidigt som den har likvärdig absolut prestanda.
Arm kommer följa efter Apple, high-end Cortex A kommer droppa stöd för 32-bitar inom de närmaste två åren. Det är goda nyheter för Microsoft, de ska helt ignorera 32-bitars stödet på Windows då det ändå kommer vara helt irrelevant när (för är övertygad att efter det Apple visat med M1 är det inte lägre frågan om) ARM64 slår igenom även på Windows.
Det Microsoft har nu i form av Surface Pro X ser jag som deras dev-kit, för att man ska kunna ta Microsoft på allvar måste de göra det Apple gjort: designa en krets som i alla fall på bärbara (som står för merparten av alla PC som säljs) totalt omdefinierar prestanda man kan förvänta sig i en tunn och lätt "ultrabook". Likt M1 måste den vara så överlägsen allt Intel/AMD har att det blir uppenbart att deras teknik nått vägens ände.
Nvidia är inte lätt att samarbete med, men om (tror det bara handlar om när även där) köpet av Arm går igenom är det just Nvidia Microsoft bör sätta sig ned med och diskutera vad de behöver från Cortex A serien för att lyckas med ARM64 på Windows. Cortex X1 är en bra bit på vägen, man att Microsoft inte ens använder den, man har inte ens gått till Cortex A78 utan stannar på en lite högre klockad A76 visar att Microsoft fortfarande inte riktigt släppt sargen.
