AMD: Intels voorstel voor 64bit-only x86-architectuur is zeer interessant

AMD heeft bij monde van Ryzen-topman David McAfee gereageerd op Intels voorstel voor een harde breuk in de x86-architectuur, waarbij alle 32bit-legacy wordt verwijderd. McAfee noemt het voorstel 'zeer interessant', maar ook 'heel erg ingewikkeld' om door te voeren.

David McAfee, corporate-vp en directeur van client channel business bij AMD, deed de uitspraken in een interview met TechPowerUp. In die functie is hij hoofdverantwoordelijke voor alle Ryzen-processors, zowel die voor desktops als die voor laptops. Volgens McAfee denkt AMD al lange tijd na over concepten die vergelijkbaar zijn met Intels voorstel voor x86-S(implified), waaruit onder meer native ondersteuning voor 32bit-besturingssystemen is geschrapt.

"Ik denk dat het niet triviaal zal zijn om de legacy-compatibiliteit uit een corearchitectuur te verwijderen, zeker als we dat zo willen doen dat het perfect uitkomt met een transitie tussen OS'en", zei McAfee in het interview. "Het is heel interessant, iets waar we echt als industrie naar zouden moeten kijken om samen de stap te zetten. Intels voorstel is naar onze mening behoorlijk intrigerend."

In x86-S worden de binnenste 32bit-ringen, de niveaus met de meeste privileges die voor de kernel en drivers worden gebruikt, uit de architectuur verwijderd. Een volledig 32bit-OS zou gevirtualiseerd moeten worden, maar het draaien van 32bit-programma's blijft wel gewoon mogelijk. Het nieuwste besturingssysteem van Microsoft, Windows 11, is overigens al uitsluitend in een 64bit-versie beschikbaar. Ook veel Linux-distro's, zoals Ubuntu, worden niet langer in 32bit-edities uitgebracht.

McAfee ging in het interview desgevraagd ook in op de stilstand van het maximale aantal cores bij processors. De achterblijvende geheugenbandbreedte is volgens hem de belangrijkste reden waarom de topmodellen voor consumenten al een tijdlang op zestien cores blijven steken. Daarnaast stelde hij dat hybride processors met verschillende typen cores vooral voor laptops interessant zijn. AMD-cto Mark Papermaster bevestigde een paar maanden geleden al dat AMD aan dergelijke processors werkt.

Reacties (200)

[CAPSLOCK2000]

Ik heb al een naam bedacht voor deze CPU: Itanium. De instructieset kunnen we dan IA64 noemen en we brengen die CPU uit in het jaar 1999! Op dezelfde dag komt AMD dan met z'n eigen architectuur die veel minder innovatief is maar wel backwards compatible. Niemand heeft zin in de pijn van een migratie naar een andere architectuur en dus kiezen we er voor om dat probleem voor ons uit te schuiven en gaan we voor de weg van de minste weerstand. Vervolgens klagen we 20 jaar lang over de beperkingen van de oude x86-architectuur en dan proberen we het nog een keer.

https://en.wikipedia.org/wiki/IA-64
https://en.wikipedia.org/wiki/Itanium

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 19:44]

[!GN!T!ON]

Geen eerlijke vergelijking toch. IA64 was een compleet nieuwe arch los van X86 of X86_64.

Volgens mij in dit voorstel hoeft een dev niet te recompilen als zijn app al X86_64 is. Dat was bij itanium v.z.i.w. nooit het geval, daarvoor moest alle software recompiled worden en was er 0 backwards compatibility.

Dus volgens mij een appel / peren vergelijking.

[kdekker]

Ik heb Windows op Itanium nooit life (in productie, wel test/beta/intern) gezien, wel HPUX op Itanium (als vervanger van de PA-RISC processor). Daar was een emulator (ARIES) die PA-RISC omzette in HP-IA64. Al heb ik daar zelf weinig voordelen van gezien, omdat we toentertijd een native port op HPUX IA64 maakten (PA-RISC was doen uitstervend).

Punt is en was dat IA64 een compleet andere architectuur was. De C/C++ compiler op HPUX maakte hele andere instructies, met name omdat een Itanium chip hele andere pipelines en scheduler had. Itanium is onder de streep nooit een succesvol project geweest. HP stopt ook met de finale ondersteuning in 2025 (al ben ik al jaren weg bij het bedrijf waar dat toentertijd speelde).

Omdat Itanium altijd al een niche markt was, waren de prijzen ook sky-high. Ondertussen kwam Linux en Windows met Xeon spul, waar ook inmiddels wat RAS en HA achtige zaken ook inmiddels van de Itanium (gekaapt) ingekomen waren. En iteraties (tic/toc) op Itanium ging op den duur zo traag, dat Itanium gewoon doodbloedde. Uiteindelijk is het lastig te zeggen of de samenwerking tussen HP en Intel dood ging omdat Intel er meer voor wilde hebben of omdat HP (bijna) de enige afnemer en verkoper bleef.

Er was volgens mij op Windows ook een emulator om x86 te draaien op IA64.

Verder heb je gelijk. Recompile is waarschijnlijk niet nodig, zolang je software maar geen 32-bit kernelmode zaken doet (en dat kan best snel nog het geval zijn, iets met Atomic dingen, was volgens mij ook al een kernel ding).

Aan de andere kant: als het x86 deel echt weg kan, dan kan de vrijgekomen ruimte op de chip nuttig gebruikt worden voor andere zaken. In die zin is het woord 'intrigerend' een beetje understatement. Mooie ontwikkeling als het lukt. Uit ervaring, overstap van 16 naar 32 bit, 32-bit naar 64-bit, IPv4 naar IPv6: het zijn allemaal zeer langdurige projecten. Maar dat OSs nu al 64-bit zijn, is mooi.

Al zal de embedded markt niet zitten wachten op 64-bit CPUs als 32-bit prima volstaat.

[Reactie gewijzigd door kdekker op 23 juli 2024 19:44]

[GekkePrutser]

Uiteindelijk is het lastig te zeggen of de samenwerking tussen HP en Intel dood ging omdat Intel er meer voor wilde hebben of omdat HP (bijna) de enige afnemer en verkoper bleef.

HP heeft intel juist enorme bedragen betaald om itanium te blijven maken (en zelfs mondjesmaat wat updates te doen) in de laatste jaren, omdat sommige van hun klanten er keihard afhankelijk van waren.

Uiteindelijk is IA64 gewoon een grote misstap geweest voor beiden. Jammer, het had hem helemaal kunnen worden maar de markt heeft het gewoon genegeerd.

[kdekker]

