'Windows 8 krijgt 128bit-kernel'

Hoewel Windows 7 voor het grote publiek nog niet beschikbaar is, werkt Microsoft al aan de opvolgers: Windows 8 en 9 staan op de planning vanaf 2012. De softwaremaker streeft voor beide besturingssystemen naar 128bit-kernels.

Het was Microsofts bedoeling Windows 7 uitsluitend van een 64bit-kernel te voorzien, maar de softwarefabrikant zag hiervan af en koos toch voor een 32- en 64bit-versie. De opvolgers van het besturingssysteem zouden echter al de overstap naar 128bit-architecturen maken.

Wellicht zal Windows 8 nog een 64bit-versie krijgen, maar het is Microsofts bedoeling zowel Windows 8 als 9 128bit-ondersteuning te geven. De plannen van Microsoft kwamen aan het licht via het inmiddels verwijderde LinkedIn-profiel van een van de ontwikkelaars van de nieuwe Windows-kernel.

Robert Morgan schrijft in een status-update te werken aan 128bit-compatibiliteit van de Windows 8 en 9-kernels. Eerder meldde Morgan dat de 128bit-architectuur volledig terugwaarts compatibel met de 64bit-instructieset zou moeten worden.

Of de 128bit-ondersteuning in Windows 8, dat eind 2011 of begin 2012 verwacht wordt, gerealiseerd wordt is niet zeker: voor Windows 9 moet dat zeker lukken. Een van de eerste processor-architecturen die ook een 128bit-architectuur ondersteunen, is de AMD-chip met codenaam Bulldozer. De chipontwerper wil die architectuur in quadcore desktop-cpu's met codenaam Orochi in 2011 op een 32nm-procedé toepassen.

Reacties (303)

[masterpoi]

En hoe een verhaal zijn eigen leven gaat leiden:

Dit stond er op www.osnews.com:

Microsoft has been thinking about Windows 8 for a while now even through the production of Windows 7. Some information has been gathered by our friends over at Ars, and all of this said information points to possible 128-bit versions of Windows 8 and definite 128-bit versions of Windows 9. Update: Other technophiles better-versed than I in this whole 64/128-bit business pointed out that it must be for the filesystem (such as ZFS described in this article) rather than the processor and memory scheme.

[Verwijderd]

Had ik ook gelezen. Een eindje verderop had iemand het volgende gepost:

Let's look at the practical side of things. Even using 16GB memory modules, it would take 268,435,456 of them to reach the 64-bit limit. Just think of how much power it would take to keep that memory going...

Als je moederbord dan op een paar voetbalvelden past mag je niet klagen denk ik.

Edit: typo

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:14]

[mrlammers]

In 1981 kon de IBM 7030 al 64-bits instructies verwerken en het eerste commerciele 64-bits OS kwam in 1993 op de markt en de thuisgebruikert werd pas in 2001 blijgemaakt.

Best ouwe tech dus, maar de 'beperkingen' van de huidige 64-bits architecturen openbaren zich alleen in de hardware. Zo heeft de AMD64 architectuur een 52-bit limiet op fysiek geheugen en ondersteunt 'slechts' 48-bits virtuele geheugen adressen... Heb jij het weleens gemerkt?
Het zou toch jammer zijn als je die 17.2 miljard gigabytes RAM niet aan kunt spreken...

Op dit moment zijn er geen echte 128-bits computers. Er zijn wat configuraties die 128-bits registers hebben, maar de enige die in de buurt komt is de IBM System370, die 128-bits floating point berekeningen kan doen.

128-bits is wat mij betreft op dit moment behoorlijke overkill, want de hardware lijkt het toch niet bij te kunnen houden. Daarnaast zijn behoorlijk wat software applicaties slechts recentelijk in het 64-bit jasje gestoken en ik denk dan ook dat de 128 bits versies nog wel even op zich zullen laten wachten...

[Reactie gewijzigd door mrlammers op 22 juli 2024 16:14]

[Verwijderd]

Een vraag: waarom? Serieus.. wat heb je in godsnaam aan 128 bit? Is er iemand hier die denkt tegen de 17 miljoen terabyte limiet aan te lopen???

[cdwave]

De verbeteringen in 64-bit mode zijn meer dan alleen maar "grotere pointers":

- Meer registers
- Grotere registers
- Sneller call model (minder stack gebruik)
- Relatieve adressering (geen "rebase DLL" meer nodig)
- Adresruimte voor OS: Efficienter delen van code en data tussen processen

T.o.v. 64-bit zou 128 bits kunnen zorgen voor:

- Alle adressen binnen de PC worden op een grote hoop geveegd. Dus ook de harddisk wordt gewoon op een geheugenadres gezet.

- Clustering: Er is genoeg adresruimte om elke byte geheugen van alle PCs op de wereld een unieke plaats te geven. In je software ontwikkeling kun je dan gewoon adressen mappen op webservices, en je kunt een functie van de Google Maps server gewoon in je programma meelinken en gebruiken alsof het een gewone C call is.

[teaser]

In je software ontwikkeling kun je dan gewoon adressen mappen op webservices, en je kunt een functie van de Google Maps server gewoon in je programma meelinken en gebruiken alsof het een gewone C call is

Icm IPv6 zit hier wel iets interessants in. Elke functie zijn eigen IPv6-adres?

[twiFight]

Met 64-bit zit je over x jaar weer met hetzelfde probleem. Dat we ooit 128 bit nodig gaan hebben is een feit, de vraag is wanneer. Dan kun je dat moment afwachten en tegen die tijd alles wéér veranderen, of je kunt nu vast vooruit denken en het vast implementeren. Het vereist alleen een andere manier van programmeren (of alleen een andere compiler, ik weet niet zeker) dus zo dramatisch is het nou ook weer niet om vast toekomstbestendig te zijn.

[MSalters]

Met 64 bits zit je niet over x jaar weer met hetzelde probleem. Zelfde idee als IPv6; in beide gevallen is het goed aangepakt. We hebben geleerd van de 16-naar-20-naar-24 bits hack van de originele 8086 en 80286. Van 32 naar 64 was 1 stap. Geheugengroote verdubbelt elke 18 maanden volgens de wet van Moore, wat betekent dat je 1 bit extra nodig hebt. De stapjes van 4 bits waren destijds dus elk goed voor 6 jaar. De stap nu naar 64 bits is goed voor 48 jaar (!)

Die 48 jaar is bovendien een onderschatting, omdat we zien dat de Wet van Moore inmiddels te optimistisch is. Het tempo van verdubbeling daalt, mede omdat er economische meerwaarde van 8GB boven 4GB niet meer zo groot is. Vergelijk het eens met 8MB tegen 4MB, dat was het verschil tussen Word 95 wel of niet kunnen draaien. En niemand heeft nog een idee wat de meerwaarde van 8TB ram gaat zijn, laat staan voor 50% van de wereldbevolking. Kortom, die 48 jaar kan er ook zomaar 100 zijn. Dan is 128 bits support dus een goede kandidaat voor Windows 2095.

[Garma]

zijn punt is dus dat x in dit geval > 100 jaar is...

en het is niet gratis hoor, die verhoging, als je nu geheugen addresseerd (wat miljoenen keren per seconde gebeurd) kun je af met een 32 bit adres versturen, maar met 128 bit worden die adressen dus 4 keer zo groot. Moet wel allemaal over de bus en verwerkt worden door de processor

[Reactie gewijzigd door Garma op 22 juli 2024 16:14]

[StefSybo]

Dat het versturen van een 128 bits adres langer zou duren is niet waar, want zo'n processor krijgt dan natuurlijk ook een bredere adresbus en kan ook 128 bits tegelijk verwerken.

[johnbetonschaar]

Die bredere adresbus zou ook gebruikt kunnen worden om 4x zoveel adressen tegelijk te verwerken en dan was je chip dus 4x zo snel geweest... En die dikkere geheugenbus krijg je natuurlijk ook niet voor niks, die komt uiteindelijk op je geheugen controller op de CPU uit, die dan ook weer 4x bredere data moet kunnen verwerken, etc. There's no such thing as free lunch, en dat geldt dubbel zo hard bij CPU's, simpelweg wat extra lijntjes op je chip zetten is echt een grove over-versimplificatie van hoe een CPU ontwerp in elkaar zit.

[FreezeXJ]

Welja, waarom dan niet meteen overgestapt op 1024bit? We moeten toch een keer over.
Het grote probleem met meer bits is dat je hele processor 2x zo veel bitjes tegelijk moet verwerken, en bijna per definitie 2x zo gecompliceerd wordt. Daarnaast vergroot je het oppervlak (al die baantjes moeten ergens blijven), dus de rest gaat ook x2.
Laten we nou maar eens eerst alles netjes 64bit krijgen, want half Nederland draait nog op 32bit met stukjes 16-bit. Te ambitieus kan altijd nog.

[FireDrunk]

64bit is niet alleen in het leven geroepen voor limieten... Ook encryptie heeft profijt van instructies met 128bit (je kan namelijk sneller bepaalde wiskundige berekeningen doen)

Met encryptie moet je 100000000 keer een wiskundige berekening doen.. Dat is met 128bit dus een paar factoren sneller

[Umbrah]

En indirect heeft dit ook effect op de snelheid waarmee compressie/decompressie werkt, en hoe 'makkelijk' een film wordt gedecodeerd. Laat ik het zo zeggen: Media Player Classic 32 en 64 bit hebben, als er software decoding in de CPU-bit-taal wordt gebruikt, een noemenswaardig verschil, met haast een 40% versnelling voor de 64bit CPU.

Overigens denk ik dat 2012 een wel heel rooskleurige schatting is; ik denk dat het marketing technisch zelfs dom zou zijn om zo dicht ná een economische levensduur-cycle zoals die nu aan de gang is al een 'grondige' vernieuwing als deze uit te voeren.

Hoewel AMD de 64 bit instructies aan de X86-set 'pas' in 2004 toevoegde, en Intel er een licentie op nam in begin 2005, heb ik het idee dat we ondanks die invoer de overstap naar 64 bit nu pas beginnen te maken. De drivers zijn er (eindelijk), en het lijkt een stuk sneller te gaan dan van 16- naar 32-bit, maar nu pas met W7 worden er ook door bedrijven volledig-64 bit PC's gekocht. En daar de economische levensduur zo langzaamaan naar 4 jaar aan het gaan is, en ik steeds meer bedrijven hoor die interesse tonen in Windows 7 (revolutie), en grote hardware/software contracten op dít moment, denk ik dat als dit eenmaal gebeurt is, we zeker tot 2014 moeten wachten tot er wéér bereidheid is om een 'switch' te maken. MS zal er handig aan doen om te wachten tot 2014, en vooral veel te praten met de chipbakkers (beiden!) en hardware/software leveranciers, om nu al vast aan 128-bit te werken; willen we tegen 2014 de driver support hebben die 64-bit nu pas heeft.

[FireDrunk]

