Arm's 'big' cores ondersteunen vanaf 2022 alleen nog 64-bit

De zogenaamde 'big' cores van Arm's Cortex-A-generatie van soc's ondersteunen vanaf 2022 alleen nog 64-bit en geen 32-bit meer. In 2022 verschijnen Arm's Makalu-chips, die dertig procent hogere prestaties dan de huidige Cortex-A78-cores moeten bieden.

De overstap naar exclusief 64-bit voor de krachtige cores van toekomstige Cortex A-generatie in 2022, maakt dat in 2023 de eerste mobiele apparaten verschijnen die alleen met 64-bit-code overweg kunnen en niet meer met 32-bit-code. Volgens Arm maakt de 64-bits instructieset hogere hardwareprestaties mogelijk, waar apps en rekentaken rond kunstmatige intelligentie en AR en VR van kunnen profiteren. Bovendien zouden ontwikkelaars er voordeel van hebben, vanwege de prestatiewinst bij het compileren in 64-bit en de focus op een enkele set binaries.

Arm maakt voor zijn soc-ontwerpen gebruik van een configuratie van kleine, zuinige cores en grote, krachtige varianten. Het bedrijf noemde deze ontwerpen aanvankelijk big.Little en sinds 2017 DynamIQ. Uit de bewoordingen van Arm valt op te maken dat de zuinige cores in ieder geval aanvankelijk nog 32-bit ondersteunen, en zo waarschijnlijk bestaande 32-bit-apps kunnen blijven draaien.

De Arm-architectuur ondersteunt al sinds 2011 64-bit-verwerking, bij de komst van ARMv8-A. Het gaat hierbij om de AArch64- of ARM64-extensie, die naast de AArch32- of 32-bit-instructieset aanwezig is. Socs kunnen daarmee zowel 64-bit- als 32-bit-apps draaien. Het laten vallen van AArch32 biedt Arm mogelijkheden om de grote Cortex-A-cores te verbeteren. Softwareleveranciers zijn al langer bezig met de overgang naar 64-bit. Apple ondersteunt vanaf iOS11 al geen 32-bit-apps meer en Google eist sinds februari 2019 dat van Android-apps ook 64-bitversies verschijnen.

Arm publiceerde verder een roadmap waar de Matterhorn-generatie van Cortex-A voor 2021 en Makalu voor 2022 op staan. Een enkele Makalu-core zou tot aan 30 procent beter moeten presteren dan een Cortex-A78-core, aldus een schatting van Arm op basis van SPECint_base2006-resultaten. Details over deze komende generaties gaf Arm verder niet.

Reacties (47)

[no_way_today]

Zelf niet zo veel verstand van, maar wanneer komt 128bit?

[supermidget]

Logische vraag, omdat 64bit het dubbele lijkt van 32bit, maar dat is het eigenlijk niet. Het dubbele van 32bit is 33bit.

Het aantal mogelijke instructies (operaties, waardes, adressen) die uit te drukken zijn met 32 extra bits wordt niet 2 keer zo groot, maar 4,294,967,296 (4 miljard) keer zo groot.

[Reactie gewijzigd door supermidget op 23 juli 2024 10:06]

[MSalters]

Het aantal mogelijke instructies (operaties, waardes, adressen) die uit te drukken zijn met 32 extra bits wordt niet 2 keer zo groot, maar 4,294,967,296 (4 miljard) keer zo groot.

Dat klinkt overtuigend. Er is alleen een probleem mee. Het aantal mogelijke instructies is niet gegroeid met 32 bits. Sterker nog, het aantal mogelijke instructies is helemaal niet gegroeid. ARMv7 had 32 bits instructies, en AArch64 heeft exact dezelfde lengte instructies.

AArch64 is dan ook een verwijzing naar de breedte van de registers. In ARMv7 heb je 15 registers van 32 bits; AArch64 heeft 31 registers van 64 bits.

Maar wanneer krijgen we 128 bits registers in ARM? Het antwoord is "Die hebben we al 10 jaar". Met de NEON extensie kreeg de 32 bits ARM al een extra set van 16 registers van elk 128 bits, naast de 15 bestaande. Niet zo gek, Intel had al een paar jaar eerder SSE registers op x86.

Het punt met deze 128 bits registers is dat ze beperkt zijn tot getallen, maar geen geheugenadressen kunnen verwerken.

[supermidget]

Bedankt voor je toelichting! Het verduidelijkt dat in de registers meer ruimte komt, zodat je operaties op grotere waardes kunt doen, en daar ook grotere adressen in kunt bewaren