HP heeft er inderdaad een hoop geld in gestoken, maar ik vermoed dat ze wel meer van Intel verwacht hadden en dat ook andere fabrikanten de chip zouden gebruiken. Aan de andere kant: IA64 is altijd hoog gepositioneerd geweest en nooit (voor zover ik weet) als desktop chip bedoeld geweest. In die zin was massa adoptie kennelijk nooit een doel geweest. En alleen daarom al had IA64 de markt nooit kunnen veroveren. Ik weet niet hoe actief Intel in die tijd andere klanten zocht voor een Itanium? Ik heb zelf wel ooit met een prototype gewerkt, dat wel rechtstreeks van Intel kwam (en dus Windows op draaide), maar ook dat was op een moment dat Windows en server markt opkomende spul was (voor mid-jaren 90 was het Novell wat de klok sloeg, pas met Windows NT (en dan eigenlijk vanaf 3.5) kwam de server markt meer in beeld.

Eerder had HP met de overname van DEC ook al een mooie (qua techniek) Alpha processor. Maar ook deze chip, net als de Itanium was 64-bit, op een tijdstip dat anderen nog de overstap van 16- naar 32-bit maakten. D.w.z. beiden speelden midden jaren 90. Al was een AT/286 computer min of meer gemeengoed, maar was er nog volop 16-bit software. Misschien liep HP te ver vooruit want EMT64/x64 is pas van rond/na 2000.

Maar misschien laat mijn geheugen me een beetje in de steek. Het is allemaal al even geleden.

[goarilla]

Ik weet dat er een tijd was dat je een DEC Alpha aan 500 mhz kon hebben die x86 emuleerden en de concurrenten toen (Intel PII 266-300) alle kanten van de kamer toonden. Maar het was ook wel een pak duurder dan de Intel en zeker de AMD en misschien nog de Cyrix/VIA CPU's.

[foppe-jan]

de markt heeft het niet genegeerd, zij heeft er terecht voor gekozen om niet te gaan voor een architectuur die door 1 bedrijf mag worden gemaakt (plus de rambus koppeling waarmee intel kwam).

[field33P]

Uiteindelijk is IA64 gewoon een grote misstap geweest voor beiden. Jammer, het had hem helemaal kunnen worden maar de markt heeft het gewoon genegeerd.

Voor Intel is het doel van Itanium gewoon bereikt: Compaq, HP en SGI overtuigen om Alpha, PA-RISC en high-end MIPS respectievelijk te nek om te draaien. In dat opzicht is het een weergaloos succes geweest. Het is ze alleen niet gelukt om SPARC en POWER te beëindigen.

[Wolfos]

Volgens mij in dit voorstel hoeft een dev niet te recompilen als zijn app al X86_64 is

Dit heeft überhaupt geen invloed op de applicatielaag, want die is al geheel 64-bits. De instructies van 32-bit applicaties worden door WOW64 vertaalt. De 16 en 32-bit instructies worden alleen nog tijdens het bootproces gebruikt. Het voorstel is om de CPU rechtstreeks in de 64-bit modus op te starten zodat de oude instructies overbodig worden.

[.oisyn]

Nou nee hoor, er vindt helemaal geen vertaalslag van instructies plaats. De cpu heeft gewoon een 32-bits modus in de 64-bits long mode en die zal ook gewoon blijven bestaan. WOW64 zorgt alleen voor de compatibiliteit van de API.

[dmantione]

WOW64 vertaalt API-aanroepen, geen instructies. 32-bit applicaties draaien wel degelijk in een 32-bit compatibiliteitsmode van de processor. Die mode blijft gewoon, dus niets om je zorgen over te maken.

[Aaargh!]

Niemand heeft zin in de pijn van een migratie naar een andere architectuur

Het blijft bijzonder dat dit in de PC wereld zo'n enorm probleem lijkt te zijn, terwijl Apple dit ondertussen al 3 keer geflikt heeft, steeds zonder noemenswaardige problemen: Van 68000 naar PPC, van PPC naar x86, en van x86 naar ARM64.

[martijnve]

De reden daarvoor is vrij eenvoudig: In het geval van pc's moet je dit, als je het goed wil doen, afstemmen tussen veel verschillende hardware leveranciers, microsoft (+ evt linux distros) en moet je duizenden software ontwikkelaars en miljarden klanten, die wellicht geen zin hebben om mee te werken, overtuigen dat dit nu de moeite waard is.

In het geval van apple zijn zij de enige leverancier van zowel de hardware als het os en zijn alle software ontwikkelaars en gebruikers al lange tijd volledig afhankelijk van apple en weten ze dat als apple iets wil ze geen keus hebben anders dan braaf meegaan.

Wil zeker niet zeggen dat het voor Apple makkelijk was en dat ze het niet erg goed gedaan hebben. Maar voor de bredere pc-wereld is waanzinnig veel moeilijker.

[Reactie gewijzigd door martijnve op 23 juli 2024 19:44]

[i7x]

Sure, maar zoals het artikel al vermeld, Windows 11 heeft ook al enkel een 64bit versie, en 32bit applicaties kun je eventueel virtueel blijven draaien. Waarom is dit dan nog zo'n punt van discussie? Kun je toch die functionaliteit--die toch al niet meer wordt gebruikt--gewoon schrappen? Of ben ik nou gek? Inderdaad, Apple fixt zo'n trasitie gewoon in 2 jaar en klaar is kees. Ouwe meuk kun je eventueel nog met Rosetta blijven draaien als het echt zo nodig moet. Al dat gepraat over hoe Windows zo anders is en zus en zo komt bij mij altijd heel erg over als slappe excuses. Dat het voor linux distros een issue zou zijn is al helemaal lachwekkend.

[Keeper of the Keys]

Als je kijkt naar het gemiddelde bedrijf/overheids instantie die al meer dan een paar jaar bestaat dan zul je vaak een enorme hoeveelheid legacy dingen vinden die "gewoon" nog moeten werken, of ze dat oplossen door het nog direct op Windows/Linux te draaien of een legacy OS te draaien of iets te virtualiseren die meuk moet draaien.

(ander voorbeeld ik heb voor mijn moeder een dos versie van rummicub via dosbox op haar Linux desktop)

Rosetta werkt vrij goed maar niet 100% en het apple ecosysteem is uiteindelijk dusdanig veel kleiner dan het PC ecosysteem dat legacy meuk meesleept uit de tijd van de 8080 terwijl je op een moderne mac alleen moderne meuk kan draaien, toen ze 32b support dropten draaide in een keer de paar games die voor een mac te krijgen waren op GOG etc. niet meer en dan hebben we het niet eens over powerpc osx, os9, en ouder (8086 zou parallel zijn aan de apple I/apple ][).

Uiteindelijk is het zoals anderen ook al noemden het verschil tussen het apple ecosysteem en PC ecosysteem dat het ene een dictatuur is waar alles door apple wordt bepaald en het andere een democratie/markteconomie/anarchie zo je wil waar de hardware en software delen door een veelvoud van partijen wordt beheerd.

[winwiz]

Die legacy zaken draaien kunnen dan nog prima draaien op de tot de transitie beschikbare hardware.

[dmantione]

Dat kan, maar voor je het weet ziet de markt het als obstakel en mislukt het feestje.

Maar... waarschijnlijk zal het deze keer niet als obstakel gezien worden, omdat oude besturingssystemen op nieuwe hardware installeren sowieso al problematisch is. Als je, zeg, Windows 2000 nodig hebt, pak je daarvoor ofwel inderdaad een oud wrak, of je gebruikt virtualisatie. Virtualisatie voor oude besturingssystemen blijft gewoon mogelijk, dus ik verwacht niet dat de markt hier problemen gaat zien, er verandert eigenlijk niets.

[RJG-223]

Sure, maar zoals het artikel al vermeld, Windows 11 heeft ook al enkel een 64bit versie, en 32bit applicaties kun je eventueel virtueel blijven draaien. Waarom is dit dan nog zo'n punt van discussie? Kun je toch die functionaliteit--die toch al niet meer wordt gebruikt--gewoon schrappen? Of ben ik nou gek? Inderdaad, Apple fixt zo'n trasitie gewoon in 2 jaar en klaar is kees. Ouwe meuk kun je eventueel nog met Rosetta blijven draaien als het echt zo nodig moet. Al dat gepraat over hoe Windows zo anders is en zus en zo komt bij mij altijd heel erg over als slappe excuses. Dat het voor linux distros een issue zou zijn is al helemaal lachwekkend.

Je vergeet dat dit niet gaat om 32-bit applicaties. Het gaat om de firmware (EFI) en de OSen. Die zijn gemaakt voor een CPU die in 16-bit modus opstart. Als dat ineens verandert, dan werken de firmware (EFI) en de OSen dus niet meer. Dan starten ze dus niet meer op. Dat kun je dus niet zomaar veranderen.

Om dit te veranderen, moeten Intel en AMD vastleggen hoe het opstarten van de CPU en de computer in de toekomst dan wel gaat werken (zonder 16-bit modus). Dan kunnen de EFI-bouwers en de OS-bouwers hun software aanpassen. Als dat allemaal gebeurd is, en getest, dan pas kunnen zulke CPUs ook aan eindgebruikers verkocht worden.

Dat alles heeft Apple ook gedaan. Alleen doen ze dat binnen hun eigen gebouwen, en merk je daar niets van totdat ze met een kant en klaar produkt komen. Daar zijn ze beslist langer dan 2 jaar mee bezig geweest. Alleen dat weet jij niet, want ze hebben pas wat gezegd toen ze al bijna klaar waren.

[bzzzt]

[...]
Het gaat om de firmware (EFI) en de OSen. Die zijn gemaakt voor een CPU die in 16-bit modus opstart. Als dat ineens verandert, dan werken de firmware (EFI) en de OSen dus niet meer. Dan starten ze dus niet meer op. Dat kun je dus niet zomaar veranderen.

Zeker wel, want juist EFI is bedacht om van de oude 16-bit modus af te komen. EFI schakelt tegenwoordig de CPU al in 64 bits modus, dat hoeft het OS niet meer te doen.
Enige reden om 32 bits te houden is dat Windows nog wel oude applicaties in 'native' 32 bits modus kan draaien. En dat kan in principe prima ge-emuleerd worden.

Dat alles heeft Apple ook gedaan. Alleen doen ze dat binnen hun eigen gebouwen, en merk je daar niets van totdat ze met een kant en klaar produkt komen. Daar zijn ze beslist langer dan 2 jaar mee bezig geweest. Alleen dat weet jij niet, want ze hebben pas wat gezegd toen ze al bijna klaar waren.

Apple was er inderdaad al heel lang mee bezig, vanaf de eerste 'Apple silicon' iPhone zo ongeveer.
De iPhone en macOS gebruiken op UI na dezelfde systeemcomponenten.

[RJG-223]

Zeker wel, want juist EFI is bedacht om van de oude 16-bit modus af te komen. EFI schakelt tegenwoordig de CPU al in 64 bits modus, dat hoeft het OS niet meer te doen.

Dat werkt voor OSen die EFI ondersteunen. Er zijn echter ook nog OSen die dat niet doen, en wel in 16-bit modus opstarten (bijv. FreeDos). Ik weet niet of FreeDos geport kan worden, maar andere van dat soort OSen wellicht wel.

Hoe dan ook, zelfs al zouden alle OSen reeds in 64-bit modus opstarten, dan nog heeft de EFI firmware dus nu nog wel 16 bit modus nodig. Je moet dus vooraf specificeren hoe de enkel-64-bit modus gaat werken, en dan de overgang plannen. Dan kan de EFI firmware aangepast worden, en de OSen - alhoewel de meest populaire OSen nu allemaal 64 bit zijn, kan het toch zijn dat ze nog bepaalde instructies of functies gebruiken die dan afgeschaft worden. Dat moet dus ook gecontroleerd zijn. En dus moeten de compilers en de assemblers ook aangepast zijn zodat ze die instructies niet meer kunnen genereren.

Ik weet niet wat jij eronder verstaat dat je iets 'zomaar kunt veranderen', maar voor mij betekent dat hooguit een triviale hoeveelheid moeite. Het aanpassen van EFI, compilers, assemblers, en eventueel (vermoedelijk?) Windows, Linux en de BSDs is niet triviaal meer. En dan heb ik het nog niet eens over het testen van dat alles - of het ook echt werkt. Het is dus zeker niet plug-in compatible. Dus conclusie: je kunt dit niet zomaar veranderen.

[bzzzt]

Je noemt FreeDOS als voorbeeld, maar daar heb je op huidige moderne hardware ook al niks aan. Het start, maar je hardware wordt amper ondersteund. FreeDOS wordt voornamelijk gebruikt in emulatoren om een DOS ondergrond te bieden en als je toch al emuleert hoef je ook geen native 16 bits support in je CPU te hebben.
Natuurlijk moet EFI firmware (en mogelijk het OS) aangepast worden als een CPU native in 64 bits modus start, maar daar is het juist om te doen: afscheid nemen van een hele hoop logica die maar een paar milliseconden van je boot sequentie gebruikt wordt en daarna eigenlijk niet meer.

[sfranken]

n 32bit applicaties kun je eventueel virtueel blijven draaien.

32 bit applicaties blijven gewoon werken. Een 64 bit CPU heeft daar geen moeite mee. Wat Intel hier voorstelt is de legacy 32 bit boot code uithalen, wat een OS (mits 64 bit) toch niet gebruikt en dus ook niet meer (actief) ontwikkeld/onderhouden word.

[bzzzt]

Ze stellen toch echt voor de 32 bits support uit te faseren.

[--Andre--]

Support voor 32-bit operating systems, niet 32-bit applicaties.

[rickboy333]

Laat ze dan 2 versies van CPU's uitbrengen. Een met en een zonder 32 bit ondersteuning. Maak de 64 bit versie iets goedkoper en als de vraag naar 32 bit ondersteunende CPU's te laag word dan stop je er mee. Voor Server/workstation CPU's kunnen ze het er mss iets langer inhouden.

Naar mijn idee is dit een beetje een soort kip en ei verhaal. De CPU bakkers willen niet veranderen waardoor ontwikkelaars ook geen noodzaak zien om te veranderen.

[RJG-223]

Naar mijn idee is dit een beetje een soort kip en ei verhaal. De CPU bakkers willen niet veranderen waardoor ontwikkelaars ook geen noodzaak zien om te veranderen.

De enige ontwikkelaars die hier iets van merken, zijn de OS-ontwikkelaars. En die maakt het waarschijnlijk niet veel uit, omdat ze voorlopig de oude CPUs ook nog moeten ondersteunen. En als iemand dit juist wel wil, zijn het de CPU-bakkers. Het maakt hun leven makkelijker. Het zijn vaker de klanten die terughoudend zijn, want dan werkt hun software misschien niet meer goed.

Jij haalt waarschijnlijk twee dingen door de war: het afschaffen van 32-bit applicaties, en het verwijderen van ondersteuning voor 32-bit OSen. Dit gaat om het laatste. 32-bit applicaties blijven gewoon ondersteund, en ontwikkelaars zullen dus ook gewoon 32-bit applicaties blijven maken en uitbrengen.

En vergis je niet: als Intel ineens ondersteuning voor 32-bit applicaties zou afschaffen, dan zouden heel veel bedrijven met 32-bit software ineens AMD gaan kopen. Dus dat doet Intel niet.

[BCC]

Dat doen ze nu al 20 jaar en daar willen ze van af

[lanarhoades]

Ze kunnen toch gewoon een 2-tier product lijn uitbrengen. Consumenten lijn en high end is dan 64bit only. High end users gebruiken toch al een 64bit OS, en meeste consument gebruiken de OS die word meegeleverd bij hun computer. En dan mid-tier enterprise modellen met 32bit architectuur, voor de servers die stok oude software op een oude OS draait.

[mcyh]

Of de komende jaren afbouwend;
Binnenkort geen 32bit os (kernel instructies) en later niet alle cores 32bit (user) instructiesset laten ondersteunen; enkel 2 of 4 cores pakweg.

Gaat misschien wat rare effecten geven als het os daar nog niet goed
op afgestemd is…

[i-chat]

Maar voor de bredere pc-wereld is waanzinnig veel moeilijker.

Volgens mij is dat ook gewoon onzin

als AMD en intel het samen op een akkoordje gooien en dat 2jr vooruit plannen dan zijn alle ossen bijgewerkt die 2 hebben samen immers 99,999 marktaandeel

Of gaat er dan echt iemand schreeuwen over kartelvorming

[JeroenED]

Plus dat apple een "hardere" leverancier is. Als microsoft 64-bit only zonder compatibilteit met 32-bit apps of ARM zonder x86 compatibiliteit wilde gaan hadden ze het wel degelijk kunnen doen. Er ging wat gemor zijn, hier en daar een PC die bij een of andere organisatie op Windows 98 bleef draaien, maar dat ging het ook wel zijn. Het merendeel van de mensen ging gewoon naar andere methodes zoeken om hun software te behouden dan wel vernieuwen.

Natuurlijk speelt er wel mee dat windows een veel grotere markt is dan apple en dat 10% verlies van de markt (wat ook een ding is) niet te lichtzinnig moet over gedaan worden.

[smartsys]

De x86 markt buiten Apple om heeft te maken met een paar duizend fabrikanten van hardware en honderd duizenden ontwikkelaars van software.
Deze hele keten meekrijgen is nagenoeg onmogelijk in een periode van een paar jaar. Intel heeft het met IA64 geprobeert, dit is mislukt. De door AMD bedachte uitbreiding op x84, x86-64 had nadelen t.o.v. IA64, maar het grootste voordeel was nagenoeg volledige compatibiliteit met het oude en vertrouwde.
I.p.v. een big bang alles in 1x overgang kon het nu geleidelijk aan en dat wil met nu nogmaals gaan doen.

Het Apple platform is veel kleiner waardoor het meekrijgen van de hele keten aanzienlijk makkelijker is.
Daarnaast was het voor de keten van Apple leveranciers ook financieel interessant om mee te gaan naar het "standaard" x86-64 hardware platform. Veel leveranciers hoefden geen custom hardware meer te ontwikkelen. Alleen de firmware en drivers moesten speciaal ontwikkeld worden. Met een prefered supplier handtekening op zak en een nagenoeg zekere afzet was het risico ook niet super groot en hebben er allemaal goed aan verdiend.

[sympa]

Je zou de hele rambam lager dan 64 bits kunnen emuleren.
Dan start je computer desnoods een 64 bits emulatiekern die dan het legacy BIOS weer draait.

[Z80]

Ios is een unix vork. Dit maakt het makkelijker om op een andere cpu architectuur te draaien.
En zowel het OS als de hardware komen volledig uit eigen huis. Alle ins en outs zijn bekend.
Windows zit aan de Intel/amd instructieset vast. Met tig verschillende fabrikanten van hardware.

[Aaargh!]

Het NT kernel is ook ontworpen om op meerdere CPU architecturen te kunnen draaien. Er zijn o.a. versies geweest van Windows NT voor DEC Alpha, PowerPC en MIPS.

[Z80]

Maar daar is lang geleden afscheid van genomen door Microsoft.
Er is nog wel een poging gewaagt om op een ARM cpu te draaien maar dat is niet echt een succes geworden.

[Dutch2007]

Windows 10 (en 11) on ARM, bestaan anders gewoon.

De Microsoft de kit (de fysieke), is een arm64

[Hobbit13]

Wat marktaandeel betreft misschien niet, maar Windows 10/11 op ARM werkt technisch prima. Bv de Surface Pro X is een prima bruikbare hybrid Tablet/PC. Ook veel gebruikte apps zoals Photoshop en Office draaien native op ARM. En de rest werkt prima via emulatie.

Voor zover ik begrijp zou de huidige Windows 10/11 64bit versies ook zonder enig problemen draaien op de nieuwe processors die alleen 64bit ondersteunen. 32bit applicaties worden sowieso al tot op zekere hoogte geëmuleerd via Windows-on-Windows.

[Aaargh!]

Die specieke versies worden niet meer verkocht, maar dat betekend niet dat de architectuur van NT niet gewoon CPU architectuur agnostisch is.

[xavalon]

Ik draai zelfs een Windows 11 Pro op ARM op mijn MacBook M1 Pro. En we hebben het hier over een canary build die deze week weer is ge-update en volgend jaar pas uitkomt. Draait prima en zelfs Office365 - ARM versie draait er vlekkeloos op.

[sympa]

Het oude Mac OS was geen unix. De hele 68030 werd geemuleerd voor applicaties.
Het OS was deels native PowerPC.
Daarna werd PowerPC x86, en daarna Arm.

[GhostShinigami]

Daarbij moet je niet vergeten dat Apple hardware en software zelf in de hand heeft, een maar een zeer minimaal aantal producten heeft.. op de PC markt is dat wel even iets anders. Van prebuilds, tot handhelds, en alles er tussen in, op minimaal 2 (compleet) verschillende OSen (windows/linux (ja dan good ik bsd daar even voor het gemak bij in), en een groter ecosysteem aan applicaties, die allemaal helemaal 100% om moeten.. (en ook nog op 'legacy' dingen moeten blijven werken...) al met al, heel gecompliceerd buiten het hele technische verhaal, en dan heb ik het nog geen eens over de server markt, waar nog veel ergere lagacy meuk draaid dat ze nu al niet naar een soort gelijk iets willen upgraden, laat staan in eens de hele applicatie moeten upgraden naar een 64 bit only, geen enkel spoor van 32 bit.. yeah dat gebeurd niet zo snel. Dus dat is niet te vergelijken met apple.

[moredruid]

Ik snap dat het niet met Apple te vergelijken is, maar je kan het softwareleveranciers wel degelijk kwalijk nemen als ze in de bijna 25 jaar dat x86-64 bestaat (release in 1999) nog steeds niet 100% 64-bit compatibel zijn.

[dmantione]

Je kunt het ze kwalijk nemen, maar tegelijkertijd is het de realiteit van de wereld waarin je leeft. Een bedrijf wat een eigen automatiseringssysteem heeft ontwikkeld waar miljoenen in geïnvesteerd zijn, kan het niet altijd verantwoorden om zoiets snel te moderniseren. Of kijk naar de Belastingdienst die met softwaresystemen uit de jaren '80 werkt.

De oplossing met dit soort dingen is nooit "zoek het maar uit", dan mislukt een moderniseringspoging en blijft de markt de spulletjes kopen die wel compatibel zijn. Je moet altijd oplossingen kunnen bieden aan degenen die oude software gebruiken, zodat iedereen in zijn eigen tempo kan moderniseren.

Die oplossingen zijn in dit geval overigens voldoende voorhanden.

[Guru Evi]

Niemand forceert leveranciers om een nieuw systeem te bouwen, Apple doet dit wel. Je kunt oa. Adobe CS4 al lang niet op macOS draaien, maar Windows kan dit nog steeds.

Daarin zitten dan ook tig beveiligingsproblemen, maar Microsoft kiest compatibiliteit over veiligheid (zie je oa. in de ondersteuning van OLE objecten, SSL/TLS en SMB versie die nog steeds standaard aanstaan in Windows 11 alhoewel ze in Windows XP al achterhaald waren) en voor 99% van de markt kun je al die beveiligingsbits weer aansteken maar er is altijd ergens een pakket (vb. Java 6) die niet goed werkt en dus vindt Microsoft dat ze liever een onveilig product leveren die werkt met Java 6 dan een veilig product voor 99% van de klanten. Apple, Linux etc zit aan de andere kant van het spectrum.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 19:44]

[devilkin]

Belangrijkste verschil: 1 vendor van zowel hardware als OS. Dus ze konden perfect inspelen op hun hardware releases om het mogelijk te maken. Ze kenden hun platform van binnen en van buiten.

Microsoft heeft ook een goede translatie laag voor ARM64 <-> x84_64, gebruikt in hun ARM64 versie van Windows.

Maar op x86 draait zoveel meer... (industriele toepassingen, stokoude boekhoudpakketten, ...), in vergelijking zijn de Apple transities 2x niks - veel minder waar men mee moest rekening houden.

[Reactie gewijzigd door devilkin op 23 juli 2024 19:44]

[Dutch2007]

Mits het 32bits applicaties zijn, blijft het gewoon werken.

En bij een 32bit win11, server 2016, 2019 en 2022 bestaan ook niet...

[beerse]

Het probleem was in 2000 helemaal niet zo groot. Microsoft heeft voor zover ik weet een aantal versies van msWindows ook voor itanium uitgebracht.

Voor zover ik heb onthouden kon je op itanium architectuur toen msWindows, HP-UX, OpenVMS en Linux draaien en misschien nog wel meer systemen. Helaas was de markt en vooral de applicatie wereld daar toen nog niet rijp voor.

Terug kijkend zie ik dat msOffice misschien wel de grootste show-stopper was. Voor zover ik weet was msOffice2016 onder msWindows in de meeste gevallen nog 32 bits.

[zonoskar]

Bij elke schakeling zijn er wel een hoop machines afgevallen die dat ondersteunen. Als Intel dat doet worden ineens miljoenen PCs niet meer compatible met de nieuwe OSen. Voor Apple was dat schijnbaar niet zo'n probleem, of de Apple gebruikers zijn kapitaal-krachtig genoeg om nieuwe machines te kopen. Maar voor Intel zou dat ws een groter probleem vormen.

[4tro]

En Linux support allerlei architecturen tegelijkertijd en zonder gebruik van emulators.

Vergis je niet, ook op MacOS trekt de emulatie van x86 door rosetta zijn wissel op applicaties.

Maar ja, dat hangt dus af van welke applicaties je draait.

Probeer bijvoorbeeld eens docker desktop met een x86_64 container te draaien, dat gaat echt heel traag kan ik je vertellen.

[kdekker]

En ik denk dat er op Apple een veel kleinere verscheidenheid aan software beschikbaar/in gebruik is. En een aardig deel al gelijk door Apple meegeleverd wordt? Hoe meer gebruikers, hoe meer software paketten, hoe lastiger een overstap. Dus als een Apple alleen voor kantoorsoftare + beeldverwerking gebruikt wordt, dan is het verhaal alleen daarom al eenvoudiger.

En Apple had volgens mij in alle gevallen een soort van emulator/compatibility modus. Volgens mij duurde het wel een behoorlijke tijd voordat de Adobe suite native naar Apple M-chips geport waren.

De variant ervoor, Apple op Intel, lag toch aardig dicht bij Linux (was nu ook zo is, zei het een compleet andere chip architectuur). En vermoedelijk hield Apple zich meer aan standaarden (POSIX, SYSV) dan Windows. Microsoft had heel lang (nu een stuk minder) broertje dood aan conformeren aan standaarden. Dat maakt porten en compatibiliteit ook lastiger, vermoed ik.

Windows heeft in ieder geval veel langer en veel meer software in het veld staan en sleept daarom al een grote bak legacy/compatibilteit meer. Meer dan Apple. Waar zeker het Intel verhaal relatief kort geduurd heeft.

[TMT]

het is geen nieuwe architectuur deze keer, alleen het uitslopen van de "oude brol die niemand meer gebruikt".
Dat het een gigantisch werk is, is wel duidelijk voor iedereen.
Regressie testing

[HashIT]

"oude brol die niemand meer gebruikt" is niet helemaal correct. Een deel van die oude zooi wordt door iedereen gebruikt, omdat het onvermijdelijk is (bijvoorbeeld opstarten in 16 bit mode). "oude brol waar niemand meer behoefte aan heeft" komt denk ik wel redelijk in de buurt.

[Fiander]

En dat opstarten in 16 dit mode is nou net één van de dingen die ze willen schrappen.
16 bit real mode,
32 bit real mode,
32 bit protected mode.
de CPU laten starten op adres FFFF:0000

Wanneer dat allemaal geschrapt wordt, hoeft alleen de bios maar aangepast te worden, en bij elk OS de boot stappen.

in de bios kan dan gewoon op adres 0000:0000 begonnen worden, ipv op FFFF:0000 een jmp naar een ander adres. Dit zorgt dus voor minder fragmentie in het geheugen.
Het boot proces van een OS hoeft dan niet meer via 16 bit mode naar 32 bit mode naar 32 bit protected naar 64 bit mode te stappen. Daar start de cpu reeds in.

Met dit voorstel worden GEEN instructies geschrapt, alleen de hardware die nu in cpu's zit ivm deze cpu modi kan weg. Dat maakt ze simpeler en kleiner.

[Vampyre]

Als je op 0000:0000 (segmented) wil beginnen zit je nog steeds in realmode.
Daarnaast, 0000:0000 is de interrupt table, geen code.
Daarnaast start een 386+ niet op ffff:0000 maar op 0xffffffff0 (top van 4gb. niet top van 1mb). ffff:0000 is 8086.
Daarnaast kan je nauwelijks dingen schrappen, hoogstens de ringstructuur.
Long mode borduurt erg diep verder op wat in 32bit p-mode ook al zit.

En btw, 16 bit p-mode entries werken ook in long mode, gaan ze die ook dan schrappen?
Waarom zou dat allemaal weg moeten, zoveel extra transistors kan het niet zijn als een 386 het ook kan...

[Hobbit13]

Waarom zou dat allemaal weg moeten, zoveel extra transistors kan het niet zijn als een 386 het ook kan...

Code die niemand meer gebruikt eruit halen is eigenlijk altijd een goed idee, minder code om rekening mee te houden bij het testen, kortere API (documentatie) etc.

Als je 16bit ondersteuning hebt, zal je het ook bij elke update weer volledig moeten doortesten, dat kost tijd en (dus) geld.

[freaq]

Plus de keuze is pange termijn wss
Of dit, wat heelveel vende opruimt wat kan zorgen dat x86 efficienter wordt zowel qua perf /die space
Maar ook perf/watt gezien dingen dichter bij elkaar zitten (niet dat de logica groot is, maar je moet ook alle traces hebben etc)

Of we gaan naar een architectuur die dit al wel heeft gedaan, zoals arm of riscV

Arm gaat al heel hard en apple heeft laten zijn dat arm kan concurreren met x86 microsoft en qualcomm staan klaar om windows op arm serieus te proberen.

Dus moeten intel en amd vooral idle power voor laptops en servers aan kunnen pakken.

En daarvoor is grote schoonmaak nodig,

Mogelijk dat arm alsnog gaat winnen door de architectuur die makkelijker bredere pipelines toestaat, maar dit is iig uitstel van executie.

En riscV is ook interessant maar dat is wat verder weg nog.

[dmantione]

En btw, 16 bit p-mode entries werken ook in long mode, gaan ze die ook dan schrappen?

Voor zover ik weet niet, het is niet mogelijk om in long mode (64-bit besturingssysteem) nog 16-bit segmenten in usermode te gebruiken.

[Vampyre]

v86 niet, voor zover ik weet 16bit zelf wel.

[RJG-223]

Gelukkig. Iemand die het begrijpt. Of iemand die kan lezen :-)

