Intel stelt x86-S-instructiesetarchitectuur voor met enkel 64bit-ondersteuning

Intel heeft een voorstel gepubliceerd om een 64bit-onlyvariant van zijn x86-instructieset te introduceren. Het bedrijf heeft een whitepaper geschreven met een idee voor een x86-S-architectuur, waaruit onder meer native ondersteuning voor 32bit-OS'en wordt geschrapt.

Intel schrijft in een blogpost dat het nadenkt over de introductie van een 64bit-only-x86-architectuur. Volgens het bedrijf is de tijd daarvoor aangebroken, omdat 64bit-besturingssystemen inmiddels de standaard zijn. Het bedrijf wil de nieuwe architectuur x86-S noemen, waarbij de S staat voor Simplified. De eventuele wijzigingen zouden doorgevoerd kunnen worden in toekomstige Intel-chips, hoewel het momenteel alleen een visie betreft.

De x86-S-isa zou betekenen dat cpu's alleen gestart kunnen worden in 64bit-modus. Het bedrijf schrapt verschillende legacymodi, die volgens het bedrijf momenteel weinig nut hebben. Een van de wijzigingen is dat 32bit-ring 0 uit de x86-architectuur gehaald zou worden. Datzelfde geldt voor ring 1 en 2, die momenteel niet gebruikt worden in moderne besturingssystemen.

Als de wijzigingen worden doorgevoerd, zouden gebruikers virtualisatie moeten toepassen om legacy-32bit-besturingssystemen te draaien. De wijzigingen zouden alleen impact hebben op het gebruik van dergelijke besturingssystemen; 32bit-applicaties zouden wel blijven werken. Dat komt overeen met de functionaliteit van huidige besturingssystemen, schrijft Intel. Microsoft bracht bijvoorbeeld alleen een 64bit-versie van Windows 11 uit, maar die versie ondersteunt nog steeds 32bit-software.

Reacties (186)

[Memori]

Een van de wijzigingen is dat 32bit-ring 0 uit de x86-architectuur gehaald zou worden.

Worden de anti-cheat makers toch nog geforceerd om te kappen met het draaien in ring-0

[lukjah]

Is er niet een 64 bits ring 0? Dan is het een kwestie van de game recompilen op 64 bits (als dat niet al zo is)

[TechSupreme]

De "Protection ring" is een verouderde beveiligingsmechanisme. In nieuwere systemen is dat vervangen met andere veel complexere mechanismen.

[field33P]

64-bit Windows gebruikt het toch nog steeds als een van de vele beveiligingslagen?

[TechSupreme]

32bit protected mode of WOW64 bedoel je. Zit er nog in vanwege compatibiliteit, maar dat betreft alleen het 32bit gedeelte.

[Reactie gewijzigd door TechSupreme op 23 juli 2024 16:16]

[xorpd]

De protection ring is niet vervangen, hij is gesimplificeerd naar user mode / supervisor mode.

[TechSupreme]

Dat is alleen voor systemen zonder een MMU of MPU.

[xorpd]

Privilege separation (wat de protection ring is) is nodig zodat user-level code geen supervisor instructies kan uitvoeren. Je kunt dus niet zonder in een modern besturingssysteem.

Even uit mijn hoofd, de twee laagste bits van het CS register bepalen of je in user mode of in supervisor mode bent. Ook in 64-bit mode. Alleen supervisor code heeft toegang tot supervisor pages. Niet andersom.

Wat er wel verdwenen is in 64-bit is segmentering en segment boundaries maar dat is iets heel anders.

[Reactie gewijzigd door xorpd op 23 juli 2024 16:16]

[TechSupreme]

Het zijn niet alleen de anti-cheat makers. Cheatmakers maakte gebruik van ring-0 lang voor anti-cheatmakers dat deden. Ik weet nog van de tijden van HLGuard, de eerste niet te detecteren cheat die via ring-0 allerlei OS level manipulaties deed waardoor bestanden onvindbaar waren. Tot er een anti-cheat uitkwam die ook via ring-0 veranderingen in het OS ging detecteren.

[DLeijen]

En een bak aan games die niet meer te spelen zijn omdat de anti-consumer software niet bijgewerkt wordt...

[killerbie]

jij hebt overduidelijk het artikel niet eens gelezen....

[DLeijen]

Software blijft werken, maar anti-cheat die expliciet ring 0-hardware aanspreekt als die hardware niet meer aanwezig is? Dat vermoed ik niet.

[killerbie]

ik vermoed dat er software bestaat om het gros van die games toch speelbaar te maken, ook vandaag al

[killerdemon]

Hij heeft wel een punt; sommige anti cheat software zal virtualisatie misschien niet leuk vinden

[Ayporos]

Dat is een feit.
Ik heb Elden Ring moeten skippen omdat mijn main-pc een VM is (draait op Proxmox met GPU en USB passthrough) en de anti-cheat voor het online gedeelte (waar ik sowieso nul interesse in heb) dus weigert het spel op te starten.

Zeer naar. Het is 2023. Ja ik ben een uitzondering dat ik mijn main (gaming) PC als VM draai.. maar ik ga dus écht niet een bare-metal bak bijhouden enkel en alleen omdat anti-cheat naar is.
Meteen refunded.. als ze m'n geld niet willen is dat hun gemis I guess. Genoeg andere games om me zoet te houden.

[Zezura]

Nah, zo raar is passthrough virtualisatie niet, in deze tijd goed te doen. Bedrijven doen het al heel heel erg lang met Citrix. Waarom zou je maar 1 instantie op hardware draaien als je er meerdere tegenlijk kan draaien of graag snel wil kunnen schakelen. Of je huis er zo op hebt ingericht. Onderhoud wordt er makkelijker op. Werkplekken versimpelen en toch overal high-performance bij je pc kunnen. Ik dacht er ook over na.

[Ayporos]

Er zitten wel pijnpuntjes aan hoor voor thuis gebruik.
Voor mij persoonlijk wegen de pros op tegen de cons.. maar het is voor Jan Alleman echt geen pretje.
Alleen al om gpu passthrough werkend te krijgen moet je een échte tweaker zijn die niet bang is een paar uur tutorials en shit door te moeten spitten.

Voor business uiteraard.. ja logisch.
Maar in de context van 'gaming' moet je dat buiten beschouwing laten want dan hebben we het immers praktisch enkel over thuisgebruik, en dán is het ineens een heel ander verhaal.

[Zezura]

Uren, daar zijn we toch tweakers voor

[Wolfos]

Dat zijn veelal live service games. Dikke kans dat ze dus eindelijk die rootkits eruit gaan halen.

[Tomislav]

Ik kan me eerlijk gezegd niet voorstellen dat dit de moeite waard is qua prestaties. Misschien heeft het er meer mee te maken dat ze dan voor nieuwe ontwerpen geen oude, nauwelijks gebruikte circuits hoeven te valideren maar ook dat lijkt me een beetje vergezocht.

[MneoreJ]

Is ook volstrekt de moeite niet waard voor prestaties en daar doen ze het dan ook niet voor. Het is eerst en vooral een makkelijke win voor dingen als beveiliging: geen ring 1 of 2 meer en geen 16-bit en dan 32-bit trampoline om in 64-bit modus te komen zijn weer minder plekken waar een of andere slimme beveiligingsexpert een probleem uit weet te knijpen omdat iemand een BIOS slordig in elkaar gedraaid heeft. Er is een lange en nobele traditie van features die al langere tijd stilstaan en alleen nog voor compatibiliteit erin zitten nieuw leven in te blazen met een exploit. Dit kan zelfs retroactief ontstaan omdat er een ontwerpwijziging komt die even vergeet dat al deze legacymeuk er ook nog is en zo onbedoeld een gaatje maakt.

Op de lange termijn is dit ook een voorbereidende stap als ze ooit wel 32-bit instructie decoding er geheel uit willen slopen (wat nu nog niet aan de orde is), want als je die zaken allemaal tegelijk door zou proberen te voeren gaat het gegarandeerd niet lukken. Je moet dan hardwareboeren, biosbakkers en user mode software vendors allemaal tegelijk door hoepeltjes laten springen; het is fijner als dat in etappes kan.

[damouze]

Volgens mij werd het concept van rings al enige tijd niet meer gebruikt, maar het er helemaal uitslopen zou wel eens heel onhandig kunnen uitpakken.

De originele 80286 processor deelde de protected mode op in 4 rings, en voor elk kon er specifieke beveiliging worden ingesteld. De meest gangbare indeling was:

* Ring 0: Kernel
* Ring 1: Device drivers
* Ring 2: Administrative privileges
* Ring 3: General user privileges

Dit concept was overgenomen uit de mainframe wereld, waar dit actief werd gebruikt. Op de x86 architectuur werd het (naar mijn weten althans) alleen gebruikt in IBMs OS/2. Met de komst van de 80386 processor kwam er het mechanisme van paging, waar iedere pagina in de pagetable kon worden gemarkeerd als 'user' of 'supervisor'. Daarmee werd het systeem van rings minder relevant, maar helemaal ervan afstappen kon niet en men bleef ring 0 en ring 3 gebruiken.

