Intel werkt niet meer aan X86S-instructiesetarchitectuur

Intel zegt dat het niet meer werkt aan de X86S-intructiesetarchitectuur. Het Amerikaanse chipbedrijf blijft zich wel inzetten om de x86-architectuur verder te ontwikkelen. Dat zal het bijvoorbeeld doen via de recent opgerichte x86 Ecosystem Advisory Group.

Intel heeft het nieuws aan de redactie van Tom’s Hardware bevestigd. Het bedrijf geeft geen reden voor de beslissing, maar verwijst in zijn communicatie wel naar zijn focus om te 'blijven innoveren' en te blijven samenwerken binnen het x86-ecosysteem. Het vermeldt bijvoorbeeld de x86 Ecosystem Advisory Group, maar ook concurrent AMD en andere bedrijven uit de chipindustrie.

De X86S-intructiesetarchitectuur was een project van Intel dat draaide rond een 64bit-onlyvariant van de x86-instructieset, waarbij onder meer native ondersteuning voor 32bit-OS’en zou worden geschrapt. Het Amerikaanse chipbedrijf had hier in 2023 een whitepaper over gepubliceerd. De X86S-isa zou betekenen dat cpu's alleen gestart kunnen worden in 64bit-modus. Intel wilde via deze isa verschillende legacymodi schrappen, 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. De wijzigingen zouden alleen impact hebben op het gebruik van dergelijke besturingssystemen; 32bit-applicaties zouden wel blijven werken.

In oktober van dit jaar raakte het nieuws bekend dat Intel en AMD de x86 Ecosystem Advisory Group hadden opgericht. De twee Amerikaanse chipmakers zullen via dit initiatief samenwerken om de x86-instructiesetarchitectuur te harmoniseren. De groep wil tevens architectuurrichtlijnen versimpelen en gestandaardiseerde interfaces 'voor alle x86-producten van Intel en AMD' ontwikkelen. Naast de twee chipmakers worden onder andere Broadcom, Dell, Google, HP, Lenovo, Meta en Microsoft lid van de adviesgroep.

Intel X86S

Reacties (172)

[Tyrian]

Mooi. Het sterkste punt van x86 en x86-64 is altijd neerwaartse compatibiliteit geweest. Ik zie weinig redenen om de legacy ondersteuning eruit te slopen. Het maakt maar een klein deel uit van het silicon en het is belangrijk voor allerlei legacy OS-sen waaronder industriële toepassingen om dit erin te houden.

[player-x]

Mooi. Het sterkste punt van x86 en x86-64 is altijd neerwaartse compatibiliteit geweest.

Windows, Linux en FreeBSD x64 gebruiken het bij voorkeur niet meer.

Zie iig zo twee redenen:
1ste, minder aanvalsmogelijkheden voor malware, door de verwijdering van junk hardware.
2de, minder complex, minder die oppervlakte, minder R&D, minder QC.

Waarom zou je je niet een klein deel van je 'real estate' op de chip reserveren voor legacy.
16 bit: 8086 (1978) had 29.000 transistoren
32 bit: 386 (1985) had 295.000 transistoren

Als je dat keer 8 of zelfs keer 192 doet, wordt dat toch best wel wat ruimte, daarnaast de hoeveelheid afgekeurde dies groeit kwadratisch met die oppervlakte.
En dat is als je er van uitgaat dat de transistor count voor legacy ondersteuning niet veder is gegroeid dan jouw 324.000 transistors. (geen idee hoeveel transistoren er echt nodig zijn)

Ik ben een groot gelover in de moto van Kelly Johnson, "houd het simpel, idioot!" (KISS), minder is vaak meer.

[Consequator]

Ja die 2 redenen had ik ook in gedachten.
missende 16 en 32 bit is eventueel wel met een software schil weer op te lossen.
Dat neemt niet weg dat er nog wel CPU's moeten blijven met de oude architectuur want er draait nog ZOVEEL oude meuk in de wereld wat zo oud is dat virtualisatie ook niet een optie is..

[player-x]

ZOVEEL oude meuk in de wereld wat zo oud is dat virtualisatie ook niet een optie is..

Zelfs de meest antieke 8 bit game rom kan geëmuleerd worden, kan me niet voorstellen dat er programma's zijn die je niet kan emuleren.

En als het wel een probleem is, dan kan het toch al niet op geen enkele moderne hardware draaien, vanwege drivers en dergelijke.
En dan heb je echt gewoon legacy hardware nodig, zoals toen NASA 8086 CPU's kocht van eBay voor de Spaceshuttle. ^_^

[Luno]

Waarom zou je je niet een klein deel van je 'real estate' op de chip reserveren voor legacy.
16 bit: 8086 (1978) had 29.000 transistoren
32 bit: 386 (1985) had 295.000 transistoren
64 bit: AMD K8 (2003) had 105.000.000 transistoren
64 bit: Intel 11 th (2021) had 6.000.000.000 transistoren
Dus om heel elementair 16/32 bit stukje op de chip neer te zetten os 0,005 promille verloren. En je hoeft dat niet meer te ontwerpen, plak het er gewoon in.

Idem ditto minimum eisen
MSDOS: 32 KB
WIN311: 100KB
Win95: 200KB
Win98: 1MB
WinXP: 4MB
Win7: 1GB
Om een 32 bits omgeving van Win98 (subsysteem in MS speak) te activeren kost je 1 promille. Je het is er al.. Kost je geen cent ontwikkel kosten.

Bronnen:
en.wikipedia.org/wiki/Transistor_count#Microprocessors
gwsmedia.com/articles/how-internet-system-requirements-have-changed-2

[RJG-223]

Zo simpel is het niet helemaal. Er zijn veeeel meer verbeteringen geweest, dan puur een uitbreiding van de instructieset. Caches zijn geïntroduceerd (die kosten buitenproportioneel veel transistoren), en groter gemaakt, en gesplitst in L1/L2/L3, virtueel geheugen is erbij gekomen, CPUs zijn superscalar geworden, met meerdere execution units, en veel transistoren zijn in gebruik voor branch prediction, en andere optimalisaties. Geheugenaansturing zit nu in de CPU, met brede geheugenbussen, en ingewikkelde en zeer brede IO bussen (PCIe). 8086 is niet te vergelijken met de laatste generatie CPUs van Intel of AMD.

Dat gezegd hebbende: ik denk niet dat 16bit/32bit OS ondersteuning erg veel transistoren kost in een moderne CPU. Maar het zijn wel allemaal bijzondere features: 8086 segmentatie, 80286 segmentatie, 32bit adresruimte met uitbreidingen naar (ik meen) 36(?) bits fysiek geheugen binnen die 32bits architectuur, rings 0-4, etc. Ik vermoed dat de meeste van die features softwarematig in microcode zijn geïmplementeerd, met mogelijk wat extra transistoren ter ondersteuning. Wel zo handig als je die microcode niet meer hoeft te ondehouden, testen, etc. etc.

[MSalters]

Je noemt een zwik legacy die al lang weg is. 80286 segmentatie (24 bits) zit niet in x86-32. PAE (36 bits fysieke adressen) zit niet in x86-64 (48 of 56 bits fysiek).
Ring 0-3 is identiek op x64, ring 4 bestaat niet.

[RJG-223]

Je noemt een zwik legacy die al lang weg is. 80286 segmentatie (24 bits) zit niet in x86-32. PAE (36 bits fysieke adressen) zit niet in x86-64 (48 of 56 bits fysiek).
Ring 0-3 is identiek op x64, ring 4 bestaat niet.

Ja, maar dat zit allemaal nog wel in de CPU ! Het is niet weg ! Het wordt in 32bit cq. 64bit modus niet allemaal gebruikt/ondersteund, maar de CPU ondersteunt het nog wel degelijk in 16bits en/of 32bits modus !

Het punt is nu net dat Intel al deze dingen definitief uit de CPU wil slopen, zodat die niet meer in 16bit modus boot, maar direkt in 64bit modus, en dus überhaupt geen 8086/80286/80386 OSen meer kan draaien (behalve gevirtualiseerd). Huidige CPUs kunnen nog wel 8086/80286/80386 OSen draaien.

Overigens heb je gelijk wat betreft ring 4. Dat bestaat inderdaad niet. Foutje van mij.

[MSalters]

Nee, echt niet. 286 support en PAE is helemaal weg. Geen van beiden is nodig in 16 of 32 bits mode.

[RJG-223]

Nee, echt niet. 286 support en PAE is helemaal weg. Geen van beiden is nodig in 16 of 32 bits mode.

Kun je je bewering onderbouwen met feiten ? Ten eerste is het onlogisch (maar toegegeven: niet volkomen onmogelijk) dat ze de compatibiliteit met bestaande programma's en OSen op enig punt uit de architectuur gesloopt hebben. Ten tweede kun je het gewoon nakijken.

Wat PAE betreft: dat is nog steeds nodig als er een 32-bit OS gedraaid wordt met meer dan 4GB geheugen, wat tegenwoordig de standaard is. En als ik op mijn computer (< 1 jaar oud) kijk, zie ik dat de processor nog steeds PAE ondersteunt (grep pae /proc/cpuinfo).

Verder heb ik de documentatie er maar eens op nageslagen:
AMD64 Architecture Programmer’s Manual Volume 1: Application Programming

In sectie 1.2.4, op de 41e pagina (genummerd p.7):

Protected Mode—Protected mode supports 16-bit and 32-bit programs with memory
segmentation, optional paging, and privilege-checking. Programs running in protected mode can
access up to 4GB of memory space.

In sectie 1.1.1, tabel 1-1 op de 36e pagina, staat dat in protected (legacy) mode, zowel 16bit als 32bit adressen (en data) ondersteund worden. 16 bit adressen (near pointers) in protected mode impliceert volgens mij al 80286 compatibility. Dat kun je aanzetten met de D-bit in een segment descriptor. Far pointers worden ook nog ondersteund - zie sectie 2.3.1, fig. 2-8

Tweede document:
AMD64 Architecture Programmer’s Manual Volume 2: System Programming

Sectie 1.2.1 (p.53) :

The AMD64 architecture is designed to support all forms of legacy segmentation

Sectie 2.1.2 (p.71-72):

The AMD64 architecture supports a pure x86 legacy mode, which preserves binary compatibility not
only with existing 16-bit and 32-bit applications but also with existing 16-bit and 32-bit operating systems.

Sectie 2.2.3 (p.74):

In compatibility mode, segmentation functions just as it does in legacy mode, using legacy 16-bit
or 32-bit protected mode semantics

Dat PAE ondersteund wordt, en noodzakelijkerwijze ondersteund moet worden, blijkt al uit het voorgaande, en kun je ook expliciet in bovengenoemde documenten nalezen....

Conclusie: PAE en 80286 modus wordt nog gewoon ondersteund, en elk programma of OS wat ooit voor 80(2)86 (of hoger) geschreven is, werkt in principe nog steeds. Ik kan me vaag herinneren wel eens gelezen te hebben dat bepaalde instsructieset-extensies er wel uitgesloopt zijn. Volgens mij een soort vector/SIMD instructies of zo, maar dat weet ik niet meer zeker, en dat waren niet dit soort features.

[ibmpc]

Is het ook niet veel veiliger om niet meer in real mode te booten? Kan malware zich wellicht infesteren (voor zover je tegenwoordig nog malware in 1024 KB kunt proppen) voordat de CPU naar protected mode omschakelt en secureboot intrapt?

Ik heb weleens de BIOS code bekeken van een IBM PC/AT en IBM XT/286. Zelfs de BIOS schakelt de 80286 naar protected mode voor wat tests en gaat dan terug naar real mode. Wel met een hack, omdat de 80286 niet terug kan naar protected mode zonder reset. Volgens mij wordt de real mode state gewoon opgeslagen, wordt er in de NVRAM een bit opgeslagen om aan te geven dat de BIOS het protected gedeelte moet overslaan en wordt de computer gereset. Maar bijv. RAMDRIVE.SYS gebruikt LOADALL om alle RAM aan te spreken. Misschien kun je in real mode een stukje malware maken die gewoon een compleet OS virtualiseert inclusief Secureboot en dan kun je toch gewoon bij al het geheugen vanuit real mode?

[Reactie gewijzigd door ibmpc op 22 december 2024 21:55]

[RJG-223]

Is het ook niet veel veiliger om niet meer in real mode te booten? Kan malware zich wellicht infesteren (voor zover je tegenwoordig nog malware in 1024 KB kunt proppen) voordat de CPU naar protected mode omschakelt en secureboot intrapt?