Overigens klopt dit waarschijnlijk niet helemaal:

Met dit voorstel worden GEEN instructies geschrapt, alleen de hardware die nu in cpu's zit ivm deze cpu modi kan weg. Dat maakt ze simpeler en kleiner.

Er zullen (vermoedelijk) wel degelijk een heleboel instructies geschrapt worden: die instructies die alleen nodig zijn voor OSen in 32-bit en 16-bit mode. Ik denk zelfs dat sommige instructies die sommige 32-bit applicaties nog zouden kunnen gebruiken ook kunnen verdwijnen, als ze even makkelijk geëmuleerd kunnen worden.

[Tomatoman]

Dit is tevens waar de grootste winst geboekt kan worden, omdat de inmiddels extreem uitgebreide instructieset van moeders processoren flink kan worden uitgekleed. Dit vereenvoudigt de architectuur van processoren, omdat allerlei trucs om legacy instructies uit te voeren dan achterwege kunnen blijven. Het maakt processoren aanzienlijk minder complex. Dat scheelt niet zozeer in de fysieke omvang van CPU’s, maar het vermindert vooral in de ontwikkelinspanning die nu nog moet worden gestoken in het behoud van compatibiliteit met stokoude x86-processoren. Die inspanning is nu onevenredig groot ten opzichte van de functionaliteit die ermee in stand wordt gehouden.

[RJG-223]