Maar om een instructie zoals 'bewaar geheugenadres X in register A' uit te voeren, wil dat dan niet zeggen dat de instructie breed genoeg moet zijn om ook de lengte van 'adres X' te bevatten?

In die zin zijn er niet instructies bijgekomen (instructieset is misschien hetzelfde, of de lengte van de opcodes is niet veranderd), maar de argumenten kunnen wel langer zijn. Dus als je die beschouwd als onderdeel van de instructie, kun je zeggen dat het aantal mogelijk instructies toenam. Of is dat niet de juiste manier om erover te denken? :-)

[MSalters]

Een instructie "bewaar 32 bits geheugenadres X in register A" past sowieso al niet in een 32 bits instructie. Dus het maakt niet uit dat geheugenaddressen of registers nu 64 bits zijn.

ARM had wel instructies om een 12 bits waarde X in register A te bewaren. Dat was wel slim geïmplementeerd. Het waren niet simpelweg waardes 0-4095, want zo vaak heb je de waarde 3751 ook weer niet nodig. In plaats daarvan kon je de waarde X*4^Y bewaren. Hierbij was X een waarde <255 en Y<16. Daarmee kon je makkelijk bitmasks maken, bijvoorbeeld 0x80000000 hex of 0x0000FF00.

Wat betreft "het aantal argumenten", het is een RISC architectuur. Elke instructie is 32 bits, inclusief de argumenten. Daarom heeft een branch instructie ook meer ruimte (25 bits) voor het geheugenadres, en een kortere codering voor de branch zelf.

[no_way_today]

Dat is inderdaad wat ik dacht, maar dan zou 128 gigantisch zijn en niet nodig! Dank voor jullie uitleg!

[marcovtjetje]

Het dubbele van 32-bit is 64-bit. Twee keer zoveel adreslijnen.

[jorisvergeerTBA]

Elke adreslijn is een verdubbeling van het bereik.

[marcovtjetje]

En een nog grotere aantal mogelijke combinaties. En dat is ook niet relevant.

In een chip zitten adreslijnen, de 2^64 bytes moet je er zelf bijstoppen met DIMM reepjes. (en de meeste consumenten CPUs supporten niet eens geen volle 64-bit fysiek geheugen, typisch 48 of 52 bits)

[Fiander]

Wat joris hieronder/boven zegt!
maar voor de datalijnen geldt dan weer wel dat 64 het dubbele is van 32.

[enzozus]