Wat jij zegt op het laatst klopt wel... Maar die 4 jaar dremple ligt toch niet bij elk bedrijf in het zelfde jaar? Dat wisselt natuurlijk per bedrijf...
Er zijn zat bedrijven die net Vista hebben, die misschien over 3 jaar al naar Windows 8 eventueel willen... Standaard MKB wil vaak best overstappen omdat ze toch voor 90% office werkzaamheden verrichten.. En zo niet werkt de meeste niet-office-wel-mkb software prima op alle windowsversies (exact, audition, etc).

Hier en daar moet je wel wat trucs uitvoeren, maar het werkt wel

[Umbrah]

Het wisselt, maar door de concurrentie werking licht het gek genoeg net zo dicht bij elkaar als de maandelijkse periode van een stel nonnen in een klooster. Stapt er een over, volgen de anderen al was het maar omdat ICT vaak 'prestige' is, en er een concurrentie strijd is, dan volgen de anderen vaak er na.

[Vorlon]

De Opteron kwam al in begin 2003 op de markt en de X86-64 instructieset is al in 2000 gepresenteerd. Die is dus al bijna 10jaar oud. Een eeuwigheid in computerland.

[flowerp]

Inderdaad, maar mensen vergeten snel dingen.

Voor heel erg veel mensen, ook mensen die beter zouden moeten weten zoals tweakers, is 64 bit (X86-64) nog steeds nieuw. Dat het alweer 6 jaar voor het grote publiek overal te koop is, en idd al weer bijna 10 jaar sinds de presentatie vergeten mensen domweg.

Zo is ook voor verbazend veel mensen de DVD nog steeds een 'nieuw' medium. Dat we daar al bijna zo'n 13 jaar mee zitten gelooft men gewoon niet. Op 'gevoel' is het voor hen pas een paar jaar. Dit merk je b.v. als je het over blu-ray hebt. Dan krijg je van die opmerkingen als "alweer wat nieuws??? Maar we hebben pas dvd!". Laat ik het dan maar helemaal niet over hebben dat blu-ray ook alweer naar de 3 jaar gaat.

[latka]

De snelheid is voor een heel klein deel 32 versus 64 bits, het voornaamste voordeel zit erin dat je in 64 bit mode eindelijk meer registers hebt op x86 (het dubbele aantal). Er zijn niet zo heel veel berekeningen die echt 64 bit nodig hebben maar extra registers maken het voor compilers veel makkelijker de code te optimaliseren zonder continue register-spills te moeten doen.
En 128 bit CPUs... tsja leuke marketing gimmick maar als het betekent dat adresregisters 128 bits worden zal de snelheid omlaag gaan ipv. omhoog: de cache is sneller vol en je hebt meer memory bandwith nodig om alle data heen en weer te schuiven. Als ze nou een x86 met 128 registers van 64 bits zouden maken....

[Ilya]

Waarom niet? Vooral omdat het volledig backwards compatible is met 64bit zie ik geen reden om het niet te doen. Ik zie liever dat ze hardware een stap voor zijn dan dat ze achter lopen zoals nu (4GB systemen met 32bit OS).
Daarbij staan ze pas op de planning vanaf 2012, dus ik verwacht niet dat Windows 9 (128bit only) het levenslicht gaat zien voor 2016, misschien zelfs wel veel later.

[johnbetonschaar]

Bitbreedte verdubbelen betekent ook dat code 2x zo groot wordt en tot 2x zoveel geheugen gaat gebruiken, en dat bepaalde instructies (vooral in het begin) trager zullen zijn. Zelfde zag je met de eerste generatie 64-bit x86 CPU's, die waren ook sneller met 32-bit code dan met 64-bit. Zal inmiddels wel anders zijn, maar het feit blijft dat meer bits niet betekent dat de CPU beter of sneller is, of meer kan. Voor de RAM limiet hoef je het ook niet te laten, want van 32-bit naar 64 bit was nog niet eens zo'n hele grote stap, maar van 64 naar 128 daarentegen is weer een kwadratische factor meer, dus zal de tijd totdat 64-bit niet meer toereikend is ook kwadratisch langer moeten zijn (32 bit heeft het een jaar of 10 uitgehouden, dus reken maar uit hoe lang we met 64 bits zouden moeten voortkunnen).

[Ilya]

Als je het uitstelt zit je wanneer het wel "nodig" is toch alsnog met ditzelfde probleem? Ook heb ik nog niet een applicatie gezien die in 64bit het dubbele geheugen gebruikt tov de 32bit variant. Uberhaupt weinig extra geheugen eigenlijk. Twee keer zo grote code is ook te optimaliseren (zie Vista64 SP2 vs Windows 7 64).
Verder groeit het aantal GB ram ook niet lineair natuurlijk, dus dit argument gaat ook niet op. Bovendien kan een CPU wél meer met een betere instructie set, zoals al gezegd (128bit berekeningen). Of dit direct een voordeel is voor de consument is een andere vraag, maar de CPU markt bestaat niet alleen uit consumenten desktops.
Wat zijn je bronnen waar je 2x zo grote code en geheugen gebruik vandaan haalt?

[johnbetonschaar]

Als je het uitstelt zit je wanneer het wel "nodig" is toch alsnog met ditzelfde probleem? Verder groeit het aantal GB ram ook niet lineair natuurlijk, dus dit argument gaat ook niet op.

Je moet het in perspectief zien, tussen de adresruimte die je met 64-bit krijgt (16777216 TB) en de hoeveelheid geheugen die momenteel courant is (4GB) zit een factor 4 miljoen. In 10 jaar tijd is de 'instap' hoeveelheid geheugen dus zo'n 1000x groter geworden (4MB naar 4GB), dus dan kan het geheugengebruik de komende 10 jaar 4000x sneller groeien en dan nog kunnen we 10 jaar vooruit. Of het groeit 'maar' 400x sneller dan de afgelopen 10 jaar en dan kunnen we 100 jaar vooruit.

Wat zijn je bronnen waar je 2x zo grote code en geheugen gebruik vandaan haalt?

Goed lezen: ik zei tot 2x zoveel geheugen, en de redenatie is simpel: in het worst-case geval slaat een programma al zijn data in het geheugen op als 32-bit woorden (dwords), of het nu booleans zijn (dus 1 of 0) of 32-bit getallen. Ga je naar een 64-bits adressering dan slaat hetzelfde programma in het worst-case geval alles op als 64-bit getal, en dan heb je dus 2x zoveel geheugen gebruikt. In de praktijk wordt data in het geheugen ook als bitfields, bytes, words en dwords gebruikt dus zal het in de praktijk niet op 2x zoveel geheugen gaan. Echter zijn moderne CPU's helemaal geoptimaliseerd voor geheugentoegang op 4-byte of 8-byte boundaries, dus veel compilers genereren graag code die structuren in het geheugen zo aligned dat elk stuk data 4 bytes beslaat, of dat nu nodig is of niet. Die alignment is bij een 64-bit CPU 8-byte, waardoor dus tot 2x zoveel RAM kan worden 'verspild'.

Wat betreft code size: de aanduiding '64-bit' op een CPU is nogal een fuzzy aanduiding, maar in de volksmond betekent het 'CPU met 64-bit registers, 64-bit instructiewoord en 64-bit adresruimte', doorgaans zijn de bitbreedtes van registers, instructiewoorden en adresruimte aan elkaar gelijk (maar dat hoeft niet), omdat je die 64 bit adressen of registerwaarden natuurlijk ook graag in 1 instructie codeert => 64-bit instructies. En native 64 bit programma gebruikt dus 64 bits voor elke instructie, terwijl een 32-bit programma er 32 gebruikt => code size verdubbeld.

[_js_]

De gebruikelijke Intel en AMD processors in onze computers hebben geen vaste lengte voor de instructiewoorden. Ook is bij deze processors het verschil tussen 32 bit en 64 bit alleen te zien in de integer registers, de floating point registers zijn ook op 32 bit cpus al veel groter (64 of 80 bit), en de matrix registers gaan zelfs tot 128 bit.

Voor de volksmond lijkt me dan ook alleen de grootte van het integer register van belang en de daarvan afgeleide adresseerbare geheugenruimte.

Het geheugengebruik in 64 bit programma's gaat vooral omhoog door grotere pointers, alignment is veel minder van belang.

[RuddyMysterious]

ussen de adresruimte die je met 64-bit krijgt (16777216 TB) en de hoeveelheid geheugen die momenteel courant is (4GB) zit een factor 4 miljoen.

Het is 4 miljard, net zoals 4GB 4 miljard bytes is, want (32=2^32)^2 = 64

[BEHM]

Je hebt kans dat we daar waarschijnlijk ook 10 jaar mee vooruit kunnen. Moore's law geldt nog steeds.

[johnbetonschaar]

Moore's law gaat over het aantal transistoren op chips, niet om de hoeveelheid geheugen in computers. 10 jaar geleden was 4 megabyte een realistische hoeveelheid ram, nu is het 4 gigabyte, dus 1000x zo veel. Bitbreedte verdubbelen geeft je kwadratisch meer adresruimte dus dan zou je nu, 10 jaar later, al aan 16 TB aan RAM zitten. Dat is niet zo, dus ik denk dat we nog wel iets langer dan 10 jaar vooruit kunnen met die 64 bit (=16777216 TB) adresruimte.

[_js_]

10 jaar geleden werd net de Pentium 3 geïntroduceerd, 128 MB geheugen was in die tijd gebruikelijk, we zijn dus maar 32x zo veel geheugen gaan gebruiken.

Dit komt precies overeen met Moore's Law, 5 verdubbelingen in 10 jaar tijd.

Moore's Law is wel van toepassing omdat geheugen een heleboel transistors in een chip is.

[Left]

Ik begrijp het ook niet. Kan me niet voorstellen dat de performance zoveel vooruit zou gaan want de performance gain die 64 bit bracht was over het algemeen erg klein.

Sterker nog in het begin zul je moeten werken met slecht geporte drivers en software, zodat de performance misschien zelfs achteruit gaat.

Het enige wat ik kan verzinnen is dat je de 128 bit support kan gebruiken als marketing argument.

[Icekiller2k6]

Foutje de performance vooruitgang voor software die gebruik maakt van 64bit instructies is zeker wel sneller.

Het feit dat er nog weinig software is die het doet is iets anders!

[Left]

Niet helemaal waar. Een 64bit OS gebruikt ook 64 bit geheugenpointers. Die zijn 2 keer zo lang als voor 32 bit, dit betekent meer netwerkverkeer/ geheugengebruik als je veel met pointers werkt.

Het hangt dus van het type applicatie af of het sneller wordt met 64bit.

[leuk_he]

1985: 640 K is enough for everyone
1995 windows wordt volledig 32 bit.
2005: 64 bit wordt gewoon voor high end,
2009: limieten van 32 bit zijn erg zichtbaar (4GB)

Dus over 10 jaar zit er wel weer een verdubbeling in. Aangezien De ontwikkeling van een nieuwe versie van het OS MS toch 5 jaar kost moet hier wel al voor gepland worden.

Ik had eerst ook een WTF moment, maar zo vreemd is het niet als je de trend doortrekt.

[Verwijderd]