Dit is tevens waar de grootste winst geboekt kan worden, omdat de inmiddels extreem uitgebreide instructieset van moeders processoren flink kan worden uitgekleed

Dat zou het geval zijn als veel 16 bit en 32 bit instructies verwijderd konden worden. Maar dat kan niet, want die worden nog steeds door bestaande, en nieuwe, applicaties gebruikt. Ook 64 bit applicaties ! Vergeet niet dat bestaande applicaties gewoon blijven werken. Ook 32-bit applicaties.

De enige instructies die verwijderd kunnen worden, zijn de instructies die enkel door firmware en OSen gebruikt worden. Dat zijn heel specifieke instructies bijvoorbeeld om privilege-niveaus aan te passen (die worden verminderd), of vermoedelijk instructies om call gates te gebruiken (ik neem aan dat die ook verdwijnen), of misschien wat instructies voor bepaalde manipulaties van segment registers, en zo voort. Dat is niet flink uitkleden, dat is hier en daar wat wegsnijden.

[Fiander]

Ik doelde ook op instructies voor applicaties.
Natuurlijk word er geschrapt in de instructies die nodig zijn om van mode te wisselen.

maar ook alle interne controles tbv PAE en andere geheugen dingetjes zullen niet meer nodig zijn.
Tis alleen wel meer dan 15 jaar terug dat ik vloeiend asm sprak.

[--Andre--]

32 bit real mode? Bedoel je de unreal mode? (Een hack om in real mode >1MB geheugen te addresseren)
Je kan niet van 16 bit real mode naar unreal mode schakelen.
Om in unreal mode te komen, ga je van 16 bit real naar 32 bit protected en weer terug naar real mode.

Verder is er nog een 16 bit protected mode.

[Fiander]

Heej, het is voor mij ook meer dan 25 jaar terug dat ik daarin programmeerde :-) dus ja, ik kan er iets naast zitten qua namen.

denk eerder dat ik flat mode bedoel trouwens. maar dat erzijde.

de essentie van het stuk/artikel is dat AL deze mode verdwijnen, en dat de CPU er straks nog maar één heeft. En dat is goed.

[Het.Draakje]

Dan laat je die oude zooi op een oude processor lopen. De fabriek gooit er eens in de x aantal jaren een lichting oude meuk-processoren uit (of je laat daarvoor één specifieke fab draaien), zodat je desnoods weer een nieuwe server/pc kan maken. Net zoals nu bijvoorbeeld voor de chips in de wasmachine of auto gebeurd.

Verdere ontwikkeling gewoon stoppen. Nieuwe software / hardware op de nieuwste processor.

Eén OS, één chip-architectuur to rule them all. Nergens voor nodig toch?

[Wolfos]

Dat is nergens voor nodig. Zelfs als dit eenmaal geïmplementeerd is zal het mogelijk blijven om 32-bit besturingssystemen te virtualizeren.

[Het.Draakje]

Ik (denk te) reageren op GhostShinigami, met name op:

(waar nog veel ergere lagacy meuk draaid dat ze nu al niet naar een soort gelijk iets willen upgraden, laat staan in eens de hele applicatie moeten upgraden naar een 64 bit only, geen enkel spoor van 32 bit.. yeah dat gebeurd niet zo snel.)

En dan is mijn reactie: so what, dan laat je legacy op legacy draaien. Hou een legacy CPU beschikbaar, probleem solved. En als het voor de legacy geen donder uitmaakt, dan maakt het niets uit dat ze de applicatie niet willen upgraden.

Linksom of rechtsom, problem solved.

[GeroldM]

Zo rond het jaar 2000 werkte ik bij een bedrijf dat 1 van hun orderpik-magazijnen op een constante temperatuur van -23 graden Celcius hield. De apparatuur die in en uit die ruimte bewoog hadden daar mechanisch al genoeg moeite mee. Maar de electronica voor de pelletrucks die deze ruimte bevoorraden en de apparaten waarmee de orderpikkers een bestelling samenstelden die kon daar heel slecht tegen. Hoe moderner het spul, des te zwakker. Dat bedrijf was toendertijd altijd op zoek naar oude 286 systemen. Snel genoeg voor de Linux versie die ze moesten draaien en deze CPUs konden probleemloos worden gebruikt in zeer wisselende temperaturen en de condensatie die daarbij hoort.

Zelfs in die dagen was het al moeilijk om nog 286 computers aan te komen. Nieuw niet, 2e hands via particulieren ook amper, Het meeste geluk had men daar als een ouder bedrijf failliet ging en hun oude computer-inventaris werd geveild.

Dan kun je wel stellen 'Linksom of rechtsom, problem solved', maar daar geven natuurwetten geen bal om. Normaal gesproken ben ik ook een aanhanger van het 'linksom of rechtsom'-mantra, maar natuurwetten, daar ontkom je niet aan en deze kunnen je aan zeer strikte limieten onderwerpen.

[Vampyre]

Leuk verhaal, maar Linux heeft nooit gedraaid op een 286.

[Het.Draakje]

Zoals ik zeg: linksom (het maakt niets uit) of rechtsom (hou een fabriek voor de oude meuk in bedrijf) geen probleem. En in beide gevallen kun je doorgaan met de ontwikkeling van nieuwe processoren zonder 32 bit onderdelen. Want dan heb je gewoon twee cpu's in de handel: de oude meuk en de nieuwe.

Ik zie niet in waarom alles maar op de nieuwste processor moet kunnen draaien.

Uiteraard is het een probleem indien een noodzakelijke processor niet verkrijgbaar is (vandaar de fabriek voor oude meuk). En ja, als die fabriek er niet komt omdat er geen droog brood mee te verdienen is, dan heb je een probleem. Dan moet je toch upgraden en/of een alternatief gebruiken.

[TMT]

Tja maar zulke archtectuur zal wel nieuwe chipsets en moederborden met zich meebrengen. Geen probleem denk ik dan om alles 64bit te maken.
trouwens 64bit UEFI bestaat ook nu al.
BIOS was 16bit maar denk niet dat er nog veel moederborden uitkomen met BIOS tegenwoordig.

[Chatslet]

Itanium is geflopt omdat het een Intel only dingetje was. x86 met een amd64 instructieset er op geplakt was destijds niet zo handig maar je kunt je ook afvragen of het wel zo’n goed idee is om daar nu x86 van af te knippen. Je lost daarmee maar een klein deel van het probleem want zoals AMD hier al aangeeft zijn er wel meer problemen. Kijken we naar Apple dan is die er helemaal vanaf gestapt en werken die nu met ARM processoren die qua performance per watt ver boven AMD en Intel processoren uitsteken. Als Intel en AMD de handen ineen slaan en bijvoorbeeld op ARM overstappen of zelf een RISC architectuur ontwikkelen en daarbij ook aankondigen te stoppen met x86 dan kunnen ze een transitie forceren die voor iedereen beter is. Minder energieverbruik, vlotte prestaties, geen zooi meer naar een GPU te hoeven offloaden etc… ik denk dat Microsoft en de mensen achter Linux daar ook wel oor naar hebben.

[fkruis]

Het was geen intel only. Het was een gezamenlijke ontwikkeling van HP en intel.

[Chatslet]

Dat is zo maar HP is geen processorfabrikant en ik hoef je natuurlijk niet uit te leggen dat de kans nihil is dat andere fabrikanten zoals AMD die dingen kunnen gaan maken en voor een concurrerende prijs verkopen.

[itcouldbeanyone]

Dat was in die tijd toch echt anders.
Hp had pa-risc later zijn die machines vervangen voor itanium .

[beerse]

HP heeft wel degelijk diverse eigen cpu-s in productie gehad. De hp pa-risc cpu was er eind vorige eeuw in 32 en in 64 bits versie. Het is dat ze bij de ontwikkeling van een nieuwe cpu gingen samenwerken met Intel. Uiteindelijk werd Intel de cpu producent en ging HP zich meer op andere zaken richten.

[batjes]

Alleen was er maar 1 partij die de chips mocht bakken.
Intels move naar Itanium was voor Intel een groot deel gewoon om van die gedeelde X86 licenties af te komen.

[laurxp]

Itanium is geflopt omdat de instructieset te complex was. Het was een heel briljant idee, waarbij het idee was dat de gebruiker expliciet al kon meegeven welke instructies parallel uitgevoerd konden worden. Hierdoor kreeg je een soort mega-instructies. In de praktijk bleek dat dit zó complex was, dat het praktisch onmogelijk was om compilers te schrijven die hier daadwerkelijk gebruik van kunnen maken.

[HollowGamer]

Wow, wat een goed idee! Hoe ben je op de naam gekomen?

Maar serieus, het is ook wel jammer dat het niet is gelukt met IA64. Het was mooi geweest, want net als de ATX-standaard, is deze niet doorgegroeid bijvoorbeeld. We zitten altijd nog met dikke kabels en onnodige features (zoals die stomme manier van aansluiten pinnen).

De X86 architectuur heeft zijn voordelen, maar waarom inderdaad niet kijken naar iets nieuws?
64-only werkt toch niet op huidige moederborden (gok ik), tenzij ze het via de BIOS-firmware kunnen oplossen.

[Pieter_621]

De X86 architectuur heeft zijn voordelen, maar waarom inderdaad niet kijken naar iets nieuws?
64-only werkt toch niet op huidige moederborden (gok ik), tenzij ze het via de BIOS-firmware kunnen oplossen.

Ik denk dat je dit vooral moet zien als een optimalisatie van een bestaande architectuur: relatief veel winst voor weinig kosten en impact.

Een migratie naar een andere architectuur is veel duurder en lastiger uit te voeren. Apple heeft dit een paar keer gedaan. Maar die heeft volledige controle over hardware én software. Dat geldt niet voor PCs, en de risico's voor fabrikanten zijn daarom veel hoger. De investering voor een nieuwe CPU is best wel hoog, en als je overstap flopt, is dat een dure grap geweest...

[laurxp]

Nee, Itanium is een compléét ander beestje.

Intel probeerde een innovatieve instructieset uit te brengen, die niets gemeen had met het bestaande x86. Het idee was om extreem lange instructies te gebruiken (VLIW), waarin expliciet werd aangegeven wat er parallel uitgevoerd kon worden. Dit zou de CPU een heel stuk eenvoudiger en sneller maken. In de praktijk bleek het praktisch onmogelijk om compilers te schrijven die hier gebruik van maken, dus bleef het steken bij een redelijk 1-op-1 vertaling van x86 - wat vervolgens een heel stuk langzamer was. Zeer baanbrekende hardware dus, maar zinloos omdat er geen software voor was.

Deze nieuwe x86-S architectuur is daartegenin slechts een kleine aanpassing van x86, waarbij een legacygedeelte wegvalt die praktisch niemand gebruikt. Oftewel, een versimpeling van het bestaande ontwerp, waar amper software-aanpassingen voor nodig zijn.

[GekkePrutser]

Praktisch onmogelijk vind ik niet helemaal correct. Het was wel mogelijk maar de markt had er gewoon geen interesse in om het te doen voor de desktopmarkt.

Voor servers is het wel een tijdje in gebruik geweest maar de ontwikkelkosten waren te hoog om het alleen daarvoor in te zetten, en daarom werd het door goedkope Linux servers ingehaald. Dat had niet zoveel met het specifieke IA64 platform te maken want hetzelfde is gebeurd met bijvoorbeeld Sun's SPARC en IBM's MIPS.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 19:44]

[laurxp]

Compilers schrijf je één keer, en je gebruikt dezelfde compiler voor de desktop- en servermarkt.

Een reguliere x86 CPU doet tijdens het draaien constant een analyse van de instructies, waarbij het kijkt welke instructies tegelijkertijd uitgevoerd kunnen worden omdat ze niet van elkaar afhankelijk zijn. Hierbij kan bijvoorbeeld een instructie een andere "inhalen" omdat die moet wachten op geheugentoegang, of kan een instructie speculatief uitgevoerd worden - waarbij het resultaat pas definitief wordt als blijkt dat deze instructie daadwerkelijk genomen moet worden. Het daadwerkelijke executie-model van de CPU is compleet anders dan de instructieset suggereert. Al deze hardware kost heel veel ruimte in de chip, vaak zelfs meer dan de daadwerkelijke reken-eenheden.

De gok van Intel was dat een groot deel van deze complexiteit weggelaten kon worden als de compiler expliciet van tevoren al deze analyse deed, en precies tegen de CPU zegt wat er parellel kan draaien. Het probleem is dat dit een compleet andere analyse vereist dan letterlijk alle andere instructiesets, en een groot deel van de analyse kan je niet doen omdat dingen zoals precieze executietijd en memory stalls pas tijdens het draaien bekend zijn. En omdat je het transistorbudget al gebruikt om heel "brede" instructies uit te kunnen voeren, kan de CPU zelf deze analyse niet meer doen! Ook al wíl je veel tijd en geld steken in het ontwikkelen van een compiler hiervoor, je blijft altijd beperkt worden door een tekort aan data.