Dat maakt helemaal niets uit. Secure boot heeft niets te maken met protected mode, maar alleen met het feit dat alle systeem-code die uitgevoerd wordt eerst met een digitale handtekening geverifiëerd moet zijn. Dus ook een OS wat van HDD/SSD geladen wordt. Dat kun je in principe zowel in real mode als in (legacy) protected mode, als in long mode (64 bit) verifiëren.

Misschien kun je in real mode een stukje malware maken die gewoon een compleet OS virtualiseert inclusief Secureboot en dan kun je toch gewoon bij al het geheugen vanuit real mode?

Om het volledige geheugen aan te spreken moet je altijd naar protected mode. Voor dat soort malware heb je ook geen real mode nodig. Real mode is niet onveiliger, behalve dat in real mode verschillende programma's niet van elkaar afgezonderd (en dus beschermd) kunnen worden, en ook niet van het OS. Dus dat betekent dat een OS draaien in real mode niet handig is (nog afgezien van de max 1MB geheugen).

Maar de BIOS / UEFI, en de OS code die gedraaid worden bij het opstarten/booten, kunnen allemaal sowieso overal bij, en dat moet ook, want dat is hun taak. En daarvoor heb je geen extra protected-mode-achtige bescherming nodig. Secure boot is wel handig, maar dat was dus volledig onafhankelijk van real/protected/long mode.

Een virus zou, als het zichzelf kan installeren, inderdaad een VM maken, en het echte OS in een VM draaien, en dat overal bij kunnen. Dat moet dan ook in protected mode, want in real mode kan dat niet. En real mode maakt dat ook niet makkelijker (tenzij het OS in real mode zou draaien, maar dat doet het niet). Maar dat virus kan dan als het goed is geen toegang krijgen tot de TPM, en dat ook niet virtualiseren, zodat het OS dan weet dat het niet op de echte hardware draait. Tevens kan dat virus alleen geladen worden als dat virus met de digitale secure-boot handtekening geauthenticeerd is. Anders weigert de BIOS/UEFI dat virus in te laden bij het booten. Niet dat secure boot niet gekraakt zou kunnen worden, maar dat is weer een heel ander verhaal.

[ibmpc]

Interessant. Je kunt dus een hypervisor maken.

Om het volledige geheugen aan te spreken moet je altijd naar protected mode.

Je kunt toch tot 4 GB aanspreken met LOADALL vanuit Real Mode?

[RJG-223]

Interessant. Je kunt dus een hypervisor maken.

Ehh. Ja ??

Dat is niet veel moeilijker dan het initialiseren van een paar datastructuren, het zetten van een bitje (of een paar) in een CPU-register, en/of het uitvoeren van een of meer CPU-instructie(s). Zie de AMD64 documentatie voor de details.

Je kunt toch ook een OS schrijven ? Waarom dan geen hypervisor ? Elk modern OS bevat een hypervisor, anders kun je geen virtuele machines draaien.

Je kunt toch tot 4 GB aanspreken met LOADALL vanuit Real Mode?

Ik moest het even opzoeken, want dat wist ik niet, of ik heb het geweten maar was het vergeten.

Volgens Wikipedia was LOADALL niet gedocumenteerd, en de opcode op de 286 was ook anders dan op de 386. Van wat ik op Wikipedia lees, was het ook gewoon een andere instructie, die voor hetzelfde doel gebruikt kon worden. Op de 486 werkte die instructie alleen nog in SMM mode, en daarna bestond ie niet meer, en kwam er een andere, officiële instructie voor in de plaats (RSM), met weer een andere opcode. Inmiddels (AMD64) zijn zelfs de oude 286 en 386 LOADALL opcodes hergebruikt voor heel andere instructies.

Samenvattend: op de 80286 en 80386 kon je inderdaad vanuit real mode het maximale geheugen aanspreken dmv een truukje met een onofficiële opcode. Vanaf de 80486 kon dat niet meer, en had je wel altijd protected mode nodig. Ik kan me voorstellen dat huidige OSen die instructie emuleren als ze VMs in virtual 8086 mode draaien.

[ibmpc]

Ehh. Ja ??

Ik bedoelde meer een hypervisor die voor de user onzichtbaar is. Maar nu ik verder lees blijkt Windows 11 (je normale sessie) ook gewoon in een Hyper-V sessie te draaien, zodra je de Hyper-V role aanzet.

op de 80286 en 80386 kon je inderdaad vanuit real mode het maximale geheugen aanspreken

Grappig, als je MS-DOS op een moderne CPU draait (kan nog op systemen zonder secureboot, dus tot de +-2nd gen Core CPUs), dan hangt het op EMM386 en RAMDRIVE.SYS. Wellicht omdat dit nu juist de twee apps zijn die LOADALL gebruiken. HIMEM.SYS werkt wel op een moderne CPU, maar volgens mij is voor de 63 KB boven de 1024 KB geen LOADALL nodig.

[RJG-223]

Grappig, als je MS-DOS op een moderne CPU draait, dan hangt het op EMM386 en RAMDRIVE.SYS

Ze moeten sowieso aparte code hebben voor 286 en 386, omdat de LOADALL instructie verschilt. Ze kunnen dus ook heel makkelijk nog een derde stukje code hebben voor CPUs vanaf 486 die geen LOADALL ondersteunen. Bijv. door wel in protected mode over te schakelen. Ik denk niet dat dat erg ingewikkeld is. Voor de 386 is dat dan ook een prima oplossing.

Omdat de naam 'EMM386' is, lijkt het me overigens logischer dat ie helemaal geen LOADALL gebruikt, maar gewoon altijd in protected mode draait, en dan virtual 8086 mode gebruikt voor MSDOS. Zoals ik het begrijp was LOADALL alleen 'noodzakelijk' op de 286. Protected mode + Virtual 8086 + paging is waarschijnlijk ook veel efficiënter en flexibeler dan goochelen met LOADALL.

maar volgens mij is voor de 63 KB boven de 1024 KB geen LOADALL nodig.

Nee, daarvoor moet je alleen de A20 lijn uitschakelen (of eerder: inschakelen...). Als je dan 0xFFFF in een segment register laadt, dan wordt het maximale adres: 0x10FFEF (1024k + 64k - 17)

[Koennnn]

Reuze boeiend allemaal, maar ik mis in de discussie het aspect van de ontoegankelijkheid van oude opslagmedia in de toekomst. Geschreven, getypt, gedrukt, je kunt het eeuwen lezen, maar digitale opslag is op de lange duur, bezien in het licht van de hier gevoerde discussie, een valkuil. Een berg van herinneringen, gegroeide inzichten, kortom op lange termijn informatie van onschatbare waarde, zal verloren gaan. Het is de moeite waard dat op te lossen, softwarematig ofs anderszins.

[D100]

Het bewaren en kunnen lezen van oude digitale informatie is inderdaad een uitdaging.
Doch dat ga je op lange termijn niet bereiken door oude apparatuur en software te bewaren in functionele toestand, maar door de oude informatie over te zetten naar nieuwe apparatuur.

Veel werk indien dat handmatig moet gebeuren, maar op grote schaal kan je dat automatiseren.

Ik zelf heb nog informatie van eind jaren tachtig, van de DOS tijd en nadien verschillende Windows omgevingen, en alles is beschikbaar in huidige formaten, ook op Mac OS. Hoe doe je dat, wel, gewoon kopiëren van ene medium en formaat naar andere.
Op grote schaal kan je dat industrieel aanpakken. Maar je hoeft niet elke bit en byte informatie ooit geproduceerd voor de eeuwigheid bij te houden. Belangrijker is nuttige historische informatie te kunnen 'mijnen'.
Privaat heb ik fotoalbums gemaakt selectief gekozen uit 100-duizenden digitale foto's. Dat is wat bekeken wordt. Een selectie digitale foto's wordt goed bijgehouden, de rest is er in meerdere formaten, maar ik veronderstel dat die nooit nog bekeken zullen worden. Video-opnames zijn meer tricky, vragen een elektronisch medium. Selectie, selectie.

[ibmpc]

Interessante vraag, ben hier heel benieuwd naar.

Kleine aanvulling: PC-DOS 1.0 had volgens mij maar 4 KB aan RAM nodig. De eerste IBM PC had ook maar 16 KB RAM. MS-DOS 3.30 wordt gezien als de MS-DOS versie die relatief het minste RAM gebruikt en toch nog redelijk wat compatibiliteit heeft met DOS applicaties. MS-DOS 6.22 had wel echt 256 KB RAM nodig voor basisfunctionaliteit, maar als je de bijgeleverde applicaties wilde gebruiken was 512 KB toch echt het minimum. Windows 3.0 kon op een systeem met slechts 640 KB draaien, Windows 3.1 had volgens mij wel echt 1 MB RAM nodig. Windows 95 kon opstarten met 4 MB aan RAM, maar 6 MB was toch echt het minimale om het werkbaar te maken. Windows 98 had minimaal 8 MB nodig. Windows XP kon met 64 MB RAM wel opstarten, maar was dan enorm traag tenzij je een SSD had voor je swapfile. Windows 7 kan opstarten met 256 MB (en als je in Hyper-V Dynamic Memory aanzet, dan is het nog best werkbaar ook).

[fenrirs]

Bizar eigenlijk als je kijkt hoe weinig echte productiviteit er bij gekomen is sinds de win95 tijd

[Llopigat]

En hoeveel security er bij gekomen is. Win 95 was zo lek als een mandje en gewoon niet te fixen door de DOS ondergrond.

Voor consumenten is dit pas met XP opgelost.

Nou moet ik wel zeggen dat het ook wel eens handig was. Ik werkte toen voor een internet cafe en we hadden altijd Chinezen die vervelende software installeerden om makkelijker Chinees te typen. Dan kon de volgende gebruiker er niet mee werken. Of allerlei messaging programma's. Maar Windows 98 was zo klein dat ik gewoon met een boot rom een vers image kon installeren met elke boot.

Toen had je nog niet echt manieren om admin rechten af te schermen.

Dus het was slecht beveiligd maar na elke uitlog deden we een reboot dus persistence was er niet.

[Reactie gewijzigd door Llopigat op 29 december 2024 01:54]

[kdekker]

Er is m.i. geen directe relatie tussen transistor count, oppervlakte en micro-code instructies. Sommige instructies kosten meer ruimte dan andere. En hoe evenredig het legacy deel verhoudt tot de rest (die allemaal al op nieuwere/andere technieken gemaakt zijn), lastig te zeggen.

Ik denk dat voor bijv Microsoft op software vlak het bijna meer voordelen heeft om de legacy spullen er uit te halen dan Intel. Maar iig einde van legacy zal voor beiden (en AMD) opleveren voor een toekomstige processor. Al weet ik niet hoe makkelijk je een legacy deel uit een chip ontwerp verwijderd. Ook in een 64-bit architectuur houd je waarschijnlijk 32-bit bewerkingen over.

[TechSupreme]

Het gaat ook helemaal niet om het verkleinen van het aantal transistoren.

Leuk dat je het aantal transistoren weet op te noemen, maar leg dat eens naast het die oppervlak.

Ook leuk dat je de geheugenvereiste van een OS weet te noemen, maar leg dat dan ook eens naast de eisen van de gebruiker.

Het gaat om een stukje legacy van je afstoten zodat je:
1. Je hardware beter kan beveiligen
2. Kan bouwen aan de toekomst zonder een blok aan het been.

[Luno]

Die 8086 had in 1978 een veel grotere die, maar dat was met lithografie van toen, Nu is die schaalt dat gewoon mee..Dus dei die oppervlak van toen is irrelevant.

De 16 (en) 32 bits subsystemen onder bv Win7 draaien onder de beveiliging van Win7. Maar doordat er voor uitvoeren van de instructies de cpu al klaar staat hoe je niet te emuleren. (Afgezien van de ontzetting naar interne microcodes door Capslock genoemd),.

Dat is met Win10,11 hetzelfde. Ze geven geen echte extra beveiligings problemen mee. Ze gebruiken de IP stack, etc van Win10/11,

<0,1% ruimte inleveren om backwards compatibel te blijven, middels subsystemen die ondertussen ook uitontwikkeld zijn dus geen blok aan het been.

Tja de eisen van de gebruiker. Voor nieuwe zaken kies ik voor de 64 bit variant, Maar er draait nog genoeg 32 bits dingen op m'n PC, die ik niet wil missen. Er zijn zelfs een paar frutsels die MSDOS vereisen, en dan zou native support toch prettiger zijn dan een DosBox moeten openen.