offtopic:
1985: Corrected: http://www.usnews.com/usnews/biztech/gatesivu.htm
1993: Windows volledig 32 bit (NT 3.1)

[Verwijderd]

Een verdubbeling van het aantal bits is meer dan verdubbeling dus ik verwacht echt niet dat het zo door blijft gaan.

[MSalters]

Klopt: Een verdubbeling van het geheugen kost 1 extra bit. 32 extra bits is goed voor 32 verdubbelingen, oftewel 4294967296 keer zoveel geheugen.

[XanderDrake]

Ja, dit vroeg ik mezelf ook meteen af, zover ik weet zijn de enige intrinsieke voordelen van 64bit vooral de grotere geheugen adressering (dus meer dan 4gb aan RAM) en de grotere registers (vooral handig voor encryptie).
Ik zie ook niet dat we ver boven de 24-32gb aan zullen hebben rond de tijd dat Windows 8 wordt geïntroduceerd.

Iemand een idee waar dit nuttig voor is?

[Fiander]

Voor het rekenen met erg grote getallen.
oa bij encriptie worden berekeningen gedaan met erg grote priem getallen met enkele honderden bits. Dit soort berekeningen zijn prima te doen op kleinere procesoren, maar om met 32 bit een 1024 bit getal te berekenen zijn 4 keer zoveel berekeningen nodig als waneer je datzelfde doet met een 64 bit proc. een 128 bitter zal het nog 4 keer sneller kunnen.

Ik hoop alleen wel dat ze dit keer de grootste botlenek wat serieuser oplossen.
Van 8 naar 16 generaal purpouse registers was niet genoeg. Hopelijk gaan we dit keer richting de 128 registers.

[Munters]

Maar voor een paar specifieke algoritmes hoef je toch niet de complete kern te verdubbelen? Dan kun je beter een co-processor (al dan niet geintegreerd in de cpu kern) voor gebruiken.
Voor de huidige multimedia extensies wordt toch ook niet de complete kernel verdubbeld?

[redGNU]

Ben je soms Bill Gates?

"640K ought to be enough for anybody." (ik weet het hij heeft het mischien waarschijnlijk toch wel toch niet gezegd)

Je kan toch ook wel inzien, terugkijkend naar de geschiedenis, dat de voorlopige trend nog steeds is dat er steeds meer, beter en sneller wordt gemaakt / geaspireerd.

Denk bijvoorbeeld ook aan de immense hoeveelheden data die Google verwerkt en moet bewerken. Als dat allemaal vanuit het geheugen zou kunnen, zou dat een stuk sneller gaan.

*edit ben spuit elf zo te zien

[Reactie gewijzigd door redGNU op 22 juli 2024 16:14]

[rtfm]

Een 'leuke bijkomstigheid'. Een IPv6 adres is 128 bit breed. Past mooi in een 128 bit adres register. Komt het sneller rekenen van IP routeringen zeker ten goede!

[beantherio]

Dat soort hoeveelheden geheugen zul je toch nodig hebben als je een fatsoenlijke teleporter wilt kunnen bouwen en gebruiken.

De vraag is dan wel even of je zo'n ding op een OS van Microsoft wilt laten draaien...

[Sijmen]

Teleportronics weigert de specs van het nieuwste model te geven, dus daar kunnen we geen drivers voor schrijven.

[YopY]

Dan ga je reverse engineeren, . Of je ontwikkelt een open source teleporter, ipv alleen de drivers.

[Tarkin]

Als iemand je 7 jaar geleden zou zeggen dat je op een normale thuispc een tera aan HDD kon hebben, dan had je die voor zot verklaard. Wel nu zijn we die limiet ook al gepasseerd hoor. 128bit zal wel nodig zijn binnen afzienbare tijd

[Grauw]

Ik betwijfel toch of 128-bit een succes zal worden. Je ziet met 64-bit dat het al heel lang bestaat, maar dat mensen nu pas langzamerhand overstappen nu ze echt gedwongen worden door de geheugenbeperkingen van 32-bit (voor de leken: die is max. 3.3 GB).

Een 128-bit-architectuur heeft echter niet zo’n dringende reden, dus ik zie een overstap daarnaar nog niet zo snel gebeuren, zeker niet op consumentensystemen.

[stewie]

128bit SIMD instructie set, de chip zelf is echter 64bit.
het heeft namelijk niets met geheugen extensie te maken kijk ook:
http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
http://en.wikipedia.org/wiki/SSE5

dit word dus een gigantisch groot succes dus, aangezien zowel intel als AMD deze extensie volledig op zowel 32bit als 64bit Operating system ondersteunt.
de CPU zelf blijf namelijk slechts 64bit geheugen adressering houden aangezien deze extensie niets met het geheugen te maken heeft.
zie ook: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
http://en.wikipedia.org/wiki/SSE5

[Grauw]

Okay, dus het is gewoon een soort SSE/3DNow. Boooring .

[stewie]

een hoop gebakken lucht om bijna niets ja.

[stimpie79]

IBM z10 werkt al met 256-bits AES encryptie
http://en.wikipedia.org/wiki/IBM_System_z10

staat IBM hier een stuk verder dan AMD/Intel,
of hoe doen ze dit dan als er zelfs nog geen 128bits processors bestaan?

[mrlammers]

Die 256-bit slaat op de grootte van de encryptiesleutel. Die sleutel kun je opslaan in blokjes van 32, of van 64, of van 128, zodat je ook op je 32-bits PC 128-bits encryptie kunt krijgen. Het heeft dus niets te maken met je processor, allocatie van geheugenadressen of busbreedte...

[SvMp]

Door 128-bit variabelen op te slaan als 2 64-bits variabelen. Voor een 128-bits variabele moeten met de huidige processoren dus minstens 2 handelingen worden verricht, voor elk 64-bit deel 1 en eventueel een overflow afhandelen bij berekeningen.

[The Flying Dutchman]

Wat is het nut van 128 bit ten opzichte van 64 bit? Even afgezien van grotere precisie bij berekeningen? Met 64 bits kun je al 2^64 =16384 PetaByte aan geheugen ruimte adresseren.

Momenteel wordt door enthousiaste thuisgebruikers maximaal zo'n 8GB aan geheugen gebruikt. Laten we eens uitgaan van een optimistische Moore, een verdubbeling ieder jaar:

2009: 8GB
2010: 16GB
2011: 32GB
2012: 64GB

Merk op dat dit erg optimistisch is, Moore voorspelt voor een aantal zaken een verdubbeling iedere 18 maanden, ik heb nu even een verdubbeling iedere 12 maanden genomen. Laten we er vanuit gaan dat het OS zo'n 5 jaar mee moet gaan, dus we zetten die trend nog een door:

2013: 128GB
2014: 256GB
2015: 512GB
2016: 1TB
2017: 2TB