De grap is dat VLIW wél een tijdje populair is geworden - maar voor GPUs. Bij GPU workloads is de benodigde analyse wel redelijk goed te maken, dus daar heb je veel minder last van de nadelen van een VLIW architectuur. Inmiddels zijn ook GPUs overgestapt op RISC-achtige architecturen, dus VLIW was slechts een tijdelijk uitstapje in een niche van de computerwereld.

[Reactie gewijzigd door laurxp op 23 juli 2024 19:44]

[rbr320]

Het verschil is wel dat er voor een 64-bit only x86 instructieset al een enorm software ecosysteem is. Iedere gebruiker en beheerder is er mee bekend, het is proven technology. 32-bits x86 applicaties die nog worden ondersteund vergen waarschijnlijk slechts een hercompilatie en misschien wat kleine aanpassingen om werkend te krijgen op 64-bit x86.

Niet dat ik nou zo'n enorm fan ben van de x86 architectuur en vind dat we niet zouden moeten kunnen veranderen als het alternatief aantoonbaar beter is, maar zo werkt de wereld nu eenmaal niet.

[RJG-223]

32-bits x86 applicaties die nog worden ondersteund vergen waarschijnlijk slechts een hercompilatie en misschien wat kleine aanpassingen om werkend te krijgen op 64-bit x86.

Jij hebt blijkbaar geen ervaring met software-ontwikkeling ? Behalve misschien in talen die onafhankelijk zijn van 32 bit of 64 bit ? Misschien dat jij alleen webpagina's maakt ? Want een 32-bit applicatie opnieuw compileren, en dan denken dat het ineens 64-bit is 'met wat kleine aanpassingen' is een utopie. Misschien dat dat zo is voor sommige kleine eenvoudige applicaties. Elke serieuze, grotere applicatie, kun je niet eenvoudig hercompileren op 64 bit. Integendeel: het is een heleboel werk.

En, in het onwaarschijnlijke geval dat het wel kan, dan weet je dat nog niet zeker, en moet je na het compileren dus nog steeds zeer uitgebreid testen om zeker te zijn dat er geen nieuwe bugs zijn, en dat het nog steeds compatibel is met de 32-bits versie. Dus dan is het nog steeds een heleboel werk.

[.oisyn]

Wat een onzin. De meeste code is bitsize agnostic, en de compiler waarschuwt al heel lang bij potentieel problematische code, zoals een cast van pointer naar 32-bits integer.

[GeroldM]

Ha!

Broncode (C++) gecompileerd voor 32-bit op de 32-bit compiler van Embarcadero. Resulterende applicatie loopt met vlag en wimpel door alle test-scenarios heen en kan worden uitgerold naar de klant. Dan begint de 64-bit compiler van Embarcadero aan zijn werk met dezelfde broncode. Resulterende applicatie komt niet door de test-batterij.

Alles gefixt voor de 64-bit compiler, wat een werkende applicatie oplevert, maar nu werkt de 32-bit versie weer niet goed. En zo blijf je wel bezig. Waarom 32-bit blijven compilen? Omdat dit bij Embarcadero flink wat sneller is. Bijna 3 keer zo snel als een compilatie voor 64-bit. En ook veel beter en uitgebreider terugkoppelt wat er mis gaat, wanneer er iets mis gaat.

Ook als je op een remote proces in moet kunnen haken voor een fout-analyse, die alleen in de produktie-omgeving optreed, dan werkt dat flink wat beter dan met 64-bit.

Het is dus leuk dat je met je Visual Studio relatief gemakkelijk 32-bit en 64-bit applicaties kan maken, En dat jouw belevingswereld daardoor gekleurd is. Maar Visual Studio is niet de enige software waarmee men applicaties kan bouwen. En er zijn meer dan genoeg code-basissen van bedrijven die voor alternatieve software hebben gekozen, omdat deze destijds een stuk verder was dan Visual Studio.

Het is dus helemaal geen onzin, zoals jij stelt.

[.oisyn]

Dank je voor je N=1 ervaring met een niche compiler . Mijn 20 jaar ervaring met de industrie standaard compilers, gcc, clang, en msvc, is idd anders.

[RJG-223]

Dank je voor je N=1 ervaring met een niche compiler . Mijn 20 jaar ervaring met de industrie standaard compilers, gcc, clang, en msvc, is idd anders.

Ook leuk dat jij jouw N=1 ervaring deelt. Misschien meerdere applicaties, maar nog steeds één persoon. En gedurende die hele 20 jaar waar jij het over hebt, hebben er 64-bit processoren bestaan (x86_64 dateert bijvoorbeeld van 1999, en was lang niet de eerste 64-bit processor...).

Hierbij nog een link (met op die pagina nog meer links) om jezelf eens in te lezen over dit onderwerp. Zie ook de links in de post van mij hierboven.

https://pvs-studio.com/en/blog/posts/cpp/a0010/

En ongetwijfeld kun je ook in verschillende open source bug databases nazoeken welke problemen er in het verleden allemaal geweest zijn in applicaties (niet het OS) toen 64-bit algemeen werd.

[.oisyn]

Maar is dat niet het hele probleem? Ik kijk vooral naar de status van nu, niet naar die van 15 jaar geleden. Een blog uit 2007 aanhalen heeft dan ook weinig nut. We zijn inmiddels wat wijzer en de compilers zijn beter in het vinden van potentiële fouten.

[Hobbit13]

Los van hele specifieke software zoals hardware drivers, herken ik jouw verhaal eigenlijk niet echt. Welke problemen kom je tegen als je een C++ programma dat voor 32bit geschreven is, door de 64bit compiler haalt?

Voor de C++ code waar ik aan gewerkt heb, was dat niet veel meer dan expliciet de 32bit of 64bit driver DLLs inladen.

[dmantione]

Over het algemeen moet C-/C++-code wel nagelopen worden voor compatibiliteit met 64-bit. Naïeve programmeurs willen nog wel eens de aanname doen dat een pointer en een int dezelfde grootte hebben, wat in de 64-mode niet het geval is.

Afhankelijk van hoe secuur de programmeurs geweest zijn, kan het een futiliteit zijn of een helehoop werk.

[RJG-223]

Vaak zitten er in een programma allerlei aannames over hoe groot een integer is, of een pointer, etc. Of het formaat van data-files is afhankelijk daarvan. Dat kan gebeuren omdat programmeurs iets snel moesten oplossen, en een keuze hebben gemaakt, of omdat de applicatie geoptimaliseerd werd, of omdat het nooit nodig was over 64 bit na te denken. Ook kunnen de APIs 32-bit afhankelijkheden hebben. Misschien dat de applicatie ook meer geheugen gaat gebruiken. Ook kan het zijn dat bestaande bugs niet optreden met 32 bit, maar met 64 bit ineens wel. Etc. etc.

Als al jouw 32-bits applicaties zondermeer op 64-bit werken, heb je mazzel. Misschien zijn jouw applicaties ook relatief klein, simpel, of zijn ze niet zo oud. Als je er in het algemeen vanuit gaat dat je een grote applicatie, die al langer bestaat, in korte tijd op 64 bit werkend kunt krijgen, dan moet je je voorbereiden op een teleurstelling. Of klagende klanten :-)

Bijvoorbeeld:
https://hownot2code.wordp...e-to-the-64-bit-platform/
https://smartbear.com/blo...elopers-migrating-32-bit/

[.oisyn]

32-bits x86 applicaties die nog worden ondersteund vergen waarschijnlijk slechts een hercompilatie en misschien wat kleine aanpassingen om werkend te krijgen op 64-bit x86.

Helemaal niet. Het voorstel gaat erover om de legacy meuk uit de cpu te halen. Dat is dus de 16-bit real mode boot, de oude 32-bits protected mode omgeving en de virtual x86 mode die daarin zat.

Het gaat expliciet niet over de 64-bits long mode en de 32-bits mode die daar vanuit beschikbaar is. Oude 32-bits apps die nu onder een 64-bits OS kunnen draaien blijven gewoon werken.

[rbr320]

Helemaal mooi, nog minder pijn dus, vandaar dat het de voorkeur heeft boven overstappen naar een geheel nieuwe architectuur.

[dmantione]

Het verschil met IA64 is dat destijds iedereen en alle software 32-bits x64 was en dus slecht zou draaien op een IA64, die overigens wel een beperkte x86-compatibiliteit had. Dat was niet te verkopen.

De situatie is nu dat vrijwel niemand nog een 32-bits besturingssysteem draait en daardoor de overgrote meerderheid niets van de wijziging zou merken.

[Reactie gewijzigd door dmantione op 23 juli 2024 19:44]

[P5ycho]

IA-64 is wel degelijk een heel ander beestje dan x86-64. Het heeft amper iets met elkaar te maken zelfs.

Waar een x86-64 cpu zelf bepaalt in welke volgorde instructies worden uitgevoerd, wordt dat in IA-64 volledig door de compiler bepaald. (Dat is wel heel kort door de bocht trouwens)
In de praktijk betekent dit dat de IA-64 CPU zich helemaal niet druk hoeft te maken over het in juiste volgorde afhandelen van instructies, branch prediction etc. Dit wordt allemaal in de compiler al bepaald. Dat maakt dat een groot complex deel van de CPU compleet vervalt en verplaatst naar de compiler stage.
Het is lastig bepalen of het beter was geweest als IA-64 het wel had gered, maar delen van de architectuur zijn zeker wel aantrekkelijk.

Het is alleen heel lastig om een 'clean break' te maken met zoiets. Ook de reden waarom we nog steeds aankloten met IPv4 en IPv6, waarom ARM64 maar niet van de grond komt voor consumer PCs, etc etc.

[BlaDeKke]

Geweldig

[rob12424]

Er is toch ook al een instructies en met 128 ?

[Wolfos]

Je hebt het niet begrepen; Er word hier geen nieuwe architectuur voorgesteld, maar een aanpassing. Wat weggehaald word is de ondersteuning voor 16 en 32 bit besturingssystemen. Die gebruikt immers niemand meer, Windows word niet meer geleverd in 32 bit en al héél lang niet meer in 16 bit. Heb je die nog wel nodig is een virtual machine nog altijd een optie.

De 16 en 32 bit instructies op de CPU worden namelijk alleen nog maar tijdens het booten gebruikt. De CPU start op in 16 bit mode, schakelt vervolgens naar 32 bit om daarna een 64-bits OS te booten en die insructies nooit meer gebruikt. De instructies van 32-bit applicaties worden namelijk vertaalt.

[Reactie gewijzigd door Wolfos op 23 juli 2024 19:44]

[CAPSLOCK2000]

Je hebt het niet begrepen; Er word hier geen nieuwe architectuur voorgesteld, maar een aanpassing. Wat weggehaald word is de ondersteuning voor 16 en 32 bit besturingssystemen. Die gebruikt immers niemand meer, Windows word niet meer geleverd in 32 bit en al héél lang niet meer in 16 bit. Heb je die nog wel nodig is een virtual machine nog altijd een optie.

Je hebt gelijk, dit is een hele kleine stap, lang niet zo ambitieus als ia64. Ik wil wel nog toevoegen dat IA64 ook virtualisatie/hardware-emulatie gebruikte voor backwardscompatibility. De performance was schijnbaar niet zo geweldig maar ook toen was het idee dat je oude binaries onaangepast zouden blijven werken zodat eindgebruikers er niks van zouden merken.

[dmantione]

Met de nadruk op "zouden", want de x86-compatibiliteit van de Itanium was niet erg goed en de klant stond dus voor de keus om een hele dure processor te kopen waarop de applicaties trager liepen dan op de oude processor.

Bovendien was het besturingssysteem een issue: Er werd weliswaar gewerkt aan Windows NT en HP-Unix, maar in die tijd Windows 9x de norm, OS/2 nog niet helemaal uitgestorven en er was Linux dat op de groeiende markt voor webservers gestaag een marktaandeel begon op te bouwen. Dat kon je allemaal niet installeren op een Itanium.

[GekkePrutser]

Linux heeft prima op Itanium gewerkt hoor. En draait er nog steeds op. De meeste distro's hebben de support nu laten vallen maar dat is meer omdat geen hond er behoefte aan heeft omdat de servers die er zijn allemaal oud zijn (met name HP-UX hardware).

[dmantione]

De SuSE of Redhat DVD die je in de winkel kocht om je webserver te installeren (zo ging het in de vroege wild-west jaren van het internet) werkte niet op een Itanium-server, dus ging je een x86-server kopen. Linux is overal naar geporteerd, dus ook Itanium, maar je behoort dan tot een kleine gebruikersgroep.

Wat overigens wél enige tijd populair is geweest, was de DEC Alpha, de voorganger van Itanium. Moederborden daarvan werden los in de winkel verkocht, dus je zag ze veel meer in het doe-het-zelf-circuit en Linuxdistributies op CD ervoor waren goed verkrijgbaar. Ik heb zelf een tijdje een Alpha gehad met SuSE Linux erop. Niet zozeer voor een webservertje, maar als je wat meer FPU-rekenkracht nodig had, was het een leuke optie.

[GekkePrutser]