Zelfs met de overstap naar de AMD64 architectuur is het systeem van rings naar mijn weten wel verdwenen. Van alle segment registers zijn alleen FS en GS actief in gebruik (o.a. door Windows), de andere segmenten zijn hardwired naar een flat 64 bit logical address space, met een absolute base van 0x0000000000000000.

Overigens vind ik het persoonlijk wel spijtig dat men 32-bit support steeds meer in een verdomhoekje stopt. Voor heel veel toepassingen is het bijv. helemaal niet nodig om een 64-bit architectuur te gebruiken, maar volstaat een 32-bit omgeving uitstekend.

[Reactie gewijzigd door damouze op 23 juli 2024 16:16]

[Sograd]

Dank voor de heldere uitleg.

[xorpd]

De ringen bestaan nog steeds (supervisor instructies zijn alleen uit te voeren in ring 0), maar zoals jij al zei is de segmentering verdwenen zodat alleen nog paging overblijft. FS en GS zijn nu geen segment registers meer, maar offset registers, en verwijzen respectievelijk naar een thread control block of naar de kernel structures.

[Tyrian]

Dat lijkt me niets. Ik heb nog genoeg Win32 applicaties waaronder games. Emulatie gaat altijd ten koste van performance en (energie) efficiëntie. Dus ik zal graag voor een x86-64 processor blijven kiezen met zowel IA32 als x64 ondersteuning.

Compatibiliteit is altijd de troefkaart geweest van de Intel x86 architectuur. En het gebrek hieraan was de reden dat de Itanium is geflopt. Intel adverteerde het zelf al in 1992: https://www.youtube.com/watch?v=6pCLte1J9aM Het mooie van x86 is dat tot voorkort al die programma's uit de bibliotheek van 1992 nog zouden draaien op een moderne Intel x86-64. Het is pas recentelijk dat PC's geen BIOS meer hebben (Alleen UEFI) waardoor je er geen DOS meer op kunt installeren. Natuurlijk koopt niemand een Intel Core om er DOS op te draaien maar ik heb veel waardering voor het feit dat dit mogelijk was.

[Reactie gewijzigd door Tyrian op 23 juli 2024 16:16]

[ShadLink]

32 bit processen draaien al binnen een "emulatie" laag op Windows 64bit.

[Tyrian]

WoW64 is een compatibiliteitslaag, geen emulator. Een Win32 proces maakt native gebruik van de x86 mogelijkheden van een x86-64 processor via deze compatibiliteitslaag.

[hiostu]

Maar als die games al langer geleden zijn uitgebracht, dan zijn de nieuwe CPUs toch makkelijk in staat om deze met voldoende snelheid te draaien ook al moeten ze emuleren. Als het betekent dat de nieuwe cpu's een hoop legacy kunnen laten vallen en daardoor minder transistoren daaraan verspillen en dus kunnen gebruiken voor meer performance of minder verbruik, dan zou ik daar zeker voor kiezen.

[RJG-223]

Dat lijkt me niets. Ik heb nog genoeg Win32 applicaties waaronder games. Emulatie gaat altijd ten koste van performance en (energie) efficiëntie. Dus ik zal graag voor een x86-64 processor blijven kiezen met zowel IA32 als x64 ondersteuning

32-bit ondersteuning blijft gewoon bestaan, voor applicaties. Dus maak je geen zorgen. Alleen 32-bit OSen (en 16 bit OSen) worden dan niet meer ondersteund. Wel 32-bit applicaties op een 64-bit OS. Zie het artikel.

Overigens heb je verschillende soorten emulatie. Als je x86 op ARM probeert te emuleren, is de performance inderdaad niet zo goed. En andersom ook. Maar ook op x86 worden sommige zaken geëmuleerd, en daar merk jij niets van. En als je een VM draait, dan kan dat ook alleen met emulatie. Die emulatie is alleen zeer beperkt, omdat 99.9(9?)% van de instructies niet geëmuleerd hoeven worden, en gewoon op 100% snelheid lopen. En wat dan wel geëmuleerd wordt, zijn voornamelijk zaken die alleen een OS gebruikt, niet een applicatie.

[mjansen2016]

Qua games heeft het dan nog wel zijn charme voor die nostalgische momenten een van je oude builds intact te houden maar wel zover pushen als het kan. Als ik de afgelopen 35 jaar terugkijk baal ik wel van de systemen die ik als afgeschreven weggegeven of weggegooid heb. Ik heb dus over enkele jaren een hele berging vol met systemen.

[bzuidgeest]

Dan doe je dat voor niets:

The 64-bit versions of Windows use the Microsoft Windows-32-on-Windows-64 (WOW64) subsystem to run 32-bit programs without modifications. The 64-bit versions of Windows don't provide support for 16-bit binaries or 32-bit drivers

Die ouwe apps lopen al lang en breed door een extra laagje heen op een moderne windows.

[Loller1]

Dat lijkt me niets. Ik heb nog genoeg Win32 applicaties waaronder games. Emulatie gaat altijd ten koste van performance en (energie) efficiëntie. Dus ik zal graag voor een x86-64 processor blijven kiezen met zowel IA32 als x64 ondersteuning.

Ik veronderstel dat je een 64bit versie van Windows gebruikt, in welk geval ik nieuws heb voor je: iedere 32bit applicatie die je hebt is nu al geëmuleerd. Altijd al zo geweest, sinds XP 64bit ondersteuning introduceerde.

Dat gezegd hebbende Win32 is niet hetzelfde als 32bit. Win32 is een API.

[beerse]

Voor de desktop zie ik nog genoeg beren op de weg. Volgens mij is er nog heel veel 32 bits software in gebruik. En om daar nu allemaal virtualisatie voor in te zetten... Misschien een 'wsl' achtige constructie.

Voor de server zie ik hier zeker wel voordelen. Misschien gaat het daarna richting een itanium structuur: echt helemaal 64 bits. Dat scheelt op de cpu-die vast de nodige ruimte.

En over de 32 bits software in virtualisatie: Zou Hyper-V, VMware, xen, kvm en dergelijke dat dan afvangen/invullen? Of zou het met de desktop ook via 'wsl'-achtige constructies kunnen?

[graey]

Er is geen 32 bit x86 hardware te koop, Windows is alleen nog 64 bits te krijgen, en 32 bits Windows software draait al jaren op een virtualisatielaagje dat al beschikbaar is sinds de XP-tijd. Een paar lagen legacy weghalen is alles wat nodig is voor x86 om volledig 64 bits te worden, en dat is wat dit beschrijft. Het valt wel mee met al die beren

[Arrigi]

Alle huidige x86-64 HW is ook 32-bit. Je kan er (in principe, HW-support daargelaten) native 16-bit DOS uit de jaren 80 op draaien.