Merk nogmaals op dat deze progressie schromelijk overdreven is (in 2017 hebben we écht geen 2TB aan geheugen in onze pc'tjes zitten). Toch zitten we nog lang niet aan 16384PB (dat zou namelijk nog eens 23 jaar lang een verdubbeling van het geheugen betekenen).

Kijk... ik ben voor vooruitgang. Maar ik zou eerst eigenlijk wel eens willen zien dat alle huidige software eens overstapt naar 64 bits, zodat ook eindelijk games (vaak nog 32 bit) gebruik gaan maken van die gigabytes aan geheugen in mijn pc.

edit:
b -> B

[Reactie gewijzigd door The Flying Dutchman op 22 juli 2024 16:14]

[Verwijderd]

Een paar correcties:
- het is GB, niet Gb. Scheelt een factor 8.
- Moore's law gaat over de verdubbeling van het aantal transistors in integrated circuits, alle andere zaken zijn te klasseren als afgeleiden van zijn wet of gelijkaardige constanten

Wat weinigen hier begrepen hebben is dat het helemaal geen wereldschokkend nieuws is. Tijdens de beta van Vista werd er ook al over de opvolger gerept. En zoals eerder vermeld, video kaarten werken ook al deels of volledig op 256- of 512-bit. Dat is wel net iets groffer dan een 128bit kernel lijkt me. Het gaat em dan ook niet om >4 exabyte aan geheugen te kunnen adresseren, wel om floating point berekeningen te versnellen en dergelijke meer. Jij als eindgebruiker zal in 2014 echt nog geen 128bit drivers moeten gaan zoeken voor je HP DeskJet.

[The Flying Dutchman]

Videokaarten maken gebruik van een een bus die vaak 128/192/256/384/512 bit is. Dat gaat alleen maar over de geheugenbus, om op die manier extra bandbreedte te winnen, wat heel hard nodig is bij videokaarten.

Videokaarten doen nog altijd voornamelijk 32 bits berekeningen en zijn nog maar net begonnen aan 64 bits berekeningen. De nieuwste AMD videokaarten doen 64 bits berekeningen geloof ik op 40% van de snelheid van 32 bits berekeningen, de nVidia Fermi die in 2010 moet uitkomen kan 64 bits berekeningen op 50% van de snelheid van 32 bits berekeningen doen.

[Airdack]

Zou me nix verbazen hoor als we tegen 2020 meer dan een TB RAM geheugen in een pc hebben zitten ... je kan het nu niet voorstellen maar ruim 10 jaar geleden kon ik me ook niet voorstellen dat iemand veel meer dan 64 MB RAM in zn PC zou hebben zitten en er zijn nu ook zat mensen met 4 tot 6 GB aan RAM

Mn punt is, zeg nooit 'nooit', het gaat allemaal ongelofelijk snel met die computers

[Reactie gewijzigd door Airdack op 22 juli 2024 16:14]

[The Flying Dutchman]

Zoals je kunt zien gaat mijn voorbeeld berekening tot 2017 en niet tot 2020. Daarnaast wordt in 2020 waarschijnlijk Windows 10 al bijna gereleased, terwijl we het momenteel over Windows 8 en 9 hebben.

Enthousiasts in 2020 met 1TB geheugen zou best kunnen, dat is al een stuk realistischer en komt vrij dicht bij Moore zijn voorspelling denk ik.

Wat ik met bovenstaande post wil laten zien is dat het voor geheugen addressering volstrekt overbodig is om naar 128 bits te gaan, zowel voor Windows 8 als voor Windows 9.

edit:
b -> B

[Reactie gewijzigd door The Flying Dutchman op 22 juli 2024 16:14]

[iPims]

Maar nog, 1TB geheugen?
Dan moeten ze wel heel groot zijn, of ze moeten de het extreem gaan verkleinen

Ik zie het al voor me,

Moeder: Hey iPims, wat ga je doen?
iPims: Ik ga even langs de Computeland.
Moeder: Wat ga je halen dan?
iPims: Ga even een TB ram kopen.
Moeder: Is goed, maar is die 768GB niet meer genoeg?
iPim: Nee, als ik nu *Insert game* speel, heb ik maar 74231 Fps, I want moar

[RuddyMysterious]

Dat is waar, maar het verschil is dat 64MB toen zeker niet meer dan genoeg was om allerlei programma's te draaien, terwijl nu 4GB (meestal) zeer ruim toekomt voor alles wat een thuisgebruiker ook maar zou willen doen met zijn pc.

Herinner je nog hoe erg Windows vroeger moest swappen bij het starten van een zware game of applicatie? Nu is dat helemaal geen waar meer.

De evolutie die er over die 10 jaar heeft plaatsgevonden is dat de evolutie van hardware die past binnen een bepaald budget veel sneller is verlopen dan de evolutie van de noden van software, en aangezien we nu al voorbij de meeste softwarenoden zitten qua hardwarepotentiëel, denk ik niet dat we dezelfde boom in hardware-evolutie nog eens gaan meemaken in de komende 10 jaar, want er is veel minder nood aan dan 10 jaar geleden.

[silentsnake]

Wat dacht je van virtualisatie? Het is al vandaag de dag al vrij gebruikelijk voor grote VMware / Xen / Hyper-V servers om 128GB geheugen in een server te doen. Wij hebben anderhalf jaar geleden VMware servers aangeschaft die 64GB geheugen hebben, dus kan je nagaan hoe hard het gaat als 128GB nu al redelijk gebruikelijk is voor een quad-socket setup. Daarbij, flinke ERP / CRM systemen hebben toch ook al dit soort geheugen aan boord. Die zullen eerder behoefte hebben aan 128bit dan de consumenten markt.

En tja, in de jaren 90 kon je je toch ook niet voorstellen dat je ooit 4GB aan geheugen in je PC zou hebben waar je toen 4 of 8 MB in je PC had zitten. Toch is het zo. Dus ik zie niet in waarom we dit niet toe moeten juigen, ondanks dat het vandaag de dag niet nodig is.

[Reactie gewijzigd door silentsnake op 22 juli 2024 16:14]

[The Flying Dutchman]

Goed, vandaag 128GB. Kijk nog eens naar mijn post, dan ben je dus 4 jaar voor op het voorbeeld dat ik gaf. Dat zou betekenen dat je eindigt met 32TB (ipv 2TB) in 2017. Dan zit je dus nog steeds ruimschoots binnen het bereik van 64 bits (dat gaat tot 16,8 miljoen TB). Vergeet daarnaast niet dat ik uitgegaan ben van een verdubbeling ieder jaar. Terwijl jouw voorbeeld (van 64GB naar 128GB) over een tijdsbestek van 1.5 jaar is genomen.

Je hebt helemaal gelijk dat servers er eerder behoefte aan zullen hebben. Maar dan kun je je nog steeds afvragen of die behoefte er al is aan het einde van de life cycle van Windows 8. Ik denk het niet.

[MistrX]

Voor de consument heeft het weinig nut. Dit is interessanter voor businesses die wat meer eisen van hun apperatuur voor grote wiskundige berekeningen zoals u zelf al aangaf of allicht beter databases doorspitten etc.

[Kerberos84]

Veel bedrijfspc's hebben slechts 2GB RAM, ze halen toch alles vanaf hun servers of terminal-sessions.

[Villean]

Hmm ik dacht ook to de enthousiaste thuisgebruiker te horen maar ik kan eerlijk gezegd niet wachten totdat het betaalbaar is om mijn 12GB te upgraden naar 24GB. Het ligt er maar net aan wat voor een toepassingen je gebruikt.

[Snake]

8Gb is nog niet zo veel.

Ik had in 2008 al 8GB.

En voor 2009 16GB.

Dat is factor 8 verschil!

bit != byte !!!!!

[The Flying Dutchman]

Addressering gaat in bytes zover ik weet. Goed, dan heb ik wellicht de verkeerde afkorting gebruikt, de berekening gaat nog steeds op.

[Verwijderd]

8 gb door een thuisgebruiker dus echt niet!

Die hebben meer dan genoeg aan 4 gb

[Verwijderd]

De wet van moore stelt de verdubbeling van het aantal transistoren op een processor. Dit zal zeker op ram van toepassing zijn, alleen vergeten jullie het feit dat hte draait om verdubbeling van transistoren, en niet om verdubbeling van behoeften.

Ofwel: Als de verdubbeling stijgt, dan krimpt de groote van een processor, tenzij de behoefte stijgt, in dat geval bijft de groote gelijk maar stijgt het aantal transistoren per cm2.
Bij processoren hebben we dit scenario gezien. Groote blijft min of meer gelijk, maar het aantal transistoren stijgt met een verdubbeling per 24 maanden, zoals moore de wet pak 't beet 40 jaar geleden (of 50?) ons voorstelde.

Het gaat dus puur om de verdubbeling van de transistoren, en niet die van de behoefte.

De wet van moore kent ook een grens, namenlijk de grens van de atomen, waarbij men niet kleiner kan gaan dan atomen uiteraard.

Groet van Gemstone

[ndonkersloot]

128-bit zozo dat is nogal wat. Hopen dat het niet zo lang duurt op goede drivers en applicatie support tegen die tijd.

[Chatslet]

Ik vraag me sowieso af waarom we 128 bit al zo snel moeten hebben. 64 bit is uitgevonden om de beperkingen van 32 bit (hoofdzakelijk maximaal 4GB ram) te overkomen. Met 64 bit zaten we geloof ik al boven de 4 exabyte. Een limiet waar we nog lang niet overheen gaan. Daarnaast is de acceptatie van 64 bit ook nog steeds niet rond dus of dit nu wel verstandig is?

Wat windows betreft: Windows 7 hadden ze van mij 64 bit only mogen maken en dan bijvoorbeeld alleen home/basic als 32 bit mogen uitgeven.

[Reactie gewijzigd door Chatslet op 22 juli 2024 16:14]

[Free rider]

Mwah 15 jaar geleden was er al een 64-bits Windows NT 3.51, en MSDN bevatte toen al artikelen over compatibiliteitszaken als je ontwikkelde voor de 64 bits DEC Alpha processor.

Het wordt tijd dat ze eens beginnen aan een opvolger, wat moeten we anders over 15 jaar hebben?

@Schnupperpuppe:
Misschien werd dan de MIPS processor in 64 bit gebruikt, feit is dat ik al in 1996 artikelen op de MSDN CDs tegenkwam die o.a. vertelden dat je niet zomaar structures in files kon oplsaan, als daar INT in staat, omdat de lengte dan anders is. En nog een aantal zaken meer, zoals de lengte pointers, enz.
In ieder geval was de omschakeling toen al begonnen, volgens mij nog voor Windows NT 4.

[Reactie gewijzigd door Free rider op 22 juli 2024 16:14]

[Schnupperpuppe]

Windows NT degradeerde de mooie DEC Alpha naar 32-bits mode.
Pas in 2003 was er voor het eerst een 'echt' 64-bit OS van Microsoft.

[StefanTs]

In ieder geval al in 2001, Windows 2000 voor IA64. Maarja, niet alsof je dat ergens tegen komt ofzo.

[zircondan]

Voor grote floatingpoints berekening is 128 bit misschien nuttig. Ik zie zo snel ook niet het voordeel om over te schakelen naar 128bit boven 64.

De meeste mensen hebben nog steeds een 32bit OS, waaronder ik ook. Wat voor mij de overstap naar 64 tot nu toe vooral tegenhoudt zijn de drivers die niet altijd werken in een 64bit omgeving.

[CobraVE]

Sorry, maar als je "drivers niet werken" gebruik je hardware uit het stenen tijdperk. Alle hardware heeft sinds XP x64 wel een 64-bit driver.

Daarbij word bij de volgende Windows hoogstwaarschijnlijk niet eens meer een 32-bit versie uitgegeven, omdat computers met 4GB of meer ook steeds meer mainstream worden.

64-bit is bijna de nieuwe standaard, zeker na de introductie en in gebruik neming van Windows 7.

[YopY]

Sorry, maar als je "drivers niet werken" gebruik je hardware uit het stenen tijdperk. Alle hardware heeft sinds XP x64 wel een 64-bit driver.

Euh, nee. Toen XP 64 net uit was waren er nog maar bar weinig drivers te krijgen.

[CobraVE]

Dat was niet zijn reactie.... Zijn reactie was "Wat voor mij de overstap naar 64 tot nu toe vooral tegenhoudt zijn de drivers die niet altijd werken in een 64bit omgeving."

Oftewel hij schijnt in de veronderstelling te zijn dat de drivers niet altijd werken, wat dus alleen op ECHT oude hardware het geval is.

[Sir Isaac]

Computers zijn uit het stenden tijdperk: allemaal silicium, silicium oxide, aluminium, koper en nog wat mineralen.

[Chatslet]

Bovendien zie ik eerder een trend in het toenemen van het aantal cores. Met NUMA in het achterhoofd is het niet ondenkbaar dat iedere core zijn eigen geheugencontroller krijgt en er zo meer geheugen kan worden aangesproken. Zo overkom je dus ook eventuele limieten en krijg je toch betere performance zonder de pijnlijke overgang naar een nieuwe architectuur. Huidige OSen en drivers blijven dus gewoon werken.

[StefSybo]

128 bits slaat niet alleen op de adresruimte, maar ook bijvoorbeeld op een bredere geheugenbus (dus meer bandbreedte) en de mogelijkheid om berekeningen op grotere getallen uit te voeren zonder ingewikkelde trucs, dus met een hogere performance.

[Psilax]

Wat windows betreft: Windows 7 hadden ze van mij 64 bit only mogen maken en dan bijvoorbeeld alleen home/basic als 32 bit mogen uitgeven.

Dan had er nog altijd 32 bit ondersteuning in gezeten, en omwille van hardware compatibiliteit is dat nooit gemakkelijk om iedereen te forceren want dan kopen ze het niet zomaar. Het is al goed dat windows 7 capable pc's 64 bit volledig moeten ondersteunen. Maar als microsoft te snel 32bit laat vallen zonder oudere besturingsystemen te blijven ondersteunen kan het wel eens veel bedrijven als klant kwijt graken. Als ze toch alles in 64 bit moeten herontwikkelen kunnen ze even goed in een open-source/license-free OS ontwikkelen met alle gevolgen voor microsoft.

[twiFight]

Eerder meldde Morgan dat de 128bit-architectuur volledig terugwaarts compatibel met de 64bit-instructieset zou moeten worden.

Hieruit lees ik af dat alle 64 bits programmatuur (incl drivers) ook gewoon zouden moeten werken. Dat moet ook wel, anders zullen ze weinig steun vinden voor 128 bits.

[.oisyn]

Nee, daaruit kun je lezen dat de 64 bit long mode van de huidige processors ook gewoon ondersteund wordt op de nieuwe chip, en dat je er dus een 64 bits OS op kunt draaien. Het betekent niet dat je eventueel 64 bits software (applicaties en/of drivers) op een 128 bits Windows kunt draaien, en je kunt er donder op zeggen dat dat verhaaltje voor drivers sowieso niet op zal gaan (net als bij 32 bits drivers op Win64), omdat die nou eenmaal direct bij de hardware moeten kunnen (en 64 bits drivers zijn nou eenmaal niet compatible met 128 bits pointers)

[Reactie gewijzigd door .oisyn op 22 juli 2024 16:14]

[ppl]

Als je in de bron van dit artikel kijkt (klik op "plannen") dan krijg je een artikel waarop een tweetal updates is geplaatst. De tweede update meldt een citaat van de man die de uitspraken heeft gedaan:

“Robert Morgan is working to get IA-128 working backwards with full binary compatibility on the existing IA-64 instructions in the hardware simulation to work for Windows 8 and definitely Windows 9.”

De enige reden waarom je uberhaupt volledige binary backward compatibility met 64 bit zou willen hebben voor je 128 bit OS is juist het draaien van 64 bit software in je OS lijkt mij. Als je 128 bit only wil hebben dan boeit je die 64 bitheid niet.

Ow en zoals je ziet gaat het dus kennelijk om de opvolger voor IA-64 die tegenwoordig beter bekend staat als Itanium.

[Reactie gewijzigd door ppl op 22 juli 2024 16:14]

[.oisyn]

Als je in de bron van dit artikel kijkt

Prima, maar dat neemt nog niet weg dat twiFight nog steeds niet de conclusie kan trekken uit het stuk dat hij quote, en daar was mijn reactie op gericht. Dat 64 bits windows apps wel binary compatible gaan zijn met een 128 bits windows leek me verder wel voordehandliggend.

Ow en zoals je ziet gaat het dus kennelijk om de opvolger voor IA-64 die tegenwoordig beter bekend staat als Itanium.

Waarom zou IA-128 een Itanium-achtige chip zijn? FYI, de 32 bits versie van de x86 heette gewoon IA-32. Dus ofwel je weet meer dan hier vermeld staat (een google search op IA-128 levert vrij weinig op), ofwel je bent ook van mening dat de Itanium de opvolger was van de IA-32 architectuur. De enige conclusie die we tot nu toe kunnen trekken is volgens mij dat IA-128 alles kan betekenen

[Reactie gewijzigd door .oisyn op 22 juli 2024 16:14]

[martijnvanegdom]

Dat lees je verkeerd... Programmatuur zal vermoedelijk wel compatibel met 64 bit, maar drivers zijn afhankelijk van de hardware en vaak wordt daar direct met geheugen locaties enzo gewerkt dus een 64 bit driver laten werken in een 128 bit OS dat gaan niet werken (evenmin je een 32 bit driver in een 64 bit OS kan laten werken)

[rdkleine]

Glaasje half leeg?

[mae-t.net]

Ervaring uit het verleden, vermoed ik. 64-bits ondersteuning bij diverse software begint nu langzaam een beetje goed te worden, terwijl de bijbehorende processoren toch al heel wat jaartjes op de markt zijn. Aan MS lag dat niet direct, en zal het deze keer al helemaal niet liggen, zo te lezen.

[Gustaaf437]

Als Microsoft had gedaan wat Apple doet (het maken van een hybride OS met zowel een 32 als 64-bit kernel) dan waren er al veel meer programma's met 64-bit ondersteuning geweest vanwege het feit dat het veel makkelijker te migreren is. Microsoft maakt migratie zo moeilijk dat gebruikers en software leveranciers en maar mondjesmaat aan willen.

[Amdk6II]

Dat denk ik niet, waarom zou je voor 64bit ontwikkelen als je het ook als 32bit kan draaien? Stel dat Microsoft van Windows ME 32 bit naar 64bit only Windows XP was gegaan was de overstap naar 64bit veel sneller en geforceerder gegaan - of - het was toch faliekant mis gegaan. (blijft koffiedik kijken)

[flowerp]

Dat denk ik niet, waarom zou je voor 64bit ontwikkelen als je het ook als 32bit kan draaien?

Ach ja, en waarom zou je voor 32bit ontwikkelen als je het ook als 16 bits kan draaien?

Waarom doen we niet gewoon alles weer lekker in 8 bit?

[Verwijderd]

Opzich logische ontwikkeling. Echter vraag ik me af wat het nut is van 128 bit. Kan iemand daar iets zinnigs over zeggen? 64-bit stelt je bijvoorbeeld in staat meer dan 4 GB geheugen te adresseren door de grotere pointers, maar geheugenadressering kan hier de motivatie niet zijn. Ja, sneller rekenen met floating point. Maar hebben consumenten daar iets aan?

[SPee]

Als je kijkt naar de videokaarten dan hebben deze ook een geheugenbus van 128, 256 of zelfs 512 bit !
Hierdoor kan meer operaties worden gedaan op data en kan deze precieser worden. Echt veel heb je er nu nog niet aan, maar voor clusters en supercomputers wel.

Uiteindelijk komt die technologie op de desktop terecht.
En aangezien Windows marktaandeel over (b.v.) linux wil winnen (die eerder met 64-bit ondersteuning was) zijn ze nu al bezig om die ondersteuning voor hun toekomstige OS-sern te maken. Zodat - tegen de tijd dat zulke processoren gemeengoed worden - het huidige beschikbare windows er al ondersteuning voor heeft en die mensen niet naar linux hoeven te gaan.

Maar dat zal wel 2015 of later worden.

[Verwijderd]

Dat is dus wat anders. Een busbreedte is niet vergelijkbaar met het bereik van geheugenaddressering. Een GPU processed bijvoorbeeld 4 32 bit floats tegelijk. Zo''n processor crunched dus 128 bit/cycle terwijl de geheugenbus wel veel groter kan zijn.

[YopY]

Hierdoor kan meer operaties worden gedaan op data en kan deze precieser worden.

Precisie is op zich geen probleem - een 8-bit PC kan ook gewoon met 128 bits cijfers werken. Snelheid is iets anders echter - de 128 bitter kan het in 1 keer doen, de 8 bitter moet het in stukjes opdelen en stukje voor stukje uitrekenen en het beeld op zetten.

[InsanelyHack]

Dat hangt toch helemaal niet van 64 bits af ? Via PAE kan dat ook. Een 32 bits besturingsysteem kan ook meer dan 4GB adresseren maar heeft dan PAE nodig.

Ach ja we hadden dezelfde discussies van 8 naar 16 bit van 16 naar 32 en van 32 naar 64. Dus aan de ene kant fijn om te zien dat Microsoft vooruitstrevender is geworden ipv zeggen "Nobody will ever use 640K"

Vaak gaan wel de standaard aan te roepen instructies. Dus het aantal standaard instructies word enorm zelfs tot een astronomische hoeveelheid opgerekt.

[84hannes]

Ik maak me er meer zorgen over dat het, AMD kennende, wel de zoveelste incarnatie van x86 zal zijn. x86 is nooit bedoeld als oplossign voor de lange termijn, het zou zoveel netter zijn om een nieuwe (bij voorkeur) RISC architectuur te ontwerpen/ondersteunen. Een die niet de evolutie van 8 bit tot 128 bit heeft mee hoeven maken met extensie op extensie op extensie.
Helaas werd Intels poging daartoe (Itanium anyone?) daartoe tegengehouden door het ``succes'' van AMD64.

@arjekoole
Volgens mij is x86 echt niet zo goed, maar ook niet zo dramatisch slecht dat iedereen over wil stappen op een andere architectuur. En het vervelende is dat als niet alle betrokken partijen over willen stappen, de ontwikkeling bij x86 zal blijven.
Intel wilde een nieuwe 64-bits architectuur, voorlopig alleen voor servers maar als het een succes was geweest was het waarschijnlijk ook wel op de desktop terecht gekomen. AMD maakte een 64 bits extensie waardoor hun chips backwards compatible te blijven. Op de korte termijn is dat voor softwareontwikkelaars veel makkelijker dan een nieuwe architectuur. Dus toen ontwikkelaars meer tijd in AMD64 dan in IA-64 stoken had intel niet veel keus dan ook AMD64 te gaan ondersteunen. Dat heet betrekkelijk weinig met "een goeie architectuur" te maken ben ik bang.
Ik kan de ironie, dat het AMD is geweest die intels x86 in leven hield, wel waarderen, maar ik betwijfel of de wereld er een betere plek door is geworden.

edit:

Ik zie nog een kleine lichtpuntje aan de horizon. Platforms als Java en .net maken een omgeving relatief architectuur en OS onafhankelijk. Op het moment dat een programma volledig .net draait, en .net of een compatible platform (mono) volledig werkt op een ander besturingssysteem en/of processorarchitectuur, is de switch eenvoudig te maken en zijn we misschien eindelijk van meer dan 40 jaar backwards compatibility verlost.

[Reactie gewijzigd door 84hannes op 22 juli 2024 16:14]

[arjankoole]

Dat het bij conceptie nooit bedoeld is als langetermijn oplossing, wil niet zeggen dat de architectuur dat niet alsnog kan worden he?

x86 is blijkbaar toch een goeie architectuur om op door te bouwen en ontwikkelen, en blijkbaar niet zonder succes.

Helaas werd Intels poging daartoe (Itanium anyone?) daartoe tegengehouden door het ``succes'' van AMD64.

Itanium (IA64) is nooit bedoeld als vervanger voor x86 (IA32), maar als concurrent voor bijvoorbeeld de 64 bit cpu's van Sun, IBM en HP. Intel heeft naar mijn weten nooit plannen gehad om Itanium ook naar de desktop te brengen. Intel wilde zelfs voorlopig niet naar 64 bit op de desktop, maar toen AMD met het 64-bits geweld kwam, konden ze niet achterblijven.

[Rudie_V]

IA64 instructies zouden toendertijd weldegelijk x86 moeten gaan vervangen. Volgens mij zijn er wel roadmaps geweest die dit aangaven. Alleen is deze 64 bit instructieset eigenlijk, welke niet compatible is met x86, afgemaakt door AMD met hun 64 bit uitbreiding op de bestaande x86 architectuur welke gewoon compatible is met x86.
http://news.cnet.com/Itan.../2100-1006_3-5984747.html

[ppl]

Ik zou dat niet roepen. Ik denk dat er eerder sprake is van hetzelfde probleem als met Windows. Mensen stappen niet snel over naar een niet-Windows systeem omdat er heel veel voor Windows beschikbaar is. Datgene wat je al hebt moet je om kunnen zetten naar iets voor dat andere systeem en dat is heel erg lastig en soms ook gewoon onmogelijk. Kijk alleen al wat er gebeurd als je naar Linux of Mac zou willen.

Wellicht is er bij x86 meer sprake van het feit dat praktisch de godganse wereld er op draait de reden waarom men niet uitwijkt naar een andere processor. Als je even terug zoekt was dat ook een discussiepunt toen Apple nog van de PowerPC architectuur gebruik maakte. Het succes is volgens mij eerder het gevolg van het feit dat we niet naar iets anders kunnen. Geen vendor lock in maar een architecture lock in. Gezien het gezeik van programmeurs op de x86 architectuur lijkt mij al bewezen dat het in ieder geval geen goede architectuur is om voor te ontwikkelen.

[Rudie_V]

De huidige Intel/AMD CPU's hebben eigenlijk al een RISC architectuur. Waarom maken ze niet een extra CPU-modus waarin je direct deze RISC architectuur en dus commando's kan gebruiken: native 32, mixed 32 & 64, native 64 en direct RISC. Dat zou een mooie overstap kunnen worden om van x86 en opvolgers af te komen.

Dan nog iets over de 128 bit en dat dit misschien een uitbreiding op een uitbreiding gaat worden
Ok, ik ga het nu even puur op Windows bekijken, ik durf niets te zeggen over andere OSen. Maar 64 bit Windows kan al geen 16 bit programma's draaien. Waarom niet als straks Windows 8 alleen 64 bit en hoger wordt om dan eens aanstalte te gaan nemen om de oude legacy ondersteuning in de CPU's te verwijderen?

[CH4OS]

Maar 64 bit Windows kan al geen 16 bit programma's draaien.

Kan de 32 bit en andere bits versies ook niet eigenlijk. Kijk maar naar Itanium, moet je die is 32 bits software geven, geheid dat ie niks doet voor je... Met andere woorden, sinds Windows 98 (welke naar mijn weten 32 bits is) en nieuwer werkt jouw situatieschets niet meer.

Dat het met de CPU's van tegenwoordig wel kan, komt omdat de 32 bits processors uitgebreid zijn en daardoor ook 64 bits aan kunnen. 64 bits is dus een aanvulling op zeg maar.

[Reactie gewijzigd door CH4OS op 22 juli 2024 16:14]

[Rudie_V]

Kan de 32 bit en andere bits versies ook niet eigenlijk.

Jawel. De 32 bit versies van Windows hebben een 16 bit subsysteem om 16 bit applicaties te draaien. Zo hebben de 64 bit Windows versies een 32 bit subsysteem om zo alsnog 32 bit applicaties te kunnen draaien. En Windows 9x is niets meer dan in de onderste laag 16 bit met daarboven het Win32 subsysteem om 32 bit applicaties te draaien.

En de Itanium had in het begin een stukje hardware om x86 te emuleren, later is dit eruit gehaald en naar software gezet(dacht ik). Dus de Itanium kan/kon weldegelijk x86 32 bit software draaien.

[CH4OS]

Jawel. De 32 bit versies van Windows hebben een 16 bit subsysteem om 16 bit applicaties te draaien.

AFAIK worden / werden 16 bits applicaties geëmuleerd. 32 bits op 64 bits is native (tegenwoordig, op Itanium hoef je het niet te proberen bijvoorbeeld), omdat de CPU 32 bits is en 64 bits uitbreidingen heeft. Dat is iets anders als wat jij bedoeld.

En de Itanium had in het begin een stukje hardware om x86 te emuleren, later is dit eruit gehaald en naar software gezet(dacht ik). Dus de Itanium kan/kon weldegelijk x86 32 bit software draaien.

Kan die nu ook wel, maar geëmuleerd en dus vele malen trager dan een natvie 32 bits processor.

[Reactie gewijzigd door CH4OS op 22 juli 2024 16:14]

[MSalters]

WOW16 gebruikt geen emulatie, maar de V86 mode. Dat is vergelijkbaar met de 32-op-64 mode die nu gebruikt wordt in Windows64. Alleen, er is geen 16-op-32-op64 mode, vandaar dat je nu dus geen 16 bits applicaties meer kunt draaien.

[Verwijderd]

Misschien moeten intel, amd en andere processor bakkers c.q. devers eens om de tafel gaan zitten en samen gaan praten over de toekomstige ontwikkelingen. Maar waarschijnlijk doen ze dat al.

[Verwijderd]

En de kip met de gouden eieren slachten ? 90% van de mensen gebruikt windows en is dus veroordeeld tot de Intel/Amd architectuur. Gaan ze over op een andere architectuur dan moeten Intel en AMD licenties gaan betalen of ze moeten zwaar investeren in een andere architectuur en hopen dat dat de winnaar wordt.

Anderzijds heeft MS ook geen belang bij een andere architectuur omdat dat zou inhouden dat de huidige Windows end-of-life is en dat zou weer kansen geven voor hun concurentie.

Kortom, niemand heeft iets te winnen.

[Verwijderd]

Bovendien komen zulke dingen vanzelf wel. Als computerapplicaties nog altijd versneld en verbeterd kunnen draaien op snellere x86 processors en de architectuur zit de snelheid niet in de weg, waarom zou je er dan vanaf stappen. If it ain't broke, don't fix it.

[Luuk1983]

Netter zou het misschien wel zijn ja, een nieuwe architectuur. Probleem is dat er miljoenen programma's zijn die x86 gecompiled zijn die niet meer zouden werken, zonder ze opnieuw te compileren. Er zouden dus veel applicaties ineens niet meer werken. Uiteraard is dit een behoorlijk belangrijke reden waarom ik denk dat dit niet gaat werken.

Bedoel, toen Microsoft het drivermodel omgooide in Vista waren er al talloze problemen, laat staan als de processor architectuur veranderd.

[ThemNuts]

Daar is altijd een oplossing voor, zeker nu virtualisatie van de grond geraakt. Het is zelfs zo ver dat Windows zelf (met een makke compatibiliteitsmodus in vista) het toch maar voor elkaar krijgt om er een XPmode in te steken die perfect aansluit op Windows 7. Ze zijn hun heus wel bewust van de eventuele restructies en die zijn altijd te verhelpen. Het ligt grotendeels aan de consument/verkoper zelf. Vertel eens als verkoper aan een consument dat je bij 32bit systemen geen volle 4Gb van je ram krijgt.. Staat die je aan te gapen of de maan net op de aarde is gevallen. Toch is het simpel op te lossen door 64bit OS te gaan gebruiken..maar daar heeft die consument dan weer een heilige schrik van.

Problemen in nieuw gereleasede OS'en zijn er altijd, er was echter nooit zo'n hype van een OS gemaakt voor Vista, en dat heeft zich tegen hun gekeerd.

Ik ben nog steed van mening: doorvoeren die hap, de consument volgt toch als een geit.

[Fireshade]

@84hannes:

het zou zoveel netter zijn om een nieuwe (bij voorkeur) RISC architectuur te ontwerpen/ondersteunen.

Waarom? RISC is ook niet de heilige graal, hoor. Die heeft ook z'n vette nadelen.
En daarnaast is de x86 architectuur al sinds de Pentium III (?) al een mix van CISC en RISC.

[MSalters]

AMD K6, om precies te zijn. De ervaring daaruit was de reden dat AMD vervolgens met de K7 (aka Athlon) Intel's Pentiums achterhaalde.

[Mathijs]

En wat blijkt er dus uit je verhaal, ondanks dat je het zelf niet wil inzien?

Backwards compatibility is zeer belangrijk. Men wil wel nieuwe hardware aanschaffen, maar niet wanneer alle software die al in huis is daar niet meer op werkt.

Verder is er niet zo veel mis met de x86 architectuur, om zo'n stap naar een nieuwe archtiectuur zonder backwards compatibility te rechtvaardigen.
Het is niet zo dat het dan meerdere malen zo krachtig wordt, zeer veel energie bespaart, of enig ander voordeel heeft waardoor iedereen over zou willen stappen.

Dat de Itanium geflopt is, is daar ook een goed voorbeeld van. Verder was de Itanium bij enkele toepassingen snel, maar wanneer je over de totale toepassingsbreedte keek, was het ding juist trager. Het was gewoon niet zo'n goede processor en zeker geen vervanger voor de x86 architectuur.

[Haan]

Alleen jammer dat het toch compatible zal moeten zijn met de X86 architectuur waar Intel het patent op heeft.. AMD had ook de eerste 64-bits desktopprocessor waar ze het zelfde probleem bij hadden.

[Caelestis]

X86 architectuur is nog altijd van IBM niet intel

[Umbrah]

Helaas, het is van intel. Het zou eigenlijk na zoveel jaar en zo'n brede impact bij een 'foundation' moeten komen, die licenties uitgeeft als er aan bepaalde kwaliteitsnormen worden gedaan, en ook aan certificering doet.

[Reactie gewijzigd door Umbrah op 22 juli 2024 16:14]

[Rob Coops]

He ja, laten we lekker duur gaan doen...

Een foundation betekend een keurings process een veel langzamer ontwikkeling van nieuwe technieken en veel minder flexibiliteit om af te wijken van het basis ontwerp en extra instructies toe te voegen. Omdat er op eens commisies over moeten beslissen tientallen verschillende bedrijven zegenschap willen hebben en meer van dat soort problemen.

Ik denk eigenlijk dat Intel een nieuwe poging moet doen om met een nieuwe architectuur op de proppen te komen. Het klinkt gek maar x86 is vere van efficient en na al die jaren met alle kennis die is op gedaan moet het mogenlijk zijn een veel betere architectuur te ontwerpen dan de x86 die in middels ook al weer heel wat jaartjes mee gaat.
Intel had het idee dat de Itanium CPU deze nieuwe architectuur was maar door verschillende problemen zo wel binnen de samenwerking met HP als in de eigen organisatie is die belofte nooit waarheid geworden. En nog steeds sukkelt Intel met het Itanium platform.

Ik denk dat de hoge heren bij Intel zelf heus wel weten dat als zij het niet doen iemand anders van zelf met een beter ontwerp zal komen. Intel zal heus niet in een keer uit de markt gedrukt worden maar het lijkt me dat ze het risico niet willen lopen dat iemand anders dan zij zelf de computer architectuur van de toekomst zal bepalen.
Ik denk dan ook dat Intel ergens op de achtergrond een team aan het werk heeft dat aan het werk is om een processor architectuur te ontwerpen die misschien de belofte die Itanium eens was waar kan maken. Misschien zelfs wel compatible met de x86 architectuur al was het maar om op die manier gemakkelijk de huiskamers binnen te kunnen rollen.

x86 is nog lang niet dood maar het lijkt me sterk dat het tot het einde der dagen de architectuur zal zijn waar alle PC's op draaien.

[CAPSLOCK2000]

Ik denk eigenlijk dat Intel een nieuwe poging moet doen om met een nieuwe architectuur op de proppen te komen. Het klinkt gek maar x86 is vere van efficient en na al die jaren met alle kennis die is op gedaan moet het mogenlijk zijn een veel betere architectuur te ontwerpen dan de x86 die in middels ook al weer heel wat jaartjes mee gaat.
Intel had het idee dat de Itanium CPU deze nieuwe architectuur was maar door verschillende problemen zo wel binnen de samenwerking met HP als in de eigen organisatie is die belofte nooit waarheid geworden. En nog steeds sukkelt Intel met het Itanium platform.

De voornaamste reden dat Itanium niks is geworden is dat AMD een gouden kans zag, en met amd64 op de proppen kwam. Intel had besloten om de backwards-compatibility in software te regelen. Dat kost wel wat snelheid, maar de voordelen van de nieuwe architectuur zouden dat moeten compenseren. AMD deed niet mee en kwam met een nieuwe x86 chip waar wat 64-bit spul op is geplakt.

Dit was geen heel nieuwe architectuur, maar gewoon een voortzetting van wat ze al hadden, maar dan weer een tikkie sneller. Hierdoor werden applicaties op korte termijn sneller, maar voor de lange termijn zitten we nu nog steeds aan die verouderde architectuur vast. Ik heb het AMD nog niet kunnen vergeven.

[blouweKip]

Ik heb het AMD nog niet kunnen vergeven.

Ik denk dat amd weinig keus had

[MaxxBass]

Niet alleen AMD had schuld, die Itanium CPU's koste toen enorm veel geld..

Als ik AMD was geweest, had ik het ook gedaan...

[RV]

Waarom? Intel heeft er recht op, hun hebben het patent erop. Dat dat niet eerlijk is, wil nog niet zeggen dat het maar in een stichting gezet moet worden. Intel heeft gewoon recht op de licentiegelden.

Het zou toch te gek zijn dat elk bedrijf patenten van goedlopende producten in een stichting moet stoppen, waarna alle concurrenten er lekker van mee kunnen profiteren? Zo beïnvloed je de innovatie nogal negatief.

[MSalters]

Onzin. Er zijn geen patenten op instructiesets

Juridisch gezien zijn bepaalde zaken niet te patenteren. In het bijzonder zijn nummers en wiskundige formules niet te patenteren. De x86 instructieset is niets anders dan een een genummerde verzameling van wiskundige formules. Zo heeft de 8 bits XOR formule nummer 48 in de x86 instructieset.

Wat wel te patenteren is, is hoe je die instructieset vervolgens met transistoren realiseert. Hardware ontwerpen zijn in de regel wel patenteerbaar. Als AMD hetzelfde slimme transistorontwerp wil gebruiken voor functie 48, dan hebben ze daarvoor een licentie nodig. Net zoals ARM overigens, ook al is heeft de XOR functie in de ARM instructieset een ander nummer.

[bbob]

Patenten verlopen na 20 jaar en xe x86 komt toch al aardig in de buurt of misschien bijna daar overheen.

Dat zegende naar x86 zijn er natuurlijk heel veel andere patenten op cpu gebied die intel mede zo sterk maken.

Natuurlijk zou MS er voor kunnen kiezen windows geschikt te maken voor andere cpu's maar waarom zouden ze. De meeste klanten werken nu éénmaal met x86 cpu en het heeft weinig zin om 3 versies te ondersteunen voor 3 verschillende cpu types.

Zalf apple die eerst powerpc had is nu x86 en het voorlaatste platform wordt al niet meer ondersteunt.

[SKiLLa]

De x86 architectuur is met de Intel 8086 geintroduceerd in 1978, de 32 bits 80386 waar meestal met x86 naar gerefereerd wordt, stampt uit 1985, dus in beide gevallen zijn die patenten verlopen ...

Echter zullen CPU-bakkers natuurlijk ook modernere uitbreidingen op de x86 instructieset (denk aan SSE, SSE2, SSE3, etc.) willen ondersteunen en dus zullen ze alsnog een licentie moeten nemen bij Intel om de "huidige featureset" aan te kunnen bieden.

Verder heeft MS in het verleden ook non x86 versies van Windows (NT 4.0 en 2000 RC2) gebakken voor de DEC/Compaq Alpha architectuur.

Een breuk met het "x86 legacy" verleden; lees: de backwards compatibility met de oer 8086 verbreken, zou een hoop ellende schelen (en zowel de kosten voor CPU/chipset bakkers als OS-schrijvers enorm drukken). Het is eigenlijk te idioot voor woorden dat je 2009 high-tech 64 bits quadcore PC met 12 GB RAM nog in 16 bits modus opstart met 640 kB aan direct adresseerbaar geheugen

Het zou ook mooi streven zijn om dit in Windows 8 (of meer waarschijnlijk 9) tegelijkertijd met nieuwe CPUs te realiseren .....

[tweakerbee]

De poging van Intel met de Itanium om die breuk te maken liep niet helemaal goed af. Voorlopig is x86 niet alleen legacy, maar ook zeer sterk geoptimaliseerd. Opnieuw optimaliseren zou vele jaren kosten. Zolang de Itanium gepusht wordt zou dat eventueel als een opvolger gebruikt kunnen gaan worden.

[Joolee]

De overstap naar Windows 8 / 9 zal dan wel langzamer gaan maar consumenten en bedrijven stappen uiteindelijk toch wel over omdat ze toe zijn aan nieuwe hardware. Microsoft heeft de macht om een nieuwe architectuur te pushen.
Heeft MS nog afhankelijkheden aan Intel?

[RazorBlade72nd]

Ik zie niet in waarom we deze architectuur niet langzaamaan vaarwel zouden kunnen zeggen. Waarom zou de volgende versie van Windows niet standaard op een hypervisor draaien. Die hypervisor kan misschien wel x86 VM’s ondersteunen maar de onderliggende hardware kan in theorie een andere architectuur hebben. De hypervisor dient dan gewoon als adapter.

[RV]

Hoezo bedoel je "natuurlijk zou MS er voor kunnen kiezen windows geschikt te maken voor andere cpu's"? Waarom zouden ze daar voor kunnen kiezen?

Ik zie geen enkele keuze die dat rechtvaardigt. Ten eerste kost dat Microsoft bakken vol extra geld, ten tweede is het voor de consument / zakelijke gebruiker ook niet echt beter qua software ondersteuning.

Er valt gewoon niets te kiezen in een cpu die voor Microsoft even belangrijk zou kunnen zijn of worden dan de x86 of x64, omdat die er niet is. Dus Microsoft heeft helemaal niets te kiezen...

[bastiaank]

misschien iets voor Brein? ;-)