[TechSupreme]

Die 8086 had in 1978 een veel grotere die, maar dat was met lithografie van toen, Nu is die schaalt dat gewoon mee..Dus dei die oppervlak van toen is irrelevant.

Wel als je het gaat vergelijken met het aantal transistoren van nu.

De 16 (en) 32 bits subsystemen onder bv Win7 draaien onder de beveiliging van Win7. Maar doordat er voor uitvoeren van de instructies de cpu al klaar staat hoe je niet te emuleren. (Afgezien van de ontzetting naar interne microcodes door Capslock genoemd),.

Het gaat ook niet om Windows of Unix Systemen of wat dan ook. We hebben het over de hardware. Je systeem start op in 16 bit modus en cycelt door alle modussen om naar de gewenste modus te komen. Die 16 bit mode is met allerlei kunstgrepen beveiligd, maar dat is nooit 100%.

Buiten dat, cheat en malware makers maken gretig gebruik van alle ringen om beveiligingsmaatregelen van het besturingssysteem te bypassen.

Tja de eisen van de gebruiker. Voor nieuwe zaken kies ik voor de 64 bit variant, maar er draait nog genoeg 32 bits dingen op m'n PC, die ik niet wil missen

Sorry dat ik het moet zeggen, maar jij hebt echt geen idee waar je het over hebt als je dit soort uitspraken doet. Zoek eens op Windows on Windows (WOW64 en WOARM)en lees je in hoe een Windows compatibel blijft op verschillende subsystemen.

Je zegt dingen die er echt helemaal niet aan toe doen!

[Luno]

Ach jij je zin.... Geloof maar wat je wilt. Ik ben tegen genoeg problemen tussen 16/32/64 aangelopen in mijn tijd. Voorbeeld uit coding van een stukje van EIGEN programma.