Euh nee in de tijd dat IA64 uit kwam, kon je ook al gewoon ISO's downloaden hoor En als je 10k uit had gegegeven voor een Itanium server dan zou je die echt niet laten liggen omdat je winkel CD'tje er niet op werkte.

Het is gewoon altijd een lastig verhaal geweest qua prijs/kwaliteit. DEC Alpha was ook alleen voor servers bedoeld en pas tijdens de teneergaande trend pas voor hobbyisten ingezet. Toen was het te laat om het platform te redden.

[HandheldGaming]

IA64 is geen x86 en is dat nooit geweest.
De juiste naam voor deze variant is dan eerder AMD64. Aangezien dat de extensie is die x86 naar het 64 bits tijdperk heeft gebracht.

[psychicist]

Ik heb een beter idee, namelijk ARM64 en RISCV64 zonder ondersteuning voor 32-bit. Die hebben we dus al en laten AMD en Intel daar maar gebruik van maken of een eigen nieuwe instructieset verzinnen. En anders zal een alsmaar kleiner wordende markt ze wel dwingen om die kant op te gaan.

[killerdemon]

Los van de instructieset is Itanium dacht ik hetzelfde idee als x86-64 vs IA64 / SATA vs SAS

[ikweethetbeter]

Ein-de-lijk!
Dit hadden ze 15 jaar geleden moeten aankondigen en 10 jaar geleden moeten uitvoeren.

Omdat ze dat hebben verzuimd, heeft MS nog tonnen 32-bits software en OS-en uitgebracht, terwijl sinds 2006 alle CPU's al 64-bits zijn.

Maar goed, beter laat dan nooit...

[Edit: tikfouten]

[Reactie gewijzigd door ikweethetbeter op 23 juli 2024 19:44]

[Blokker_1999]

En welke nadelen heb jij ondervonden aan het niet verwijderen ervan? Welke nadelen heb jij ondervonden aan het compatibel blijven met oude producten? Welke nadelen ondervind jij omdat MS nog 32bit applicaties maakt naast de 64bit versie die je evengoed kan gebruiken?

Ik heb er niets op tegen dat ze het doen, maar ik zie helemaal niet waarom je er op moet reageren met een eindelijk, hadden ze eerder moeten doen. Want ik heb er helemaal geen last van. En zoals in het artikel ook staat gaat het hier enkel om wat het OS kan doen. 32bit applicaties op een 64bit OS blijven gewoon ondersteund in het plan van Intel.

[ikweethetbeter]

En welke nadelen heb jij ondervonden aan het niet verwijderen ervan? Welke nadelen heb jij ondervonden aan het compatibel blijven met oude producten?

Intel heeft schaarse tijd en middelen aangewend om 32-bits compatibel te blijven in plaats van:
* het verbeteren van de Core i architectuur;
* het optimaliseren van de 64-bits microcode;
* het ontwerpen van zuinige CPU's (ze zijn jaren op 10nm blijven hangen)
* ...

Deze keuzes hebben onder Apple doen besluiten om hun Macs op hun eigen ARM architectuur te laten draaien.

Daarbij ken je MS waarschijnlijk ook wel. Geef ze een keuze, en ze kiezen niet, ze doen alles. Zo hebben ze MS de kans gegeven om nog heel lang 32-bits software te kunnen maken, en dat hebben ze gedaan. Ook daar hebben ontwikkelaars eeuwen aan manuren weggegooid.

[SuperDre]

32bit software kan nog steeds dus op 64bits OSsen, dus 32bits ondersteuning in de CPU verwijderen heeft hier geen invloed op. En de gebruiker zap weinig tot niets merken of een applicatie nu in 32bit is of 64bit, alleen voor specifieke applicaties heeft het echt nut, en daarvan zijn de meeste inmiddels al wel overgezet naar 64bit.

[ikweethetbeter]

Bij Windows wel. Apple heeft de 32-bits banden jaren geleden al doorgesneden. Het kan dus wel.

[SuperDre]

Het kan wel, omdat Apple in kantooromgeving 'amper' gebruikt werd en dus niet veel 'oudere' software draaide die dagelijks gebruikt wordt.

[RJG-223]

[...]

Intel heeft schaarse tijd en middelen aangewend om 32-bits compatibel te blijven in plaats van:
* het verbeteren van de Core i architectuur;
* het optimaliseren van de 64-bits microcode;
* het ontwerpen van zuinige CPU's (ze zijn jaren op 10nm blijven hangen)
* ...

En dat gaaat dus niet veranderen, en dat was ook niet anders geweest als ze de overstap eerder gemaakt hadden.

Wat de meeste mensen niet begrijpen, is dat dit alleen om zaken gaat die heel specifiek voor BIOSen en OSen gebruikt worden. compatibiliteit met 32-bit applicaties blijft gewoon gehandhaafd, en dus zal Intel (alsmede de OS-bouwers) daar moeite in moeten blijven stoppen.

Het heeft ook niets te maken met 10nm en dergelijke. Het lijkt erop dat je alles wat je niet bevalt aan Intel hier op een hoop gooit en het in de schoenen schuift van 16-bit en 32-bit boot-code compatibiliteit.

[moredruid]

Het zou hoe dan ook fijn zijn om het oude x86 deel van de instructieset niet meer te hoeven gebruiken en volledig in 64 bit long mode te draaien. Voor chipfabrikanten betekent het 1 instructieset laden, ipv 2 met elk nog verschillende modi.

En er kan inderdaad vast wel via een abstractielaag een 32-bit applicatie gestart blijven worden. Hardware is tegenwoordig snel genoeg om daar niets meer van te merken.

[kimborntobewild]

Hardware is tegenwoordig snel genoeg om daar niets meer van te merken.

Abstractielaag? Is dat hetzelfde als virtualisatie?

Als ik 32-bit PaintShopPro7 opstart op mijn PC, duurt dat ongeveer 1 seconde.
Vanaf PSP8 werd het opstarten van PSP gigantisch veel trager. Ik wil graag een plaatje meteen kunnen editen als ik een plaatje open. Dus heb ik PSP7 ingesteld als programma die wordt geopend als ik op een plaatje dubbelklik. Sinds 2001 heb ik geen grafisch programma kunnen vinden die even gebruikersvriendelijk is en die opties heeft die ik voornamelijk nodig heb, én die zo snel opstart.
Toch vind ik die 1 seconde al lang genoeg duren. Als het gevirtualiseerd gaat worden, lijkt me dat er niet beter op worden. Zo ben ik verknocht aan PSP7; zo zullen anderen verknocht zijn aan andere oude programma's.
Ik zie trouwens dat ik momenteel 18 processen draai in 32-bit. Die zouden dan alle 18 gevirtualiseerd moeten worden. Dat moet haast wel een grote verslechtering op snelheid geven.

[moredruid]

Het kan best zijn dat je verknocht bent aan PSP7, je hebt in ieder geval de keuze om een nieuwere (64-bit) versie te gebruiken. Dat jij een andere keuze maakt en een produkt wil gebruiken dat 17 jaar geleden zijn laatste update heeft gehad is prima, maar begrijp wel dat de rest van de wereld hier geen rekening mee hoeft te houden. En als ze dat wel doen middels een abstractielaag die latency introduceert denk ik dat je blij moet zijn dat het nog gewoon blijft werken ipv dat je helemaal in de kou wordt gezet.

[kimborntobewild]

Het kan best zijn dat je verknocht bent aan PSP7, je hebt in ieder geval de keuze om een nieuwere (64-bit) versie te gebruiken.

Alleen de naam is hetzelfde, van de 64-bits versies. Het belangrijkste: de lage opstartsnelheid heeft de 64-bits versie niet. Vanaf versie 8 is het opstarten te traag geworden.

Dat jij een andere keuze maakt en een produkt wil gebruiken dat 17 jaar geleden zijn laatste update heeft gehad is prima, maar begrijp wel dat de rest van de wereld hier geen rekening mee hoeft te houden.

Nee, dat hoeft niet. Maar ik zou het jammer vinden als het niet meer kan draaien. Er zullen meer mensen zijn die verknocht zijn aan bepaalde 32-bits programma's, waar geen goed alternatief voor bestaat.

En als ze dat wel doen middels een abstractielaag die latency introduceert denk ik dat je blij moet zijn dat het nog gewoon blijft werken ipv dat je helemaal in de kou wordt gezet.

Laten we het hopen dat dat goed en snel werkt . Ik denk dat ik er tot mijn dood mee wil blijven werken.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 19:44]

[markg85]

Jazeker ein-de-lijk!

Jij en elke x86 cpu gebruiker die alles op 64 bit draait heeft hier al vele jaren nadeel van. Zie je dat nadeel? Nee, je weet tenslotte niet anders. Maar je ziet wel wat de concurrentie doet met nieuwe architecturen (Arm en Risc-V) en je ziet ook dat Apple bizar grote energie optimalisaties (performance per watt) haalt die simpelweg niet mogelijk zijn door de goede oude x86 CPU.

Het schrappen van de 32 bit kant maakt het hele cpu design veel simpeler (relatief dan). Er zijn simpelweg minder transistors nodig in het ontwerp voor een gelijke performance als nu. Letterlijk minder hardware op cpu die niveau. En wat win je daarmee? Kleinere chips, zuiniger chips en koelere chips. Dat ga je merken in het stroomgebruik en waarschijnlijk ook in de prijs van de cpu zelf (goedkoper).

Het zou ook veel helpen als ze die enorme berg instructie sets, vooral de oude, die een cpu nu heeft ook eens op de schop nemen.

[RJG-223]

Het schrappen van de 32 bit kant maakt het hele cpu design veel simpeler (relatief dan).

32 bit wordt niet geschrapt. Alleen de ondersteuning voor 6432-bit OSen wordt geschapt. 32-bit applicaties blijven gewoon werken. En de enige die hier dus voordeel van heeft, zijn Intel en AMD, omdat het ontwerp van de CPUs iets minder complex wordt, en dus iets goedkoper.

Alle andere mensen, in het bijzonder de x86 gebruikers, gaan hier he-le-maal niets van merken. En sowieso hebben ze nu ook geen nadeel van de 32-bit ondersteuning die er is. Sterker nog: als je alle 32-bit ondersteuning eruit zo slopen, dan zouden sommige applicaties meer geheugen gaan gebruiken en/of langzamer worden. Dus hebben mensen er nu juist voordeel van dat 32-bit applicaties mogelijk blijven.

[Reactie gewijzigd door RJG-223 op 23 juli 2024 19:44]

[markg85]

Onzin.

Ik neem aan dat je 32 bit OS bedoeld, niet 64.

Natuurlijk blijft 32 bit gewoon werken. De grote software boeren (microsoft) zouden eens alles updaten naar 64 bit... neehoor. Dus backwards compatible zal wel moeten blijven. Maar dat hoeft niet in de cpu zelf te zitten. De CPU kant kan versimpeld worden dat het emuleren van die specifieke instructies. Kijk naar Mac als voorbeeld met hun Rosetta voor hoe goed zoiets kan werken.

Sterker nog: als je alle 32-bit ondersteuning eruit zo slopen, dan zouden sommige applicaties meer geheugen gaan gebruiken en/of langzamer worden. Dus hebben mensen er nu juist voordeel van dat 32-bit applicaties mogelijk blijven.

Dat zijn heerlijke argumenten om vooruitgang volledig de nek om te draaien. Deze broodje aap onzin argumenten waren er in de begintijd toen 64 bit er net kwam ook. En ja, applicaties gebruikten toen iets meer geheugen ja. Maar niet veel meer en weer winst op andere plekken. Aan de software kant kunnen veel betere optimalisaties worden gedaan om geheugenverbruik te verminderen dan simpelweg het verschil van 32 en 64 bit.

[SuperDre]

Lol, software kant en meer optimalisaties, dat is iets dat al 20+ jaar geleden uit het raam is gevlogen bij de meeste developers, anders dan dat de compiler wat voor je optimaliseert zoals altijd daarvoor ook al gebeurde.

[markg85]

Helaas ja. Grappig is wel dat je soms bij software ineens een release ziet die dingen veel sneller maakt. Dan hebben ze eindelijk is naar performance en profiling gekeken... Zou een vast onderdeel moeten zijn van development wat mij betreft.

[RJG-223]

Aan de software kant kunnen veel betere optimalisaties worden gedaan om geheugenverbruik te verminderen dan simpelweg het verschil van 32 en 64 bit.

Dat is wel een zeer algemene bewering, die dus nooit kan kloppen.