[_Dune_]

De 64bit instructie set heet AMD64, dit is inderdaad van AMD en hierin heeft Intel AMD een keer moeten volgen omdat zij hun eigen 64bit instructie set nog niet op orde hadden. Microsoft heeft er toen voor gekozen om AMD64 te ondersteunen.

[Reactie gewijzigd door _Dune_ op 22 juli 2024 16:14]

[MaxxBass]

De 8086 instructieset heet in de regel toch x86, en de 64 bit set x64? heb nog niet van AMD64 set gehoord, wel van de CPU...

En Intel heeft snel ook eieren voor haar geld gekozen toen AMD sneller was met de 64 set, dan zij met het laten zakken van de itanium prijzen... ;-)

[Verwijderd]

Een mooi verhaal weer. Ze streven ernaar om een product wat nog niet bestaat te laten werken op een architectuur die men nog aan het uitvinden is. En voor het gemak nemen ze aan dat alles compatible blijft en dat genoeg mensen systemen zullen hebben met die nieuwe techniek om de investering in de ontwikkeling lonend te maken.

Eerst WinFS maken, dan nieuwe beloften doen microsoft ! We wachten al sinds 1993.

[sniek]

WinFS zou bij Vista zitten,... Zit het al in Windows 7? Nee, hoor er ook niks over voor de volgende win releases. Ik zou het maar uit je hoofd zetten!