if(fdtm_osversioninfo.wow32==0) {
fdtm_message("This a 64 bit exe. FSRedirection is always off. -[NO]WOW32 ignored (see -help (no_)wow64)\n");
return;
}
// fdtm_message("\nLF_WOW onoff=%d status=%d\n",onoff,status.wow32FSredirected); //3jul2022
if(onoff==FALSE && status.wow32FSredirected==TRUE) {
//fdtm_message("\nLF_WOW in Disable onoff=%d status=%d\n",onoff,status.wow32FSredirected); //3jul2022
// Disable redirection immediately prior to the native API
// function call.
fnWow64DisableModule = (LPFN_Wow64DisableWow64FsRedirection) GetProcAddress(
GetModuleHandle(TEXT("kernel32")),"Wow64DisableWow64FsRedirection");
if(NULL != fnWow64DisableModule)

NB, fdtm_message is mijn routine, zoek daar maar niet naar (tenzij je echt een NGN'er van de oude stempel bent)/ .

Wellicht moet je nadenken voordat je roept dat ik nergens van weet. En de tijd dat een CPU ongeveer een reboot moest doen van 16->32 is al een tijd geleden. 't is meer dan 55 jaar geleden dat ik m'n eerste programmacursus volgde. Okay ik ben fossiel. maat wel beta tester geweest van operating systemen.

QQ vind ik dat microsoft er een puinhoop van heeft gemaakt sowieso qua naamgeving)

Tot slot (helaas heb ik de documentatie niet meer). maat in de MSC C6 compiler (MSDOS/Windows etc) stond echt dat er ook een 32 bits variant van de compiler was, maar dat was trager. Helaas heb ik dat stukje papier nier meer (evenals de Microsoft word 6 voor Dos die we op floppies kregen inclusief een virus...

Ach verberg je in je eigen bubbel van alwetenheid...

[TechSupreme]

Wat heeft FS redirection hiermee te maken? Je wil toegang tot de systeem32 directory en daardoor is je OS ineens 32bit?

[Reactie gewijzigd door TechSupreme op 25 december 2024 01:40]

[Xander2]

Waarom wel?

Die legacy modes en bijbehorende software zijn niet meer veilig te gebruiken in deze tijd.
Het gros van de gebruikers heeft het ook niet nodig.

Die backwards compatibility kan prima softwarematig geregeld worden en voor specifieke toepassingen kan best een run op een oude fab gedraaid worden.

[uiltje]

Het probleem is dat het ook qua tijd in de weg zit. Als je een geheugen adresseert moet je ook rekening houden in welke stand de CPU zich op dat moment bevind. Het is dus niet zozeer het aantal transistoren maar de complexiteit die het met zich meebrengt. Dat kan ook invloed hebben op de 64-bit omgeving want je kan die circuits er niet zomaar uithalen als de CPU over schakelt. Nou vermoed ik dat ze het meeste in microcode zullen proberen te ondervangen, maar ik weet niet of dat altijd op kan gaan zonder vertraging te introduceren.

[Reactie gewijzigd door uiltje op 22 december 2024 16:53]

[Navi]

Ik weet hier niet heel veel van, maar als je een 64-bit only CPU maakt, kun je dan niet gewoon alles qua 32-bit emuleren?

Het zal trager zijn dan native maar CPU's zijn tegenwoordig snel zat om oude software in 32-bit te emuleren denk ik?

Ik zou denk ik wel voor zijn om al die oude meuk te droppen en door te gaan met 64-bit only architectuur, mits je het kunt emuleren in ruil voor een performance penalty.

[Reactie gewijzigd door Navi op 21 december 2024 14:02]

[CAPSLOCK2000]

Ik weet hier niet heel veel van, maar als je een 64-bit only CPU maakt, kun je dan niet gewoon alles qua 32-bit emuleren?

Zo werkt het stiekem al op CPU-niveau. x86 chips hebben aan de "buitenkant" een andere instructieset dan intern. De instructies die wij geven worden eerst vertaald naar de interne "micro code". Dat is échte instructieset. Maar iedere instructie die je wil ondersteunen kost ruimte op je CPU die je ook anders zou kunnen gebruiken en maakt het geheel complexer wat weer invloed heeft op de rest van de CPU.

[Reactie gewijzigd door CAPSLOCK2000 op 21 december 2024 14:14]

[catfish]

Dus eigenlijk is het tijd om die vertaalslag in software te steken en het hele x86 boeltje buiten te flikkeren.
Vat ik het zo goed samen?

x86 is gewoon verouderd. intel en AMD hebben goed hun best gedaan, maar Apple en ARM laten toch zien dat het einde van x86 is aangebroken.
Ik kan alleen maar hopen dat intel en AMD ook met ARM beginnen of iets compleet anders. Als het maar efficiënt is.

[CAPSLOCK2000]

Dus eigenlijk is het tijd om die vertaalslag in software te steken en het hele x86 boeltje buiten te flikkeren.
Vat ik het zo goed samen?

Ja. Sterker nog, er zijn al stappen genomen. Intel heeft veel werk gestoken in het bouwen van geoptimaliseerde compilers die rekening houden met hoe de CPU's intern werken op een niveau ver voorbij de instructieset waarmee we tegen de CPU praten.

x86 is gewoon verouderd. intel en AMD hebben goed hun best gedaan, maar Apple en ARM laten toch zien dat het einde van x86 is aangebroken.
Ik kan alleen maar hopen dat intel en AMD ook met ARM beginnen of iets compleet anders. Als het maar efficiënt is.

Eerlijk gezegd denk ik dat ARM nogal overschat wordt omdat Apple een efficiente CPU heeft utigebracht die toevallig ARM gebruikt. Ik schrijf toevallig omdat ik denk dat die efficiente weinig te maken heeft met ARM, ik ben niet overtuigd dat ARM fundamenteel sneller is.

ARM is net zo oud als x86. De afgelopen 40 (!) jaar hebben die twee architecturen alles van elkaar afgekeken dat de moeite waard is. De overeenkomsten zijn veel groter dan de verschillen. Ik schreef eerder dat x86 aan de binnenkant een andere taal spreekt dan de x86-instructieset die we aan de buitenkant zien, dat is deels om de vrijheid te hebben om het intern anders aan te pakken en principes van andere systemen over te nemen.

Als we dan toch van architectuur wisselen zou ik liever een grotere stap zien naar iets dat echt stuk moderner is want waarschijnlijk zitten we er weer 50 jaar aan vast. RISC-V is wat mij betreft het minimum en die architectuur is ook al weer 15 jaar oud.

[Reactie gewijzigd door CAPSLOCK2000 op 21 december 2024 16:56]

[terradrone]

Was Itanium niet native 64bit en relatief behoorlijk state-of-the-art?

[dmantione]

Kortzichtig. Een moderne processor maakt een vertaalslag naar een interne instructieset, met meer registers e.d. Je kunt Itanium zien als een poging een processor zonder vertaalslag te maken, maar dan krijg je de kwestie dat de interne instructieset veroudert: Een moderne x86/ARM heeft veel meer interne registers dan een Itanium ooit gehad heeft. En daarmee verdween het voordeel dat Itanium had heel snel.

[terradrone]

Wat is kortzichtig? Itanium?

[dmantione]

Ja, de Itanium-instructieset was met name de juiste op het moment dat de Itanium bedacht is en niet toekomstbestendig. Gezien hoe lang een instructieset mee moet kunnen, was dat echt wel een serieuze denkfout.

[terradrone]

Interessant. Nu is me duidelijk waarom Itanium nooit echt doorgebroken is. Toch vind ik het jammer dat de : "keuze" tegenwoordig in cpu land redelijk beperkt is. Waar ooit naast x86, mips en arm, grote cpu's als ibm power, ultrasparc, itanium en zelfs ibm met hun cell-cpu (baanbrekend voor die tijd) het landschap domineerde, lijkt dit nu redelijk beperkt tot x86 en arm...

[uiltje]

PowerPC is nog niet helemaal weg hoor, het mist vooral op de desktop.

[jeronimo]

RetroBytes heeft een leuk filmje gemaakt over de Itanium. Voor wat meer achtergond het bekijken waard.
https://www.youtube.com/watch?v=3oxrybkd7Mo

[Hatseflats]

Eerlijk gezegd denk ik dat ARM nogal overschat wordt omdat Apple een efficiente CPU heeft utigebracht die toevallig ARM gebruikt.

Nee hoor, x86 is CISC, ARM is RISC. Over het algemeen doet een RISC CPU meer per clockcycle dan een CISC CPU. --> minder warmte.

Dat was dan ook de truuk van Intel. Een auto met min of meer vierkante wielen (CISC) t.o.v. een auto met perfect ronde wielen (RISC). Je kan als Intel iedere keer het vermogen omhoog gooien (een zwaardere motor / hoger wattage) wat je meer brandstof kost (stroom) om dezelfde snelheid te halen of sneller te gaan als een RISC chip, maar op een gegeven moment houdt het op, naast dat het een heleboel warmte genereert. Voor een desktop PC wellicht minder van belang, voor telefoons en laptops e.d. cruciaal.

Wat nu de doorslag heeft gegeven is dat een andere reus nu de RISC chip verder heeft ontwikkeld, nl. Appel, zodanig dat deze CPU ruim is opgewassen tegen alles wat intel te bieden heeft. Het punt is hier geld. Appel heeft geinvesteerd in ARM. Appel heeft niet voor niets Intel de deur gewezen vanwege de warmte problemen.

Op dat punt zijn we nu belandt. Intel loopt tegen de beperkingen van CISC aan, kleiner maken kan niet meer, wat in het verleden wel werkte met hun eigen fabrieken.

Jij denkt het toch niet beter te weten dan al die Appel techneuten? En daar kijken ze ook al verder naar RISC-V i.v.m. licentie kosten.

[Reactie gewijzigd door Hatseflats op 21 december 2024 20:41]

[sympa]

RISC had als voordeel dat de decoder op de chip kleiner was. Maar die decoder is op de schaal van wat er allemaal meer in een moderne CPU zit, helemaal niet belangrijk meer.
Daarom zijn de verschillen zo goed als weggevallen.

[dmantione]

Het is niet belangrijk meer, maar het verschil bestaat ook niet meer: Een "CISC"-processor heeft intern een RISC-pijplijn en een "RISC"-processor heeft intern een CISC-decoder met microcode, want probeer bijvoorbeeld zonder microcode anders maar eens een x86 bij te houden die instructies voor Rijndael-encryptie heeft. Het is niet langer óf-óf, maar én-én, beiden ontwerpfilosofieën hebben hun waarde bewezen.

[Hatseflats]

Waar blijkt dat uit? Dat is helemaal niet zo.

Hooguit hebben ze wat dingen van RISC geleend, omdat het ene nou eenmaal sneller werkt dan het ander.

[dmantione]

Als we een Commodore 64 met d oer-IBM PC vergelijken. Welke is sneller? Op het eerste gezicht denk je dat een 1 MHz 6502 geen partij kan zijn tegen een 4,77 MHz 8088, die ook nog eens 16-bit is.

Maar als we er wat dieper naar kijken, die 4,77 MHz 8088 kan slechts éénmaal per 4 klokpulsen uit het geheugen lezen of schrijven. Een 6502 kan iedere klokpuls met het geheugen communiceren.

Een instructie als:

adc al,[es:bx]

... op een 8088 heeft een lengte van 5 bytes.

adc $34

... op een 6502 heeft een lengte van 2 bytes.

Een 8088 is dus alleen al 20 klokpulsen kwijt om de instructie uit het geheugen te lezen (in totaal kost het 23 klokpulsen), terwijl een 6502 in 2 klokpulsen klaar is met lezen. Een adc op een 6502 kost ook daadwerkelijk 2 klokpulsen.

Op het tweede gezicht is een 1MHz 6502 dan ook veel sneller dan een 4,77 MHz 8088. Een 6502 noemen we geen RISC-processor, de instructieset is namelijk nóg beperkter, maar het idee is het zelde, de CISC is ogenschijnlijk trager.

Maar nu even advocaat van de duivel: Welke processor is nu echt de snelste? Dat is zonder twijfel de 8088. En het antwoord daarop is CISC. Voorbeeld: Een lus. In programma's komen heel veel lussen voor: Een lus van 10 iteraties. Op een 6502:

ldx #10
:
[inhoud van de lus]
dex
bne :-

Op een 8088:

mov cl,10
:
[inhoud van de lus]
loop :-

Loop is een typische CISC-instructie met voor CISC typische beperking dat hij op maar één register gebruikt kan worden (nu ja, cl, cx, of ecx). De instructie kost wel maar twee bytes. De 6502 is 5 klokpulsen kwijt. De 8088 kan nu pas voordeel van zijn 4,77MHz hebben, want het verlagen van register cl vereist geen interactie met het geheugen.

Ander voorbeeld delen:

DIV BX

DIV vreet maar liefst 144-162 klokpulsen op een 8088, maar dat zijn wel klokpulsen op 4,77MHz. Er is no way dat je op een 6502 in minder dan 2000 klokpulsen een 16-bit deling kunt uitvoeren. En die pulsen werken dan op 1 MHz.

Ondanks dat een 6502 meer instructies per seconde uitvoert en er wat synthetische voorbeelden gegeven kunnen worden waarin een 1MHz Commodore 64 sneller is dan een oer-PC, zal in eigenlijk alle gevallen de PC in praktijk sneller zijn.

Hoewel met name in academische kringen vaak neerbuigend gedaan wordt over CISC, het werkt heel goed om een processor meer rekenkracht te geven. Zowat alle RISC-processoren hebben tegenwoordig een instructie die kan delen. Want ja... als een processor niet snel kan delen, is dat een behoorlijk probleem in dat lastige fenomeen dat de praktijk heet. Delen is niet goed te doen met harde bedrading, er is microcode voor nodig en dus hebben RISC-processoren microcode net als CISC-processoren. Niet alleen om te delen, en overigens al héél erg lang.

[Reactie gewijzigd door dmantione op 22 december 2024 18:46]

[Hatseflats]

Nee, want daarom heeft Appel Intel eruit gegooid en draait iedere mobiele telefoon op een RISC chip.

Er is wel degelijk verschil.

[GewoonWatSpulle]

CISC en RISC zijn allebei voertuigen met ronde wielen, als je al een onderscheid wilt maken dan is CISC een station/pickup en/of busje waarbij RISC altijd een hatchback is. Meestal voldoet een RISC hatchback, maar mocht je usecases/workloads hebben dan is CISC multi functioneel voertuig al snel de betere keuze.

[bdbfz]

RISC en CISC zijn ook behoorlijk naar mekaar toe gegroeid in de loop der jaren. Een sun4c uit 1990 had nog geen instructie voor vermenigvuldiging. De compiler moest maar een lusje met optellingen genereren... De huidige RISC instructiesets zijn een pak minder "reduced" dan hun voorgangers ooit waren.

[JeroenED]

Daarnaast komt ook dat risc voor reduced staat, wat gewoon per definitie zuiniger is, maar de definitie van reduced bestaat niet. Gevolg: zowel x86 en arm zijn even complex als reduced.

[jbhc]

Reduced is natuurlijk niet per definitie zuiniger als dit betekend dat je veel meer werk moet verzetten om iets voor elkaar te krijgen.

[Hatseflats]

Je mist denk ik de vergelijking. Intel heeft nu niet voor niets processoren met een hoog verbruik om het bij te benen qua snelheid.

[GewoonWatSpulle]

Oh ja zoals AMD met dezelfde instructie set laat zien dat het anders kan of is dat niet te vergelijken?

[Hatseflats]

Nee, klopt. Die hebben een andere opbouw, met ccx & ccd modules. Dat is denk ik niet zo maar even geimplementeerd.

Daar moet je weer diep voor in de buidel tasten om Jim Keller of zo iemand het te laten ontwerpen.

[Reactie gewijzigd door Hatseflats op 22 december 2024 13:24]

[GewoonWatSpulle]

Grappig genoeg is het CCX en CCD niet perse een positieve bijdrage aan het verbruik, in benchmarks en ruwe prestaties, in dagelijks gebruik wel. Het is voornamelijk een productie kosten oplossing.

[Hatseflats]

Je begrijpt dat we het over RISC en CISC hadden?

Wat Intel en AMD deden t.o.v. RISC is het productieprocess verkleinen om zo voorsprong te behouden op RISC. Naast een klein beetje optimaliseren is het verkleinen reeds opgehouden.

[Reactie gewijzigd door Hatseflats op 22 december 2024 16:30]

[GewoonWatSpulle]

Je gaf aan dat Intel enkel snelheid weet te behouden met hoog verbruik en dat lag aan CISC. Maar AMD kan meer prestaties per watt laten zien met dezelfde instructie set dus is het niet CISC dat het verbruik veroorzaakt. Dus tenzij je verhaal eigenlijk Intel CISC vs. Apple RISC is het dus niet het volledige verhaal.

[well0549]

Is het niet zo dat de Apple chip alleen maar zo snel is omdat het geheugen er direct op zit...

Ik geloof niet dat de instructie set revolutionair is, memory direct naast de processor wel

[Hatseflats]

Dat helpt natuurlijk ook. Over de instructieset kan ik niet oordelen, tenzij iemand die ter beschikking stelt.

Maar ik denk dat het een combinatie is van de instructieset en hardware matige oplossingen op de CPU / SOC. En cache, veel cache.

[Reactie gewijzigd door Hatseflats op 22 december 2024 13:35]

[Powerblast]

Naar wat ik begrepen had zorgt het inderdaad voor obstakels in development van cpus en willen ze er liever vanaf om de ruimte nuttiger te gebruiken. 20j geleden was het misschien een logische transitie stap maar dat punt zijn we vind ik voorbij. Enige optie die dan nog rest is het op software/driver niveau te fixen. Er gaat nog genoeg x86 software de ronde die niet direct geüpgraded zal worden

[Reactie gewijzigd door Powerblast op 21 december 2024 16:40]

[IndoBoy]

Daar waren ze ook allang mee bezig. Dat was toch de iA 64 Intels Itanium processor. Alleen maar 64bit.

[latka]

Nou, niet helemaal. Stel je gaat de interne structuur van de CPU gebruiken in je software dan kan een cpu bakker die nooit meer veranderen. Alles in de IT draait om abstractielagen: ARM is ook een abstractielaag op de onderliggende core: een Apple M of een Snapdragon zijn intern anders en zullen intern andere instructies hebben.
X86 of Arm maakt dus weinig uit. Wel is het zo dat er transistoren nodig zijn voor die abstractie. Dat zijn er bij x86 meer dan bij Arm vermoedelijk (alhoewel Arm ook al wat jaartjes meegaat en zo zijn eigen f*ckups heeft gemaakt: Thumb en Jazalle. Maar volgens mij heeft Arm die gewoon weggelaten, wat x86-s ook zou doen met de rariteiten in de x86 architectuur).
En Intel is ooit begonnen met iets anders (Amd ook, wie kent de 29k architectuur nog?). Intel had de Itanium: daarbij gingen ze over een heel andere boeg (superwide, scheduling in software etc.). Dat werd vervolgens de Itanic en is nu weg.... Er komt heel veel kijken bij het vervangen van een CPU: van het software ecosysteem voor ontwikkelaar (compilers), betaalbare computers voor de massa en compatibiliteit met het verleden, want iedereen wil wel de originele Doom kunnen spelen op zijn computer.

[MSalters]

Nope.

X86 heeft stiekem een paar voordelen. Omdat het ontwikkeld is in een tijd dat elke byte telde, passen er meer x86 operaties in elke cache line. Daarom is alleen de laagste cache een micro-op cache.

Ten tweede is x86 standaard. Ja, elke moderne x86 vertaalt het naar uops, maar niet naar dezelfde uops. Zeker AMD en Intel verschillen, maar ook tussen modellen is er verschil.

[Luuk1983]

ARM is super efficient en perfect voor thuisgebruikers die niet teveel eisen. Maar rauwe performance krijg je amper uit een ARM chip met een veel kleinere instructieset. Beiden hebben hun sterke en zwakke punten, maar ik zie ARM niet snel dominant worden wanneer er harde performance nodig is.

[dmantione]

ARM heeft geen kleine instructieset. Dat is een wijdverbreid misverstand.

x86 heeft bijvoorbeeld LEA waar je in machinetaal leuke dingen mee kunt doen:

LEA EAX,[8*EAX+EAX]

... vermeningvuldigen met 9 zonder de dure vermenigvuldigingsinstructie gebruiken. Op een x86 kan je zo met 2,3,4,5,8,9 vermenigvuldigen. Welnu, op ARM kan dit ook, maar het is veel generieker:

ADD r4, r4, r4, LSL #4

.... vermenigvuldigt bijvoorbeeld met 17.

ARM heeft geen monsterinstructies zoals LOOP, REP MOVSB en dat soort dingen, maar in beginsel verzet een ARM-instructie meer werk dan een x86-instructie.

[bzzzt]

Wel eens gezien hoe een Apple M4 max scoort? Misschien niet de snelste chip op dit moment, maar zeker geen gebrek aan 'rauwe performance'.
Dezelfde performance bij Intel komt met een veel hoger verbruik.

[Luuk1983]

Jazeker, het zijn fantastische efficiënte chips, maar er zijn zover ik weet nog geen ARM processors die de rauwe performance hebben van de high end x86 chips in veel scenario's.

[sympa]

Dat ligt meer aan dat de niche waar ARM in zit die vraag niet heeft. Geen 14900K processor, maar meer de sweet sport van power/performance opzoeken.
En ook qua data center is de vraag er nog niet.

[Reactie gewijzigd door sympa op 21 december 2024 21:21]

[bzzzt]

Je kan bij diverse cloud aanbieders al kiezen voor ARM servers van bv Ampere.
De vraag naar zuiniger verwerken wordt bij stijgende energieprijzen groter dan de vraag om heel veel taken in een enkele, minder efficiënte, machine te draaien.

De 'rauwe performance' van de top end x86 chips is voornamelijk te danken aan het combineren van ontzettend veel cores. Single core performance is niet heel hard vooruit aan het gaan...

[well0549]

Komt dat niet vooral omdat het memory op de processor zit.....

De instructie set is bij mijn weten totaal niet revolutionair

[bzzzt]

Ik reageerde op @Luuk1983 die stelt dat ARM geen rauwe performance kan bieden.
Volgens mij is de instructieset hierin niet de beperkende factor.
Geheugen dicht op de CPU is nuttig voor applicaties die veel geheugen gebruiken, maar niet per se beperkend voor rekenbenchmarks.

[RJG-223]

Dus eigenlijk is het tijd om die vertaalslag in software te steken en het hele x86 boeltje buiten te flikkeren.
Vat ik het zo goed samen?

Dat zou weinig zin hebben. Ten eerste zouden de instructies dan zo simpel worden dat er veel meer van nodig zijn. Dan gebruikt elk programma ineens 2x zoveel geheugen (of zo), en is er dus ook meer geheugen-bandbreedte nodig om al die simpele instructies tijdig bij de CPU te krijgen. Veel makkelijker om een paar complexe instructies uit het geheugen te laden, en intern te vertalen naar veel meer simpele instructies.

Daarnaast kun je sowieso niet buiten die vertaalslag, omdat een 2-byte of 4-byte, of evt. 8-byte instructie veel te weinig informatie bevat om de hele CPU aan te sturen. Dus moet die sowieso vertaald worden.

Verder kun je de cruft wel wegsnijden, maar dan draaien bestaande/oude programma's niet meer, en dan kopen de klanten liever een CPU die dat allemaal nog wel draait.

Als laatste, als je dan de cruft weggesneden hebt, dan wil de CPU-ontwerper een paar jaar later toch weer iets aan de CPU veranderen, en moet dan toch weer intern gaan vertalen, zodat je binnen no-time weer nieuwe cruft krijgt. Je blijft dus altijd een interne vertaler nodig hebben. Dan kun je die net zo goed nuttig gebruiken...

[MSalters]

ARM 32 laat zien dat 32 bits instructies meer dan voldoende informatie bevatten. Thumb16 mode laat zien dat 16 bits dat niet heeft, maar elke extra bit geeft 2x zoveel mogelijke instructies. 16 extra bits is 65536x zoveel. 8 bytes is ridicuul.

X86 kan nog veel langer, in theorie, maar dat is een variabele lengte. Beter 1% een extra byte om in 25% van de instructies een byte te besparen.

[RJG-223]

ARM 32 laat zien dat 32 bits instructies meer dan voldoende informatie bevatten. Thumb16 mode laat zien dat 16 bits dat niet heeft, maar elke extra bit geeft 2x zoveel mogelijke instructies. 16 extra bits is 65536x zoveel. 8 bytes is ridicuul.

X86 kan nog veel langer, in theorie, maar dat is een variabele lengte. Beter 1% een extra byte om in 25% van de instructies een byte te besparen.

Ik zeg niet dat 2^32 instructies niet voldoende is. Ik zeg dat 32 bits niet voldoende is om direkt (zonder vertaalslag) alle stuursignalen en registers aan te sturen die er in een CPU zitten. Het gaat dus niet om het aantal benodigde instructies, maar om het aantal benodigde stuursignalen. Dat zijn er meer dan 32, zelfs meer dan 64.

[dmantione]

Ja, dat kan, maar er wordt nog veel 32-bit applicatiesoftware gebruikt. 50% minder fps in een spel kan reden zijn voor een slechte recensie, zelfs al is dat een heel oud spel. Een processor moet niet in 90% van de situaties bruikbaar zijn, de lat ligt veel hoger. Vandaar dat 32-bits applicatiesoftware buiten schot zou blijven en voornamelijk 32-bits besturingssystemen en 16-bits software getroffen zouden worden.

[Thekilldevilhil]

Ik snap de link tussen ineens 50% lagere fps hebben en 64bit only cpus even niet?

[Reactie gewijzigd door Thekilldevilhil op 21 december 2024 17:39]

[dmantione]

Software-emulatie heeft nogal een overhead.

[bzzzt]

Een goed geschreven emulator met just in time code generatie gaat geen 50% overhead hebben.

[MSalters]

32 bits op x86S is natuurlijk geen generieke emulatie. Het memory model en cache coherentie is identiek, register mappings zijn triviaal. Bovendien kan de emulatie hardwarematig versneld worden. Gangbare sequenties kunnen met uop fusion worden gecombineerd.

[bzzzt]

Vergeet het belangrijkste niet aangezien de thread post over fps ging: games gebruiken de GPU voor rendering, niet de CPU. Die eerste gaat veel meer impact hebben op fps dan een mogelijke CPU bottleneck.

[uiltje]

Dat geld vooral voor moderne games. Dus dat is minstens wat kort door de bocht als je het over 32 bit games hebt...

[bzzzt]

Als het zo oud is maakt de emulatie overhead ook niks meer uit.

[uiltje]

Bij hoe veel 32 bit applicaties die alleen draaien op een 32-bit OS zal die emulatie overhead nou werkelijk uitmaken? Ik ben daar erg benieuwd naar, ik kan me echt niet voorstellen dat het er veel zullen zijn. 32-bit games zijn sowieso wel geschreven met variabele snelheid HW in mind, en ze zullen meer afhangen van de GPU (Voodoo enzo). Het beetje overhead maakt niet uit als de beginsnelheid veel hoger ligt.

[bzzzt]

Volgens mij zeggen wij hetzelfde

[uiltje]

Ah, OK, ik ging uit van een tegenargument. My bad.

[Navi]

Worden er nu nog nieuwe 32-bit games uitgebracht?

[dmantione]

Ik denk niet veel, maar ik sluit het niet uit. Zeker voor de meer casuele spellen kan ik me voorstellen dat programmeurs om wat voor reden dan ook besluiten voor 32-bit te compileren.

[bzzzt]

Misschien voor hobbymatige dingen. Games die een van de grote engines gebruiken zijn 64 bits. Games die op mobieltjes moeten draaien zijn 64 bits.
Misschien is er nog een markt voor games voor antieke computers, maar die zal 18 jaar nadat iedere nieuwe CPU 64 bits compatible is geworden niet heel groot meer zijn.

[dmantione]

Er kunnen meer redenen zijn dan antieke computers. Op Windows is men vrij laat met 64-bit begonnen, Windows XP is vrijwel alleen in 32-bit gebruikt. Linux is veel sneller overgeschakeld. Een programma staat vaak niet op zichzelf en gebruikt code van derden. Er kunnen 32-bits softwarebibliotheken zijn waar geen broncode van is. Een spelstudio kan een eigen 3D-engine hebben waar 32-bit machinetaal in gebruikt wordt. 32-bit code gebruikt minder geheugen. Dat soort dingen.

De grote engines zijn natuurlijk allemaal al vele jaren over, maar kenmerk van x86 is juist dat het een enorm breed gebruik heeft en als gevolg iedereen in eigen tempo vernieuwt. Juist omdat x86 zo breed is, is het ook niet zo eenvoudig te zien of alles inmiddels overgeschakeld is.

[Reactie gewijzigd door dmantione op 22 december 2024 17:09]

[bzzzt]

Windows XP is meer dan 10 jaar geleden end-of-support gegaan. Alle hardware en OSen die sinds die tijd zijn uitgebracht zijn 64 bits compatible.
Van studio's verwacht je juist dat ze zien waar de technische bal heenrolt ipv dat ze wachten tot ze door legacy beperkt worden. En moderne 100+Gb games bouwen wordt een forse uitdaging als je je beperkt tot een 32 bits model.

Breed gebruik is geen probleem, nieuwere 64 bits processoren zullen 32 bits software nog steeds prima kunnen emuleren. Voor een casual game zal dat niet veel uitmaken.

[hbvdh]

Hoi, hier maak je een kleine fout, alle (Intel) processoren sinds de Pentium Pro hebben een 36bit of groter geheugenregister en konden dan ook meer dan 4 GB (32bit limiet) adresseren. Windows Server 2000 Advanced kon dan ook 16 GB geheugen gebruiken terwijl het gewoon een 32bit OS was.
Dat er in Windows Xp vaak maar 2 á 2,5 GB beschikbaar was had twee redenen.
1- MS had problemen met drivers (3rd party) welke niet goed om konden gaan dan hoger dan 4GB adresseren en daarmee grote stabiliteits problemen opleverde.
2- Het video geheugen is eigenlijk ook systeem geheugen en omdat het geadresserd onder de 4GB moets worden werd het van het systeemgeheugen afgetrokken.

[dmantione]

Wat je schrijft klopt, maar ik zie niet waar de tegenspraak is met wat ik schreef?

[hbvdh]

Hoi ik wou reageren op een bericht dat 32 Bit winxp maar 2GB ondersteunde, verkeerde aangeklikt, kan die niet zo snel meer vinden.

[RJG-223]

Ik weet hier niet heel veel van, maar als je een 64-bit only CPU maakt, kun je dan niet gewoon alles qua 32-bit emuleren?

Is niet nodig. de 64-bit x86-lijn ondersteunt ook 32bit en 16 bit instructies, en kan gewoon 32bit en 16bit programma's draaien. Geen enkele emulatie nodig. En als je goed leest, dan zie je dat ondersteuning voor 32bit software (en ik neem aan ook 16bit software) er juist niet uitgesloopt zou worden.

Het zal trager zijn dan native maar CPU's zijn tegenwoordig snel zat om oude software in 32-bit te emuleren denk ik?

Mensen die nog bepaalde 32bit software nodig hebben, willen die niet extra langzaam draaien. Of denk jij dat het alleen maar om spelletjes gaat, of andere software voor eindgebruikers dzoals jij ie sowieso meestal een CPU hebben dit zwaar overpowered is ?

[bzzzt]

Mensen die nog bepaalde 32bit software nodig hebben, willen die niet extra langzaam draaien. Of denk jij dat het alleen maar om spelletjes gaat, of andere software voor eindgebruikers dzoals jij ie sowieso meestal een CPU hebben dit zwaar overpowered is ?

Als het echt zo belangrijk is dat software snel draait is het al lang gecompileerd voor 64 bits. Je krijgt op dezelfde CPU dan al betere performance vanwege grotere registers etc.
Het lijkt mij vreemd dat je aan de ene kant performance belangrijk vindt en je aan de andere kant vastbindt aan een antiek stuk software wat niet optimaal loopt op moderne systemen.

[kdekker]

De hoofdreden dat we, jaren geleden al over moesten stappen op 64-bit, was geheugen adres ruimte. Met 64-bit werd de 2GB (met foefjes iets meer) geslecht. De prijs was ca 30% meer geheugengebruik, voor dezelfde software (die 30% is applicatie afhankelijk).

Een tweede reden was dat database leveranciers geen 32-bit client library leverden en voor C/C++ moest je dan ook zelf 64-bit worden in tegen de 64-bit rdbms clien library te kunnen linken.

Intussen werd op Windows de 32-bit laag een soort van extra laag (Syswow64) op een 64-bit OS (waar maf genoeg de systeem directory nog steeds system32 heet). Daardoor werd 32-bit een fractie trager (dat zat in Windows, niet in de CPU). Linux had hier geen last van. Maar ook daarvan is 32-bit alleen nog in de embedded wereld nuttig (iig niet meer voor pc's en servers).

Al met al wordt 64-bit onterecht als sneller gezien, domweg omdat 64 meer is dan 32 en meer kennelijk beter is. Het was niet sneller, het gebruikte meer geheugen (je moet die 8-byte pointers ergens opslaan), maar bood gelijk de mogelijkheid om simpel meer dan 2 (of 4) GB te adresseren voor 1 programma. En daarmee was de drempel om efficiënt te programmeren wbt geheugengebruik ook weg (dat is niet helemaal waar, maar was wel een indirect gevolg).

[bzzzt]

Al met al wordt 64-bit onterecht als sneller gezien, domweg omdat 64 meer is dan 32 en meer kennelijk beter is. Het was niet sneller, het gebruikte meer geheugen (je moet die 8-byte pointers ergens opslaan), maar bood gelijk de mogelijkheid om simpel meer dan 2 (of 4) GB te adresseren voor 1 programma.

64-bits x86-64 CPUs hebben grotere registers waardoor 64 bits code daadwerkelijk sneller draait voor veel CPU gebonden bewerkingen.
Daarnaast was er oorspronkelijk een 32 bits "ABI" model waarmee je 64 bits code kon gebruiken met 32 bits pointers (waarmee je effectief je applicatie tot max 4Gb limiteerde). Het lijkt er alleen op dat het veel werk voor weinig winst was.
Voor wat het waard is: moderne Java VM's kennen een modus waarbij 32 bits referenties via een lookup table naar 64 bits adressen worden omgezet (je hebt dan een beperking van 4 miljard objecten in je systeem wat veel meer is dan 4Gb), dus er wordt wel degelijk geprobeerd zo efficient mogelijk om te gaan met geheugen.

En daarmee was de drempel om efficiënt te programmeren wbt geheugengebruik ook weg (dat is niet helemaal waar, maar was wel een indirect gevolg).

Die drempel bestaat al niet meer op iedere plek waar de investering in geheugen goedkoper is dan programmeurs salarissen betalen voor extra optimalisatie.

[RJG-223]

64-bits x86-64 CPUs hebben grotere registers waardoor 64 bits code daadwerkelijk sneller draait voor veel CPU gebonden bewerkingen.

Alleen als je daardwerkelijk iets nuttigs kunt doen met die extra 32 bits. Anders kan het zelfs langzamer zijn. 64bits floating point is langzamer dan 32bits.

Verder maak je je er wel heel makkelijk van af door te zeggen 'voor CPU gebonden bewerkingen'. Dat zijn veel dingen in de praktijk niet.

Die drempel bestaat al niet meer op iedere plek waar de investering in geheugen goedkoper is dan programmeurs salarissen betalen voor extra optimalisatie.

Sommige toepassingen gebruiken veel geheugen. Hoe efficiënter je dan het geheugen gebruikt, hoe sneller het gaat. 32 bits is efficienter met geheugen dan 64bits. Je kunt dubbel zo veel 32bits getallen en/of pointers per seconde uit het geheugen lezen als 64bits getallen/pointers, en je hebt voor hetzelfde aantal getallen minder TLB entries nodig (zodat de kans op TLB misses minder is, waardoor er minder onnodige vertraging is) en minder CPU cache, waardoor je hele dataset misschien net wel in de cache past in plaats van net niet. En dan heb ik het nog niet eens over de mogelijkheid dat je hele dataset misschien wél in het geheugen past met 32bits data/pointers, terwijl je moet swappen met 64bits, wat nog eens een paar orders van grootte langzamer is.

Investeren in geheugen is makkelijk zat voor eenvoudige applicaties. Maar als geheugenbandbreedte de beperkende factor wordt, of als je berekening een week draait in plaats van twee weken als je het TLB gebruik of het cache-gebruik optimaliseert, dan is die extra programmeur misschien wel de moeite waard. Zeker als je de resultaten zo snel mogelijk wilt.

En wat dacht je van een supercomputer. Denk jij dat je zo maar even in bijv. 32000 nodes alle 16 16GB DIMMs per node vervangt door 32GB DIMMs om het geheugen te verdubbelen ? En denk je dat je überhaupt het geheugen in de GPU compute kaarten in die nodes kunt vervangen ?

[bzzzt]

Verder maak je je er wel heel makkelijk van af door te zeggen 'voor CPU gebonden bewerkingen'. Dat zijn veel dingen in de praktijk niet.

Veel applicaties hebben ook baat bij een grotere adresruimte, maar jij had het over snelheid.

Investeren in geheugen is makkelijk zat voor eenvoudige applicaties.

Ik denk dat de grote meerderheid van de applicaties die op dit moment geschreven worden dat zijn.
Misschien nu iets meer omdat bedrijven er achter komen dat hun cloud kosten uit de pan rijzen, maar dan nog is een 'all over the map' optimalisatie een extreem dure ingreep versus een paar duizend euro per jaar meer betalen.

[HollowGamer]

Ze kunnen dit toch al doen in de x86 specificaties? Dus een sub versie van x86. Je hebt dacht ik al v2 en v3.

Deze gaat natuurlijk wel een stap verder, maar je kunt als CPU producent toch aangeven wat er wordt ondersteund?

Is het overigens zo dat de chipset ook hier een rol in speelt?

[SG]

Op AMD64 kan 32bit versie van windows en 32bit applicaties draaien.
X86-S zal 32bit OS maar ook 32bit apps niet meer draaien. optie is emulatie niet meer native.
Voor een X86-S CPU moet je een 64bit versie van app en OS hebben of 32bit emulator

[RJG-223]

X86-S zal 32bit OS maar ook 32bit apps niet meer draaien. optie is emulatie niet meer native.

Dat klopt niet. X86s zou inderdaad geen 32bit OS meer draaien, maar wel nog steeds alle bestaande of nieuwe 32bit apps. Niets emulatie. Staat ook in het artikel.

[ari3]

Het artikel verdient wel wat duiding, want niet alle 32bit apps zullen werken. 32-bit Linux, BSD en Window apps zullen wel werken, maar om onder DOS een 32-bit applicatie te starten is een zogenaamde DOS-Extender (een populaire was DOS/4G) noodzakelijk. Die DOS-extender gebruikt dezelfde CPU-instructies die 32-bit besturingssystemen gebruiken om het 32-bit geheugen- en ringmodel te initialiseren. En dat zijn dus juist de instructies die Intel voorstaat te verwijderen.

Doom starten vanuit DOS zal niet meer werken als het aan Intel ligt.

[Reactie gewijzigd door ari3 op 21 december 2024 22:19]

[RJG-223]

Doom starten vanuit DOS zal niet meer werken als het aan Intel ligt.

Ik denk dat het enige wat niet meer kan, is DOS direkt booten. Er zal een 64bit executive tussen moeten zitten, die in 64bit modus kan booten, en die dan een VM opstart die elk legacy OS in 16bits modus kan booten. Alle afgeschafte instructies zal die executive dan emuleren. De eindgebruiker merkt in het dagelijks gebruik het verschil waarschijnlijk niet.

Dt is aangenomen dat ze 16bit modus niet afschaffen. Dan zou het inderdaad wat moeilijker worden. Maar als DOOM een 32bit applicatie is, dan zal het misschien wel mogelijk zijn om hem in z'n eigen 32bit VM op te starten en te draaien. De software daarvoor moet dan nog wel geschreven worden - als 16bit modus afgeschaft wordt dus.

[dmantione]

16-bit zou eruit gaan en is wordt nu al geblokkeerd als het besturingssysteem de processor tijdens het opstarten in 64-bit mode zet. Dat is de reden dat een 64-bit Windows geen 16-bit software kan draaien. Emulatie d.m.v. DOSEmu kan natuurlijk prima.

Intel had een voorziening in X86-S ingebouwd om het voor virtualisatiesoftware efficiënter te maken om 16-bit instructies te emuleren.

[dmantione]

Ik denk dat dat heel goed mogelijk is: DPMI. DOS/4G zal als hij DPMI detecteert niet zelf besturingssysteem gaan lopen spelen, anders zou een DOS-spel niet onder Windows of Dosemu kunnen werken, hij gaat met DPMI praten om de adresruimte voor de 32-bits DOS-applicatie in te richten.

De 16-bit DOS-omgeving zou via software-emulatie gerealiseerd moeten worden. In die emulatie zouden DPMI-diensten beschikbaar moeten zijn. De DPMI-implementatie van de emulator kan dan prima een niet-geëmuleerde 32-bit omgeving voor het DOS-spel ingerelen, zodat het op volle snelheid kan draaien.

De andere kant van het verhaal is dat DOS inmiddels zo lang geleden is, dat je je af kunt vragen of je voor het gemak niet beter alles kunt emuleren. Weinigen zullen nog behoefte hebben aan de rekenkracht van een moderne processor onder DOS.

[uiltje]

Ik zou graag nog een keer een spel spelen wat nog voor de oude AT snelheid is gemaakt zonder timer. A10 tank killer waarbij je na het opstarten naar "Turbo" schakelde bijvoorbeeld. Waarschijnlijk site je alleen een flits voordat je crashed

[uiltje]

Slecht voorbeeld want de Doom code is vrijgegeven maar we snappen wat je bedoelt

[Blokker_1999]

x86 is en blijft neerwaarts compatibel. Je kan vandaag nog altijd netjes iets als PC-DOS 4.0 starten op een moderne Ryzen 9000 CPU net omdat deze nog altijd in 16 but modus start. Intel wenste met deze -S variant dat er dus uit te halen, dat de CPU direct in een 64-bit modus zal zitten en dus enkel nog maar een 64bit OS zal ondersteunen.

[SillieWous]

Ik vraag me altijd af waarom alles tot in den treure compatibel moet blijven. Ze kunnen beter iets zeggen als “de 32bit-isa is nog 5 jaar supported in nieuwe CPUs” daarna moet je legacy CPUs gebruiken. Wellicht nog extended support voor bepaalde CPUs.

Zelfde gebeurt ook met OSen. 5 jaar LTS support en eventueel nog 10 jaar extended support. (Getallen zijn natuurlijk als voorbeeld).

[RJG-223]

Ik vraag me altijd af waarom alles tot in den treure compatibel moet blijven

Dat hoeft niet, maar dat is wel de weg van de minste weerstand. En mensen lopen bij voorkeur (bijna) allemaal als lemmingen achter elkaar aan langs de weg van de minste weerstand, want dat is op korte termijn het goedkoopst en het makkelijkst (duh!)

[TheMak]

Dat kan, dan zegt AMD na vier jaar, we supporten alles nog wel even. En dan zegt onze ICT afdeling we gaan over op AMD

[SillieWous]

Geloof ik geen reet van. Bij ieder standaard bedrijf wordt deze functionaliteit totaal niet gebruikt. Of draaien jullie ook nog een volop Linux dozen uit het jaar 0? De markt die echt nog zo’n oude meuk wil/moet draaien, is heel klein.

[kdekker]

Ik denk dat toegang tot hardware icm een modern bios en file system praktische problemen op zal leveren onder de streep weinig werkt.

[oudengrijs]

Au! Was dat nu nodig? Een opmerking over DOS 3.3 of DOS 5.0 trek ik nog wel. Maar iedereen die het destijds moest ondersteunen zal de herinnering aan DOS 4.0 liever uit het bewustzijn verdringen.

[RJG-223]

Deze gaat natuurlijk wel een stap verder, maar je kunt als CPU producent toch aangeven wat er wordt ondersteund?

Ja. Maar hoe gaat jij die CPU dan in gebruik nemen ?

Stel je koopt een PC met nieuwe CPU volgens x86s architectuur. Je stopt de CD/DVD erin, of de USB-stick, voor OS installatie (Windows, Linux, etc.), en die boot dan dus niet. Want x86s boot op een heel andere manier dan x86, en dat ondersteunen de bestaande OSen niet. Dus heb je een dure doos waarmee je niets kunt. Hopelijk heb je er dan mooie LED verlichting en fans in zitten, kun je daar nog van genieten...

En dan heb ik het nog niet eens over de BIOSen, die die nieuwe manier ook niet ondersteunen, en dus ook niet zullen werken op de nieuwe CPU variant.

Natuurlijk zul je dan zeggen dat een OS, en de BIOS, overal mee rekening kunnen gaan houden. Mee eens. maar dan moeten ze wel weten wat ze precies wel en niet kunnen verwachten, en hoe die nieuwe variant precies werkt. En dat is dus precies wat Intel aan het ontwikkelen was: een gedetailleerde specificatie van hoe die nieuwe variant werkt, zodat BIOS en OSen die kunnen gaan ondersteunen, en zodat de eindgebruiker daarvan niets hoeft te merken. Maar ja, dat kost tijd en moeite, en geld, en dat is op dit moment een beetje een probleem voor Intel...

[bzzzt]

Je operating systeem kan toch aangepast zijn aan de nieuwe architectuur?
En die media download je gewoon bij de OS leverancier die een compatible versie aan kan bieden?
Als je dan per se MS-DOS 6.22 of een ander stuk antiek wil draaien doe je dat in een emulator.

[RJG-223]

Je operating systeem kan toch aangepast zijn aan de nieuwe architectuur?
En die media download je gewoon bij de OS leverancier die een compatible versie aan kan bieden?
Als je dan per se MS-DOS 6.22 of een ander stuk antiek wil draaien doe je dat in een emulator.

Dat is toch precies wat ik ook al zeg. Maar dat gaat allemaal toch niet vanzelf ? Intel kan niet gewoon die nieuwe CPUs uitbrengen, want dan kan niemand ze gebruiken. Als het om een eenvoudige uitbreiding ging van een bestaande CPU, zoald AVX512, kan dat wel. OSen die die uitbreiding niet herkennen, die gebruiken 'm niet. maar die kunnen de rest van de CPU wel gebruiken. Met deze verandering is de hele CPU onbruikbaar als het OS niet specifiek daarop aangepast is. Dus moet deze verandering in detail gespecificeerd zijn. Daarna moeten de partners (BIOS leveranciers, OS leveranciers) hun software aanpassen, en testen (als ze daar zin in hebben - ze moeten dus eerst ook nog eens overtuigd worden dat dit zinvol is!). Pas als die hun nieuwe BIOS/OS aangepast, getest en uitgebracht hebben, dan kunnen er überhaupt computers met die CPU erin verkocht gaan worden.

[bzzzt]

Met deze verandering is de hele CPU onbruikbaar als het OS niet specifiek daarop aangepast is.

Als je verder dan x86 kijkt is dat precies wat Apple doet. Nieuwe machines worden vanaf een bepaalde macOS versie ondersteund en je kan nooit terug naar een OS versie ouder dan de machine.

Maar voor Intel systemen valt het wel mee, als je boot via UEFI is x86-64 al ingeschakeld dus het blijft bij een kleine aanpassing (en een hoop verwijderde code) in de BIOS implementatie.
Mogelijk dat Microsoft een aangepaste Windows moet uitbrengen als ze 16 en/of 32 bits via emulatie willen ondersteunen, maar voor 64 bits moest ook een nieuwe Windows uitgebracht worden dus dat kunnen ze vast wel

[MSalters]

Er zijn geen "x86 specificaties" en ook geen v2 of v3.

Die v2 en v3 zijn beschrijvingen van ring 3 (applicatie) ISAs, waarbij een gemeenschappelijke deler van Intel en AMD woedt beschreven. Maar met alleen al SSE1-4 en AVX tot -512 heb je al een dozijn versies.

[dasiro]

Geen nieuw Itanium debacle dus. Jammer langs de ene kant, want ze slepen een hoop ballast mee uit het verleden, maar gelukkig langs de andere kant, om een hoop compatibility issues en hoge kosten te vermijden.

[PolarBear]

Compatibility met 32-bits OS'en? Dat hadden we wel kunnen missen toch?

[RJG-223]

Compatibility met 32-bits OS'en? Dat hadden we wel kunnen missen toch?

De simpele eindgebruiker die alleen de laastste, en mogelijk voorlaatste versie van Windows draait wel. Maar niet hele wereld draait om dat soort gebruikers. Zakelijke gebruikers, met specifieke applicaties en spefcifieke OSen kunnen dat nog lang niet zomaar missen. Dat jij het kunt missen, of denkt dat je het kunt missen, betekent niet dat dat ook voor de hele wereld geldt.

[field33P]

Op menig Windows-computer draaien nog genoeg exe's in 32-bitsmodus, ook voor thuisgebruikers. Dus het dumpen van i386 gaat nog jaren duren.

[MSalters]

Die kun je prima een dure Xeon verkopen. Het idee hier is dat je in een low power low budget laptop alle overhead kwijt wil.

[SuperDre]

Maarja, als je nog zo afhankelijk bent van een 32-bit OS, dan ga je waarschijnlijk toch al niet voor nieuwere CPU's. Denk toch echt wel dat de meeste zakelijke gebruikers dus die 32-bit ondersteuning kan missen in nieuwere x86 CPU's.

[RJG-223]

Maarja, als je nog zo afhankelijk bent van een 32-bit OS, dan ga je waarschijnlijk toch al niet voor nieuwere CPU's. Denk toch echt wel dat de meeste zakelijke gebruikers dus die 32-bit ondersteuning kan missen in nieuwere x86 CPU's.

Zakelijke gebruikers zijn niet alleen consultants of administratief personeel met een PC. Of web- of ecommerce servers in een datacentrum. Dat zijn ook embedded systemen voor allerhande apparaten, die een embedded OS draaien wat nog 32 bits is, omdat niemand het nog nodig vond het te porten naar 64 bits. Want dat kost geld, en het levert niets op, want op 32 bits draait het even goed. Maar ze willen misschien wel een nieuwe CPU, want dat gaat wel sneller.

[SuperDre]

Maar dan hebben ze nog meer dan genoeg keuze uit snellere CPU's, en op den duur zul je toch de software moeten vervangen. Let wel, 32-bit applicaties werken dus nog steeds wel op (bepaalde) 64-bit OSsen, dus dat zal dan met embedded OSsen niet anders zijn. Grote kans dat een oud 32-bit embedded OS ook niet eens meer fatsoenlijk draait op een splinternieuwe 32-bit CPU.

[FreezeXJ]

Voor wie de ballast achter zich wil laten is er gewoon RISC-V, maar dan mag je dus weer netjes opnieuw beginnen. Inmiddels keurig gesupport door de grote compilers (en Linux zelf), maar een ecosysteem bouw je niet zomaar. De enige die ik nu succesvol in staat acht om dat te doen is Apple, die ook hun eigen ARM-versie nu keurig geaccepteerd hebben gekregen. De rest is te Windows-afhankelijk, en te gebonden aan (inerte) 3e partijen voor software.

[dasiro]

ik denk dat je vergeet dat er enorm veel datacenter-servers net NIET op windows draaien en dat wat Apple doet het tegenovergestelde is van wat er met x86 bereikt is. Ik vrees dat je de term ecosysteem veel te nauw ziet en verengt tot een volledig gesloten omgeving, want er is letterlijk geen enkele andere OS of CPU-fabrikant die er producten voor op de markt kan/mag brengen, op 1 (wat ik noem shell-company) na die een onbekende linux distro mag uitbrengen.

[sympa]

Volgens mij is RISC-V er nog helemaal niet qua performance.

[uiltje]

RISC V is voor mij vooral een nieuw platform. Voor het echte werk heb je extensies nodig en we weten nog niet hoe dat gaat uitpakken wat betreft compatibiliteit. Vooral leuk voor makers van embedded devices die geen IP-rechten willen betalen voor de ISA als je het mij vraagt... In ieder geval voor nu, ik heb ook geen grote glazen bol.

[catfish]

Welke compatibility issues?
Wie draait er op een moderne intel of AMD cpu nog MS-DOS?
Voor de meeste nieuwe hardware zijn geen WindowsXP drivers te vinden.
Om 32bit software te laten draaien in Windows (of linux) kunnen ze toch wel een emulator maken lijkt mij. Het zal wel trager zijn, maar dat lijkt mij niet het probleem aangezien moderne cpu's een veelvoud sneller zijn dan de cpu's uit het 32bit tijdperkt.

[RJG-223]

Wie draait er op een moderne intel of AMD cpu nog MS-DOS?

Volgens mij maakt sommige BIOS-update software, die vanaf USB-stick gedraaid wordt, nog gebruik van FreeDOS, dat nog 16 bits modus nodig heeft, zover ik weet (CMIIW)

Voor de meeste nieuwe hardware zijn geen WindowsXP drivers te vinden.

Zat mensen kunnen dat soort drivers makkelijk zelf schrijven. En FreeDOS, en andere OSen die 16-bits modus nodig hebben, draaien niet op Windows XP. Dus het is compleet irrelevant welke drivers wel of niet beschikbaar zijn voor Windows XP.

Om 32bit software te laten draaien in Windows (of linux) kunnen ze toch wel een emulator maken lijkt mij

Is niet nodig. Dat soort software draait zonder probleem en zonder emulatie op 64-bit Linux of Windows. Op volle snelheid. En de ondersteuning voor 32-bit software zou er juist NIET uitgesloopt worden. Alleen de ondersteuning voor native 32bit en 16bit OSen.

[kars noordhuis]

Volgens mij maakt sommige BIOS-update software, die vanaf USB-stick gedraaid wordt, nog gebruik van FreeDOS, dat nog 16 bits modus nodig heeft, zover ik weet (CMIIW)

Zou dit niet door een moderne, lichtgewicht linux distro overgenomen kunnen worden? Iets als alpine ofzo?
Daarbij zou er bij de ontwikkeling van nieuwe moederborden rekening mee gehouden kunnen worden natuurlijk.
Voor industriele toepassingen waar dos nog nodig is is het een ander verhaal maar wellicht zouden die beter een speciale LTS 16 bits chip kunnen krijgen dan.

[RJG-223]

[...]

Zou dit niet door een moderne, lichtgewicht linux distro overgenomen kunnen worden? Iets als alpine ofzo?
Daarbij zou er bij de ontwikkeling van nieuwe moederborden rekening mee gehouden kunnen worden natuurlijk.
Voor industriele toepassingen waar dos nog nodig is is het een ander verhaal maar wellicht zouden die beter een speciale LTS 16 bits chip kunnen krijgen dan.

Kan allemaal wel, in principe, maar het gebeurt nu op een bepaalde manier, en iets anders doen, dat kost moeite, tijd en geld. Bedrijven zijn allergisch voor geld uitgeven als dat niet hoeft. Daarom gebruiken ze waarschijnlijk FreeDOS. Omdat het vroeger op MSDOS draaide, en FreeDOS een makkelijk alternatief was, en bovendien gratis. Bijkomend voordeel van FreeDOS, is dat het geen multitasking is, en dat er niet TALLOZE andere activiteiten plaatsvinden tijdens de update, zodat je niet allemaal moeite hoeft te doen om te zorgen dat andere processen, of het OS zelf, de BIOS-update niet in de weg zitten. Dat kun je onder Linux en WIndows misschien ook wel bereiken, maar dat kost allemaal moeite, en FreeDOS ontbeert al die complexiteit van Windows en Linux, zodat je ook geen moeite hoeft te doen om die complexiteit te omzeilen.

En daarnaast kun je FreeDOS makkelijk samen met je update verspreiden, zonder dat een 4MB BIOS-update bestand ineens een 4GB download wordt.

[kars noordhuis]

En daarnaast kun je FreeDOS makkelijk samen met je update verspreiden, zonder dat een 4MB BIOS-update bestand ineens een 4GB download wordt.

Daarom kaartte ik alpine linux ook aan. Gemaakt voor die docker container meuk dus errug klein. 130mb schijfruimte voor de volledige install met de mogelijkheid om onnodig spul weg te halen.

Efin, zoals field33p al aangaf: dit soort dingen kunnen tegenwoordig vaak al vanuit de UEFI of zelfs vanuit windows! Scheelt weer gehannes!

[dmantione]

De BIOS-boeren AMI en Phoenix hebben al lang tooltjes om vanuit DOS, Windows, Linux en UEFI-prompt het BIOS te updaten. Een moederbordfabrikant heeft alleen niet altijd zin om al die tooltjes voor een mobo beschikbaar te maken. In het grote plaatje is het dan ook een non-probleem, als een processor geen DOS kan draaien, schakelen de fabrikanten heel makkelijk over op één van de andere tooltjes.

[field33P]

Inmiddels kunnen de meeste UEFI-implementaties gewoon zichzelf updaten vanuit Windows, dan wel vanuit het UEFI-menu.

[kdekker]

Itanium is, voor zover ik weet, nooit gepositioneerd geweest als cliënt/desktop/laptop product, maar altijd als server chip, voornamelijk omdat HP van hun PA-RISC af wilde (die overigens toen ook al een 64-bit evenknie had). Voor de server kant klopt het waarschijnlijk wel wat je zegt, maar dat Itanium heel x86 (32-bit) moest vervangen, betwijfel ik.

Er zijn wel features uit Itanium in Xeon gekomen en prijs/prestatie was die gewoon veel beter. AMD speelde toen maar een beperkte rol. Wel is de 64-bit extensie van AMD ongeveer dezelfde tijd (rond de eeuwwisseling) ontstaan. Maar - mijn geheugen laat me iets in de steek - dacht al eerder met een Intel prototype gewerkt te hebben (Merced) wat een voorloper was van Itanium. En maf genoeg, dat was met een Windows versie. Weet niet meer welke (een NT versie). Windows Server bestond toen nog niet eens.

Reactie was bedoeld op @CAPSLOCK2000, maar kwam toch hier (de browser op mijn telefoon stuitert wat bij edit)

[Reactie gewijzigd door kdekker op 21 december 2024 15:38]

[Blokker_1999]

Intel was, voor zover ik mij herinner, wel bezig met een consumentenversie van Itanium omdat ze uiteraard wisten dat ook consumentenplatformen op een dag 32bit achter zich zouden moeten laten. En het doel van Intel was om daar wel degelijk de breuk te maken met x86, ook op consumentensystemen. Maar AMD was hen voor met hun AMD64 en Microsoft had al laten weten dat ze maar 1 64bit platform voor consumenten zouden ondersteunen, en dat is dus AMD's implementatie geworden.

Uiteindelijk niet eens zo slecht daar dit Intel verplichte tot een cross licensing deal met AMD, anderzs had Intel mogelijks heel de PC markt kunnen monopoliseren.

[CAPSLOCK2000]

Itanium is, voor zover ik weet, nooit gepositioneerd geweest als cliënt/desktop/laptop product, maar altijd als server chip, voornamelijk omdat HP van hun PA-RISC af wilde (die overigens toen ook al een 64-bit evenknie had). Voor de server kant klopt het waarschijnlijk wel wat je zegt, maar dat Itanium heel x86 (32-bit) moest vervangen, betwijfel ik.

Het is nooit zover gekomen maar volgens was het de bedoeling om uiteindelijk te stoppen met x86.
Speculatie: Intel vond het maar niks dat anderen chips maakten die compatible waren met x86, zoals AMD, maar ze konden de licenties niet intrekken. Met een nieuwe architectuur zouden ze geen last meer hebben van oude afspraken en zou de concurrentie buiten spel worden gezet.

Er zijn wel features uit Itanium in Xeon gekomen en prijs/prestatie was die gewoon veel beter. AMD speelde toen maar een beperkte rol. Wel is de 64-bit extensie van AMD ongeveer dezelfde tijd (rond de eeuwwisseling) ontstaan.

1999: Intel kondigt IA64 aan
2000: AMD kondigt x86-64 aan (zoals we het nu noemen)
2001: Intel brengt Itanium op de markt,
2003: AMD brengt Opteron op de markt, de eerste chip met x86-64.
2004: Intel brengt een Xeon op markt met x86-64 support

Maar - mijn geheugen laat me iets in de steek - dacht al eerder met een Intel prototype gewerkt te hebben (Merced) wat een voorloper was van Itanium. En maf genoeg, dat was met een Windows versie. Weet niet meer welke (een NT versie). Windows Server bestond toen nog niet eens.

Merced was geen prototype maar de eerste commerciele variant van Itanium. De architectuur is daarna wel verder ontwikkelt maar Merced is al "echt" Itanium.

[Rarz]

De x86 architectuur opschonen is toch wel een goed idee. Veel van de legacy functionaliteit vormt ook aanvalsvectoren en worden gebruikt in hacks. Als je kijkt naar de huidige generatie consoles, zie je dat die prima werken zonder alle 16 en 32 bit lagen in de hardware.

[TheekAzzaBreek]

Maar op een console kan je zorgen dat daar alleen geschikte code op draait. Om dezelfde reden kan Apple grote architectuur ingrepen doen: een gesloten software landschap. Mensen verwachten nou eenmaal dat op x86 alles draait. Ook verouderde code, zoals die driver voor je oude scanner die het verder nog prima doet e.d.

[feuniks]

Ik heb al een tijdje geen MAC meer gebruikt, maar de laatste keer dat ik het deed kon ik gewoon software downloaden van eender welke site en die installeren en draaien. Daar heeft Apple geen controle over.

[PaulHelper]

Ja en nee. Volgens mij hebben ze geprobeerd alles zo goed mogelijk te laten werken zeker grotere software pakketten. Maar oudere applicaties en daar gaat het veel over zijn hit en miss. In theorie zouden die allemaal moeten werken maar met een beetje ongeluk door legacy benodigdheden crasht of werkt een deel van de applicatie niet. En als het wel werkt kan het prestatie verlies hebben van amper tot heel veel trager.

[bzzzt]

Apple breekt doodleuk applicaties als het ze niet meer uitkomt. Dat is een vloek en een zegen want minder stabiele of insecure oplossingen worden daarmee ook vaak uitgefaseerd, zoals bijvoorbeeld de 'driver voor de oude scanner' uit 2006.

Wat ook een behoorlijke impact heeft gehad is de "32 bits purge" actie waardoor sinds macOS Ventura geen 32 bits applicaties meer draaien.

[komododraak]

Ik snap niet waarom ze zo moeilijk doen:32 emulgeren en alle 32 bit hardware eruit. Voor voorbeelden zie Apple (10-15 jaar geleden).
Als ze toch bezig zijn kunnen ze ook gelijk x86 dumpen en een modern ontwerp introduceren ( idem..)
Al met al snap ik niet waarom Intel nog energie steekt in techniek uit 1980

[CAPSLOCK2000]

Ik snap niet waarom ze zo moeilijk doen:32 emulgeren en alle 32 bit hardware eruit. Voor voorbeelden zie Apple (10-15 jaar geleden).
Als ze toch bezig zijn kunnen ze ook gelijk x86 dumpen en een modern ontwerp introduceren ( idem..)
Al met al snap ik niet waarom Intel nog energie steekt in techniek uit 1980

We hechten enorm aan backwardscompatibility.
Intel heeft ooit geprobeerd om x86 te vervangen een 64-bit architectuur met de naam Itanium (ia64).
Dat ging helemaal fout omdat AMD toen uitkwam met een x86 CPU die ook 64 bit kon en daar de markt mee veroverde. Het huidige marktaandeel van AMD hebben ze daar grotendeels aan te danken.
Sindsdien is Intel nogal terughoudend geworden met veranderingen die niet backwardscompatible zijn.

[FreezeXJ]

AMD's 64-bit versie had hier niks mee te maken, de Itanic is afgezonken omdat hij totaal niet backwards compatible was, en dus alle code die je erop wilde draaien opnieuw gecompileerd moest worden. Voor een deel van de mensen geen probleem, maar voor teveel bedrijven dus wel. Even je oude 32-bit software draaien zit er niet meer in, en het alternatief is bakken ontwikkelkosten, of je leverancier pushen dat deze die kosten pakt. HP (toch geen kleintje) heeft er hard genoeg voor gevochten, maar het alsnog ook verloren.

ps. die eerste AMD64s waren inderdaad prima (Clawhammers en opvolgers) maar daar hebben ze hun huidige marktaandeel niet aan te danken. Dat is dankzij Ryzen, die de Bulldozer-issues eindelijk doet vergeten.

pps. Intel is al sinds 1990 en eerder vrij dol op backwards compatibilty (afgedwongen door de industrie), en daarmee hebben ze flink punten gescoord. Dat blijven ze dus nog wel even (ook al roepen ze af en toe van niet).

[dmantione]

Dat klopt niet. De eerste Itaniums hadden een x86-decoder, waarmee hij gewoon compatibel met bestaande software was. Pas in latere Itaniums is deze decoder verwijderd. Er waren een aantal problemen: (1) Itanium was compatibel met x86-applicatiesoftware, maar voerde deze vrij traag uit. (2) Itanium kon geen x86-besturingssysteem draaien. Windows 9x was de norm in die tijd. (3) Zelfs al had je de Itanium-versie van Windows NT, Windows had nog geen WoW64 zoals het dat nu heeft. (4) Itanium was voor programmeurs behoorlijk anders, ze hadden geen Itanium-laptops, de eenvoudigste oplossing was om te doen of Itanium niet bestond. Als je een Itanium-machine had, dan had je weinig aan die 64-bit, want het enige dat je kon draaien was 32-bit x86-applicaties, en veel te traag.

[Jeanpaul145]

Het huidige marktaandeel van AMD hebben ze daar grotendeels aan te danken.

Ik ben het goeddeels met je eens maar niet hiermee.
AMD heeft z'n huidige marktaandeel te danken aan een paar dingen:

1. De ijzersterke executie met de Ryzen en Threadripper platforms.
Voordat de eerste Threadripper ten tonele verscheen was het marktaandeel van AMD niet echt noemenswaardig te noemen.

2. Intel heeft enorm gefaald in de periode dat TR/Ryzen uitkwam. Inzoverre Intel chips sneller werden was dat vooral omdat ze meer en meer energie gingen slurpen, met bijbehorende afvalhitte en dus koelproblemen als gevolg. Intussen had AMD daar helemaal geen last van.

En nu, 7 jaar later, is het alsof de rollen tussen AMD en Intel volledig zijn omgedraaid. Niet helemaal qua marktaandeel maar wel qua relevantie.

[Caayn]

Wat zie jij als "modern", ARM is slechts een paar jaar jonger en stamt uit 1985.

X86 van nu vergelijken met X86 uit de jaren 80 slaat nergens op.

[Reactie gewijzigd door Caayn op 21 december 2024 14:42]

[Stevendefeij]

ARM heeft wel degelijk alle legacy eruit gesloopt met ARM64. Dus je slaat de plank hier nogal mis.

[dmantione]

Ik ben van mening van niet: Ook een ARM64-processor heeft een 32-bits modus, waarmee hij compatibel is met oude software. Nu is het zo dat de ene ARM-processor de andere niet is en een ARM64-processor zonder 32-bit mogelijk is, maar op een 64-bit Raspbery Pi kun je gewoon een 32-bit Raspberry PI OS installeren.

Voor ARM is er ook minder reden om de legacy eruit te gooien, omdat ARM vanaf het begin veel beter in elkaar stak dan x86.

[latka]

Jazelle en Thumb zijn behoorlijk legacy en weggesneden. Je oude software daarmee werkt niet meer op je snapdragon van nu.

[dmantione]

Let wel, dat zijn altijd optionele uitbreidingen geweest, geen enkele versie van de ARM-instructieset heeft de ondersteuning verplicht gesteld. Ik denk ook dat er niets op tegen is als een moderne ARM-processor ze zou implementeren, alleen is het niet zo nuttig. Wellicht vergelijkbaar met 3DNow en FMA4 bij x86.

[latka]

Het is bij Arm een grote teringzooi qua naming en instruction sets is denk ik een betere samenvatting: Thumb-1 is niet meer in gebruik sinds 2011 ofzo maar was wel verwacht op CPUs van voor die tijd. De Cortex-M (moderne Arm cpus) doen dan weer geen Aarch64 maar een soort van Thumb-2 oid. Het is in ieder geval geen gegeven dat je binary op device 1 het doet op device 2. Iets wat Intel beter doet (tot de AVX E-core fubar): een Atom CPU kan dezelfde code draaien als een 128 core Xeon server, maar dan wat trager. Ook de Quark CPUs van Intel draaiden X86 code (32 bit, dat dan wel).
Jazelle was inderdaad zo optioneel dat het bijna geen enkele cpu heeft gehaalt zover ik weet.

[bzzzt]

Jazelle is een acceleratietechniek, helaas bleek die in de praktijk weinig acceleratie op te leveren en werd het amper gebruikt. Er is dus geen enorme hoeveelheid software die daarmee weggevallen is.

[Wolfos]

Maar ARM apparaten zijn dan ook nauwelijks onderling compatible. Je kunt de Android versie van Samsung niet op een Huawei draaien - of zelfs op een andere Samsung telefoon.

Binnen het PC ecosysteem word verwacht dat alles wel samenwerkt en daar is enige vorm van backwards compatibility voor nodig. Hoewel ondersteuning voor 32 bit er inmiddels wel uit kan, omdat de transitie compleet is, was het in 2000 (toen AMD64 geïntroduceerd werd) een probleem geweest als deze niet compatible waren met de besturingssystemen uit die tijd.

[catfish]

Maar uiteindelijk draait dezelfde software wel op alle Android smartphones.
Het lijkt dus dat de HAL bij ARM wat meer verschilt?
Is dat een probleem? WindowsNT4 had een HAL voor IA-32 (x86), Alpha, MIPS en PowerPC.

[Blokker_1999]

Wat moet ik zien bij Apple 10 of 15 jaar terug? Want ook Apple gebruikte toen gewoon Intel CPUs, die dezelfde 16 en 32bit instructiesets aan boord hadden.

Je kan beter zeggenL kijk naar ARM vandaag. Zij hebben wel degelijk een ontwerp waarop je enkel maar een 64bit OS kunt starten, Maar vergeet niet dat Apple de M CPUs dan weer heeft aangepast zodat deze net wel weer een deel van de x86 instructies hardwarematig sneller kunnen uitvoeren dan je ooit in software zou kunnen doen.

[Pendora]

Hij bedoelde ouder dan 18 jaar. Toen was het nog de IBM PowerPC. En daarvoor nog Motorola.
Apple is meerdere keren van architecture verwisseld, heeft in de eerste jaren een "universal binary" + emulatie en daarna is alle backwards compatibiliteit weg.

[Rudie_V]

Ik vind het jammer, het had misschien de nodige prestaties kunnen brengen. Als ze de instructie encoding zouden aanpakken naar een vaste lengte wordt het een stukje makkelijker voor de branch predictor.

[latka]

Dat wel, maar je cache hit ratio gaat omlaag omdat je code minder dense zal zijn. It's all about tradeoffs en compatibility.

[RJG-223]

Ik vind het jammer, het had misschien de nodige prestaties kunnen brengen

Ik denk amper. Bijna alle 16bit en 32bit instructies blijven gehandhaafd, omdat 32bit applicaties (en 64bit applicaties) die nog nodig hebben. Alleen een aantal specifieke instructies en registers die alleen voor 32bit en 16bit OSen nodig zijn, zouden verdwijnen. Dat maakt de CPU ietsjepietsje eenvoudiger, maar ik denk niet zo veel dat het echt sneller wordt, en zeker niet zo veel dat je dat merkt - de verbeteringen zullen in het niet vallen bij de verbeteringen van een generatie naar de volgende.

[TheDeeGee]

Ook al bleven 32-Bit apps wel werken is het toch mooi dat ze voorlopig voor maximale compatibiliteit kiezen.

Vraag me af of dit Pat's idee was, en ze het nu schrappen omdat ie weg is.