Neem bijvoorbeeld een applicatie die zeer veel pointers gebruikt, maar niet meer dan, zeg, 2G geheugen. Dan gebruikt die in 64 bit modus misschien wel tot twee keer zo veel geheugen. Al die data neemt bij gebruik ook dubbel zo veel L3, L2 en L1 cache in, zodat daar minder nuttige data in past, met meer cache-misses, meer DRAM-access, en dus tragere code. Ook de TLB heeft daar last van (meer pagina's in de working set, zodat er vaker een page-table-lookup gedaan moet worden), zodat ook daar dan nog een vertragende factor zit.

Al die zaken kan een compiler niet optimaliseren, want die moet altijd met die 64-bit pointers werken. De programmeur kan dat wel proberen te optimaliseren, met truukjes, maar het is dan veel sneller/makkelijker om er een 32-bit applicatie van te maken. Zeker als je dan wél van de x86 64-bit registers gebruik kunt maken (als je een OS hebt die die modus ondersteunt).

Dit alles is onderzocht en aangetoond. Niet in het algemeen voor alle applicaties. Wel voor specifieke applicaties waar het significant uit kan maken. Het hangt dus heel erg van de applicatie af.

[Reactie gewijzigd door RJG-223 op 23 juli 2024 19:44]

[markg85]

Neem bijvoorbeeld een applicatie die zeer veel pointers gebruikt, maar niet meer dan, zeg, 2G geheugen. Dan gebruikt die in 64 bit modus misschien wel tot twee keer zo veel geheugen.

Dat is een zeer selectieve uit de context geplukte waarheid.
Als jouw programma alleen maar uit pointers zou bestaan (wat niet kan) ja dan gebruikt die 2x zoveel geheugen.

In een programma heb je de data in het geheugen en de pointers naar die data. Procentueel (ik weet niet hoeveel het is, maar simpelweg door mijn ervaring als developer) is het geheugen verbruik van enkel de pointers echt maar een fractie van het totale geheugen verbruik van een applicatie. Je heb het dan ook nog over L1, L2 en L3.. Ik betwijfel of je wel weet waar je het over heb en niet gewoon een artikel kopieert hier. Hoe dan ook, als je je om die lagen druk gaat maken zijn pointers in zijn algemeenheid een probleem. Pointers houdt ook nagenoeg altijd in dat je data niet netjes achter elkaar in het geheugen zit wat funest is voor CPU cachelines en daarmee je performance volledig om zeep helpt.

Maargoed, ik ga hier niet zitten uitleggen en verdedigen dat dit normaal is en dat jouw "angst" voor 2x zoveel geheugen simpelweg onzin is. Google het zelf maar.

[Fiander]

Neem eens een applicatie die plaatjes bewerkt.
Er word een plaatje in het geheugen gezet, en daar wordt een pointer naar gezet.
Die pointer is inderdaad twee keer zo groot, dat klopt.

Met 32 bit kun je aan één pixel tegelijk rekenen ( RGBA ) en met 64 bit kun je aan twee pixels tegelijk werken. en dan heb je in 64 bit ook nog eens twee keer zoveel registers tot je beschikking

( DAT vind ik persoonlijk de grootste fout van AMD met de 64AMD instructie set. te weinig registers. van 8 naar 16 is gewoon karig te noemen. 32 of 64 had echt lekker geweest. vooral met een dedicated register cache voor swappen tussen vele threads. maar offtopic... Itanium had 1024 registers btw...)

Verder zijn compilers slim genoeg om wanneer het kan een near jmp te doen ipv een far jmp waarbij je inderdaad het absolute adres opgeeft. terwijl bij de near je een relatief adres opgeeft.

En als je last hebt van een volle TLB in je programma, staat het je natuurlijk altijd vrij om je software te herschrijven en PSE te gebruiken. je kunt dan ipv pages van 4KiB, ook pages van 4MiB gebruiken, waardoor de TLB minder belast word.

Maar ben het met je eens hoor, als software voor het grootste gedeelte geprogrammeerd is om pointers naar integers te gebruiken, dan gaat DIE software inderdaad meer geheugen gebruiken, en trager zijn.
maar door de software GOED te schrijven, en geen pointers naar integers te doen, maar integers gewoon rechtstreeks te gebruiken, dan zal zowel de nieuwe 32 bit, als de nog nieuwere 64 bit software sneller werken dan dat de oude 32 bit dat deed.

[RJG-223]

Maar ben het met je eens hoor, als software voor het grootste gedeelte geprogrammeerd is om pointers naar integers te gebruiken, dan gaat DIE software inderdaad meer geheugen gebruiken, en trager zijn.
maar door de software GOED te schrijven, en geen pointers naar integers te doen, maar integers gewoon rechtstreeks te gebruiken, dan zal zowel de nieuwe 32 bit, als de nog nieuwere 64 bit software sneller werken dan dat de oude 32 bit dat deed.

Het hangt heel erg van de software af. Sommige software gebruikt naar zijn aard relatief veel pointers. Als die allemaal dubbel zo groot worden, dan scheelt dat aanzienlijk. En dat zijn echt geen kunstmatig gefabriceerde voorbeelden. Alleen misschien niet het soort software dat jij gewend bent. Het schijnt overigens dat talen met GC ook al snel 'last' kunnen hebben van de grotere pointers.

Voor dat soort (pointer-intensieve) programma's worden dus ook truukjes gebruikt om toch met 32 bit 'pointers' te kunnen werken. Bijvoorbeeld door geen echte (64 bit) pointers te gebruiken, maar (32 bit) indices in een array. Is complexer, en dus wat lastiger programmeren, maar wel geheugen-efficiënter, en dus ook sneller. Alle makkelijke optimalisaties, zoals pointers naar integers vervangen door integers, zijn dan natuurlijk al gedaan.

[Argantonis]

Heb je hier cijfers voor? Volgens mij valt ‘t wel mee wat er hierdoor allemaal weg kan.

[!GN!T!ON]

Minder complexe CPU, minder transistoren nodig voor 32bit deel, die vrije ruimte kan dan gebruikt worden voor extra performance of minder stroomverbruik.

En eindelijk snap ik wel, want dit komt al 20 jaar ofzo met enige regelmaat voorbij als optie/wens. Dus nu na 20 jaar worden er weer stappen gemaakt, daar mag je toch prima dan 'eindelijk' bij plaatsen als je het topic al zolang volgt?

[RoyD]

Een aanzienlijk deel van de chipoppervlakte gaat op aan het cache geheugen. Die 32 bits compatibiliteit zal marginaal schelen in de oppervlakte.

[uiltje]

Het gaat vooral om verschillen in de architectuur. Die ringen hebben rechtstreeks invloed op de core functionaliteit. Het zal niet per se om transistoren gaan, meer om optimalisatie en vermindering van de complexiteit.

[RJG-223]

Omdat ze dat hebben verzuimd, heeft MS nog tonnen 32-bits software en OS-en uitgebracht

Er zijn talloze software-applicaties die prima lopen op 32 bit, en waarbij omzetten naar 64 bit veel moeite (dus tijd, geld, nieuwe bugs, etc.) kost, zonder voordelen - er zijn dan soms zelfs nadelen: meer geheugengebruik, en daardoor misschien zelfs langzamer. En MS is heus niet de enige leverancier van software. Je wist het misschien niet, maar er zijn talloze bedrijven die software maken voor X86 processoren. Veel brengen dus gewoon nog heel erg veel 32 bit software uit, en zitten echt niet te wachten op een geforceerde omschakeling. Daarnaast heb je legacy-applicaties, 32 bit, die niet meer verder ontwikkeld worden, maar waar bedrijven nog wel van afhankelijk zijn. Als die ineens niet meer draaien, hebben veel bedrijven ineens een probleem...

En dan heb ik het nog niet eens over het feit, dat met deze voorgestelde verandering, 32-bits software niet verdwijnt. Integendeel. Die wordt de komende jaren (decennia?) nog gewoon ondersteund. Het enige dat verdwijnt is ondersteuning voor 32-bit en 16-bit OSen. Maar die 64-bit OSen kunnen dan dus wel gewoon nog 32-bit applicaties draaien.

[Fiander]

En die 32 bit software blijft gewoon werken.
Er worden geen cpu instrtucties verwijderd,
Alleen maar CPU modi. ( 16 bit modi, 32 bit real, 32 bit protected. )
allemaal zaken welke puur en alleen door een OS gebruikt kunnen worden.

[MarcoC]

Er zijn nog wel een redelijke tijd daarna Intel 32-bit CPU's verkocht en ook uitgebracht (bijv. Intel Atom netbooks).

[RPS13]

Ja, dit bericht typ ik vanaf mijn Atom N2600 netbook! Een CPU uit 2011, maar gebonden aan 32 bit OS & software. Draait overigens wel gewoon Windows 10 vanaf een Samsung 860 EVO.

Via een gemodde bios heb ik 64 bit support weten te unlocken, maar er zijn geen 64 bit drivers beschikbaar voor de GMA 3600. Ik heb het een en ander geprobeerd om drivers handmatig aan te passen, maar tot dusver zonder succes. (mocht een andere tweaker dit willen proberen, let me know )

[CAPSLOCK2000]

Ein-de-lijk!
Dit hadden ze 15 jaar geleden moeten aankondigen en 10 jaar geleden moeten uitvoeren.

Mag het een decenniumpje meer meer zijn? Ze hebben het namelijk al 25 jaar geleden gedaan onder de naam Itanium. Aangekondigd in 1999, uitgebracht in 2001, maar die architectuur (ia64) heeft het niet gered. Sindsdien bekend als de "Titanic"-architectuur.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 19:44]

[jaenster]

Je had daar ook wel echt andere software voor nodig. Tegenwoordig is 95% van de applicaties 64 bit, en de enkele die dat niet zijn, zijn zo oud en licht dat ze makkelijk virtueel te draaien zijn. Er veranderd eigenlijk niks. 64 bit is niet universeel, arm64 is immers ook niet hetzelfde als amd64

[dmantione]

Nog sterker, die resterende 5% is ook afgedekt, want 32-bits applicaties blijven gewoon mogelijk. Het is de gebruiker die nu nog Windows 2000 op zijn nieuwe computer wil installeren die getroffen zou worden.

[gast128]

Tegenwoordig is 95% van de applicaties 64 bit, en de enkele die dat niet zijn, zijn zo oud en licht dat ze makkelijk virtueel te draaien zijn.

Weet u dat zeker? Visual Studio 2019 is zelfs nog 32 bits naast een hoop oude (en goede) spellen van voor 2010. Onze ontwikkelde applicaties zijn pas een paar jaar geleden naar 64 bit gegaan omdat veel afhankelijke bibliotheken nog niet of buggy in 64 bit vorm beschikbaar waren.

Merced / Itanium processoren hadden een geheelde andere instructie set (EPIC). Performance van de processoren viel tegen (door hoge cache druk; geen goede compilers) maar waarschijnlijk heeft het gebrek aan terugwaartse compatibiliteit (naar x86) de processor de das omgedaan.

[Zer0]

Dit hadden ze 15 jaar geleden moeten aankondigen en 10 jaar geleden moeten uitvoeren.

DIt hebben ze al ruim 20 jaar geleden aangekondigd en uitgevoerd.... https://en.wikipedia.org/wiki/Itanium
Was een groot succes

[ikweethetbeter]

Itanium was voor de server, ze stopten niet met de x86 architectuur, wat voor de desktop bedoeld was. En MS is MS, x86 bleef bestaan, dus maakten ze nog spullen voor de oude architectuur. Tot op de dag van vandaag

[!GN!T!ON]

Itanium is / was anders dan dit voorstel, IA64 was een complete nieuwe architectuur toch die helemaal niks meer met x86 te maken had, en daarom ook nul backwards compatibility had. Dat is in dit voorstel als ik het goed begrijp wel zo.

Beetje appels / peren dus volgens mij.

[Frame164]

Het is niet de hardwarefabrikant die eisen stelt aan de gebruikers maar andersom. Als gebruikers om wat voor reden dan ook 32-bits nodig hebben dan moet je dat leveren. Als je het niet zelf doet, doet een ander het wel. Jij redeneert heel erg 1-dimensionaal en verliest daarbij het doel uit het oog. Een CPU architectuur is niet het doel, wat gebruikers willen en moeten doen is het doel.

[Reactie gewijzigd door Frame164 op 23 juli 2024 19:44]

[batjes]

MS wilde met Vista 32bit al volledig achter zich laten en pushde vrij sterk naar 64bit. Toen ze met XP begonnen, was het originele idee om dat 64bit only te maken (maar al heel vroeg in de ontwikkeling zijn ze hier al afgestapt).

Maar er is gewoon zo ontzettend veel 32bit software dat zelfs vandaag nog gebruikt wordt. Antieke software is de primaire reden waarom Citrix nog zo populair is.

[Martinspire]

Wat is de verwachting in voordelen/performance voor zo'n stap? En wat voor performance impact voor virtuele 32bit compatibiliteit?

[ThunderNet]

Geen performance verschil. Het haalt complexiteit uit het chipontwerp weg. Delen die er nu nog in zitten vanwege backwards-compability, maar die dus in 99.99% van de use-cases totaal niet gebruikt wordt.

[HollowGamer]

Er kan wel degelijk een performance verschil in zitten, zoals @bewerkers al aangeeft.

Het voordeel is ook, dat die nieuwe ruimte benut kan worden voor nieuwe zaken, of inderdaad voor kleinere chips.

[Robbaman]

Nou ja, de vraag is natuurlijk of ze met de vrijgekomen chipruimte en door de afgenomen complexiteit extra ruimte creëren om nieuwe features/instructies toe te voegen die de performance verbeteren.