[Cyber007]

WinFS is optioneel te downloaden (voor technet + abbo's)
WinFS zit voor een gedeelte in windows vista en windows 7. de search functie is daarvan afgeleid

[Reactie gewijzigd door Cyber007 op 22 juli 2024 16:14]

[WPN]

echter is die download het laatst geupdate in 2006 en is het beta

WinFS Beta 1 Refresh (English)

Includes: Other; 07-27-2006
Details
Keys
Download
76.82 (MB)


WinFS Beta1 Refresh Documentation (English)

Includes: Other; 07-27-2006
Details
Keys
Download
9.91 (MB)

[Verwijderd]

Ze beloven helemaal niets: Robert Morgan schrijft in een status-update te werken aan 128bit-compatibiliteit van de Windows 8 en 9-kernels.
Dus ze werken er alleen aan.

[eXisTa]

Niet overdrijven hè, WinFS werd pas geïntroduceerd in 2003 (tien jaar later dan je nu suggereerd).
Bron: http://en.wikipedia.org/wiki/Winfs
"developed by Microsoft and first demonstrated in 2003 as an advanced storage subsystem"

[Verwijderd]

Hij heeft wel een beetje gelijk:

"The development of WinFS is an extension to a feature which was initially planned in the early 1990s"

[zyberteq]

gizmodo
Robert Morgan is working to get IA-128 working backwards with full binary compatibility on the existing IA-64 instructions in the hardware simulation to work for Windows 8 and definitely Windows 9.

Dus MS wil liever voortborduren op de IA64 architectuur, begrijpelijk want die is puur 64-bit, AMD64 is dat niet.
Maar dat ze dan wel weer BC willen hebben met IA-128 snap ik dan weer niet

[loekf2]

Linkje is compleet BS.

Hij bedoelt niet IA64 maar AMD64.

IA64 != AMD64

IA64 is een VLIW architecture, meer RISC achtig. De compiler moet de boel slim schedulen voor max.performance. AMD64 is qua instructie set nog steeds CISC, maar onder de motorkap zit er vertaling naar een RISC achtige micro-code.

Ik vind het verrassend dat men nu al aan 128-bits denkt. Andere kant worden AMD64/x64 server procs steeds meer in compute farms en supercomputers gestopt en je loopt een keer tegen grenzen aan natuurlijk... niet qua memory maar accuracy.

[i-chat]

ik zou dat hele artikel eens moeten lezen, - want ik vraag me hier heel erg af of dit wel klopt,
128bit ia64 compatible, - zou idd betekenen dat het een itanium port wordt,
echter als we het hebben over windows 8 (denk ik in eerste instantie dus direct aan de desktop versies. waar ik vziw nog nooit ook maar 1 systeem ben tegen gekomen waar een desktop os op de IA64 arch draaide,

dus: ofwel het artikel klopt niet,
; ofwel er zijn wel degelijk desktops met een itanium cpu
; ofwel er zit iets nieuws aan te komen...

[Who Am I?]

AMD was ook als eerste met een native 64 bit processor voor consumenten. Intel had wel al een Itanium die 64 bit was. Daarnaast hebben Intel en AMD een overeenkomst dat ze elkaars instructiesets mogen gebruiken. Zo gebruikt AMD al jaren de SSE instructiesets en x86 architectuur van Intel en heeft Intel een paar jaar terug de AMD64 van AMD gebruikt.
Het voordeel nu is dat Microsoft eerst aankondigd dat er een compatibel besturingsysteem *komt en dat er dan pas processors voor komen. Win 8 in 2012, Bulldozer van AMD in 2011 (vaak loopen dit soort dingen wel een paar maanden tot een jaar uit). Met de eerste 64 Bit processors heeft Microsoft de 64 bit versie van Windows XP maanden uitgesteld en waren de 64 bit processors van AMD al ruim een half jaar op de markt. Pas toen de 64 bit processors van Intel er aan kwamen heeft Microsoft de 64 bit versie van XP uitgebracht.

[Reactie gewijzigd door Who Am I? op 22 juli 2024 16:14]

[ppl]

En dan ben je er nog niet. De 64 bit versie van XP en de eerste 64 bit versies van de diverse Linux distro's lieten al wel zien dat een 64 bit OS draaiende op 64 bit capable hardware niet genoeg is. Men is veel meer afhankelijk van wat 3rd parties doen met hun software, men is meer afhankelijk van drivers en programma's die op zo'n OS werken. Met de 64 bit only versie van XP kon je ook alleen 64 bit only software draaien en daar lag dan ook het grote probleem en de reden waarom die versie een flop werd. Er was amper ondersteuning voor 64 bit. Met Vista en Windows 7 heeft men dat beter aangepakt door 32 bit op een 64 bit systeem te kunnen laten draaien. De vraag is nu of we in 2 jaar tijd helemaal van 32 bit naar 64 bit weg kunnen migreren en hoe rap we aan 128 bit software beginnen (aangezien men de 128 bitsheid van ZFS al idioot vond kon dat nog wel eens heel erg lang gaan duren als men er überhaupt ooit aan begint).

[Rafe]

WoW64 was ook op XP x64 aanwezig.

[Vyo]

Je kon/kunt op de amd cpu's uitstekend x86-32 code draaien, de reden dat het ook nog eens relatief snel gaat is omdat de instructies ook in hardware ondersteund worden. Het probleem zat en zit 'm voor een groot deel in de drivers die verplicht 64bits moeten zijn. Als
ze al beschikbaar waren zaten er bugs in. Veel daarvan is ook niet altijd opgelost in de 64bits xp drivers maar wel weer in de vista drivers, die nu weer bruikbaar blijken bij 7.

Dat waren idd 3rd party problemen, maar Microsoft heeft trouwens wel vieze trucjes uitgehaald om gebruik van xp64 te ontmoedigen, zo zijn er voor simpele programma's als de live suite officieel geen werkende installers. Dit geldt overigens ook voor het hele iTunes/iPod pakket van Apple. Uiteindelijk bleek dit slechts een arbitraire "do no not run if" waarde in de installer te zijn die je met MS Orca eruit kunt slopen.

[Reactie gewijzigd door Vyo op 22 juli 2024 16:14]

[watercoolertje]

Voor zover ik weet zijn die native 32-bit met extenties waardoor ze ook 64-bit aan kunnen

[the_stickie]

klopt niet: de cpu werkt native volledig 64 bit. Allen zijn alle 32 bit instructies net zo geïmplementeerd als vroeger.
Wel klopt het dat amd64 geimplementeerd is als extensie op x86 (net zoals mmx, 3dnow, sse etc) zodat oudere software gewoon blijft werken. Maar dat zegt niets over de interne werking van de cpu, dit is slecht de interface, de commando's waarmee een cpu bestuurd kan worden.

[Amito]

Waarschijnlijk is Intel er ook al mee bezig, dan wordt het lastig om er patent op te krijgen i.v.m. prior art.

[hiostu]

Zolang ze niets publiekelijk bekend hebben gemaakt kun je niet spreken over priorart. Anders kun je altijd achteraf wat documenten in elkaar zetten en aangeven dat je het 10 jaar geleden al bedacht had.

[RV]

Ja dan zou je nu net zo goed al kunnen roepen dat je met 256bit computers bezig bent, terwijl dat niet zo is. Wat een argument zeg.

[MSalters]

Sterker nog, dan kun je wel uit je hoofd zetten. Een minimale eis aan patenten is "non-obviousness", niet voor de hand liggend Dat je na 16, 32 en 64 ook 128 bits krijgt is wel "obvious", voor de hand liggend, en dus op zic niet patenteerbaar. Een slimme truc om transistoren te stapelen (zodat die 128 bits ook passen) zou dat wel kunnen zijn.

[Chatslet]

Cross license agreement tussen AMD en Intel voorkomt dat.

[Bacchus]

Is die allesomvattend dan? Uiteraard gebruiken met name Intel en AMD duizenden gepatenteerde technologieën van elkaar. Daar zit vast wel een raamovereenkomst overheen.

[penetreerbeer]

Cross license is allesomvattend. Alles wat AMD ontwikkeld mag Intel gebruiken en omgekeerd. (Als beide binnen hun overeenkomst blijven)

Dus alle voorgaande berichten over patenten en dergelijke zijn off-topic. De nieuwswaarde hiervan is dat AMD eerder zo een processor zal hebben. Alhoewel Intel ook een konijn uit zijn hoed kan toveren.

Vind wel dat die codenamen vrij goed op elkaar gelijken:
Windows 8: Chidori
AMD Bulldozer: Orochi

[HerrPino]

Onderdeel van de licentie die AMD bij Intel heeft genomen is dat Intel AMD technologie mag gebruiken. Leeg zuigen zit er dus niet echt in.

bron: http://www.amd.com/us-en/Weblets/0,,7832_12670_12686,00.html

[Pb Pomper]

AMD als eerste 128 bit processor? snel patent erop zetten en intel lekker leeg zuigen!

Een patent moet vernieuwend zijn. Dit ligt echter zo voor hand dat het niet als vernieuwend beschouwd kan worden.
Het zou net zoiets zijn als patent aanvragen op een processor van 3 GHz.

Patent aanvragen mag natuurlijk altijd maar ik denk dat AMD enkel haar eigen bankrekening leegzuigt

[Reactie gewijzigd door Pb Pomper op 22 juli 2024 16:14]

[stewie]

het gaat hier om sse5, de chip is nog steeds 64bit met een 128bit vector unit "ala altivec".
http://www.amd.com/us-en/...s_and_tech_docs/43479.pdf

de cpu zelf blijft echt 64bit.

[Reactie gewijzigd door stewie op 22 juli 2024 16:14]

[arnoo1]

128bit-kernel' wat heeft dat zowieso voor zin
misschien zou ik ut op moeten zoeken wat en grote kernel voor zin heeft

btr verteld iemand dat effe op profiel ofsoow:P

[Verwijderd]

Ik vind die plaatje van dat logo van windows 8 er wel heel erg nep uitzien

[Verwijderd]

Worden jullie nou nooit moe van jezelf. Altijd als er iets nieuws uitkomt waarvan jullie het nut NOG niet inzien, dan krijg je altijd weer het 64k getrol. Wees blij dat ze "innoveren" en de technieken sneller "lijken" te ontwikkelen. Iets is NOOIT uit ontwikkeld, als je alleen dat al weet te onthouden dan kunnen dit soort nuttelose discussies vermeden worden.

[MadEgg]

Het probleem met dit soort ingrijpende wijzigingen is dat het jarenlange rompslomp met zich meebrengt. Zoals de overgangsfase van 32 bit naar 64 bit die we nu hebben; hoeveel software problemen komen daar wel niet uit voort. Zowel op Windows, als op Linux als op Mac OS X zijn er veel problemen omdat vele programma's nu in 2 versies gebouwd moeten worden en aangepast om te werken met 64 bits. Willen we datzelfde traject over 4 jaar weer beginnen terwijl we het de komende 20 jaar waarschijnlijk nog niet nodig hebben?

Volgens de optimistische Moore-wet van hierboven, elk jaar verdubbeling, kan je makkelijk rekenen: een verdubbeling is 1 bit meer, dus van 32 bits naar 64 bits kunnen we 32 jaar vooruit, van 64 bits naar 128 bits kunnen we weer eens 64 jaar vooruit. Aangezien we nog maar net de randjes van de 64-bits processoren aan het afsnoepen zijn, kunnen we nog minstens 30 jaar vooruit met 64-bits, waarna we dus nog eens 64 jaar bezig zijn om 128 bit te benutten.

Het voordeel in precisie is vrijwel niets en zeker niet nodig voor alles behalve de meest specialistische supercomputers.

Conclusie: laat die 128-bits nog maar eens even lekker in de kast staan, we hebben er toch niets aan.

[mrlammers]

De Wet van Moore stelt dat het aantal transistoren op een computerchip door de technologische vooruitgang elke 2 jaar verdubbelt.

Dat heeft dus niets te maken met registers of adresbussen.

Wanneer je de analoog zou willen trekken met de Wet van Moore, dan zal de tijd tussen 64 en 128 bits vele malen korter zal zijn dan de tijd tussen 8 en 32 bits.

In het begin hadden we 8 bits bussen en tot inde jaren 90 prevaleerden de 32-bits processoren. Laten we zeggen, ca. 25 jaar <=32-bits.
Vanaf die periode kwamer er 64-bits processoren. Als AMD ergens in 2011 128-bits processoren gaat produceren, dan hebben we minder dan 17 jaar met 64-bits processoren gedaan.
Het ligt dan in de lijn der verwachting dat er dan vervolgens binnen 9 jaar (in 2020 dus) een 256-bits processor op de markt ligt...

En hebben we dat dan nodig? Hmm.. nee, waarschijnlijk niet. Kan de markt ons dat dicteren? Ik denk het wel.

[Verwijderd]

Dit is echt wel geschift hoor. Vergelijk het met praten over 64-bit ondersteuning ten tijden van de 386, de eerste 32-bit processor van Intel, in 1985. 64-bit werd pas 20 jaar later nuttig. Aan hetzelfde tempo zal 128-bit pas over 40 jaar nuttig worden.

Voor Windows 8 al over 128-bit spreken is idioot. Windows bestond niet eens ten tijde van de 386...

64-bit kan nog extreem lang mee. Men zit zelfs zodanig dicht op de fysieke limiet van één atoom per bit dat het twijfelachtig is of men ooit meer dan 2^64 bytes kan opslaan.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:14]

[TheCapK]

De eerste 386 is van een wat latere datum. In 1985 waren het vooral 8086 CPU's die de boventoon voerden. Daar kwam tegen het eind van de 80-er jaren de 286 bij en begin jaren 90 kwam de 386. Er bestond toen ook al een Windows (3.11) en Windows 95 was ook niet zo ver meer weg. (Nee: de 95 sloeg niet helemaal op het jaartal)
Voor win8 spreken over 128 bit is niet per se idioot maar wel wat overdreven aangezien 64 bit nog steeds niet erg gemeengoed is geworden. De meeste PC's en Laptops die een 64 bit processor hebben worden vaak standaard met 32 bit besturingssysteem uitgerust.

[Verwijderd]

1985 werd de 80386DX geintroduceert, hierna kwamen de SX, dat er "vooral 8086" cpu's waren die de boventoon voeren is omdat alle software van die tijd er gemakkelijk op draaide en die processor destijds extreem duur en overbodig was, tegen de tijd dat we 32-bit software gingen benutten zaten we al rond eind 1992, en toen was de 80486DX2 al in de winkel en een half jaartje later kwam de pentium al om de hoek sjezen. De 8086 komt trouwens uit 1978. Er is een verschil tussen wat je in de winkel ziet en wat er te koop is, 8086XT's zijn t/m 1992 in de winkels blijven hangen hoor.

Meeste software, ook zakelijke draait op 32-bits omgevingen, nog steeds. Voordat windows XP64 en Vista op de markt kwamen waren 64-bits CPU's al een tijdje op de markt. Ik verwacht over 5 jaar een windows 8 op de markt, maar ik verwacht niet voor die tijd standaard pc's en notebooks met een of andere high-end 128-bits 16-corechip oid.

[Bor]

Windows bestond niet eens ten tijde van de 386..

De 80386 werd gemaakt vanaf 1985 als ik het goed heb. Uit hetzelfde jaar is Windows 1.0 Feitelijk heb je het onjuist.