De hoeveelheid fysiek ondersteund geheugen (en daarmee de hoeveelheid adreslijnen) is in werkelijkheid veel lager op huidige platforms. De volledige 64 bits zijn voornamelijk relevant voor "virtual memory" adressen (de adressen die programa's zien, waardoor het lijkt alsof elk programma beschikking heeft over het volledige geheugen), die door de CPU vertaald worden in fysieke adressen.

Maar op huidige 64 bits platforms wordt er zelfs geen volledige 64 bits virtuele memory adressen ondersteunt, omdat dan de vertaaltabellen om van virtueel naar fysiek te gaan te groot worden. Op x86-64 bijvoorbeeld zijn er maar 48 significante bits toegestaan zelfs in virtuele adressen, en moeten de hoogste 16 bits gelijk zijn aan bit #47 (mogelijk zijn er nu al CPUs met iets meer bits?) Op ARM heb je volgens mij iets soortgelijks.

[GertMenkel]

Niet, tot we 16 exabyte aan geheugen weten te vullen. Misschien dat bepaalde velden baat zullen hebben bij integeroperaties op getallen van die ordegrootte, maar voor de consument heeft 64-bit de komende decennia nog wel genoeg ruimte.

Eigenlijk is 64-bit al veel te veel voor moderne computers; het was alleen makkelijker om de bitgrootte te verdubbelen dan om aan 32 bits nog een keer 16 bits vast te lijmen: 48-bit had ook prima aan onze eisen kunnen voldoen, maar het is makkelijker om onderdelen volledig te hergebruiken en dubbel uit te voeren (door 32 * 2 bits te pakken) dan om extra hardware te ontwikkelen voor een onhandig aantal bits (40/48/56-bit). Net zoals IPv6 eigenlijk, die is nu 128-bit en is zo groot dat iedereen praktisch een adresblok ter grootte van IPv4 krijgt en nog zijn er voor de komende dertig jaar genoeg adressen.

Zwaar overkill als je objectief kijkt, maar je kunt beter te veel van iets hebben dan achteraf te concluderen dat je te weinig had.

[tweaknico]

Over het aantal bits spoor breedte van een CPU zijn al heel vormen geweest.
1, 4, 8, 16, 18, 24, 28, 30, 32, 36, 48, 60, 64 zijn populaire waarden geweest
Ook oneven afmetingen: 31,45 komen voor

1? ja bitslice processoren waarvan je er net zoveel naast elkaar kon zetten als je wil.
4: 4004 de "eerste cpu"
8: 6505, 8008, 8080
16: later systemen...
18: Dec system 10
24: Harris
32: veel CPU's
36: DECsystem 20
45: Almaz (rusland)
48: Buroughs
60: Cyber
64: moderne processoren...
128: ICL had een systeem dat 128 bit Floating point data direct kon verwerken.

Register breedtes kunnen handig zijn als ze direct passen op adres lijnen maar dat hoeft niet...
Z80, 8080 gebruikten 16 adres lijnen maar 8 bits ALU's
8086, 8088 gebruikten 20 adres lijnen mar 16 bit ALU's

En de meeste CPU's met grote spoor breedte (64 bits CPU;s bv.) hebben lang niet zoveel physieke adres lijnen. Virtual Memory != Physical memory.
IBM/370 begon als 32 bitter met 24 adres lijnen, later toto 31 opgerekt (XA).

Opvoeren naar 128 bit is niet heel logisch de markt voor dergelijke CPU's niet m.i. niet groot genoeg.
Voor berekeningen is een brede ALU niet nodig. VAX (32 bit systeem, uiteindelijk ook 32bit adres lijnen) kon met data overweg van 128 bit Floating point en integeres (en gebruikte hier van 4 opeenvolgende registers voor).
De x86 CPU's kennen trouwen ook 80 bit floats.

[sympa]

De breedte van de adresbus, de adresgrootte en de databus en datagrootte zijn natuurlijk niet dezelfde dingen.
De adresgrootte is vaak 32 en 64 bits.
De adresbus was vaak geen 64 bits. Op de CPU kan je dan niet al het geheugen aansluiten wat je ook kan adresseren (is ook overkill voorlopig).
En bij de databus zijn er natuurlijk 32 bits processoren die 64 bits floats kunnen verwerken. Of neem AVX-512: 512 bits in 1 keer, maar zo breed is de adresbus echt niet - niet buiten de chip in elk geval.
Of neem de 8088: 16 bits processor, maar met een 8 bits databus. Langzamer maar 100% compatibel met de 'echte' 8086.

[tweaknico]

Wat ik zeg dus.

[.oisyn]

het was alleen makkelijker om de bitgrootte te verdubbelen dan om aan 32 bits nog een keer 16 bits vast te lijmen: 48-bit had ook prima aan onze eisen kunnen voldoen, maar het is makkelijker om onderdelen volledig te hergebruiken en dubbel uit te voeren (door 32 * 2 bits te pakken) dan om extra hardware te ontwikkelen voor een onhandig aantal bits (40/48/56-bit).

Ik denk niet dat daar ook maar iets moeilijkers aan is. Sterker nog, dat zal vast goedkoper zijn geweest omdat je minder transistors en datalijnen nodig hebt. Het punt is alleen, dat is niet echt toekomstgericht. Oude 32-bits code runt natuurlijk niet in een CPU die alles als 64-bits (of 48 of whatever) interpreteert. Daar is dus een nieuwe modus voor, en het heeft een aparte OS versie nodig om in die modus te kunnen runnen. Als je naar iets als 48-bits gaat, waarmee je 256 terabyte kan aanspreken, dan zul je binnen de kortste keren wéér moeten upgraden, met alle gevolgen van dien.

Het is dan makkelijk om 1 keer over te schakelen naar 64-bits. En omdat je de volledige 64 bits nog niet nodig hebt, gebruik je die extra adreslijnen gewoon nog niet. En dat is dus precies wat er momenteel gebeurt - hedendaagse x86-64 cpu's gebruiken slechts een 48-bits adresbus. En om compatible te zijn met de toekomst, moet bit 47 herhaald worden in bits 48-63 zodat je een nette onderhelft en bovenhelft krijgt die ook blijft werken als ze in de toekomst meer bits gaan gebruiken. Zie https://en.wikipedia.org/wiki/X86-64#VIRTUAL-ADDRESS-SPACE.

[Squee]

De meeste processoren zijn dan fysiek gezien ook slechts 48 bits of iets dergelijks qua adressen; bij beide fysieke adressen maar ook virtuele adressen in sommige gevallen (er zijn wat uitzonderingen). Zo heeft Intel niet lang geleden aangekondigd van 48 naar 57 bits virtuele adressen te gaan in Ice Lake (wat een 5-level page table vereist). Wat je bijvoorbeeld ziet met 48-bit virtuele adressen is dat de hoogste bits [63:48] dan of allemaal 1 of allemaal 0 moeten zijn. Veel architecturen kennen dat, zo had SPARC ook een zogeheten "VA hole".

[.oisyn]

De bitgrootte slaat vooral op de breedte van het standaard register, wat in een flat memory model bepaalt hoeveel geheugen je kan adresseren. Aangezien je met 64 bits theoretisch 16 exabytes aan geheugen kan adresseren, staat een vergroting ervan voorlopig nog niet op de planning

[Reactie gewijzigd door .oisyn op 23 juli 2024 10:06]

[wica]

Als het om het benaderen van geheugen gaat, zullen we idd niet snel boven de 64bit uit hoeven te komen.

Maar gelukkig hoeft dat niet de enige reden te zijn, ik denk dat we wel boven de 64bit gaan uitkomen. Daar we meer en meer aan encryptie gaan doen. Wat ook nog eens steeds sneller verwerkt moet worden.

[.oisyn]

Maar grotere registers hebben we allang, en eveneens speciale instructies om dat soort bewerkingen te versnellen.

[wica]

Klopt SSE doet dat o.a. maar de CPU moet dat nog steeds in stukjes hakken.

[.oisyn]

De CPU moet helemaal niets . Als een implementatie dat hardwarematig wil versnellen dan kan dat gewoon. AVX-512 geeft registers met in totaal 512 bits. Over het algemeen om SIMD bewerkingen te doen met bijvoorbeeld 16 32-bit floats of ints in een enkel register, maar feit blijft dat er gewoon mogelijkheden zijn om grotere int ALU's te gebruiken zonder dat er iets aan de architectuur hoeft te veranderen. 128-bit of grotere general purpose registers zijn gewoon niet echt nuttig.

[Reactie gewijzigd door .oisyn op 23 juli 2024 10:06]

[Fiander]

Mee eens
Ik vind het zelf alleen wel zonde dat AMD er bij het maken van x64 voor heeft gekozen om het aantal registers slechts te verdubbelen van 8 naar 16. Dat had gerust naar 64 of 128 gemogen.
de 1024 van de Itanium zou te veel zijn geweest.
Het zou het voor compilers een stuk gemakkelijker hebben gemaakt om optimalisaties uit te voeren.

[.oisyn]

Maar het zijn geen RISC registers. Onder water zijn er echt veel meer. In een Zen core zitten bijvoorbeeld 168 GP en 160 SSE registers. De CPU doet intern al allemaal optimalisaties bij het uitvoeren van de instructies, en maakt gebruik van register renaming om de logische registers on-the-fly te vertalen naar fysieke registers. Hierdoor kan een logische register alweer opnieuw gebruikt worden voor een nieuwe instructie terwijl de oude waarde nog in gebruik is voor een oudere instructie.

[Fiander]

kan zijn, maar wanneer een compiler nu ziet dat hij geen vrij register heeft, zal hij iets naar het gehuegen moeten sturen, en dat later weer ophalen. Dan kan de cpu ivm de pipeline nog zoveel registers hebben, die geheugen operaties verdwijnen er niet door.

[.oisyn]

Nonsens, dat gaat sowieso eerst naar L1 cache, en de CPU is heel goed in het herkennen van effective addresses. Als een store even later wordt gevolgd door een load vanaf hetzelfde adres, dan krijg je te maken met store forwarding waarbij de CPU de waarde direct uit de store buffer pakt (nog voordat het naar L1 cache is gegaan). Dat is net zo snel als een register.

[Reactie gewijzigd door .oisyn op 23 juli 2024 10:06]

[MSalters]

De CPU moet helemaal niets . Als een implementatie dat hardwarematig wil versnellen dan kan dat gewoon. AVX-512 geeft registers met in totaal 512 bits.

En stiekem heeft wica daar helemaal gelijk. De CPU moet die 512 bits nog steeds in stukjes hakken.

Geloof je't niet? Dan moet je maar eens googlen op "AVX 512 lanes". Die nieuwe AVX registers hebben intern nog steeds 4 "lanes" van 128 bits elk, net zo breed dus als de originele SSE1 registers. Het gevolg is dat ze wel een "shuffle" hebben waar je float 0 en float 3 kunt swappen (zelfde 128 bits lane) maar niet floats 3 en 4 (want niet in dezelfde lane).

En zelfs in die 128 bits lanes heb je nog geen 128 bits integers. Je heb wel een bitshift, maar die kan niet eens over een 64 bits grens heen shiften. "1 << 64" is geen operatie die in AVX512 mogelijk is, laat staan "1<<511". Het zijn, zoals je zegt, effectief 16x32 bits waarden die je met 1 instructie kunt bewerken. En dat laatste is de winst. Het scheelt nogal in de instructie decoder.

[.oisyn]

En stiekem heeft wica daar helemaal gelijk. De CPU moet die 512 bits nog steeds in stukjes hakken.

Nee, dat heeft ie niet, en nee, dat hoeft een CPU niet. Ik ben bang dat je de context van de discussie uit het oog hebt verloren. Hij zegt dat de bitgrootte uiteindelijk wel omhoog moet vanwege bijv. encryptie, maar dat hoeft helemaal niet. Niets staat een theoretische implementatie in de weg om dat uit te voeren met de huidige set registers die we hebben (en wat extra instructies natuurlijk). En dat gaan we niet ineens x86-128 noemen oid.

Maar dat een hedendaagse implementatie dat niet doet, doet daar weinig aan af

[Reactie gewijzigd door .oisyn op 23 juli 2024 10:06]

[Sandor_Clegane]

Voor filesystems doen we dit al en een Iseries van IBM heeft een 128bit memory adress space.

[sebastiaan1997]

Voorlopig nog niet. Qua geheugen is het niet echt nodig om grotere getallen te gebruiken en voor de grootte van getallen ook niet echt. 2^64e is fors. De meeste CPU's zijn voor geheugengroottes zelfs nog 48-bit

[Reactie gewijzigd door sebastiaan1997 op 23 juli 2024 10:06]

[AmbroosV]

Not any time soon. 64bit was echt nodig vergeleken met 32bit (beperkingen qua RAM), 64bit zit lang niet tegen de limieten.

Als het over berekeningen gaat, instructiesets hebben veel instructies aan boord die kunne werken met meer dan 64 bits aan data, dus de hele instructieset verhuizen naar 128bit of meer is ook daarvoor niet nodig.

[dmantione]

Het zou kunnen dat dat nooit gaat gebeuren: Je kunt 18 exabyte (decimaal) geheugen met een 64-bit adresruimte aanspreken. De kans is levensgroot dat de Wet van Moore definitef ten einde is voordat dat een beperking wordt. Het vergroten van de grootte van een integerregister naar 128-bit is eveneens maar beperkt nuttig, maar maakt processoren wel stukken complexer.

[Aetje]

64 bit kwam als respons op addresseringsproblemen voor geheugen. 32 bit kan maximaal 4GB addresseren (tenzij je zaken zoals physical address extension toepast, maar dat gaat ten koste van performance), en de hoeveelheid geheugen die computers kregen nam alleen maar toe.
64 bit zal uiteindelijk ook te klein worden als we op de huidige trend doorgaan, maar dat gaat nog wel even duren. 16 Exabytes zullen we nog niet zo snel in ons desktopje prikken

[inorde]

Volgens mij heeft 128bit niet zoveel zin momenteel. 32bit werd een probleem omdat je maar max 4gb aan geheugen kon aanspreken. Bij 64 bit is deze grens ver voorbij de horizon verschoven, je hebt het dan over 16 exibytes volgens stack. Verder is 64bit mooi voor floating point nummers wat goed werkt bij moderne games/applicaties, maar er is volgens mij zelden meer nodig dan dat.

Even een gesprek met de dochter tussendoor en vier mensen hebben al gereageerd...

[Reactie gewijzigd door inorde op 23 juli 2024 10:06]

[davekok]

Van 64bits naar 128bits integers en pointers gaan vraagt veel meer geheugen. Gezien software een hoop van die dingen heeft staan in het geheugen. Dus waarschijnlijk pas als we genoeg RAM hebben.

[MauricevL]

Dit soort grotere getallen (en ruim meer dan 128bit) zie je dan weer wel terug komen als we het hebben over geheugen bussen, om de bandbreedte te vergroten terwijl de geheugens op een zelfde clock frequentie werken.

[rob12424]

128 bit ik wat? ;P in Bestandssysteemen is het er al: zfs is 128 normen Btrfs volgens mij nog meer.

[Verwijderd]

Ik zou dat erg jammer vinden want de meeste oudere spelletjes lopen op 32bit.
Ik denk niet dat ze die nog gaan porten naar 64bit.
Tenzij ze een emulatie optie bij doen, net als bij Windows om oudere versies te simuleren.

[Eagle Creek]

Op een 64-bits x86 processor met een 64-bits Windows besturingssysteem functioneren 32-bits applicaties prima middels emulatie (volgens mij is dit WoW). Daar zal dus niet veel aan veranderen. Ik ben wel nieuwsgierig of dit ook geldt voor Windows op ARM.

[.oisyn]

Op een 64-bits x86 processor met een 64-bits Windows besturingssysteem functioneren 32-bits applicaties prima middels emulatie (volgens mij is dit WoW).

Nee, een 64-bits x86 processor heeft gewoon een 32-bits modus. Dat heeft een 64-bits ARM CPU momenteel ook, maar dit bericht gaat er juist over dat die modus verdwijnt.

De WoW-laag waar je het over hebt gaat vooral over de interactie van een 32-bits applicatie met de 64-bits kernel, en de componenten die er tussen zitten (zoals DLL's) die zowel in 32-bits als 64-bits versie naast elkaar leven. Maar de instructies van een 32-bits applicaties worden gewoon native uitgevoerd met de CPU in 32-bits modus.

Dit is trouwens precies de reden waarom oude DOS-applicaties niet meer werken in een 64-bit Windows. Er is in Long Mode, zoals de 64-bit modus heet, niet mogelijk om terug te schakelen maar 16-bit Real mode (of virtual x86 mode, wat een manier is om real mode in een beschermde omgeving te draaien). De enige manier om dat te implementeren is via instructie emulatie (zoals bijv. DOS-box) of hardware CPU virtualiation (zodat je een virtuele 32-bit kernel kunt draaien die de app runt in virtual x86 mode).

[Reactie gewijzigd door .oisyn op 23 juli 2024 10:06]

[dec0de]

De meeste oudere spelletjes zijn niet grafisch intens oid, die kunnen inmiddels prima op de low power cores werken van arm SoCs.

[jerkitout]

Offtopic, maar ik zou zo graag een Raspberry Pi 5 met Cortex-A78 zien.

[divvid]

zowiezo zijn dat briljante dingetjes.

[Squee]

Bedenk ook dat dit dus het afschaffen van 32-bit modus in de client/mobile CPUs is. Armv8 server processoren ondersteunen vaak de 32 bit modus niet, wat ook wel te begrijpen is omdat AArch64 een flinke opschoning was van de architectuur terwijl AArch32 zoveel mogelijk met Armv7 backward compatible was. Wat je dus ziet is dat vooral de custom cores zoals bijvoorbeeld de ThunderX2, Fujitsu's A64fx (Fugaku), en voorheen Qualcomm's Centriq allemaal 64-bit only zijn. Overigens ondersteund Arm's eigen huidige server core, de Neoverse N1 (A76 afgeleide), die je nu ook in AWS Graviton 2 vindt, nog wel 32 bit.

[Reactie gewijzigd door Squee op 23 juli 2024 10:06]

[psychicist]

Ik heb die 32-bit modus eigenlijk ook nooit gebruikt en ben bij Cortex A53 ingestapt. Nu heb ik wel enkele armel en armhf virtuele machines (met een 64-bit kernel), maar die blijken slechts zelden nodig te zijn en die heb ik eigenlijk alleen nog maar om 32-bit software te testen voor eventueel embedded toepassingen voor anderen.

[Emiel L]

De overstap naar exclusief 64-bit voor de krachtige cores van toekomstige Cortex A-generatie in 2022, maakt dat in 2023 de eerste mobiele apparaten verschijnen die alleen met 64-bit-code overweg kunnen en niet meer met 32-bit-code.

Dit is een overstap die Apple al heeft gemaakt. Ontwikkelaars hebben een jaar de tijd gekregen om hun apps te updaten (in veel gevallen een kwestie van even opnieuw compileren met 64 bits code ingeschakeld).
Wel een goede zet; hoe eerder je legacy kwijt bent hoe beter. Ik ben benieuwd of ARM's ontwerpen nu weer in de buurt gaan komen van Apple's SoCs qua performance.