[bewerkers]

Voordelen zijn al genoemd: minder transistors nodig per core, dus een core wordt kleiner. Dus er passen meer cores in een chip. Verder is het startup process van de CPU versimpeld. Er zijn vast meer voordelen zoals energieverbruik en yields.

[RJG-223]

Voordelen zijn al genoemd: minder transistors nodig per core, dus een core wordt kleiner. Dus er passen meer cores in een chip. Verder is het startup process van de CPU versimpeld. Er zijn vast meer voordelen zoals energieverbruik en yields.

Ik kan me niet voorstellen dat dit enorm veel gaat schelen in aantal transistoren. Misschien hooguit één, of heel misschien een paar procent. Veel minder dan de overstap naar een nieuwe node. Beslist niet genoeg voor een extra core. Het voordeel zal 'm vooral zitten in een minder complex ontwerp, en misschien een paar extra optimalisaties die vooralsnog niet mogelijk zijn vanwege die complexiteit.

[dmantione]

Je moet wel bedenken: Intel heeft een minder geavanceerde node en dat zal niet 1-2-3 gecorrigeerd zijn. Efficiënt met transistoren omgaan is daarom voor Intel belangrijker dan voor AMD. Een paar procent transistoren is best behoorlijk, zeker als je dat kunt inruilen om nieuwe krachtige instructies te implementeren om de achterstand kleiner te maken.

[Natean]

Ik denk dat dit meer impact heeft op hardware en development resources.

Als je deze niet meer ondersteunen dan bespaar je een hele brok werk uit.
Met als gevolg dat je een snellere time-to-market hebt en minder kosten.

Ook verwacht ik dan een hele boel plaats die op de chip die vrij komt.
Dan zou je voor minder kosten meer cores kunnen toevoegen op hetzelfde oppervlakte of de chip gewoon kleiner maken.

Ergens verwacht ik dan ook hogere overclock gezien er minder transistoren kunnen zijn die niet kunnen volgen en/of lagere energie verbruik door minder poorten die aan het schakelen zijn. Nu dit laatste verwacht ik wel dat al tot in zekere mate dynamisch aan en uit word geschakeld op de huidige chips.

[mcmd]

Hoeveel procent oppervlak zou het dan schelen?

[TD-er]

Zou verwachten dat het vrij weinig scheelt, omdat het met name 'legacy' spul is.
Oftewel wat decennia geleden al in een CPU paste.
Dus in vergelijking met de huidige enorme hoeveelheid aan transistoren in een moderne CPU zou het wellicht amper meetellen.
Maar dat het in complexiteit veel kan schelen, kan ik mij goed voorstellen.

[Hardfreak]

Ik kan mij vergissen, maar het gaat niet om een 64-bit only CPU, maar een 64-bit CPU waarin alle onnodige zooi is uitgehaald om een 32-bit OS te booten. Ondersteuning voor 32-bit applicaties blijft gewoon bestaan: https://www.techpowerup.c...adulterated-64-bit-future

How Would a 64-Bit Mode-Only Architecture Work?
Intel 64 architecture designs come out of reset in the same state as the original 8086 and require a series of code transitions to enter 64-bit mode. Once running, these modes are not used in modern applications or operating systems.

An exclusively 64-bit mode architecture will require 64-bit equivalents of technologies that currently run in either real mode or protected mode. For example:
* Booting CPUs (SIPI) starts in real-address mode today and needs a 64-bit replacement. A direct 64-bit reset state eliminates the several stages of trampoline code to enter 64-bit operation.
* Today, using 5-level pages requires disabling paging, which requires going back to unpaged legacy mode. In the proposed architecture, it is possible to switch to 5-level paging without leaving a paged mode.
These modifications can be implemented with straightforward enhancements to the system architecture affecting the operating system only.

What Would Be the Benefits of a 64-bit Mode-Only Architecture?
* A 64-bit mode-only architecture removes some older appendages of the architecture, reducing the overall complexity of the software and hardware architecture. By exploring a 64-bit mode-only architecture, other changes that are aligned with modern software deployment could be made. These changes include:
* Using the simplified segmentation model of 64-bit for segmentation support for 32-bit applications, matching what modern operating systems already use.
* Removing ring 1 and 2 (which are unused by modern software) and obsolete segmentation features like gates.
* Removing 16-bit addressing support.
* Eliminating support for ring 3 I/O port accesses.
* Eliminating string port I/O, which supported an obsolete CPU-driven I/O model.
* Limiting local interrupt controller (APIC) use to X2APIC and remove legacy 8259 support.
* Removing some unused operating system mode bits.

Dus je kan alleen nog 64-bit OS'es starten. Gaat waarschijnlijk wel een probleem vormen voor tools als MATS, denk niet dat die 64-bit is

//edit: typo
//edit: wel ballz van Intel om het Intel 64-bit te noemen gezien het echt wel AMD64 is

[Reactie gewijzigd door Hardfreak op 23 juli 2024 19:44]

[RJG-223]

Ik kan mij vergissen, maar het gaat niet om een 64-bit only CPU, maar een 64-bit CPU waarin alle onnodige zooi is uitgehaald om een 32-bit OS te booten. Ondersteuning voor 32-bit applicaties blijft gewoon bestaan:

Je vergist je niet. De meeste mensen lezen blijkbaar niet, of half, of ze trekken al een conclusie op basis van de titel, en interpreteren dan het hele artikel volgens die foutieve conclusie.

Het gaat hier inderdaad alleen om 16-bit en 32-bit boot support. 32 bit applicaties blijven gewoon werken. Als dat niet zo was, dan zouden heel veel mensen/bedrijven op hun achterste benen staan...

[sfranken]

Gaat waarschijnlijk wel een probleem vormen voor tools als MATS, denk niet dat die 64-bit is

Nee hoor, 32 bit applicaties blijven gewoon werken. Het is, zoals je zelf ook al zegt, alleen de 32 bit OS support (16 bit -> 32 bit -> 32 bit protected mode -> 64 bit chain) die eruit gaat.

[Hardfreak]

Maar MODS/MATS is voor zover ik weet enkel beschikbaar als bootable ISO en zelfs die zijn niet altijd even makkelijk te vinden: https://repair.wiki/w/Nvidia_Memory_Testing_Guide

Qua compatiblility lijkt het mij logisch dat die bootable ISO een 32-bit OS bevat (not sure though).

[nokie]

Waarom zouden ze dit eigenlijk precies willen laten samenvallen met een “transitie van OS”? Win11 en Linux zijn eigenlijk al volledig 64bit, het gaat vooral om legacy applicaties.

De sleutel lijkt me overigens mij Microsoft te liggen (sorry, maar het marktaandeel op desktop voor Linux is te klein om daar het gewicht uit te maken). Als ze (Apple-stijl-gewijs) gewoon doorduwen dat vanaf nu alles 64bit moet zijn om native te draaien, en 32bit alleen nog gevirtualiseerd of zo, dan wordt het “probleem” (dat voor 90% van de gebruikers zelfs geen probleem is) ook zichtbaar.

Nu ja, als Windows 12 straks als eis krijgt dat het moet draaien op een CPU waar 32bit is uitgesloopt, dan staan we weer met z’n allen op de achterste poten, waarschijnlijk. Dat helpt ook niet…

[dmantione]

Ik kan me voorstellen dat besturingssystemen nagelopen moet worden op het gebruik van functionaliteit die niet meer in de processor aanwezig is. Dat zal geen schokkende wijziging (want 64-bit long mode blokkeert al veel functionaliteit zodra het ingeschakeld wordt) zijn en kan misschien ook gewoon met een kernelupdate uitgevoerd worden.

[RJG-223]

Waarom zouden ze dit eigenlijk precies willen laten samenvallen met een “transitie van OS”?

??? Waar staat dat ?

Overigens wordt 32 bit helemaal niet eruit gesloopt. Alleen de 16-bit opstart-mode en de 16-bit en 32-bit CPU-functionaliteit die alleen OSen nodig hebben (en firmware - zoals EFI) wordt eruit gesloopt. 32bit applicaties blijven gewoon ondersteund. En dat zal nog wel even zo blijven, want die zijn soms efficiënter en sneller dan 64-bit appicaties.

En als Microsoft zoiets door zou willen duwen, zijn de daarvoor ook niet afhankelijk van Intel. Dat kunnen ze nu al doen. Ze doen het niet, omdat het amper/geen voordeel oplevert, en wel nadelen.

[nokie]

[...]

??? Waar staat dat ?

In het artikel.

Overigens wordt 32 bit helemaal niet eruit gesloopt. Alleen de 16-bit opstart-mode en de 16-bit en 32-bit CPU-functionaliteit die alleen OSen nodig hebben (en firmware - zoals EFI) wordt eruit gesloopt. 32bit applicaties blijven gewoon ondersteund. En dat zal nog wel even zo blijven, want die zijn soms efficiënter en sneller dan 64-bit appicaties.

En als Microsoft zoiets door zou willen duwen, zijn de daarvoor ook niet afhankelijk van Intel. Dat kunnen ze nu al doen. Ze doen het niet, omdat het amper/geen voordeel oplevert, en wel nadelen.

Dat had ik inderdaad verkeerd begrepen, dat het er niet volledig wordt uitgehaald. Ik zie overigens niet wat het nadeel is, behalve backward compatibility met oude software.

[Consequator]

Zolang we via software nog wel 16/32bit kunnen draaien vind ik het prima.

[Hardfreak]

Draait 16-bit software nog natively op moderne hardware?

[sfranken]

Ja, *als* je het aan de praat krijgt. Veel compilers slikken dat niet, en veel runtimes hebben ook meer en meer moeite.

[NoobishPro]

Als 32 bits weghalen een pad vrijmaakt naar hybrid CPU's, dan zeg ik; Go for it! -- niet dan?

Wat heb je er nou aan om 64 van dezelfde cores in één CPU te klappen? Uiteindelijk hebben we na bijna 20 jaar quad cores nog steeds zelden meer nodig dan quad cores.

Ik zit hier nu met 16 cores en daarvan staan er geloof ik 4 voor het grootste deel van de tijd uit, met nog 4 op 2 loads per uur ofzo.

8 cores begint nu net wat te worden...

Maar, zeg dat je 8 "normale" CPU cores op zo'n ding pleurt voor de heavy taken die we er nu ook mee uitvoeren... Dan heb je nog heel veel ruimte voor hele specifieke cores, zoals AI cores, efficiency cores, en allerlei andere cores welke dan gebruikt kunnen worden voor flinke optimalisatie.

Ik doe even een gok en aanname door te stellen dat, in de onderdelen waarbij wij (consumenten, niet servers) wél de volle 16-32 whatever cores gebruiken, het vooral workloads zijn welke mogelijk beter besteed zouden zijn aan specifiekere cores voor specifiekere taken?

In dat geval ben ik he-le-maal pro hybrid CPU's. Klinkt als een strak plan.

[Verwijderd]

Is 'interessant' niet Amerikaans voor 'dat doen we niet' ?

Ben zelf geen cpu-man, maar legacy wegstrepen geeft op korte termijn vaak grote issues, maar daarmee gaat alles vaak wel met grote sprongen vooruit. Zie apple met de overstap van cpu-architectuur de afgelopen decennia. Kan niet wachten!

[Jan Onderwater]

Ik vind het excuus van Legacy software zoals boekhouding een lame excuus, je kan wmb gewoon je DOS applicatie blijven draaien, maar verbind hem niet met internet.
Zelfde geld voor industriële SW, laat die 386 maar lekker je weefgetouw aansturen, vooral niet investeren in modernisering als daar geen geld voor hebt, maar verbind hem niet met internet, dan is er niets aan de hand.

Maar als je dan toch helemaal over gaat naar 64 bit, ga dan ook weg van x86. Bijvoorbeeld hierom
Een Instructie op een X86 kan tussen de 1 en 15 Bytes lang zijn, iedere ARM Instructie is altijd 4 Bytes. De chip hoeft de Instructie dus niet te decoderen en te analyseren om te kijken waar deze begint en eindigt zoals bij een X86.
Dit betekent dat meer dan 4 Decoders op een x86 veel te complex wordt, maar op een ARM kan de hoeveelheid decoders zo groot worden gemaakt als de Processoren kunnen verwerken, er is daar niet echt sprake van een limiet door complexiteit.

[Reactie gewijzigd door Jan Onderwater op 23 juli 2024 19:44]

[AtariXLfanboy]

Als ik de huidige emulatie van oudere PC's zie dan lijkt het me dat het vrij eenvoudig en zelfs veiliger om oude pure 32bit OS + Software in een emulator te draaien. Goed ... de snelheid van een late Pentium 4 of AMD Athlon XP haalt het dan (nog) wel niet, maar in de buurt van een Pentium 3 machine komt het al wel! Het zal echt dan bij hogere uitzondering zijn dat er geen oplossing is, want het meeste moderne 32 bit dat echt power nodig heeft werkt ook wel op een 64 bit systeem.