Dat "virtualisatielaagje" (dat WoW64 noemt) draait als het mogelijk is de 32-bit software gewoon native als 32-bit op de CPU en virtualiseert als het moet. De CPU kan gewoon tussen modes wisselen. Of je dat toevalligerwijze ook virtualiseren kan noemen weet ik niet. Een andere instructieset draaien (zoals 32-bit x86 op ARM of 32-bit x86 op een "x86-64-S" noemen we gewoon emuleren.

Dus het kan best meevallen met die beren, maar dat je tegenwoordig alleen maar pure 64-bit code draait is nu ook weer niet helemaal waar.

[Reactie gewijzigd door Arrigi op 23 juli 2024 16:16]

[bzzzt]

Voor veruit de meeste eindgebruikers is dat wel het geval. Windows, browser, office en misschien nog wat populaire tools zijn vrijwel altijd 64 bits. (hey, x64 Windows wordt 18 dit jaar, mag ook wel eens)

Wat je dan overhoudt is een kleine groep gebruikers die of heel erg gehecht zijn aan software die ze meer dan een decennium geleden hebben aangeschaft of bedrijfsgebruik waarbij het niet triviaal is te upgraden. Voor zulke niches hoef je niet 100% van de gebruikers van een oplossing te voorzien. De overlap met bv. performance jagers (gaming, ML) zal nagenoeg 0 zijn.
Misschien kan Intel (voor veel geld) nog wel wat 32-bits compatible chips slijten voor de gevallen waarin daar serieus vraag naar is.

[sfranken]

Je moet eens kijken welk percentage van het office pakket 64 bit is, dat zou je verbazen. Veel daarvan (en veel installaties) zijn 32 bit. Maar goed, 32 bit software blijft gewoon werken, het draaien van 32 bit OS'en word moeilijk, maar goed, het is 2023, kom op...

[bzzzt]

Mijn impressie was toch echt dat recente versies van MS Office volledig 64 bits zijn. Natuurlijk zijn er nog mensen die oude versies hebben, maar zijn dat echt actieve gebruikers en kunnen die niet over wanneer hun hardware het begeeft?

[_JGC_]

Office zelf is 64 bit. Maar een klant van me heeft een CRM pakket die inhaakt op Office met een plugin, en laat die plugin nou 32bit zijn en niet werken met een 64bit versie van Office. Dus die klant draait Office365 32bit.

[bzzzt]

Ok, maar dat is de situatie nu omdat het werkt. De bouwer van dat CRM pakket kan dat gewoon fixen als het niet meer werkt. Zo niet, tijd voor een nieuw CRM pakket.

[joker1977]

Ja, zo geredeneerd kun je alles naar 64-bits migreren.

"Ach als die oude legacy opstelling met CNC-bank van 2 ton niet meer werkt met 64-bits Windows, tijd voor een nieuwe"

Mag aankomende woensdag nog naar een bedrijf om een oude legacy meet-bank waarop een 16-bits Windows applicatie de boel draaiende houdt. Software is allang EOL, maar geen opvolger beschikbaar. Geschatte kosten om weg te migreren: Meer dan een ton én een beste knal downtime. Tuurlijk, had veel eerder gemoeten, maar "zo lang het draait" is de filosofie die je toch nog steeds veel ziet, zowel bij kleine ls grote bedrijven.

[Madshark]

Ik ken het.
Heb ergens nog een gigantische lasersnijmachine van €12m in een soort van beheer. Ding draait nog Windows NT 4.0, de software en de hardware (een soort van PLC controller in een ISA slot) is alleen NT4 compatible.
Hij is verder wel airgapped, heeft geen ethernet, geen USB, alleen een 3.5" floppy drive waar een paar keer per jaar een bestandje van wordt ingelezen.

De fabrikant gaat/kan dit alleen upgraden als men de gehele aansturing vervangt, dat is zowat de halve machine.
Kost €2.5m, en als je dan aan het management moet uitleggen dat de machine er niet sneller/beter/nauwkeuriger op wordt, dan is dat lastig te verkopen.

[bzzzt]

En als die machine nou spontaan de geest geeft?
Je kan gewoon aan management doorgeven dat de machine dan X weken uit de lucht is en als dat goed gevonden wordt is dat geaccepteerd risico.

[Madshark]

En als die machine nou spontaan de geest geeft?
Je kan gewoon aan management doorgeven dat de machine dan X weken uit de lucht is en als dat goed gevonden wordt is dat geaccepteerd risico.

Voordeel van dat industrieel spul is dat ze altijd wel erg lang de spareparts op voorraad houden.
Sowieso heb ik zelf al, ingeval van nood nog 2 reserve computers incl controller kaart liggen. Maar het huidig support/onderhoud contract voorziet ook dat de fabrikant nog steeds alle onderdelen op voorraad heeft. Wel heb ik de HDD vervangen voor een DOM, voor de rest is het eigenlijk inderdaad oude legacy rommel. Maar super stabiel (heeft wel eens uptimes gehad van >1200 dagen)

[bzzzt]

Toch ga je daar op een bepaald moment wel problemen krijgen. De vervanging die je neerzet is niet nieuwer dan de hardware die je vervangt. Ligt helemaal aan de bouw van zo'n machine of je 10 of 20 jaar haalt, maar het volgende defect komt op een bepaald moment steeds sneller.
De directeur rijdt z'n auto ook niet 20 jaar lang compleet af omdat het goedkoper is...

[Xander2]

Kost €2.5m, en als je dan aan het management moet uitleggen dat de machine er niet sneller/beter/nauwkeuriger op wordt, dan is dat lastig te verkopen.

Dat is heel simpel, je hebt minimaal 2x werkende legacy pc onderdelen nodig als je wilt dat het blijft werken.

Nieuwe hardware biedt totaal geen garantie dat oude software werkt, vaak doen b.v. die DB25 dongle drivers rare dingen.

[curkey]

Het is gewoon uitgesteld onderhoud. Uiteindelijk ga je een keer de downtime moeten pakken, alleen zal het dan misschien op een erg slecht moment gebeuren. Ik snap prima dat je op stel en sprong niet zomaar 2.5M bij elkaar gesprokkeld hebt, maar ze hadden het wel op een meerjarig spaarplan kunnen zetten met een stip op de horizon. Tenzij ze weten dat die machine met een paar jaar volledig afgeschreven wordt en dan vervangen.

[bzzzt]

Zo lang je die hardware (al dan niet met spares) aan de gang kan houden is er niet zoveel aan de hand.
Tot iemand "handig" een netwerkstekker inplugt en die oude meuk onderuit gaat vanwege malware oid...

[gooos]

Een air-gapped productiemachine vind ik persoonlijk wel een andere categorie dan een CRM wat ook interactie met andere software oplossingen kent. Die bouwers van de CRM zijn in mijn ogen gewoon lui geweest om niet mee te ontwikkelen met de tijd. Het is niet zo dat de overstap naar 64-bits only niet al jaren in de lucht hangt.

[gooos]

Of... op tijd een voorraad reserveonderdelen in slaan om het nog een tijd uit te kunnen houden met die oude CNC-bank (of welk ouder apparaat dan ook).
Heet in mijn beleving risico management.

[field33P]

“Tijd voor een nieuw <X> pakket” is wat zo vaak gezegd wordt maar bij de meeste bedrijven krijg je er geen budget voor “want het werkt toch gewoon?”

Tot het opeens niet meer werkt, natuurlijk.

[mjansen2016]

Bouwer is ermee gestopt, vervangend pakket bestaat op dat moment niet en een ontwikkelaar moet nog gevonden worden, en dan moet er ook nog onderhandeld worden over een prijs. Genoeg reden die zomaar kunnen vereisen om iets 5 jaar draaiende te houden.

Idem met antieke hardware- en software combinaties, vaak industrieel waar men nooit aan een supportcontract of upgradepad heeft gedacht...

Komt vaker voor dan je in eerste instantie zou vermoeden.

[bzzzt]

Klopt, maar zeker voor nieuwe apparatuur zou je toch enige realiteitszins over de support termijn van soft- en hardware aanwezig mogen verwachten...

[devices]

Mijn werkloptop (nu 2 jaar oud) heeft gewoon Office als 32-bit draaien. In de Task Manager heet het "Microsoft Excel (32 bit)" en "Microsoft Outlook (32 bit)". Ook in de software zelf staat dat het 32-bit betreft. Deze versie komt zo te zien uit september 2022.

[bzzzt]

Daar moet je bij de laatste versies bewust voor kiezen. Office 365 kan je prima als 64 bits app installeren.

[Gallo_Claudio]

Is dat zo? Mijn Office 2021 installatie was na een default install 32 bit. Ik heb specifiek de install64 moeten kiezen om de 64 bit versie te krijgen. Vanwege allerlei macro's en plugins geen 365 gekozen trouwens.

[curkey]

Langzaamaan komen er wel meer 64 bits plugins, dus wellicht wat support calls inschieten naar de vendor dat ze iets moeten verzinnen.

Ikzelf gebruik veel SAP tools, en daar zijn de Analytics tools inmiddels wel te gebruiken in een 64 bits office. Grotere files zijn dan ineens mogelijk, wat voor analytics toepassingen wel erg fijn werken is.

[sfranken]

Er zijn recente versies van MS Office die 64 bit zijn ja, maar zover ik weet is de "default download" die je vanuit MS krijgt nog steeds een 32 bit versie.

[bzzzt]

Niet volgens MS: https://support.microsoft...95-4d0c-b5fe-6c6f49b8d261

[sfranken]

Ah, mooi dat dat sinds MS365 aangepast is. De laatste Office versie die ik grootschalig heb uitgerold was 2016, daarna geen MS product meer aangeraakt.

[batjes]

Office 16 default install locatie is nog altijd naar program files x86.

Maar blader er even doorheen, je struikelt over de 32bit dlls.

[beerse]

Daar zat mijn gedachte ook. Voor office2016 weet ik zeker dat er nog issues waren tussen 32bits of 64 bits excel en dat de meeste gebruikers (de standaard) 32 bits draaiden. Dat had iets met compatibiliteit te maken, een term die in op het wintel platform 'heilig' is.

[graey]

True, maar zelfs zonder mode switching op pure 64 bits x86 silicon zal WOW64 minder zwaar zijn dan bijv. ARM emuleren, of de WOW64-laag die in Windows voor Itanium zat. De instructies zijn er allemaal nog, ze eten alleen allemaal 64 bits waarden ipv 32 bits waarden (simpel gezegd). Dus zelfs als je het emulatie zou noemen, dan is het nog steeds een kwestie van dezelfde instructies in dezelfde volgorde uitvoeren.

[leonbong]

Itanium instructies zijn 64 bits, echter hebben totaal niks te maken 64Bitsx86 instructies.

Itanium heeft een totaal andere instructieset dan x86.

[graey]

Dat zeg ik toch ook? WOW64 op Itanium is zwaarder dan op x86-64 en ook op deze nieuw voorgestelde x86-s, net als x86-emulatie op ARM zwaarder is, omdat alle x86-families dezelfde 'taal' spreken, los van het 'bitdialect'.

[dmantione]

Er is nog heel veel 32-bit code en ook 16-bit code bestaat nog. Maar... 32-bits besturingssystemen worden niet vaak meer geïnstalleerd. Dit gaat enkel over het besturingssysteem, 32-bit software blijft de processor gewoon ondersteunen.

16-bit software kan als het besturingssysteem de processor in 64-bit mode gebruikt nu al niet meer worden uitgevoerd, maar het kan toch weer wel door middel van virtualisatie en ook dat blijft in dit voorstel gewoon mogelijk. Bovendien heb je ook emulatie in je gereedschapskist: Veel DOS-software draait gewoon het beste onder DOSbox, omdat er in al die tijd véél meer aan een PC is veranderd dan de processor alleen.

Kortom, ik ben niet zo bevreesd over het draaien van oudere software. Wil je Windows 95 installeren, ja dan ben je in de toekomst aan software als VMWare overgeleverd, maar Office 97 draaien op een moderne Windows zal nog steeds tot de mogelijkheden behoren.

[TheVivaldi]

Dat ook. En daarnaast moet iemand ook gewoon een keer de stap zetten, anders komen we nooit van x86 af.

[RoestVrijStaal]

Dat ook. En daarnaast moet iemand ook gewoon een keer de stap zetten, anders komen we nooit van x86 af.

Dat zijn we bijna.

x86 is al door ARM ingehaald als het meest gebruikte CPU architectuur.

Zowat alle merken smartphones hebben een ARM CPU, de nieuwste desktop en laptops van Apple hebben enkel een ARM CPU.

[YGDRASSIL]

75 procent van de desktops draait windows dus dat apple op ARM over is betekend niet dat we al 'bijna van x86 af zijn'

https://www.statista.com/...arket-share-of-windows-7/

[Alfa1970]

Dit is zo'n verschrikkelijke non-discussie.
What aboutism.

Dat er een nieuwe CPU met een nieuwe architectuur komt betekend niet dat de oude CPU's niet meer gemaakt worden, of heaven forbid ineens met een donderklap van de aardboden verdwenen zullen zijn.

Kijk eens naar de Zilog Z80 CPU, die wordt 47 jaar na introductie nog steeds geproduceert.
Kijk eens naar de Intel 8086 CPU, die wordt 45 jaar na introductie ook nog steeds geproduceert door Intel.

Zo lang de vraag er is, zal het product gemaakt blijven worden.
Echt een volledig non-probleem..

[Goz3rr]

De 8086 word al sinds 1998 niet meer door Intel gemaakt

[youridv1]

Uh, de functionaliteit die jij omschrijft zit bij mijn weten gewoon in Windows gebakken en vereist nul extra werk van de gebruiker. Daarmee heb je 99% van de desktop markt gevangen.

[beerse]

Dat is juist het issue hier: het zit in windows omdat het er altijd al in zat. Het wordt nu nog door de hardware ondersteund en dus werkt het nog. Maar het nieuwsbericht meldt dat de hardware ondersteuning er uit gaat. Dat zaagt toch wel een poot onder de functionaliteit weg. Daar moet dan wat aan gedaan worden.

[youridv1]

En dit is een probleem omdat? Deze architectuur is er helemaal niet en WOW64 heeft hetzelfde probleem al een keer eerder opgelost voor itanium. Zo is er bijvoorbeeld ook wow64 voor x86 op arm32.

[Reactie gewijzigd door youridv1 op 23 juli 2024 16:16]

[Zer0]

In plaats van naar beren kijken wellicht het artikel lezen...
De wijzigingen zouden alleen impact hebben op het gebruik van dergelijke besturingssystemen; 32bit-applicaties zouden wel blijven werken.

[Loller1]

Je weet dat Windows al sinds XP 64bit een 32bit emulatie toepast voor 32bit applicaties? En lees het artikel eens een keertje.

[Reactie gewijzigd door Loller1 op 23 juli 2024 16:16]

[Omega]

De bestaande 32-bit software blijft functioneren door het te draaien via een compatibiliteitslaag/emulator. Mensen die bekender zijn met dit onderwerp dan ik zij vrij om mij te corrigeren; volgens mij is dit al precies wat WOW64 doet onder 64-bit Windows.

Dit houdt puur in dat het systeem niet langer 32-bit software kan opstarten of rechtstreeks kan uitvoeren.

[dmantione]

Zelfs rechtstreeks uitvoeren blijft mogelijk (32-bit, niet 16-bit). Er verandert aan applicatiezijde niets. Het is het besturingssysteem dat niet langer 32-bit kan zijn.

[Dutch2007]

Wsl gebruikt al hyper-v voor Android en Linux sub-system

[Blizzard_1978]

Niet echt heb hier wsl draaien en geen hyper-v, ze gebruiken we hetzelfde virtualisatie sub-systeem denk ik.

[Dutch2007]

Wsl1 of wsl2?

Wsl 2 draait nml als een vm

https://learn.microsoft.c...dows/wsl/compare-versions

[Reactie gewijzigd door Dutch2007 op 23 juli 2024 16:16]

[Blizzard_1978]

WSL2 en geloof me geen hyper-v geinstaleerd

[Dutch2007]

Wsl2 gebruikt onderwater hyper-v, dat wil niet zeggen dat je elk onderdeel van hyper-v geïnstalleerd hebt staan.

Als je alleen de hyper-v management toolkit zou installeren, zal je de vm die voor subsystemen for linux gebruikt wordt, ook gewoon zien (en kan je ook de vm aanpassen van Nat naar bridge e. d.)

[Blizzard_1978]

Niet helemaal correct wsl2 gebruikt het zelfde vitualisatie subsystem als hyper-V.
kijk maar in je features daar zal je een apart virtualisatie system terugvinden dit is waar ook hyper-V op draait. En ook met de hyper-V MT zie ik wsl-vm niet terug komen.

[killerdemon]

Itanium is vooral een versimpelde instructieset en bespaart daarom ruimte.

[xorpd]

Niet echt, Itanium is namelijk geen RISC maar een VLIW, met 128-bit instruction bundles (die weer bestaan uit 3x 41-bit instructies plus 5 control bits).

[vinkjb]

Misschien is dat opzich wel handig maar als ik naar mezelf kijk heb ik nog wel genoeg programmaatjes die alleen in32b verkrijgbaar zijn voor me rc_hobby. Regelaars die ik met programmaatje aan usb kast kan hangen.

[PvdVen777]

En die blijven met de huidige opzet (WOW32) gewoon werken zo begrijp ik.

[wildhagen]

Kleine nuancering: WOW32 heeft nooit bestaan. Je had wel WOW (Windows on Windows), die maakte het mogelijk om 16-bits applicaties op een 32-bits OS te draaien. Deze WOW-techniek bestaat al sinds 1993 en werd in Windows NT 3.1 (de eerste Windows NT-versie, en de oervader van de huidige Windows 10/11 etc) geintroduceerd.

Maar deze WOW is inmiddels uitgefaseerd, en zit niet meer in het OS sinds Windows 11, daar die alleen nog een 64-bits versie kent en geen 16-bits applicaties meer ondersteunt. Dus WOW werd overbodig,

Ter verduidelijking: die 16-bits applicaties stammen dus nog uit de Windows 3.x tijd. Die apps zullen er niet veel meer zijn.

Wat jij bedoelt is WOW64, die in oktober 2001 werd geintroduceerd (in Windows XP). Die maakt het mogelijk om 32-bits applicaties te draaien onder een 64-bits Windows versie. WOW64 is dus nog altijd aanwezig, ook in Windows 11 en Windows Server 2022.

Dit is dus de reden dat er een C:\Windows\SysWOW64 directory op je systeem bestaat. Waar je overigens vooral vanaf moet blijven.

[Reactie gewijzigd door wildhagen op 23 juli 2024 16:16]

[WoutervOorschot]

En dat is (volgens mij) ook de reden dat 32bit emulatie direct in windows on arm beschikbaar was, en 64 bit emulatie tot windows 11 heeft geduurd. Gezien 32bit emulatie al in windows zat, maar 64bit emulatie nog niet.

SysArm32 bestaat overigens ook op arm-windows-installaties, het bevat de bestanden voor arm32 emulatie (volgens mij alleen enkele windows 8 apps voor de originele surface en surface 2).

[.oisyn]

Maar deze WOW is inmiddels uitgefaseerd, en zit niet meer in het OS sinds Windows 11, daar die alleen nog een 64-bits versie kent en geen 16-bits applicaties meer ondersteunt.

Kleine toevoeging, 16-bits modus binnen een 64-bits long modus is nooit mogelijk geweest op de x86-64 architectuur. Daarom ondersteunden de 64-bit Windows OS'en dit nooit, omdat het gewoon niet mogelijk was (tenzij je volledige ISA emulatie gaat doen oid). Vanuit 32-bits protected mode is er wel een 16-bits compatibiliteitsmodus, maar die verdwijnt in dit voorstel uiteraard.

[vinkjb]

Ja die zouden moet blijven lees ik nu, iets te snel doorheen gescrolled met me ogen..oops

[M3m3nt0m0r1]

De wijzigingen zouden alleen impact hebben op het gebruik van dergelijke besturingssystemen; 32bit-applicaties zouden wel blijven werken.

Dit staat letterlijk in het artikel. Programma's blijven werken. Alleen de 32bit OS versie niet meer.

[Astennu]

Het zal vast te emuleren zijn en anders houd je er toch een oude laptop naast om dit soort applicaties op te draaien? Ik heb ook nog een oude Windows 95 laptop liggen met een oude Pentium 1 er in als ik me niet vergis.

Ze moeten een keer iets. Het is zonde om die oude instructies te behouden terwijl 99% van de mensen het niet meer gebruikt. Dat is gewoon niet efficient. Dan kan je het beter gaan emuleren of zeggen gebruik onze wat oudere hardware maar waar het nog wel op kan. Ze zouden er mocht de vraag groot zijn er dan voor kunnen kiezen om de laatste generatie CPU's die het nog wel ondersteund wat langer te blijven produceren en wat langere support te geven om die klanten te bedienen. De hardware van vandaag de dagen is toch meer dan snel genoeg voor dat soort oude applicaties over 5-10 jaar is die nog steeds snel genoeg voor dat soort applicaties.

[PvdVen777]

Dus Intel wil hun CPU's gaan uitvoeren met enkel nog AMD-64 instructieset !?
Dit is ongeveer net zo ironisch als toen ze AMD integrated graphics toepasten.

[beerse]

Bedenk dat je dan een amd cpu zou moeten gebruiken om 32 bits wintel-compatibiliteit te krijgen

[itContinues]

Ik dacht hier ook direct aan idd.
How the turns have tabled.
Misschien herinner ik het me verkeerd, maar kon AMD door deze cross-licentie niet fabless gaan omdat ze eerst het vereiste hadden om eigen fabs te draaien?

AMD64 heeft dan namelijk niet alleen tot Global Foundries geleid, maar ook tot het huidige succes van AMD met Zen omdat ze hierdoor helemaal wegkonden bij GF en hun productie via TSMC kunnen doen.

De laatste grap die ik nog zie plaatsvinden in de toekomst is dat Intel AMD CPU's gaat bakken in hun fabs.

[Toettoetdaan]

32-bit instructies blijven gewoon. Het gaat echt om legacy features die een 16-bit of 32-bit OS nodig heeft. Bij veel van die zaken kun je je afvragen of het de transistors waard is en daar bovenop zijn enkele features zelfs een veiligheid risico.

[Z80]

Dit is poging twee van de geflopte Itanium.

[computerjunky]

Onder de streep zal dit Windows natuurlijk een stuk eenvoudiger maken. Maar als ik even kijk naar al mijn programma's dan is 70+% toch echt nog 32 bit. Dit zijn voornamelijk kleine applicaties waar gewoon nog geen valide alternatief voor is. Veelal omdat alternatieven vol bloat zitten. Of gewoon niet zo goed zijn als gespecialiseerde applicaties.

Ik zit dus ondanks dat het positieve kanten kan en zal hebben helemaal niet te wachten op 64 bit only.
Nou kan je natuurlijk met VM gaan klooien maar dan doe je effectief gewoon een stap terug ipv vooruit.

[-=bas=-]

Kunnen we die 32bit ondersteuning niet gewoon emuleren?

[JeroenED]

Dit gebeurt al gewoon. Dit heet WoW64 (https://en.wikipedia.org/wiki/WoW64). De OP heeft het verkeerd dat dit windows eenvoudiger zal maken. Windows is al 64-bit only. Het is nu gewoon de hardware die de evolutie van de software volgt. Dit heeft enkel impact op besturingsystemen, niet op programma's.

Het enige wat dit volgens mij tot gevolg zal hebben is dat nu verschillende developers die vasthouden aan 32-bit (om welke krankzinnige redenen dan ook), mogelijks nu ook overstag gaan en Microsoft WoW64 iets rapper dan voorzien (als dat er al is) kan afschrijven.

[computerjunky]

Dat zal vest kunnen. Dat doen we nu ook al met 16 bit geloof ik. Maar dat maakt de applicatie er niet sneller en beter op.
En ik kan me voorstellen dat met audio applicaties waar latency best wel een dingetje is dat niet een wenselijke optie is.

Als ik kijk naar bijvoorbeeld een switch emulator op de pc en hoeveel rekenkracht dat kost ten opzichte van de rekenkracht van een switch dan is de overhead voor emulatie echt enorm.

[graey]

Daar wordt echter een volledig andere architectuur geemuleerd, in het geval van de switch ARM. Dat is echt appels en peren in dit geval, waarbij de ISA nog steeds heel erg gelijk opgaat met de oude x86. Op applicatieniveau sowieso al geen problemen met compatibiliteit (check ook WOW64 voor hoe Windows dit al tijden doet voor 32 apps op 64 Windows), op OS niveau zou je een 32 bits versie van XP of Windows 7 moeten virtualiseren, maar daar zal los van de bootcode weinig emulatie voor nodig zijn.

[DonCortizone]

Als jij nog 32 bit applicaties draait dan stammen die uit de oertijd (van voor 2009, windows 7). Gezien de hardware evolutie zou de vertraging die je vreest toch ruimschoots gecompenseerd moeten worden.

[Arrigi]

Ik heb op m'n werklaptop die ik nog geen jaar heb eens gekeken. Chrome 113 van 3 mei 2023: 32-bit. En nog een paar kleine dingetjes. Maar die Chrome valt wel op, temeer omdat hun support voor alles ouder dan windows 10 ook al weg is.

Ik heb op MacOS door de jaren heen al heel wat nieuwe tools moeten zoeken (als ze al bestonden) omdat de 32-bit support verdween. Enkele Steam games zijn bvb enkel als 32-bit executable beschikbaar.
Zal binnenkort nog eens gebeuren, dat Intel-binaries niet meer ondersteund worden.

Zie dit bvb, iemand anders die soortgelijke problemen tegenkomt: https://www.macfreak.nl/m...or-road-trip-effects-pro/

[bzzzt]

Dat zal vest kunnen. Dat doen we nu ook al met 16 bit geloof ik. Maar dat maakt de applicatie er niet sneller en beter op.

Maar waarom is er nog geen 64 bits versie van een applicatie als die 'sneller en beter' zou moeten zijn?
Je kan niet verwachten dat de hele wereld moeilijk gaat doen om een enkele 32 bits applicatie waarvan de makers zelf al gestopt zijn met support te kunnen blijven draaien.

[gast128]

Maar waarom is er nog geen 64 bits versie van een applicatie als die 'sneller en beter' zou moeten zijn?

Ik heb zelf nogal wat oudere games (e.g. Fallout 3; Skyrim; STALKER) die 32 bits zijn en die niet zomaar opnieuw gecompileerd worden. Zelfs Microsofts Visual Studio 2019 alsmede Office 2016 is nog 32 bits.

Dit voorstel gaat overigens alleen om een aantal weinig gebruikte features te verwijderen (e.g. boot in real mode; ring 1 en 2) waardoor het OS alleen nog maar 64 bit kan zijn. 32 bits applicaties zullen nog steeds kunnen draaien.

[Reactie gewijzigd door gast128 op 23 juli 2024 16:16]

[bzzzt]

Uiteindelijk zal je dat soort titels ook gewoon kunnen emuleren.

[Eikeltje]

Omdat een 64 bits applicatie niet sneller en zelfs langzamer kan zijn dan dezelfde applicatie gecompiled in 32 bits.

[RJG-223]

Maar waarom is er nog geen 64 bits versie van een applicatie als die 'sneller en beter' zou moeten zijn?

Omdat 32-bit applicaties soms juist sneller zijn, en minder geheugen gebruiken dan 64-bits applicaties.

En als je een 32-bit applicatie hebt, die prima functioneert, en niet extreem veel geheugen nodig heeft of zo, waarom zou je dan moeite gaan doen hem naar 64-bits te porten ? Je hebt nul voordeel, en alleen maar veel extra werk, en het risico op nieuwe bugs, of bestaande 'theoretische' bugs die met 32 bit niet optraden, een geen probleem vormden, en nu ineens echte bugs worden.

[bzzzt]

Dat is complete kul. Dan moet je voor iedere applicatie een volledige compatibiliteitslaag voor de 'ideale' architectuur onderhouden terug tot de eerste computer. Dat zou pas een kolossale verspilling van resources zijn.

Er is geen enkele reden dat 32-bits applicaties per definitie beter performen. De meeste CPU-gebonden software (compressie, encryptie etc) is juist een fractie sneller op x64 door de grotere registers. Grotere pointers kunnen zorgen voor een iets hoger geheugengebruik, maar door de grotere adresruimte is het dan weer makkelijker 'random' adressen te pikken en minder gevoelig te zijn voor bepaalde brute force exploits. Bovendien zijn er manieren deze overhead wat te drukken voor als het echt pijn doet (Java VMs hebben een heel interessante 32-bits object-id naar 64-bits pointer mapping).
Die 'theoretische bugs' treden zowiezo wel op op nieuwe architectuur omdat de onderliggende microcode van de huidige CPU families iedere generatie wordt omgegooid...

[RJG-223]

Dat is complete kul

Misschien kun je zorgen dat je enigszins geïnformeerd bent voordat je iets wat iemand zegt als 'complete kul' bestempelt ?

En dan bevestig je zelf ook nog eens deels wat ik zeg:

Grotere pointers kunnen zorgen voor een iets hoger geheugengebruik

En dat hoger geheugengebruik kan ook weer zorgen voor een langzamer programma !

En dan heb je het ook nog over truukjes om het nadeel van 64-bit pointers te omzeilen, waarbij je wederom bevestigt dat er een nadeel is:

Bovendien zijn er manieren deze overhead wat te drukken voor als het echt pijn doet

Als laatste:

Die 'theoretische bugs' treden zowiezo wel op op nieuwe architectuur omdat de onderliggende microcode van de huidige CPU families iedere generatie wordt omgegooid...

Inderdaad. En dus moet er een goede zakelijke reden zijn om die investering te doen. En met een 32-bit x86 applicatie die in 32-bit modus prima loopt, is die reden er niet.

Edit: Dat laatste had ik niet goed genoeg gelezen. Niet dat het uitmaakt: Het is algemeen bekend dat het porten van een applicatie van bijv. 32 bit naar 64 bit voor enorme problemen kan zorgen, omdat sommige datatypes (en in ieder geval pointers) een andere grootte krijgen. In het ergste geval moeten zelfs de (binaire) bestandsformaten van de applicatie aangepast worden. Dat levert allerlei bugs op in de applicatie. Jij hebt het over bugs in de processor, cq in de nieuwe microcode. Daarvoor kan de fabrikant een update uitbrengen. Dat is niet hetzelfde als een bug omdat bijvoorbeeld een pointer in de applicatie ineens niet meer in 32 bits past. En dan heb ik het nog niet eens over de mogelijke problemen door de verschillen tussen 64 bit OS APIs en 32 bit OS APIs

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

[bzzzt]

[...]
En dat hoger geheugengebruik kan ook weer zorgen voor een langzamer programma !

Wat compleet ge-offset wordt door de hogere verwerkingssnelheid in de meeste gevallen.

En dan heb je het ook nog over truukjes om het nadeel van 64-bit pointers te omzeilen, waarbij je wederom bevestigt dat er een nadeel is

Omdat je er werk voor moet doen om een bepaalde efficiency (als die er toe doet) te houden betekent niet dat je efficiency per definitie verloren gaat.

Edit: Dat laatste had ik niet goed genoeg gelezen. Niet dat het uitmaakt: Het is algemeen bekend dat het porten van een applicatie van bijv. 32 bit naar 64 bit voor enorme problemen kan zorgen, omdat sommige datatypes (en in ieder geval pointers) een andere grootte krijgen. In het ergste geval moeten zelfs de (binaire) bestandsformaten van de applicatie aangepast worden.

Je kan ook overal beren zien. Als je 'gemakshalve' geheugenblokken naar schijf schrijft en terugleest (wat tegenwoordig qua security echt een no-no is) moet je misschien iets meer werk doen, maar vrijwel iedere applicatie is dat nivo al lang ontgroeid.
Je kan ook prima een importer bouwen voor oude binaire formaten.
Als je ziet hoe snel OSen en hele Linux distributies omgebouwd zijn naar x86-64 lijkt het me duidelijk dat dat prima mogelijk is en ook geen buitensporige reeks bugs opgeleverd heeft.

[gast128]

Omdat 32-bit applicaties soms juist sneller zijn, en minder geheugen gebruiken dan 64-bits applicaties.

Microsoft had in 2009 een aantal redenen om Visual Studio nog niet in 64 bit mode aan te bieden. 64 bit pointers met bijbehorende hogere druk op de (beperkte) cache was daar een van. Met VS2022 maken ze deze stap wel.

Mijn eigen ervaring is dat 64 bit code wel iets sneller is (e.g. door meer registers en long long past erin). E.e.a. hangt af van de applicatie uiteraard. Alexandrescu beweerde in een van zijn video's dat ontwikkelingen op de CPU alleen nog maar op het 64 bit code pad plaatsvinden.

[RJG-223]

Mijn eigen ervaring is dat 64 bit code wel iets sneller is (e.g. door meer registers en long long past erin). E

Het is (op de x86 architectuur) ook mogelijk om code te draaien met een 32bit adresruimte, maar wel alle 64bit registers en instructies. Dat schijnt een significante verbetering op te kunnen leveren tov volledig 64 bit.

Windows ondersteunt dit overigens niet, zover ik weet.

[Croquetten]

Even een vraagje, hoe goed is een Switch emulator eigenlijk?
Ik heb zelf 2 weken geleden CEMU gedownload, dat is een een emulator voor Wii U.
Ik heb zelf nog een Wii U die staat te verstoffen en ik vind persoonlijk dat CEMU veel mooiere beelden emuleert dan de originele Wii U, tenminste als je over een notebook of pc met de juiste specs bezit.
Een Switch emulator heb ik nog niet geprobeerd omdat ik zelf geen Switch bezit en dus ook niet fysiek de spellen in bezit heb.

[The Zep Man]

Onder de streep zal dit Windows natuurlijk een stuk eenvoudiger maken.

32bit-applicaties zouden wel blijven werken. Dat komt overeen met de functionaliteit van huidige besturingssystemen, schrijft Intel. Microsoft bracht bijvoorbeeld alleen een 64bit-versie van Windows 11 uit, maar die versie ondersteunt nog steeds 32bit-software.

Dit doet niets met Windows. x86-S processors kunnen 32-bit code in een 64-bit besturingssysteem draaien. Wat Intel wegneemt is de mogelijkheid om een puur 32-bit OS te draaien.

Dus geen zorgen. Je kan TempleOS sowieso gewoon nog draaien, want die is 64 bit.

Iets serieuzer:
Ik denk niet dat men hierdoor veel moet missen. Voor 64-bit UEFI-only systemen (afwezigheid van compatibility support module (CSM)) is het sowieso al gebruikelijk om een 64-bit OS te draaien omdat 32-bit in deze situaties geen enkel voordeel biedt. Gevirtualiseerd kan men ook 32-bit besturingssystemen draaien, dus ook het draaien van 99,998% van het oude spul onder oude besturingssystemen zal geen probleem zijn.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 16:16]

[Terry A Davis]

Op TempleOS kan je zelfs DosBox in ELF format draaien, daarop kan je standaard weer Windows 3.11 of Windows 95 en 98 draaien, met S3 video drivers.

Hier een demonstratie waar TempleOS een ELF64 binairy van DOOM runt.
https://www.reddit.com/r/...r/templeos_now_runs_doom/

Dank aan @MatiasG voor het plaatsen op Reddit.

Holy C van TempleOS ondersteunt nu sdl2 library

Nu is het mogelijk eveneens andere elf64 binary's te draaien.
https://wiki.osdev.org/ELF

[M3m3nt0m0r1]

De wijzigingen zouden alleen impact hebben op het gebruik van dergelijke besturingssystemen; 32bit-applicaties zouden wel blijven werken.

Staat letterlijk in het artikel. Programma's blijven dus gewoon werken.

[redfightjuh]

De wijzigingen zouden alleen impact hebben op het gebruik van dergelijke besturingssystemen; 32bit-applicaties zouden wel blijven werken.

Zoals ik het hier lees is er niks aan de hand.... of zie ik dit verkeerd?

[RJG-223]

Zoals ik het hier lees is er niks aan de hand.... of zie ik dit verkeerd?

Wel voor de mensen / bedrijven die besturingssystemen schrijven, of die BIOSen schrijven. En vermoedelijk voor hardware met 16/32-bit firmware (als dat nog bestaat).

[ikt]

Het heeft weinig met Windows te maken - het gegoochel met System32 (voor 64-bit systeem dingen), SYSWOW64 (voor 32-bit syteemdingen) en "Program Files (x86)" (voor 32-bit applicaties) blijft gewoon, want dit zijn Microsoft-keuzes

[SuperDre]

Het gaat puur om de basis van het OS zelf. Zoals in het artikel (nu) staat, blijven 32-bits applicaties nog gewoon werken omdat dat door het 64bit OS al afzonderlijk opgelost wordt.

[BI-Forcer]

Itanium was technologisch de tijd wel ver vooruit met een keiharde drop van 32bits compabiliteit. Echter zeer belangrijke andere binaries zoals de Java JIT compiler hadden (te) lang nodig om echt goed te performen op Itanium. Ik herinner me dat SAP Portal (Java based) op Itanium 30 minuten nodig had om te starten en op m'n Dell laptop 10 minuten. HP heeft er hard aan getrokken maar de brede ondersteuning is er nooit gekomen.

[bzzzt]

Ik denk niet dat het ontbreken van goede Java support alleen het probleem was. Itanium vereiste veel werk om performante software te krijgen, maar de machines waren duur waardoor er weinig verkocht waren. Klassiek kip en ei probleem. Sowieso had Intel in die tijd wel meer slechte ideeën: de Pentium 4 netburst architectuur stond ook bol van de beloftes die nooit uitgekomen zijn.

[uiltje]

Na ja, we zitten ondertussen op 5 GHz

[Reactie gewijzigd door uiltje op 23 juli 2024 16:16]

[Xander2]

Dat valt wel mee hoor, MIPS, PA-RISC e.a. zaten al jaren op 64-bit.
Er werd iets te rooskleurig gedacht dat de compiler het allemaal kon oplossen.

[field33P]

Het doel van Itanium was dan ook om Alpha AXP en PA-RISC om zeep te helpen. Daar is Intel onomstotelijk in geslaagd.

[SherlockHolmes]

Zou dit performance verbeteringen met zich mee kunnen brengen?

[Defiance]

Nope.

Enige wat dit doet is technisch gezien AMD zijn x64 (x86-64) patent proberen onderuit te schoppen zodat intel die niet meer hoeft te licensen van AMD.

Het cleared mogelijk wel wat die-space van de CPU omdat 32-bit inderdaad al oud is en daarna dus eigenlijk alleen nog maar "ge-emuleerd" wordt via VMs.

Denk niet dat het commercieel hard van grond komt omdat het nog steeds de x64 instructie set van AMD gebruikt voor operatie.

[Loller1]

En je trekt die conclusie op basis van wat exact? Want voor zover hier uit blijkt zijn het juist voornamelijk AMD's technieken die *wel* overreind blijven staan.

[Defiance]

Defiance in 'Intel stelt x86-S-instructiesetarchitectuur voor met enkel 64bit-ondersteuning'

Zie bovenstaande reactie.

Het gaat er niet om wat wel/niet blijft staan, het gaat hoe Intel ermee om gaat.

Intel heeft al meermalen getracht de x86 licentie onderuit te schoppen bij AMD dat zij het niet mogen gebruiken.
Intel heeft zelfs nog een boete van 1,x miljard openstaan omdat ze dit bij AMD hebben trachten te verkloten en de rechtzaak hebben verloren, maar nog steeds niet hebben betaald.

Ze hebben AMD zelfs ook eens verkeerd aangeklaagd waardoor zij bijna de gehele cross-licensing deal verloren hadden van AMD zelf, Intel zou dan CPUs moeten produceren vanuit het Intel P4 tijdperk.

Voor meer info - check gewoon even de geschiedenis van dit soort dingen.

[Loller1]

Loller1 in 'Intel stelt x86-S-instructiesetarchitectuur voor met enkel 64bit-ondersteuning'

Zie bovenstaande reactie.

Het gaat uiteraard over wat wel en niet blijft staan. De x86S architectuur maakt nog steeds gebruik van AMD's patenten. Dit veranderd daar niks aan. De x86S architectuur houd ook AMD niet tegen om Intel's x86 patenten te blijven gebruiken. Dit veranderd ook daar niks aan. Juist AMD zou beter afzijn in deze gezien juist Intel's patenten op x86 minder relevant zijn voor x86S.

Het laatste incident stamt daarvan uit 2009 en was omtrent Global Foundaries, toen AMD Intel's IP aan derde partijen begon te geven, wat tegen de deal in ging. Waarop vervolgens de vereisten van die deal werden aangepast om dat wel toe te laten (en AMD toen geheel fabless is gegaan). Als Intel die deal opblaast kunnen ze zelf niet eens x64 processors bouwen.

Dus nogmaals. Waar bazeer je dit in godsnaam op? En je eigen reacties zijn geen bewijs van de stelling in die reacties...

[Defiance]

Het ging om de antwoord in mijn eigen reactie, anders copy/paste ik de post 2 keer en herhaal ik dingen, de link zelf was makkelijker om te doen i.p.v. hetzelfde post nog een keer te posten - even de context lezen.

Ongeacht - Hier wordt een nieuwe Instructie Set voorgesteld - een instructieset die niet common gedeeld wordt tussen bedrijven tenzij de deal wordt aangepast.

Dat incident (2009) heeft Intel ook bijna de licensing deal gekost omdat AMD toen nog het meerendeel van GlobalFoundries in handen van AMD was, doordat Intel die fout had gemaakt gaf dat AMD de kans fabless te gaan, wat technisch gezien ook wel hun originele doel was.

Was een kantje-boord issue toen voor Intel.

Voorbeeld zijnde:
Stel Intel past x86-S toe en het is een succes, maar er zitten daar x64 instructies in die hetzelfde zijn als x86-64 maar omdat een groot gedeelte van de Instructie Sets verwijderd zijn krijg je een andere classificatie en het wordt geclassificeerd als inderdaad "x86-S" - dit valt dan in de wettelijke ogen (vooral in de US - zie willekeurige voorbeelden van je huisdier in een magnetron doen en dat het er niet specifiek staat het NIET te doen) als een ander iets, waardoor X, Y of Z niet meer geldt.

Of dat wettelijke standpunt houdt is 1 ding, maar het is hoe dit soort dingen werken.

Intel probeert al 40-50 jaar van AMD af te komen in het x86 gedeelte, dat zal niet zo snel stoppen.

Voorbeeld van een simpler technisch iets: Hoeveel verschillende patenten zijn er al om een BIOS flashback functie zonder CPU uit te kunnen voeren dat essentieel hetzelfde zijn maar net anders zijn verwoord.

Principieel is het hier hetzelfde, alleen gaat het dan om instructie sets van een CPU i.p.v. een functie op een moederbord.

Heb ik bewijs dat Intel deze reacties gaat doen in de toekomst hiermee? Nope.
Kan ik daar redelijkerwijs van uit gaan gezien de geschiedenis? Yep.

Principieel stop het AMD zijn x86 license niet - maar wel de x86-S en alle mogelijke gevolgen van dien wat er in de x86-S zit.

Stelt Intel dat het alleen de legacy Instructie-sets verwijderd en niets anders en dit een addendum is op x86 dan gebeurt er niets, introduceren ze dit als een eigen instructie set dan is van alles mogelijk.

[xorpd]

Er wordt geen nieuwe instructieset voorgesteld - x86-S is een subset van de huidige instructieset. Er worden een aantal legacy operating modes verwijderd. Dit vereist nieuwe BIOS software en operating system support.

[RJG-223]

Zie bovenstaande reactie

Dat is jouw eigen reactie, die @Loller1 terecht in twijfel trekt. En als antwoord herhaal je je eigen woorden ?

Dit is wat jij zegt:

Enige wat dit doet is technisch gezien AMD zijn x64 (x86-64) patent proberen onderuit te schoppen zodat intel die niet meer hoeft te licensen van AMD.

Loller1 vraagt waarop je dat baseert, en misschien dat je dat dus alsnog uit wilt leggen ?

De geschiedenis ken ik. En als jij die als bewijs wilt aanhalen, zou je op z'n minst bronnen kunnen vermelden. Anders zijn het gewoon holle woorden. FUD. Demagogie.

Het feit dat Intel vroeger anticompetitieve praktijken heeft gehanteerd (en misschien wel nog steeds doet), is geen reden dat alles wat ze doen louter anticompetitief is, en ook geen reden dat deze actie zo gemotiveerd is. Maar het lijkt dat dat het enige is waar jij je conclusie op baseert. Kun je nu ook met feiten komen op jouw bewering te onderbouwen ?

[Defiance]

Zie bovenstaand.

En als je als Tweaker links moet hebben met verwijzingen voor common knowledge geschiedenis punten anders accepteer je het niet is het dezelfde meme als "pics or it didn't happen".

Ik denk dat we allemaal wel bekend ermee zijn en het niet constant herhaald hoeven te hebben vind je niet?

[RJG-223]

En als je als Tweaker links moet hebben met verwijzingen voor common knowledge geschiedenis punten anders accepteer je het niet is het dezelfde meme als "pics or it didn't happen".

Ik hoef geen links die de geschiedenis herhalen, zeker niet als ik net bevestigd heb dat ik die geschiedenis ken.

Ik wil alleen links (dwz. bewijzen) dat deze actie van Intel gemotiveerd wordt door anticompetitieve doelen. Dat is wat jij beweert, en dat is geen 'common knowledge'. De geschiedenis is geen bewijs voor de acties in het heden.

[graey]

Volgens mij is de cross-licensing deal can Intel/AMD redelijk voortvarend, o.a. om de monopoliewaakhonden weg te houden, en krijgt AMD automatisch een licentie op aanpassingen op bijv x86-64, vooral ook omdat de 64 bits instructies nog wel deels AMD-IP zijn.

[Defiance]

Correct (het is geheel van AMD de x86-64).

Maar je ziet over het hoofd dat Intel kan claimen dat het niet meer x86-64 is maar "x86-S"
En daarmee dus het spelletje kan spelen om AMD te koeieneren.

Het is niet veel, maar als je de geschiedenis van Intel bekijkt met betrekking tot CPU pesterijen ... ze hebben het voor minder gedaan.

[graey]

Zoals ik zei, die cross-licensing deal is heel breed. Zo lang het een aanpassing van x86 is, krijgen beide partijen toegang. En als het gaat over licensing deals met AMD, daar zijn ze sinds de 386-tijd behoorlijk stabiel in. Intel weet ook dat bijv. een minder brede deal er toe zou kunnen leiden dat wanneer AMD een innovatie doet die sterk is, Intel die zelf dan niet kan toepassen om een generatie daarna weer een kans te hebben.

[batjes]

Die cross licensing is heel breed, omdat AMD de hand van Intel geforceerd heeft met AMD64.

Daarvoor waren die licenties niet zo cross and het heeft meermaals weinig gescheeld of AMD zou zijn licentie kwijt geraakt zijn.

X86's borduurt zo te zien gewoon voort op AMD64, het dropt alleen een boel 30+ jaar oude legacy.

[Defiance]

Je vergeet Multi-Core technology, Integrated Memory Controllers, iGPUs, etc.

[graey]

AMD was in het 386-tijdperk de licentie bijna kwijt, daarna was het toch echt redelijk stabiel.
De laatste rechtzaken daarover gingen over of AMD fabless kon gaan met x86, en daar hebben ze een schikking voor bereikt. In 2009 was daar voor het laatst milde onzekerheid over, wat eindigde in een deal waarbij beide partijen kregen wat ze wilden, en AMD een zak geld (niet genoeg imho) in verband met anticompetitive praktijken. Dat is al met al 14 jaar geen gezeik nu, en het gezeik daarvoor ging t/m het pentium 1-tijdperk terug alleen over uitwerkingsdetails.
Intel heeft proberen te voorkomen dat AMD een 386 kloon maakte, waarbij ze verloren. Daarna heeft Intel gekozen voor marketing en namen die beter te beschermen zijn (na de 486 kwam Pentium en moest AMD een naam verzinnen ipv gewoon ook een '586' verkopen), maar de x86-deal was toen in de basis al redelijk rond.

De deal is nu dusdanig ingericht, dat als Intel de licentie intrekt of de deal opzegt zonder dat AMD de afgesproken regels schendt, Intel daarmee de regels schendt, en dan staan de antitrust-waakhonden morgen op de stoep.

[_Arjen_]

Nee, wat Intel hier voorstelt is om alleen de X86-64 instructieset te behouden.
De 32 en 16 bits instructies worden verwijderd uit de processoren.
De X86-S instructieset bestaat nl niet, instructieset is niet hetzelfde als architectuur

[loekf2]

Hangt er vanaf denk hoe de instructie decoding and pipelining in elkaar zit. Voor ARM zijn er goeie artikelen ooit op Anandtech verschenen, kan me niet herinneren dat ooit van x86/x64 gezien te hebben. Kan me eigenlijk niet voorstellen dat het over boord gooien van 16-bits en 32-bits code (versimpeling) geen voordeel geeft.

x86 is vrij complex. Omdat een instructie wordt omgezet in micro-code. Bij de 8086 zat er een soort PLA en group decode ROM in (30% van chip oppervlakte). Check de posts van @kenshirriff maar eens op Twitter.

[Defiance]

Jeen.

Het betreft hier puur alleen maar het verwijderen van 16/32-bit Instructie Sets.

Het enige wat dit veroorzaakt is niet het versnellen van dingen, de x86-64 instructie set is al vast gelegd en wijzigt niet.

Het vertraagt alleen dingen (16/32 bit) omdat het het nu moet gaan "emuleren" (niet het correcte woord, maar ja...)

Bij deze voorstel is het alleen maar die-space besparing en zoals eerder genoemd de patent licensing gezeur.

[RJG-223]

Het betreft hier puur alleen maar het verwijderen van 16/32-bit Instructie Sets.

Niet echt. 32-bit applicaties (en 16 bit?) blijven gewoon ondersteund. Het gaat hier alleen om dat deel van de 16 en 32-bit legacy die enkel door BIOSen en OSen gebruikt kan worden / wordt (maar in hedendaagse OSen eigenlijk amper tot niet gebruikt wordt...).

De meeste 32-bit en 16-bit instructies worden ook nog gewoon volop gebruikt door applicaties. Als je die eruit sloopt, dan draait ongeveer alle software niet meer. Dat zou niet echt een populaire maatregel zijn

[Defiance]

Niet helemaal correct.

Ook te zien in de rest van deze topic, WOW (Windows on Windows) met Instructie Set backwards compatability in de x86-64 Instructie Set etc.

Het is alleen het direct aanspreken van deze sets wat een probleem wordt.

Niet het via-via gedeelte, daarom ben ik ook zo hesitant om het "emuleren" te noemen.

[RJG-223]

Niet helemaal correct.

Ook te zien in de rest van deze topic, WOW (Windows on Windows) met Instructie Set backwards compatability in de x86-64 Instructie Set etc.

Heb jij de links ook gelezen over WoW en WoW64 ? Zie deze reactie.

WoW en WoW64 zijn compatibiliteitslagen om respectievelijk de 16-bits Windows ABIs te emuleren bovenop de 32 bits W32 ABIs, en om de 32-bits Windows ABIs te emuleren met bovenop de 64-bits Windows ABIs.

Dat gaat dus helemaal niet over instructiesets en dergelijke. Dat gaat over Windows ABIs. En dus alleen over Windows. En over Windows gaat het artikel helemáál niet.

Het artikel gaat over de X86 architectuur. En daarvan blijven de 32bit instructieset, en de 16bit instructieset gewoon bestaan. Alleen bepaalde functionaliteit die enkel door 16bit en 32bit OSen gebruikt wordt, en door BIOSen wordt eruit gesloopt.

En voor jouw informatie: een 64bit x86 CPU kan zonder probleem 32bits applicaties draaien, zonder enige compatibileitslaag of emulatie. De enige emulatie die misschien nodig is (afhankelijk van het OS), is de emulatie van een 32-bit ABI op een OS dat alleen een 64bit ABI heeft. Maar dat heeft dus niets met de CPU te maken.

Het is zelfs mogelijk om voor een applicatie wel 64-bits registers toegankelijk te maken, maar nog steeds een 32-bits adresruimte te gebruiken. Ik weet niet of WIndows dat ook ondersteunt - ik betwijfel het, maar Linux kan het bijvoorbeeld wel.

Het is alleen het direct aanspreken van deze sets wat een probleem wordt.

Welke sets ? De 32 bit en 16 bit instructiesets ? Nee dus. Dat blijkt nergens uit, behalve uit de veronderstellingen van mensen die het artikel niet goed gelezen hebben, of die niet begrijpen waarover het gaat.

[batjes]

Het neemt wel ruimt in op de chip en het zorgt ook voor overhead.

32/64 bit zal niet automatisch sneller worden, maar men kan de chips beter optimaliseren en minder overhead is altijd positief.

[Loller1]

Direct? Een klein beetje bij booten misschien. Maar dit betekent wel een stuk van de hardware naar de prullenbak kan verwezen worden, minder hardware betekend meer ruimte voor andere hardware wat op zijn beurt wel weer dingen mogelijk maken die nu gelimiteerd zouden zijn door de oppervlakte (al weet ik niet hoeveel verschil dat maakt, dit is puur "in theorie").

[jeroen3]

Ja, want dan passen er meer nuttige features per mm2 op de chip.

[andru123]

Heb je referentie toevallig? Ik was benieuwd of er enkele nadelen zijn.

[well0549]

32-bit can be slightly faster in certain use cases -- the smaller addresses means sightly more compact code, which means greater cache efficiency. In the benchmarks I've seen, that efficiency tends to be be overshadowed by 64-bit's greater computational efficiency in heavy-computation environments. But 32-bit does in fact occasionally win on some benchmarks. YMMV. The age of your software matters, as newer builds take advantage of 64-bit stuff that older builds do not.

[damouze]

Vanuit een design perspectief kan ik me dit heel goed voorstellen. De x86 instructieset is intussen zo complex geworden dat het hoog tijd is voor een cleanup.

Tegelijkertijd zit een hoop van die complexiteit niet zozeer in de legacy modes, maar in wat er sindsdien bijgekomen is. Zaken als AVX, SSE, TGX, TSX, etc... Zaken die strict genomen overbodig zijn voor het dagelijks functioneren van programmatuur, maar waarvan de toegevoegde waarde hem zit in de performancewinst die ermee te behalen valt.

Mijn (betrekkelijke) lekenbrein zegt dan meteen: waarom zijn de bestaande instructies dan niet zo geoptimaliseerd dat die performance winst er op die manier uitgehaald kan worden? Iets zegt me echter dat dit indertijd niet mogelijk was of reëel werd geacht.

[graey]

Over AVX kan je misschien discussiëren, maar alle SSE extensies tot SSE4 (SSE5 is soort van AVX maar dan anders, en een nieuwere versie daarvan overlapt meer met AVX om meer compatibel te zijn) zijn dusdanig populair dat ze in best veel consumentenapplicaties gebruikt worden. Ook AVX wordt sporadisch toegepast in game engines voor hogere performance.

Op je vraag waarom bestaande instructies niet worden geoptimaliseerd: de Wikipedia-pagina van SSE(1) heeft een helder voorbeeld van de voordelen van SIMD-instructies, met wat psuedocode ter illustratie:
https://en.m.wikipedia.org/wiki/Streaming_SIMD_Extensions

Lang verhaal kort: je kan in 1 128-bits SIMD-instructie vier 32 bits waarden tegelijk verwerken. Scheelt drie 32 bits instructies. De performance is niet perse 400%, maar wel sowieso sneller dan 4 keer een 32 bits instructie.

[RJG-223]

Vanuit een design perspectief kan ik me dit heel goed voorstellen. De x86 instructieset is intussen zo complex geworden dat het hoog tijd is voor een cleanup.

Het lijkt erop dat dat nu net iets is wat ze niet gaan vereenvoudigen. 32-bit applicaties (en 16bit?) blijven ondersteund. En 64-bit applicaties gebruiken ook volop 32-bit en 16-bit instructies.

Het enige wat zo te zien gaat veranderen, is de functionaliteit die allen door OSen gebruikt wordt. Zie het artikel voor meer details...